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 <[email protected]> Tue, 17 Jul 2007 04:03:35 -0700
> > committer Linus Torvalds <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
