Jean Delvare schrieb: > That's right, but it doesn't explain why i2c-piix4 crashes in the first > place, not why merely loading it causes further lspci -xxx to crash > when they did not beforehand. I admit I am totally clueless. > Sorry, I expressed myself a bit unclear. With _worked_ I meant the system crashed (thats what killer commands are for). lspci -xxx (and co) bring this system down in every case, module loaded or not. Obvious this crash occuress when reading the config space in short periods. lspci (or better proc-fs and sys-fs) do that, and i2c-piix4 does it sometimes. Looking at read() of drivers/pci/proc.c i had the idea of stalking the critical area with: #!/bin/sh for i in `seq 100`; do dd if=/proc/bus/pci/00/07.3 of=/dev/null bs=1 count=n 2>/dev/null; done I got no crashes with n == 192, but with n == 193 theres no reaction from the system. Maybe it's interesting, that (all the time after crashes) the screen (in my case the console with a blinking cursor) can still be seen. But no reaction on keyboard hits. Also strange is, that the device works well IF those two read accesses have not done the crash. I'll test tomorrow without the second read access, just to know if it works. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
