Re: [stable] Wanted: Allow adding new device IDs during the -stable cycle
On Tue, 2007-05-22 at 15:17 -0700, Greg KH wrote: > > > > Theres more to this than just PCI IDs though. > > ac97 ID updates, usb id updates, etc, etc. > > USB ids also can be added through sysfs :) > FWIW, With the asix.c driver, you can't just add the USB IDs and have it work. Each ID also needs to be told which driver structure to use, since the driver itself supports three similar, but distinct chips. Adding the IDs to the driver itself is naturally trivial, but adding via sysfs or the like doesn't work. I would imagine that there are other drivers that operate quite similarly. -- David Hollis <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] Wanted: Allow adding new device IDs during the -stable cycle
On Tue, 2007-05-22 at 15:17 -0700, Greg KH wrote: Theres more to this than just PCI IDs though. ac97 ID updates, usb id updates, etc, etc. USB ids also can be added through sysfs :) FWIW, With the asix.c driver, you can't just add the USB IDs and have it work. Each ID also needs to be told which driver structure to use, since the driver itself supports three similar, but distinct chips. Adding the IDs to the driver itself is naturally trivial, but adding via sysfs or the like doesn't work. I would imagine that there are other drivers that operate quite similarly. -- David Hollis [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unidentified Intel wifi network card
On Wed, 2007-01-31 at 11:30 -0600, Scott Lockwood wrote: > I'm looking for assistance with a wifi device I can't find a driver for, > the Intel Wireless 3945. > > I"m getting this: > > :0c:00.0 Network controller: Intel Corporation: Unknown device 4222 > (rev 02) > > on a new Dell Latitude D820. Anyone know if there will be an open source > driver for this any time soon, or if there is one now? > > I'm using the latest vendor supplied kernel, so my apologies if this has > already been done and I'm late to the party. I wasn't able to find much, > other than 'use the NDIS wrapper' which I really don't want to do. http://ipw3945.sf.net http://ieee80211.sf.net -- David Hollis <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
On Tue, 2007-01-30 at 17:41 -0500, Jeff Garzik wrote: > > I think this is a quite fair criticism, and I would love to see > someone > step up and help with this sort of organization. > > For example, I didn't know that XGI graphics specs were available at > all, otherwise it might have been something fun to tackle Just to pony up my experience in all of this, which I think is probably quite representative of many other drivers: A bunch of years ago I picked up a USB Ethernet device at the store because it seemed really cool and I hoped it worked under Linux. Turns out that it didn't. I had never written a kernel driver before, and dealing with USB was an alien concept to me. I searched around and found that FreeBSD had a driver and I tried to use that in combination with other USB Ethernet drivers in the kernel as reference to get something working. There was a basic spec sheet from the vendor, but a lot of detail was missing and for someone who was new to spec sheets and such, it wasn't much of a source. I wound up coming across a driver that Tivo had written for the device so I started working to hammer that into shape to be added to the kernel. The driver was quite a mess and had a lot of issues and took a good amount of work, but eventually I was able to get it to give me basic operation. As I published updates and such, I found that there were a lot of folks that were wanting these devices to work. I eventually was contacted by the manufacturer to add support to their newer chips and they even provided some code to make the devices work. The code was not suitable for inclusion because it was circuitous, spaghetti, impossible to understand, brute-force style code that just could not be maintained (which I think is quite common with vendor drivers, and really makes me shudder when I think of what the code behind many Windows drivers must look like). I kept hammering on the code to get it to be understandable and modular and got it sent upstream. For one of the chips, it wound up taking a lot longer than I had hoped, mainly due to a lack of time on my end and lack of interest from the community - I wasn't seeing much of a 'Hey, can we get this chip working?' so it seemed that the devices weren't out there in many hands. At this point, the driver supports 19 devices and seems to work quite well on x86 and x86_64, but big-endian systems seem to show some issues which are being worked out. The endian-issues drive me mad since I don't have access to any big-endian systems and have little experience with it but I'm determined to get them resolved. For a vendor, they likely would care less if it doesn't work on big-endian. If it works on Windows, that's all that matters. The driver has been upstream for 3+ years or so and is included in all distros that I'm aware of so for most people, they can go out to BestBuy, buy the device and plug it into their Linux box and it just works, and that is what we all want in the end. Conversely, I've seen many cases of drivers that are developed by the community, but kept out-of-kernel forever due to various reasons. Some of them are due to the code quality and the developers not accepting the feedback to get the drivers into shape to be 'kernel worthy', sometimes it seems to be a lack of interest from the developers to merge upstream. Maybe because they think they would lose control or something? Sometimes it may just be that they don't realize that they can do that. Thankfully, these tend to be somewhat fringe devices though all would benefit at their being upstream to make everyones lives easier. -- David Hollis <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Free Linux Driver Development!
On Tue, 2007-01-30 at 17:41 -0500, Jeff Garzik wrote: I think this is a quite fair criticism, and I would love to see someone step up and help with this sort of organization. For example, I didn't know that XGI graphics specs were available at all, otherwise it might have been something fun to tackle Just to pony up my experience in all of this, which I think is probably quite representative of many other drivers: A bunch of years ago I picked up a USB Ethernet device at the store because it seemed really cool and I hoped it worked under Linux. Turns out that it didn't. I had never written a kernel driver before, and dealing with USB was an alien concept to me. I searched around and found that FreeBSD had a driver and I tried to use that in combination with other USB Ethernet drivers in the kernel as reference to get something working. There was a basic spec sheet from the vendor, but a lot of detail was missing and for someone who was new to spec sheets and such, it wasn't much of a source. I wound up coming across a driver that Tivo had written for the device so I started working to hammer that into shape to be added to the kernel. The driver was quite a mess and had a lot of issues and took a good amount of work, but eventually I was able to get it to give me basic operation. As I published updates and such, I found that there were a lot of folks that were wanting these devices to work. I eventually was contacted by the manufacturer to add support to their newer chips and they even provided some code to make the devices work. The code was not suitable for inclusion because it was circuitous, spaghetti, impossible to understand, brute-force style code that just could not be maintained (which I think is quite common with vendor drivers, and really makes me shudder when I think of what the code behind many Windows drivers must look like). I kept hammering on the code to get it to be understandable and modular and got it sent upstream. For one of the chips, it wound up taking a lot longer than I had hoped, mainly due to a lack of time on my end and lack of interest from the community - I wasn't seeing much of a 'Hey, can we get this chip working?' so it seemed that the devices weren't out there in many hands. At this point, the driver supports 19 devices and seems to work quite well on x86 and x86_64, but big-endian systems seem to show some issues which are being worked out. The endian-issues drive me mad since I don't have access to any big-endian systems and have little experience with it but I'm determined to get them resolved. For a vendor, they likely would care less if it doesn't work on big-endian. If it works on Windows, that's all that matters. The driver has been upstream for 3+ years or so and is included in all distros that I'm aware of so for most people, they can go out to BestBuy, buy the device and plug it into their Linux box and it just works, and that is what we all want in the end. Conversely, I've seen many cases of drivers that are developed by the community, but kept out-of-kernel forever due to various reasons. Some of them are due to the code quality and the developers not accepting the feedback to get the drivers into shape to be 'kernel worthy', sometimes it seems to be a lack of interest from the developers to merge upstream. Maybe because they think they would lose control or something? Sometimes it may just be that they don't realize that they can do that. Thankfully, these tend to be somewhat fringe devices though all would benefit at their being upstream to make everyones lives easier. -- David Hollis [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unidentified Intel wifi network card
On Wed, 2007-01-31 at 11:30 -0600, Scott Lockwood wrote: I'm looking for assistance with a wifi device I can't find a driver for, the Intel Wireless 3945. Im getting this: :0c:00.0 Network controller: Intel Corporation: Unknown device 4222 (rev 02) on a new Dell Latitude D820. Anyone know if there will be an open source driver for this any time soon, or if there is one now? I'm using the latest vendor supplied kernel, so my apologies if this has already been done and I'm late to the party. I wasn't able to find much, other than 'use the NDIS wrapper' which I really don't want to do. http://ipw3945.sf.net http://ieee80211.sf.net -- David Hollis [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc4-mm1 USB (asix) problem
On Tue, 2007-01-16 at 17:59 -0500, Eric Buddington wrote: > On Mon, Jan 15, 2007 at 08:32:17PM +0000, David Hollis wrote: > > Interesting. It would really be something if your devices happen to > > work better with 0. Wouldn't make much sense at all unfortunately. If > > 0 works, could you also try setting it to 2 or 3? The PHY select value > > is a bit field with the 0 bit being to select the onboard PHY, and 1 bit > > being to 'auto-select' the PHY based on link status. The data sheet > > indicates that 3 should be the default, but all of the literature I have > > seen from ASIX says to write a 1 to it. > > My hardware is ver. B1. > > 0, 2, and 3 all worked for me. 1, as before, does not. > That's good to hear. Some other patches have started floating around to deal with these cases of internal vs. external PHY's and also seem to work. > 'rmmod asix' takes a really long time (45-80s) with any setting, and > sometimes coincides with ksoftirqd pegging (99.9% CPU) for several > seconds. This I haven't seen before. Does it occur even when the device is able to work (using 0 or the like from above)? This may be due to something else in the USB subsystem or something. -- David Hollis <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc4-mm1 USB (asix) problem
On Tue, 2007-01-16 at 17:59 -0500, Eric Buddington wrote: On Mon, Jan 15, 2007 at 08:32:17PM +, David Hollis wrote: Interesting. It would really be something if your devices happen to work better with 0. Wouldn't make much sense at all unfortunately. If 0 works, could you also try setting it to 2 or 3? The PHY select value is a bit field with the 0 bit being to select the onboard PHY, and 1 bit being to 'auto-select' the PHY based on link status. The data sheet indicates that 3 should be the default, but all of the literature I have seen from ASIX says to write a 1 to it. My hardware is ver. B1. 0, 2, and 3 all worked for me. 1, as before, does not. That's good to hear. Some other patches have started floating around to deal with these cases of internal vs. external PHY's and also seem to work. 'rmmod asix' takes a really long time (45-80s) with any setting, and sometimes coincides with ksoftirqd pegging (99.9% CPU) for several seconds. This I haven't seen before. Does it occur even when the device is able to work (using 0 or the like from above)? This may be due to something else in the USB subsystem or something. -- David Hollis [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc4-mm1 USB (asix) problem
On Mon, 2007-01-15 at 14:50 -0500, Eric Buddington wrote: > The asix_write_cmd argument in question did indeed change from 0 to 1 > between 2.6.20-rc3-mm1 and -rc4-mm1. I'll change it back, rebuild, > and test. Probably tomorrow. > Interesting. It would really be something if your devices happen to work better with 0. Wouldn't make much sense at all unfortunately. If 0 works, could you also try setting it to 2 or 3? The PHY select value is a bit field with the 0 bit being to select the onboard PHY, and 1 bit being to 'auto-select' the PHY based on link status. The data sheet indicates that 3 should be the default, but all of the literature I have seen from ASIX says to write a 1 to it. And FWIW, that change for setting it to 1 fixed a bunch of broken adapters, including mine. -- David Hollis <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc4-mm1 USB (asix) problem
On Sat, 2007-01-13 at 15:31 -0500, Eric Buddington wrote:
> The following problem occured on an Athlon64 X2 under 2.6.20-rc4-mm1,
> but not 2.6.20-rc3-mm1.
>
> I'm using two D-Link DUB-E100 USB ethernet adapters, using the 'asix'
> driver. When I upgraded to 2.6.20-rc4-mm1, they were still recognized,
> but various ifconfig operations on them (up/down, changing IP) caused
> a system freeze (including caps lock/num lock lights) for many seconds.
> I do not believe there was anything new in dmesg when the system
> resumed. USB debugging was not turned on at the time, though the
> problem is repeatable.
>
> Also, no packets actually made it out of the adapters (watching from
> other systems on the network).
>
> Since this is a system we need running and networked, I can't do
> extensive testing on it, but I might be to bring it down for a few
> quick tests if that would help.
Do you happen to have a Rev. B1 DLink adapter? If so, the only change
that was put in (PHY Select fix) should actually make these devices
work. Can you check the top of the ax88772_bind() call in your file and
see if it has this bit:
if ((ret = asix_write_cmd(dev, AX_CMD_SW_PHY_SELECT,
1, 0, 0, buf)) < 0) {
dbg("Select PHY #1 failed: %d", ret);
goto out2;
}
That '1' after the AX_CMD_SW_PHY_SELECT was the key to that patch. If
yours is 1, you could try setting it to 0, though that should make
things not work. I'd very interested if it made things work for you.
BTW, the ramifications of this bug were similar to what you describe:
the interface would come up, look fine but just wouldn't send or receive
any packets. The hard lock-ups and such are likely from something else.
--
David Hollis <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc4-mm1 USB (asix) problem
On Sat, 2007-01-13 at 15:31 -0500, Eric Buddington wrote:
The following problem occured on an Athlon64 X2 under 2.6.20-rc4-mm1,
but not 2.6.20-rc3-mm1.
I'm using two D-Link DUB-E100 USB ethernet adapters, using the 'asix'
driver. When I upgraded to 2.6.20-rc4-mm1, they were still recognized,
but various ifconfig operations on them (up/down, changing IP) caused
a system freeze (including caps lock/num lock lights) for many seconds.
I do not believe there was anything new in dmesg when the system
resumed. USB debugging was not turned on at the time, though the
problem is repeatable.
Also, no packets actually made it out of the adapters (watching from
other systems on the network).
Since this is a system we need running and networked, I can't do
extensive testing on it, but I might be to bring it down for a few
quick tests if that would help.
Do you happen to have a Rev. B1 DLink adapter? If so, the only change
that was put in (PHY Select fix) should actually make these devices
work. Can you check the top of the ax88772_bind() call in your file and
see if it has this bit:
if ((ret = asix_write_cmd(dev, AX_CMD_SW_PHY_SELECT,
1, 0, 0, buf)) 0) {
dbg(Select PHY #1 failed: %d, ret);
goto out2;
}
That '1' after the AX_CMD_SW_PHY_SELECT was the key to that patch. If
yours is 1, you could try setting it to 0, though that should make
things not work. I'd very interested if it made things work for you.
BTW, the ramifications of this bug were similar to what you describe:
the interface would come up, look fine but just wouldn't send or receive
any packets. The hard lock-ups and such are likely from something else.
--
David Hollis [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc4-mm1 USB (asix) problem
On Mon, 2007-01-15 at 14:50 -0500, Eric Buddington wrote: The asix_write_cmd argument in question did indeed change from 0 to 1 between 2.6.20-rc3-mm1 and -rc4-mm1. I'll change it back, rebuild, and test. Probably tomorrow. Interesting. It would really be something if your devices happen to work better with 0. Wouldn't make much sense at all unfortunately. If 0 works, could you also try setting it to 2 or 3? The PHY select value is a bit field with the 0 bit being to select the onboard PHY, and 1 bit being to 'auto-select' the PHY based on link status. The data sheet indicates that 3 should be the default, but all of the literature I have seen from ASIX says to write a 1 to it. And FWIW, that change for setting it to 1 fixed a bunch of broken adapters, including mine. -- David Hollis [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.13 : __check_region is deprecated
On Tue, 2005-08-30 at 01:55 +0200, Diego Calleja wrote: > El Tue, 30 Aug 2005 01:34:25 +0200, > Jesper Juhl <[EMAIL PROTECTED]> escribió: > > > I don't see why we should break a bunch of drivers by doing that. > > Much better, in my oppinion, to fix the few remaining drivers still > > using check_region and *then* kill it. Even unmaintained drivers may > > I'd usually agree with you, but check_region has been deprecated for so many > time; I was just wondering myself if people will bother to fix the remaining > drivers without some "incentive" Shouldn't it be (or have been) added to the Documentation/feature-removal-schedule.txt then so it could be deprecated and removed through the proper mechanisms. -- David Hollis <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Linux-2.6.13 : __check_region is deprecated
On Tue, 2005-08-30 at 01:55 +0200, Diego Calleja wrote: El Tue, 30 Aug 2005 01:34:25 +0200, Jesper Juhl [EMAIL PROTECTED] escribió: I don't see why we should break a bunch of drivers by doing that. Much better, in my oppinion, to fix the few remaining drivers still using check_region and *then* kill it. Even unmaintained drivers may I'd usually agree with you, but check_region has been deprecated for so many time; I was just wondering myself if people will bother to fix the remaining drivers without some incentive Shouldn't it be (or have been) added to the Documentation/feature-removal-schedule.txt then so it could be deprecated and removed through the proper mechanisms. -- David Hollis [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: confguring grub to load new kernel
On Thu, 2005-01-27 at 01:01 -0500, [EMAIL PROTECTED] wrote: > Hi, > > I just compiled kernel 2.6.10 and now wondering how to make the grub to > load the newkernel. > > The grub.conf file is configured as: > > #boot=/dev/hda > default=1 > timeout=10 > splashimage=(hd0,5)/boot/grub/splash.xpm.gz > title Red Hat Linux (2.4.20-8) > root (hd0,5) > kernel /boot/vmlinuz-2.4.20-8 ro root=LABEL=/ > initrd /boot/initrd-2.4.20-8.img > title DOS > rootnoverify (hd0,0) > chainloader +1 > > > How should I change the configuration? Upgrade your modutils to the one from Fedora Core 2. It supports the 2.6 modules as well as 2.4 so you are covered in either case. FC3 now uses module-init-tools which only works with 2.6. You should be able to just run a 'make install' which will use /sbin/installkernel to setup the proper files in /boot. The Fedora kernel RPMS use this kind of statement to add the entries to grub: [ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --package kernel -- mkinitrd --depmod --install 2.6.10-1.741_FC3 Should work for you as well with no issues. -- David Hollis <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: confguring grub to load new kernel
On Thu, 2005-01-27 at 01:01 -0500, [EMAIL PROTECTED] wrote: Hi, I just compiled kernel 2.6.10 and now wondering how to make the grub to load the newkernel. The grub.conf file is configured as: #boot=/dev/hda default=1 timeout=10 splashimage=(hd0,5)/boot/grub/splash.xpm.gz title Red Hat Linux (2.4.20-8) root (hd0,5) kernel /boot/vmlinuz-2.4.20-8 ro root=LABEL=/ initrd /boot/initrd-2.4.20-8.img title DOS rootnoverify (hd0,0) chainloader +1 How should I change the configuration? Upgrade your modutils to the one from Fedora Core 2. It supports the 2.6 modules as well as 2.4 so you are covered in either case. FC3 now uses module-init-tools which only works with 2.6. You should be able to just run a 'make install' which will use /sbin/installkernel to setup the proper files in /boot. The Fedora kernel RPMS use this kind of statement to add the entries to grub: [ -x /sbin/new-kernel-pkg ] /sbin/new-kernel-pkg --package kernel -- mkinitrd --depmod --install 2.6.10-1.741_FC3 Should work for you as well with no issues. -- David Hollis [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
