| Summary: | b44 driver doesn't work reliably | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tyson Harding <tharding> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | major | CC: | masterdriverz |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| URL: | http://bugzilla.kernel.org/show_bug.cgi?id=7696 | ||
| Whiteboard: | watch-linux-bugzilla | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 145525 | ||
|
Description
Tyson Harding
2006-09-15 13:09:01 UTC
(In reply to comment #0) > I am experiencing problems receiving large amounts of data, I see > > b44: eth0: Link is down. > b44: eth0: Link is up at 100 Mbps, full duplex. > b44: eth0: Flow control is off for TX and off for RX. So let me get this straight, when you are receiving large amounts of data, those messages then appear in dmesg? How do they compare to the ones that appear when the connection is initially established? Also, please explain what the problems are exactly. (In reply to comment #1) > (In reply to comment #0) > > I am experiencing problems receiving large amounts of data, I see > > > > b44: eth0: Link is down. > > b44: eth0: Link is up at 100 Mbps, full duplex. > > b44: eth0: Flow control is off for TX and off for RX. > > So let me get this straight, when you are receiving large amounts of data, > those messages then appear in dmesg? How do they compare to the ones that > appear when the connection is initially established? Yes. It appears that when I receive large amounts of data the link goes down. The only difference between the messages during initial boot, is that the first message indicating the link is down does not show up. So at bootup/initial connection, I only see the second and third messages. > > Also, please explain what the problems are exactly. > I have a MythTV frontend installed on this computer with the broadcom controller. My backend is on another machine on my network, using a different network card. I setup these computers last January and originally used the driver in the kernel (I can't remember what kernel version it was back then). It was marked experimental, but I figured I would try it. When trying to watch something (live TV, or a recorded video) on the frontend, the video would pause for a second or two at a time. For each one of these pauses I would see the tree messages listed above in the output of dmesg. I then installed the bcm4400 package, and everything worked great, no pausing, and no messages in dmesg. At the end of August the bcm4400 packages was masked, and the comment in package.mask indicated the kernel driver was ready to be used, and was infact what was being provided by broadcom now, so I decided to give it a try. When I tried the kernel driver (2.6.17-r8) I saw the same problems as before, video would pause, and I would see the messages in dmesg. I then went out the broadcom's website and downloaded the latest version of the drivers 1.00g and tried those. I saw the same results. I then looked at some of the bugs listed on this site, and saw a request to try the latest development version of the kernel, so I tried it (2.6.18-rc7) and had the same results. I have since gone back to the bcm4400 drivers, and back to kernel 2.6.17-r8 and everything is working correctly. Please file a bug for this at http://bugzilla.kernel.org including "lspci -v" output. Explain clearly that the problem is that the driver thinks the link has gone down and then back up again when under load. We should be able to get the broadcom developers to look at this. Any news on this? I wouldn't want to drop it while there are still open bugs about the kernel driver... (In reply to comment #4) http://bugzilla.kernel.org/show_bug.cgi?id=3050 and http://bugzilla.kernel.org/show_bug.cgi?id=4566 are still open, so yes Those reports do not seem to be of the same problem. Tyson, any news? Sorry it took so long to respond, I posted a response two weeks ago, but it doesn't look like it worked, so it I go again. I too looked at those two bugs and they do not match what I was seeing. I have not submitted a bug report to kernel.org, I had previously submitted one directly to broadcom, and they were providing reasonable feedback. That has since stopped, and it appears that they have dropped the issue, and I am no longer getting any help. I have since given up and replaced this network interface, so I am no longer using this driver. I would be fine if this bug was closed, and do not see a large value in pursuing this issue as I seem to be the only one with this problem. It also only seems to effect large downloads, and is only a noticeable issue when what is being downloaded is real time content like streaming video. If the preference is to pursue a fix for this bug, I will submit the bug to kernel.org, but will not be able to do a large amount of testing as this is in a production machine now with the new network card. OK, don't worry about it for now. Charlie suffers from this bug and will file it upstream soon. I'm going to remove b44 sometime next week and Charlie (or another candidate) can file this upstream in their own time. Sorry I took so long filing the upstream bug. |
