dm9601 driver won't init device properly
in [Kernel]
|
Prev: [PATCH] of: remove of_default_bus_ids
Next: [PATCH] PCI: Do not run NVidia quirks related to MSI with MSI disabled
From: Bob Tracy on 23 Jul 2010 16:20 On Fri, Jul 23, 2010 at 02:57:36PM -0500, Bob Tracy wrote: > (...) > Jul 23 13:57:26 no1nozit kernel: [ 1182.910095] eth2: register 'dm9601' at usb-0000:00:1d.0-2, Davicom DM9601 USB Ethernet, 04:00:06:04:06:e0 > (...) > ... the reported MAC address may not be correct -- I need to check > against the value reported for WinXP... As suspected, the Linux driver is reporting a bogus value. The correct MAC address is 00:06:06:e0:00:1a. Perhaps this is a useful clue as to what's going on. --Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Valdis.Kletnieks on 24 Jul 2010 10:50 On Fri, 23 Jul 2010 14:57:36 CDT, Bob Tracy said: > I've got one of the inexpensive Davicom DM9601 USB to fast Ethernet > devices, commonly available on eBay for under $10 including shipping. > It works fairly well in a WinXP environment with a MTU of 1000: 1500 > and 1492 are confirmed not working, and values between 1000 and 1492 > have not been tested at this point. Wow. An "ethernet" card that won't do an MTU of 1500 even under Windows. May I add this to my gallery of examples I use when people say "no vendor could *possibly* ship hardware that fscked up"? :)
From: Chris Fowler on 24 Jul 2010 11:50 On Sat, 2010-07-24 at 10:44 -0400, Valdis.Kletnieks(a)vt.edu wrote: > Wow. An "ethernet" card that won't do an MTU of 1500 even under > Windows. May I > add this to my gallery of examples I use when people say "no vendor > could > *possibly* ship hardware that fscked up"? :) A lot of these "cards" are not meant for you and I. They are meant for casual desktop users that would never put any amount of load on them. About 6 years ago we needed some PCMCIA modem cards and bought 100 of them from a vendor for $25/ea. They started failing in the field. When calling they just could not sync up. Only a reboot could fix the problem. What we learned was that a combination of heat and other factors caused them to drift so much the timing was off. We replaced those in the field with Zoom 3075 at about $65/ea. These modems were not meant for our solution. They were meant for casual laptop users that needed to dial an ISP every so often. I was expecting them to work in a box that would stay up 24x7. They couldn't handle it. I wrote a perl program that used a TLS-4 simulator and would dial the modem constantly. The failures were too much. On the Zooms we would average 10 failures per 1000 calls. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bob Tracy on 24 Jul 2010 12:50
On Sat, Jul 24, 2010 at 10:44:41AM -0400, Valdis.Kletnieks(a)vt.edu wrote: > On Fri, 23 Jul 2010 14:57:36 CDT, Bob Tracy said: > > I've got one of the inexpensive Davicom DM9601 USB to fast Ethernet > > devices, commonly available on eBay for under $10 including shipping. > > It works fairly well in a WinXP environment with a MTU of 1000: 1500 > > and 1492 are confirmed not working, and values between 1000 and 1492 > > have not been tested at this point. > > Wow. An "ethernet" card that won't do an MTU of 1500 even under Windows. May I > add this to my gallery of examples I use when people say "no vendor could > *possibly* ship hardware that fscked up"? :) You may :-), although I wouldn't assume the Windows driver is blameless. At 100 Mbit/s, flow-control simply has to work if the device is USB 1.1. According to the data sheet, there's a total of 16 kB of on-chip SRAM available for buffering (oddly enough, the documentation indicates the device *could* support up to 64 kB of SRAM). Gotta shovel out that stall quickly, and I suspect using a smaller MTU is simply giving an inefficient driver more time to do that. If I don't get tired of messing around with this adapter, I may experiment a little to see what happens when I lock the interface speed at 10 Mbit/s (instead of letting it auto-sense). Another respondent said MTU >= 1280 is required for IPv6, so I gave that a try just to see if the floor could be raised a bit above 1000. For what it's worth, 1280 works. --Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |