Re: 2.6.{30,31} x86_64 ahci problem - irq 23: nobody cared

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/12/2009 09:03 AM, Alexander Huemer wrote:
Alexander Huemer wrote:
Tejun Heo wrote:
Alexander Huemer wrote:

Tejun Heo wrote:
Frans Pop wrote:

On Monday 12 October 2009, Tejun Heo wrote:
Alexander, can you please attach full boot log and the output of
"lspci -nn"? Also, how reproducible is the problem? You already
answered to Frans' question but can you be more specific?
Full dmesg was made available earlier at:
http://xx.vu/~ahuemer/dmesg_ahuemer_20090923
Does blacklisting i801_smbus make any difference?

lspci -nn:
http://xx.vu/~ahuemer/lspci_nn_ahuemer_20091012

what do you mean with "blacklisting i801_smbus" ?

[ 3.872387] i2c /dev entries driver
[ 3.873943] i801_smbus 0000:00:1f.3: PCI INT B -> GSI 23 (level, low)
-> IRQ 23
[ 3.875580] w83627hf: Found W83627HF chip at 0x290

IRQ23 is also used by i801_smbus and it would be nice to confirm
whether the problem can still be triggered with that driver not
loaded. Adding "blacklist i2c_i801" to /etc/modprobe.d/blacklist
should probabaly do the trick.

Thanks.

okay, i think you assume that i2c_i801 is a module.
it is indeed built into the kernel.
i'll rebuild the kernel without that component and run a test again.

regards
-alex
tejun, it seems you hit an interesting point.
i compiled kernel-2.6.31.3 with my ususal config _without_ i2c_i801.
my usual test (compilation of gcc-4.3.2) finished 5 times without the
error.
i'll let it run some more times over night.
does anybody have an idea how i can trace what exactly causes the error
during the compilation run so that i can create a short test program ?

Do you have any hardware sensors monitoring software running (such as the GNOME sensors panel applet or something?) Something like that would be the most likely cause for something to access the smbus driver.

Interesting that the device seems to be on the same interrupt but it hasn't registered itself as a handler (it looks like that driver doesn't use interrupts). If the device did generate an interrupt though, it would indeed cause this problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux