i801_smbus 0000:00:1f.3: Bus collision!

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

 



On Thu, Sep 08, 2005 at 01:12:34PM -0400, Mark M. Hoffman wrote:
> Richard's symptoms seem to implicate the i2c-i801 and i2c-core patches.

Yeah, got a stack trace at the point where it starts recursing
down the stack:

Call Trace:
 [<f89e4bb7>] i801_start+0x2fd/0x375 [i2c_i801]
 [<f8a0ede6>] i2c_start_entry+0x28/0x52 [i2c_core]
 [<f8a1010c>] i2c_non_blocking_op+0xbb/0xcf [i2c_core]
 [<f8ea5960>] start_resend+0x7d/0x99 [ipmi_smb]
 [<f8ea52d9>] msg_done_handler+0x57/0x532 [ipmi_smb]
 [<c011e09c>] printk+0xe/0x11
 [<f89e4680>] i801_block_next_byte+0xb7/0xfd [i2c_i801]
 [<f8a0eec0>] i2c_entry_put+0x58/0x7c [i2c_core]
 [<f89e4c1e>] i801_start+0x364/0x375 [i2c_i801]
 [<f8a0ede6>] i2c_start_entry+0x28/0x52 [i2c_core]
 [<f8a1010c>] i2c_non_blocking_op+0xbb/0xcf [i2c_core]
 [<f8ea525a>] retry_timeout+0x47/0x6f [ipmi_smb]
 [<f8ea5213>] retry_timeout+0x0/0x6f [ipmi_smb]
 [<c012548a>] run_timer_softirq+0x123/0x145
 [<c0122094>] __do_softirq+0x4c/0xb1
 [<c0105db7>] do_softirq+0x41/0x48


so it looks like there is now a path where a request can fail
in i2c_start() which causes it to start the next request
which calls i2c_start() ... etc.

Pretty clear this is most likely an issue with the patches I'm
using.  Thanks to you both for the helpful responses.

Richard





[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux