Don't know if it's a bug, but Linux shouldn't hang without at least a
panic, so here's a short report:
rgrep -rl wm /proc/* crashes the machine
I discovered this by accident by running rgrep -rl wm .* in /root.
Machine has Redhat 6.1 installed with most patches installed.
K6-200, 64MB, 4GB harddisk
Doesn't happen with normal grep - reassigning
Are you sure it's hanging the machine? It will certainly
hang the rgrep process, as it will try to read from things
(like /proc/kmsg) that it won't get EOF on.
No, I'm sure it hangs the machine....
But, I finallly managed to trace the right file.
Even grep manages to crash the machine. Here's what happens:
grep test /proc/bus/pci/00/07.3 hangs the machine:
1. Can't change consoles anymore
2. CTRL+C/Z does nothing
3. Can't ping the machine anymore (!)
Now, the device info from /proc/pci:
Bus 0, device 7, function 3:
Bridge: Intel 82371AB PIIX4 ACPI (rev 1).
Medium devsel. Fast back-to-back capable.
Don't know if this happens on other machines as well, but shouldn't happen.
The mainboard is an AOpen AP5T. But it has the Intel chipset.
It's running on a K6-200Mhz.
Don't know if this is a real bug, or how many mainboards have that chipset.
Perhaps this belongs on the kernel dev list.
OK. Reassigning to kernel, as that's where the problem lies.
However, it might just be that reading the ACPI device's config
space locks it up. Out of curiousity, does it also
crash if you do 'lspci -xxx'?
'lspci -vvx' works like a charm
but 'lspci -xxx' does crash the machine....
It says in the manpage that that's exactly what it does on some machines...
But still, should reading from the file in /proc/bus/pci/ cause this behaviour?
Yes, because it's doing the same thing as lspci -xxx.
Unfortunately, there's not much we can do, as this seems
to fall into the cases mentioned in the lspci manpage