Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: regression: fireware causes oops during system | Date | Sun, 16 Sep 2007 21:52:24 +0200 |
| |
On Sunday, 16 September 2007 20:41, Stefan Richter wrote: > (Adding Cc: Rafael, Ingo) > > Pavel Machek wrote: > >> Dmesg with the oops or/and bisection would be good. > > > > Sorry, had to hand-copy. It is oops at virtual adddress 6b6b6b7b -- > > looks like slab poison to me? > > > > EIP is in task_rq_lock, backtrace is > > try_to_wake_up > > highlevel_host_reset > > ohci_irq_handler > > In reverse order, this trace is most certainly > > drivers/ieee1394/ohci1394.c::ohci_irq_handler > drivers/ieee1394/highlevel.c::highlevel_host_reset > drivers/ieee1394/highlevel.c::nodemgr_highlevel.host_reset > == nodemgr_host_reset > kernel/sched.c::wake_up_process(hi->thread); > > with hi->thread being the kthread which executes > drivers/ieee1394/nodemgr.c::nodemgr_host_thread of the ieee1394 core driver. > > The ieee1394 core has two (or more) threads: One nodemgr_host_thread > alias [knodemgrd_*] for each card, and one hpsbpkt_thread alias > [khpsbpkt] for all cards. The knodemgrd should be frozen during suspend > or hibernate, while khpsbpkt should not be frozen in order to let > transactions to go on in the case of saving the hibernation image to a > FireWire disk. > > > Quoting your other post: > > On Tue 2007-09-11 21:45:58, Stefan Richter wrote: > >> Between -rc3 and -rc4: > >> > >> ieee1394: sbp2: fix sbp2_remove_device for error cases > >> a2ee3f9bbb0ce57102dad8928d54f59acdc4b8f7 > >> should not occur in suspend path > > > > Plus I do not have firewire attached disk here, so sbp2 should not be > > used, right? > > Sbp2's host_reset handler would do something if it was loaded even > without any SBP-2 devices attached,but it wouldn't under any > circumstances call try_to_wake_up. Actually with no devices attached it > would simply "iterate" over an empty list. > > >> Between -rc1 and -rc2: > >> > >> ieee1394: sbp2: more correct Kconfig dependencies > >> e4f8cac5e07528f7e0bc21d3682c16c9de993ecb > >> unrelated > >> > >> ieee1394: revert "sbp2: enforce 32bit DMA mapping" > >> a9c2f18800753c82c45fc13b27bdc148849bdbb2 > >> unrelated > >> > >> (not via linux1394-2.6.git) > >> raw1394 __user annotation > >> 5b26e64ea39e45802c5736c8261bf8a8704d212f > >> unrelated > >> > >> So it must be something older which was somehow uncovered. > >> Dmesg with the oops or/and bisection would be good. > > > > The others look even more innocent. I wonder if this may have been > > responsible? > > > > commit 831441862956fffa17b9801db37e6ea1650b0f69 > > tree b0334921341f8f1734bdd3243de76d676329d21c > > parent 787d2214c19bcc9b6ac48af0ce098277a801eded > > author Rafael J. Wysocki <rjw@sisk.pl> Tue, 17 Jul 2007 04:03:35 -0700 > > committer Linus Torvalds <torvalds@woody.linux-foundation.org> Tue, 17 > > Jul 2007 10:23:02 -0700 > > > > Freezer: make kernel threads nonfreezable by default
Well, I don't think so.
nodemgr_host_thread() calls set_freezable() as it should.
Greetings, Rafael - 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/
| |