Bug#350235: pcmciautils ?
Hi,
I've had exactly the same problem when I started playing with
pcmciautils a few days ago. The latest version of pcmcia-cs (3.2.8-6)
depends on pcmciautils, so I'm afraid this package might have
triggered the problem in the original report too. (But it also solved
an issue I had with my prism54 wifi card.)
I've tried to follow some of the suggestions so here are my results.
Without any modifications, I did this while CPU usage was close to 100%:
udevinfo -a -p /block/hde hdebad
The after reboot (because I had a kernel oops when trying pccardctl
eject 1. See below.) I removed the link to z20_persistent.rules and
did:
udevinfo -a -p /block/hde hdegood
Then:
diff -u hdebad hdegood
--- hdebad 2006-01-29 09:35:06.0 +0100
+++ hdegood 2006-01-29 09:44:08.0 +0100
@@ -8,7 +8,7 @@
looking at device '/block/hde':
KERNEL==hde
SUBSYSTEM==block
-SYSFS{stat}==1578 122522424119120
00001191211912
+SYSFS{stat}== 20 16 230
0000 23 23
SYSFS{size}==15680
SYSFS{removable}==1
SYSFS{range}==64
I have no idea if this can help or not fixing the bug. udevinfo -a -p
/block/hde/hde1 returns nothing interesting in the first case.
Below is the OOPS I got, in case it might help. Some messages were
probably generated while I was trying to halt the machine.
didit
Jan 29 09:35:20 MyMachine kernel: hde:5pccard: card ejected from slot 1
Jan 29 09:35:20 MyMachine kernel: Unable to handle kernel paging
request at virtual address 00070142
Jan 29 09:35:20 MyMachine kernel: printing eip:
Jan 29 09:35:20 MyMachine kernel: c019c332
Jan 29 09:35:20 MyMachine kernel: *pde =
Jan 29 09:35:20 MyMachine kernel: Oops: 0002 [#1]
Jan 29 09:35:20 MyMachine kernel: Modules linked in: ide_cs radeon drm
binfmt_misc ipv6 thermal fan button processor ac battery eeprom lm9
0 cpufreq_userspace p4_clockmod speedstep_lib freq_table prism54
pcmcia firmware_class usbhid ohci1394 ieee1394 yenta_socket
rsrc_nonstati
c pcmcia_core joydev snd_intel8x0m snd_intel8x0 snd_ac97_codec
snd_ac97_bus snd_pcm_oss snd_mixer_oss 8139cp 8139too mii psmouse
snd_pcm s
nd_timer intel_agp snd serio_raw ide_cd cdrom soundcore uhci_hcd
agpgart shpchp pci_hotplug snd_page_alloc usbcore i2c_i801 i2c_core
ext3
jbd mbcache generic ide_disk ide_generic piix ide_core evdev mousedev
Jan 29 09:35:20 MyMachine kernel: CPU:0
Jan 29 09:35:20 MyMachine kernel: EIP:0060:[as_add_arq_hash+71/84]
Not tainted VLI
Jan 29 09:35:20 MyMachine kernel: EFLAGS: 00210007 (2.6.15-1-686)
Jan 29 09:35:20 MyMachine kernel: EIP is at as_add_arq_hash+0x47/0x54
Jan 29 09:35:20 MyMachine kernel: eax: df3b8138 ebx: c1719d08 ecx:
0007013e edx: c1719d28
Jan 29 09:35:20 MyMachine kernel: esi: c167a0c4 edi: c1719d08 ebp:
de141380 esp: d4803b20
Jan 29 09:35:20 MyMachine kernel: ds: 007b es: 007b ss: 0068
Jan 29 09:35:20 MyMachine kernel: Process vol_id (pid: 11126,
threadinfo=d4802000 task=d9264550)
Jan 29 09:35:20 MyMachine kernel: Stack: 0001 c019d54e de141380
c1719d08 0001 0001 c171a07c
Jan 29 09:35:20 MyMachine kernel:c167a0c4 0003 c167a0c4
c0196977 c167a0c4 c171a07c c171a07c 0008
Jan 29 09:35:20 MyMachine kernel:0008 c0199710 c167a0c4
c171a07c 0003
Jan 29 09:35:20 MyMachine kernel: Call Trace:
Jan 29 09:35:20 MyMachine kernel: [as_add_request+184/408]
as_add_request+0xb8/0x198
Jan 29 09:35:20 MyMachine kernel: [__elv_add_request+220/297]
__elv_add_request+0xdc/0x129
Jan 29 09:35:20 MyMachine kernel: [__make_request+1057/1104]
__make_request+0x421/0x450
Jan 29 09:35:20 MyMachine kernel: [generic_make_request+236/254]
generic_make_request+0xec/0xfe
Jan 29 09:35:20 MyMachine kernel: [mempool_alloc+33/153]
mempool_alloc+0x21/0x99
Jan 29 09:35:20 MyMachine kernel: [submit_bio+165/170] submit_bio+0xa5/0xaa
Jan 29 09:35:20 MyMachine kernel: [bio_alloc+19/34] bio_alloc+0x13/0x22
Jan 29 09:35:20 MyMachine kernel: [submit_bh+274/307] submit_bh+0x112/0x133
Jan 29 09:35:20 MyMachine kernel: [block_read_full_page+595/617]
block_read_full_page+0x253/0x269
Jan 29 09:35:20 MyMachine kernel: [radix_tree_insert+102/249]
radix_tree_insert+0x66/0xf9
Jan 29 09:35:20 MyMachine kernel: [add_to_page_cache_lru+24/45]
add_to_page_cache_lru+0x18/0x2d
Jan 29 09:35:20 MyMachine kernel: [add_to_page_cache_lru+40/45]
add_to_page_cache_lru+0x28/0x2d
Jan 29 09:35:20 MyMachine kernel: [read_cache_page+124/271]
read_cache_page+0x7c/0x10f
Jan 29 09:35:20 MyMachine kernel: [blkdev_get_block+0/77]
blkdev_get_block+0x0/0x4d
Jan 29 09:35:20 MyMachine kernel: [read_dev_sector+50/132]
read_dev_sector+0x32/0x84
Jan 29 09:35:20 MyMachine kernel: [blkdev_readpage+0/21]
blkdev_readpage+0x0/0x15
Jan 29 09:35:20 MyMachine kernel: [adfspart_check_ICS+24/286]
adfspart_check_ICS+0x18/0x11e
Jan 29 09:35:20 MyMachine kernel:
Bug#350235: pcmciautils ?
On Jan 29, di dit [EMAIL PROTECTED] wrote: I have no idea if this can help or not fixing the bug. udevinfo -a -p /block/hde/hde1 returns nothing interesting in the first case. I still need the data. Below is the OOPS I got, in case it might help. Some messages were You should open a kernel bug about this. -- ciao, Marco signature.asc Description: Digital signature
Bug#350235: pcmciautils ?
2006/1/29, Marco d'Itri [EMAIL PROTECTED]:
On Jan 29, di dit [EMAIL PROTECTED] wrote:
I have no idea if this can help or not fixing the bug. udevinfo -a -p
/block/hde/hde1 returns nothing interesting in the first case.
I still need the data.
Here it is. In the first case (when the CPU usage is 100%), I only have this:
** BEGIN
udevinfo starts with the device the node belongs to and then walks up the
device chain, to print for every device found, all possibly useful attributes
in the udev key format.
Only attributes within one device section may be used together in one rule,
to match the device for which the node will be created.
*** END
In the second case, I have this additional info:
*** BEGIN
looking at device '/block/hde/hde1':
KERNEL==hde1
SUBSYSTEM==block
SYSFS{stat}== 0000
SYSFS{size}==15584
SYSFS{start}==32
SYSFS{dev}==33:1
looking at device '/block/hde':
ID==hde
BUS==block
DRIVER==
SYSFS{stat}== 20 16 230
0000 23 23
SYSFS{size}==15680
SYSFS{removable}==1
SYSFS{range}==64
SYSFS{dev}==33:0
looking at device
'/devices/pci:00/:00:1e.0/:02:07.1/1.0/ide2/2.0':
ID==2.0
BUS==ide
DRIVER==ide-disk
looking at device '/devices/pci:00/:00:1e.0/:02:07.1/1.0/ide2':
ID==ide2
BUS==
DRIVER==
looking at device '/devices/pci:00/:00:1e.0/:02:07.1/1.0':
ID==1.0
BUS==pcmcia
DRIVER==ide-cs
SYSFS{modalias}==pcmcia:m0045c0401f04fn00pfn00paE2D20B54pb91844B1CpcAAC4295Bpd
SYSFS{prod_id3}==5/3 0.6
SYSFS{prod_id2}==SDP
SYSFS{prod_id1}==SunDisk
SYSFS{card_id}==0x0401
SYSFS{manf_id}==0x0045
SYSFS{func_id}==0x04
SYSFS{function}==0x00
looking at device '/devices/pci:00/:00:1e.0/:02:07.1':
ID==:02:07.1
BUS==pci
DRIVER==yenta_cardbus
SYSFS{modalias}==pci:v1180d0476sv1043sd1624bc06sc07i00
SYSFS{local_cpus}==1
SYSFS{irq}==11
SYSFS{class}==0x060700
SYSFS{subsystem_device}==0x1624
SYSFS{subsystem_vendor}==0x1043
SYSFS{device}==0x0476
SYSFS{vendor}==0x1180
looking at device '/devices/pci:00/:00:1e.0':
ID==:00:1e.0
BUS==pci
DRIVER==
SYSFS{modalias}==pci:v8086d2448svsdbc06sc04i00
SYSFS{local_cpus}==1
SYSFS{irq}==0
SYSFS{class}==0x060400
SYSFS{subsystem_device}==0x
SYSFS{subsystem_vendor}==0x
SYSFS{device}==0x2448
SYSFS{vendor}==0x8086
looking at device '/devices/pci:00':
ID==pci:00
BUS==
DRIVER==
*** END
didit
Bug#350235: pcmciautils ?
On Jan 29, di dit [EMAIL PROTECTED] wrote:
I can see why the rule does not work, at the removable==1 level we have
BUS==block instead of the expected BUS==ide, and DRIVER is only
available at the upper level.
Kay?
BUS==ide, SYSFS{removable}==1, DRIVER!=ide-cdrom, GOTO=no_volume_id
Maybe a rule like this one would work, but is it correct? (And how are
people going to figure this?)
BUS==ide, SYSFS{block/removable}==1, DRIVER!=ide-cdrom,
GOTO=no_volume_id
looking at device '/block/hde/hde1':
KERNEL==hde1
SUBSYSTEM==block
SYSFS{stat}== 0000
SYSFS{size}==15584
SYSFS{start}==32
SYSFS{dev}==33:1
looking at device '/block/hde':
ID==hde
BUS==block
DRIVER==
SYSFS{stat}== 20 16 230
0000 23 23
SYSFS{size}==15680
SYSFS{removable}==1
SYSFS{range}==64
SYSFS{dev}==33:0
looking at device
'/devices/pci:00/:00:1e.0/:02:07.1/1.0/ide2/2.0':
ID==2.0
BUS==ide
DRIVER==ide-disk
looking at device '/devices/pci:00/:00:1e.0/:02:07.1/1.0/ide2':
ID==ide2
BUS==
DRIVER==
looking at device '/devices/pci:00/:00:1e.0/:02:07.1/1.0':
ID==1.0
BUS==pcmcia
DRIVER==ide-cs
SYSFS{modalias}==pcmcia:m0045c0401f04fn00pfn00paE2D20B54pb91844B1CpcAAC4295Bpd
SYSFS{prod_id3}==5/3 0.6
SYSFS{prod_id2}==SDP
SYSFS{prod_id1}==SunDisk
SYSFS{card_id}==0x0401
SYSFS{manf_id}==0x0045
SYSFS{func_id}==0x04
SYSFS{function}==0x00
looking at device '/devices/pci:00/:00:1e.0/:02:07.1':
ID==:02:07.1
BUS==pci
DRIVER==yenta_cardbus
SYSFS{modalias}==pci:v1180d0476sv1043sd1624bc06sc07i00
SYSFS{local_cpus}==1
SYSFS{irq}==11
SYSFS{class}==0x060700
SYSFS{subsystem_device}==0x1624
SYSFS{subsystem_vendor}==0x1043
SYSFS{device}==0x0476
SYSFS{vendor}==0x1180
looking at device '/devices/pci:00/:00:1e.0':
ID==:00:1e.0
BUS==pci
DRIVER==
SYSFS{modalias}==pci:v8086d2448svsdbc06sc04i00
SYSFS{local_cpus}==1
SYSFS{irq}==0
SYSFS{class}==0x060400
SYSFS{subsystem_device}==0x
SYSFS{subsystem_vendor}==0x
SYSFS{device}==0x2448
SYSFS{vendor}==0x8086
looking at device '/devices/pci:00':
ID==pci:00
BUS==
DRIVER==
--
ciao,
Marco
signature.asc
Description: Digital signature
Bug#350235: pcmciautils ?
Hi,
2006/1/29, Marco d'Itri [EMAIL PROTECTED]:
BUS==ide, SYSFS{removable}==1, DRIVER!=ide-cdrom, GOTO=no_volume_id
Maybe a rule like this one would work, but is it correct? (And how are
people going to figure this?)
BUS==ide, SYSFS{block/removable}==1, DRIVER!=ide-cdrom,
GOTO=no_volume_id
I confirm that making the change described above to the file
/etc/udev/persistent.rules fix the problem here.
Thanks very much for your help,
didit
Bug#350235: pcmciautils ?
On Sun, Jan 29, 2006 at 12:07:50PM +0100, Marco d'Itri wrote: On Jan 29, di dit [EMAIL PROTECTED] wrote: I can see why the rule does not work, at the removable==1 level we have BUS==block instead of the expected BUS==ide, and DRIVER is only available at the upper level. Kay? Correct, that broke with the stricter logic to select the parent device in the recent udev. I'll go fix udev also to look at SYSFS at the device we received the event for and not only at the device selected by BUS. Then it should work again. In the case you compile udev yourself, can you check, if adding this to udev_rules.c fixes this? I'm on the road at the moment and don't have an IDE device, but the same logic works when testing with scsi. value = sysfs_attr_get_value(udev-dev_parent-devpath, key_name); if (value == NULL) + value = sysfs_attr_get_value(udev-dev-devpath, key_name); + if (value == NULL) goto try_parent; strlcpy(val, value, sizeof(val)); Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350235: pcmciautils ?
On Sun, Jan 29, 2006 at 12:07:50PM +0100, Marco d'Itri wrote:
On Jan 29, di dit [EMAIL PROTECTED] wrote:
I can see why the rule does not work, at the removable==1 level we have
BUS==block instead of the expected BUS==ide, and DRIVER is only
available at the upper level.
Kay?
BUS==ide, SYSFS{removable}==1, DRIVER!=ide-cdrom, GOTO=no_volume_id
Maybe a rule like this one would work, but is it correct? (And how are
people going to figure this?)
BUS==ide, SYSFS{block/removable}==1, DRIVER!=ide-cdrom,
GOTO=no_volume_id
Sure, it is correct, but we should better not introduce dependencies on
the weird symlinks that crosslink class devices and devices, they
will probably go away when we change /sys/devices to a sane layout and
the block device will just become a real child of the device.
Changing udev to look with SYSFS{} at the device we got the event for,
should work just fine.
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350235: pcmciautils ?
On Sun, Jan 29, 2006 at 12:07:50PM +0100, Marco d'Itri wrote:
Maybe a rule like this one would work, but is it correct? (And how are
people going to figure this?)
BUS==ide, SYSFS{block/removable}==1, DRIVER!=ide-cdrom,
GOTO=no_volume_id
I'll test this in the next hour or two and let you know. Sounds
promising from the other messages in this thread.
Thanks,
Hamish
--
Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
