Messages in this thread | | | Date | Wed, 11 Oct 2006 09:06:50 +0200 | From | Martin Lorenz <> | Subject | Re: [ltp] Re: X60s w/t kern 2.6.19-rc1-git: two BUG warnings |
| |
On Tue, Oct 10, 2006 at 05:18:27PM -0600, Eric W. Biederman wrote: > Jeremy Fitzhardinge <jeremy@goop.org> writes: > > > Martin Lorenz wrote: > >> Dear kernel gurus, > >> > > > > (CC:s added to various interested parties.) > > > >> whatever I do and whic problem I seem to get fixed new ones arise: > >> > >> now I loose ACPI events after suspend/resume. not every time, but roughly 3 > >> out of 4 times. > >> > > > > Yes, I'm seeing this as well. It used to be a 100% failure, so there has been > > some improvement. On the other hand, before that it used to work perfectly... > > Unfortunately I don't have a good feeling for when these changes happened. > > So the first symptom is not the failure in e1000 open but this. > [ 6727.082000] Trying to free already-free IRQ 20 > Which I suspect comes from e1000_close as it happens after > the e1000 watchdog timer goes off because it hasn't gotten > interrupts for a while. > > We have other bits of suspicious code as well. > The e1000 rolls it's own version of pci_save_state but doesn't > call any of the msi save/restore state routines. > > The bug is from the attempt to allocate an already allocated irq. > So it appears somehow in the save/restore mess the msi code > thought the irq code was allocates but the irq code did not? >
this morning I tried and booted the machine with pci=nomsi the BUG does not come up as expected but the symptom of loosing ACPI after suspend/resume remains...
I put up some information on my current configuration on http://www.lorenz.eu.org/~mlo/kernel/ tell me, what I should add to help
BTW: can someone tell me, why I can't pull from git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git anymore? I keep getting 'fatal: unable to connect a socket (Connection refused)' since yesterday afternoon (first noticed ~2pm UTC)
> I have scratched the msi code enough lately that something may have > shaken loose. In particular in commit: > d7bd007e480672c99d8656c7b7b12ef0549432c37 I explicitly disallowed some > weird double allocation/deallocation code that could have masked this > problem. > > The e1000 watchdog doesn't seem to be going off in the functioning > case so that may not be it. > > My problem is I have been given two incomplete dmesg traces one > that works and one that doesn't and without any background in this > area beyond noting the e1000 watchdog timer is firing I can't say what > happened. > > In the working cases do you have trouble if you up and down the > network interface? > > We seem to be at that nasty interface layer where every piece is > making assumptions about how someone else's piece works, and someone > has their assumptions wrong. > > If someone who understands the how suspend/resume is supposed to work > for these kinds of things can speak up that would help. > > > > >> the only errornous things I see in the logs are those: > >> > >> [ 6727.089000] BUG: warning at drivers/pci/msi.c:680/pci_enable_msi() > >> [ 6727.089000] [<c0103bd9>] dump_trace+0x69/0x1af > >> [ 6727.089000] [<c0103d37>] show_trace_log_lvl+0x18/0x2c > >> [ 6727.089000] [<c01043d6>] show_trace+0xf/0x11 > >> [ 6727.089000] [<c01044d9>] dump_stack+0x15/0x17 > >> [ 6727.089000] [<c0208cd6>] pci_enable_msi+0x78/0x22e > >> [ 6727.090000] [<c0257fe5>] e1000_open+0x64/0x176 > >> [ 6727.091000] [<c029b121>] dev_open+0x2b/0x62 > >> [ 6727.092000] [<c0299c2f>] dev_change_flags+0x47/0xe4 > >> [ 6727.093000] [<c02cdceb>] devinet_ioctl+0x252/0x556 > >> [ 6727.094000] [<c0290e9a>] sock_ioctl+0x19e/0x1c2 > >> [ 6727.095000] [<c016979b>] do_ioctl+0x1f/0x62 > >> [ 6727.095000] [<c0169a23>] vfs_ioctl+0x245/0x257 > >> [ 6727.096000] [<c0169a81>] sys_ioctl+0x4c/0x67 > >> [ 6727.096000] [<c0102dc3>] syscall_call+0x7/0xb > >> [ 6727.096000] DWARF2 unwinder stuck at syscall_call+0x7/0xb > >> [ 6727.096000] > >> [ 6727.096000] Leftover inexact backtrace: > >> [ 6727.096000] > >> [ 6727.096000] [<c02e007b>] unix_stream_connect+0x15b/0x367 > >> [ 6727.096000] ======================= > >> > >> which occurs in variations but very often > >> > > > > This just seems to be something thinking the IRQ isn't MSI-capable. It doesn't > > seem to have any negative effect - the e1000 works fine anyway. > > It is a BUG. The first symptoms of which where the failure to free > the irq in by the e1000 watchdog. The normal irq code said you didn't > have an irq handler registered for that irq. > > Does anyone know how the irq handler could go aways in the weird > suspend/resume world? > > >> [ 6708.389000] e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full > > Duplex > >> [ 6708.389000] e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO > >> [ 6727.082000] Trying to free already-free IRQ 20 > >> [ 6727.089000] BUG: warning at drivers/pci/msi.c:680/pci_enable_msi() > >> [ 6727.089000] [<c0103bd9>] dump_trace+0x69/0x1af > >> [ 6727.089000] [<c0103d37>] show_trace_log_lvl+0x18/0x2c > >> [ 6727.089000] [<c01043d6>] show_trace+0xf/0x11 > >> [ 6727.089000] [<c01044d9>] dump_stack+0x15/0x17 > >> [ 6727.089000] [<c0208cd6>] pci_enable_msi+0x78/0x22e > >> [ 6727.090000] [<c0257fe5>] e1000_open+0x64/0x176 > >> [ 6727.091000] [<c029b121>] dev_open+0x2b/0x62 > >> [ 6727.092000] [<c0299c2f>] dev_change_flags+0x47/0xe4 > >> [ 6727.093000] [<c02cdceb>] devinet_ioctl+0x252/0x556 > >> [ 6727.094000] [<c0290e9a>] sock_ioctl+0x19e/0x1c2 > >> [ 6727.095000] [<c016979b>] do_ioctl+0x1f/0x62 > >> [ 6727.095000] [<c0169a23>] vfs_ioctl+0x245/0x257 > >> [ 6727.096000] [<c0169a81>] sys_ioctl+0x4c/0x67 > >> [ 6727.096000] [<c0102dc3>] syscall_call+0x7/0xb > >> [ 6727.096000] DWARF2 unwinder stuck at syscall_call+0x7/0xb > >> [ 6727.096000] [ 6727.096000] Leftover inexact backtrace: > >> [ 6727.096000] [ 6727.096000] [<c02e007b>] unix_stream_connect+0x15b/0x367 > >> [ 6727.096000] ======================= > >> [ 6728.719000] e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full > > Duplex > >> [ 6728.719000] e1000: eth0: e1000_watchdog: 10/100 speed: disabling > >TSO > > Eric > -- > The linux-thinkpad mailing list home page is at: > http://mailman.linux-thinkpad.org/mailman/listinfo/linux-thinkpad
gruss mlo -- Dipl.-Ing. Martin Lorenz
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin
please encrypt your mail to me GnuPG key-ID: F1AAD37D get it here: http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xF1AAD37D
ICQ UIN: 33588107 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |