Am I right in saying there has been substantial changes to the way in which hardware detected works in FC5? (I see from the release notes PCMCIA handling has changed and kudzu has been deprecated). I have prepared a report of my (not good) experience with a Thinkpad T41p, but right now there is very little hard data in there which can be used for debugging.
Any advice how to file a useful report about hardware that did work with FC4 and does not work with FC5?
Also: I was thinking about the testing of the install install process prior to the final release. Since many people cannot afford the space to have a spare partition for test releases (especially on laptops) and it is not possible to install to a USB drive, it would be useful to have some sort bootable live-CD with just enough software to test the hardware detection. Eg something like the Windows Device Explorer program. If I had something like that during the test phase I would have caught all these problems a long time ago. (I did all my testing in a virtual VMWare environment -- and it works great there!).
Joe.
On 3/26/06, Joe Desbonnet jdesbonnet@gmail.com wrote:
Am I right in saying there has been substantial changes to the way in which hardware detected works in FC5? (I see from the release notes PCMCIA handling has changed and kudzu has been deprecated). I have prepared a report of my (not good) experience with a Thinkpad T41p, but right now there is very little hard data in there which can be used for debugging.
What specifically are you talking about... general comments about "hardware not working" are difficult to respond to.
Any advice how to file a useful report about hardware that did work with FC4 and does not work with FC5?
First be specific as to which hardware you are concerned about and what specific funtionality you want other people to attempt to confirm on this list.
-jef
Thanks Jeff,
Perhaps the /etc/sysconfig/hwconf of the working FC4 vs the non-working FC5 installation might be useful? Anyhow here is a list of what I encountered installing FC5-i386 on a Thinkpad T41p:
1. During install and after install I no longer had use of my 3Com 3CRWE737A 802.11b PC Card (this worked with FC4,3,2,1). This card is handled by the orinoco dirver. Even force loading the driver did not bring this card to life. I do not think it is a kernel issue -- a grep of "3CRWE737A" on orinoco_cs.ko demonstrates that support for this card is still in the kernel. The /etc/sysconfig/hwconf entry from FC4 reads: class: NETWORK bus: PCMCIA detached: 0 device: eth2 driver: orinoco_cs desc: "3Com 3CRWE737A AirConnect Wireless LAN PC Card" vendorId: 0101 deviceId: 0001 function: 0 slot: 0
2. After FC5 install I no longer have use of my built in bluetooth device.
3. After a few reboots I lose things like battery gauge (/proc/acpi/battery directory gone!). This seems to correspond to kudzu related errors on boot. I'm sorry -- I didn't capture the exact text of the error at the time. I encountered this type of problem before where kudzu failed at boot time and made a mess things. I can reinstall FC5 and get that error message if it is going to be useful.
4. Suspend does not work (no surprise there). Blank flickering LCD screen on restore. This never worked, so I'm not too concerned about it.
5. Not a Thinkpad issue per se: When installing FC5Test3 on VMWare the BusLogic module had to be manually loaded. This was not required during the FC4 install -- it was autodetected there. At the time I thought that was a VMWare issue, now I suspect otherwise...
Joe.
On Sun, 2006-03-26 at 19:37 +0100, Joe Desbonnet wrote:
- After FC5 install I no longer have use of my built in bluetooth device.
The updates-testing selinux policy should be happier for bluetooth devices.
- After a few reboots I lose things like battery gauge
(/proc/acpi/battery directory gone!). This seems to correspond to kudzu related errors on boot. I'm sorry -- I didn't capture the exact text of the error at the time. I encountered this type of problem before where kudzu failed at boot time and made a mess things. I can reinstall FC5 and get that error message if it is going to be useful.
That's ... interesting. Definitely haven't seen anything like that.
- Suspend does not work (no surprise there). Blank flickering LCD
screen on restore. This never worked, so I'm not too concerned about it.
You might find that acpi_sleep=s3_bios on the kernel command line might fix this.
- Not a Thinkpad issue per se: When installing FC5Test3 on VMWare
the BusLogic module had to be manually loaded. This was not required during the FC4 install -- it was autodetected there. At the time I thought that was a VMWare issue, now I suspect otherwise...
The BusLogic module doesn't export PCI ids it supports and is pretty much unmaintained upstream. VMWare can also be configured to have a virtual mptfusion scsi instead, which will work much better.
Jeremy
Joe Desbonnet (jdesbonnet@gmail.com) said:
- During install and after install I no longer had use of my 3Com
3CRWE737A 802.11b PC Card (this worked with FC4,3,2,1). This card is handled by the orinoco dirver. Even force loading the driver did not bring this card to life. I do not think it is a kernel issue -- a grep of "3CRWE737A" on orinoco_cs.ko demonstrates that support for this card is still in the kernel. The /etc/sysconfig/hwconf entry from FC4 reads: class: NETWORK bus: PCMCIA detached: 0 device: eth2 driver: orinoco_cs desc: "3Com 3CRWE737A AirConnect Wireless LAN PC Card" vendorId: 0101 deviceId: 0001 function: 0 slot: 0
Try either:
blacklist hostap_cs
or
blacklist orinoco_cs
in /etc/modprobe.d/blacklist.
That may fix things.
- After a few reboots I lose things like battery gauge
(/proc/acpi/battery directory gone!). This seems to correspond to kudzu related errors on boot. I'm sorry -- I didn't capture the exact text of the error at the time. I encountered this type of problem before where kudzu failed at boot time and made a mess things. I can reinstall FC5 and get that error message if it is going to be useful.
That really doesn't make sense... nothing kudzu does would cause ACPI modules to not get loaded.
Bill
I haven't tracked this down fully, but the kudzu error seems related to /lib/modules/(kernel-version)/modules.dep being reduced to a zero byte file (I don't know that caused that).
With the zero byte modules.dep file kudzu segfaults.
Joe.
- After a few reboots I lose things like battery gauge
(/proc/acpi/battery directory gone!). This seems to correspond to kudzu related errors on boot. I'm sorry -- I didn't capture the exact text of the error at the time. I encountered this type of problem before where kudzu failed at boot time and made a mess things. I can reinstall FC5 and get that error message if it is going to be useful.
That really doesn't make sense... nothing kudzu does would cause ACPI modules to not get loaded.
Bill
Joe Desbonnet (jdesbonnet@gmail.com) said:
I haven't tracked this down fully, but the kudzu error seems related to /lib/modules/(kernel-version)/modules.dep being reduced to a zero byte file (I don't know that caused that).
With the zero byte modules.dep file kudzu segfaults.
Hm, ok, will look at fixing that. That would also break modprobe of many things, but that's unrelated to kudzu breaking.
Bill
Bill Nottingham (notting@redhat.com) said:
Joe Desbonnet (jdesbonnet@gmail.com) said:
I haven't tracked this down fully, but the kudzu error seems related to /lib/modules/(kernel-version)/modules.dep being reduced to a zero byte file (I don't know that caused that).
With the zero byte modules.dep file kudzu segfaults.
Hm, ok, will look at fixing that.
Fixed in CVS. Won't help modprobe, though.
Bill
On Sun, 2006-03-26 at 19:37 +0100, Joe Desbonnet wrote:
- After FC5 install I no longer have use of my built in bluetooth device.
If the selinux policy update Jeremy suggested doesn't fix it, make sure it's actually enabled in acpi. There are a couple of things to check: the "status" value in /proc/acpi/ibm/bluetooth and the output of lsusb would be good places to start.
Thanks for the help -- it appears to be a SELinux thing alright. It works when SELinux is disabled. I am starting to see lots of light at the end of this FC5 upgrade tunnel now. Joe.
On 3/29/06, Peter Jones pjones@redhat.com wrote:
On Sun, 2006-03-26 at 19:37 +0100, Joe Desbonnet wrote:
- After FC5 install I no longer have use of my built in bluetooth device.
If the selinux policy update Jeremy suggested doesn't fix it, make sure it's actually enabled in acpi. There are a couple of things to check: the "status" value in /proc/acpi/ibm/bluetooth and the output of lsusb would be good places to start.
-- Peter
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sun, 2006-03-26 at 18:19 +0100, Joe Desbonnet wrote:
Am I right in saying there has been substantial changes to the way in which hardware detected works in FC5? (I see from the release notes PCMCIA handling has changed and kudzu has been deprecated). I have prepared a report of my (not good) experience with a Thinkpad T41p, but right now there is very little hard data in there which can be used for debugging.
Any advice how to file a useful report about hardware that did work with FC4 and does not work with FC5?
For PCMCIA cards that don't appear to work, be _sure_ to include the output of 'pccardctl info' and 'pccardctl ident'. 2.6.15 and 2.6.16 changed the way that PCMCIA drivers get bound to particular hardware instances, which may be what you're running into. The output of those commands can help determine what driver should be binding to your cards.
Also, if you happen to remember the driver that got bound to the card in previous FC versions, that's helpful as well. Stick all this into the bug report.
Dan
devel@lists.stg.fedoraproject.org
-
Bill Nottingham -
Dan Williams -
Jef Spaleta -
Jeremy Katz -
Joe Desbonnet -
Peter Jones