Hi, I've nailed this down to something that happened in 2.6.17-rc4. The system locks up with either a NULL dereference or an unhandable paging request. The stack trace shows this: paging request NULL dereference _raw_spin_trylock+12 _raw_spin_trylock+20 __spin_lock+22 main_timer_handler+22 timer_interrupt+18 handle_IRQ_event+41 __do_IRQ+156 do_IRQ+51 default_idle+0 _spin_unlock_irq+43 thread_return+187 generic_unplug_device+0 default_idle+45 dev_idle+95 (I can't read the func clearly in this handwriting) start_secondary+1129 I'm guessing this is the same problem only that it once manifests itself as one and another time as the other. The problem is in the call to write_seqlock(&xtime_lock) from main_timer_handler(). I've not been able to determine what patch has caused this to happen, but it is between 2.6.17-rc3 and -rc4. I'm bisecting, but if anybody has a good candidate, it'd probably be faster than doing a complete bisect. cmn -- Carlos Martín Nieto | http://www.cmartin.tk Hobbyist programmer |
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: A couple of oops.
- From: Andrew Morton <[email protected]>
- Re: A couple of oops.
- Prev by Date: ext3-fs transient corruption with devmapper over md raid, kernel 2.6.16.14
- Next by Date: [PATCH 1 of 10] ipath - fix spinlock recursion bug
- Previous by thread: ext3-fs transient corruption with devmapper over md raid, kernel 2.6.16.14
- Next by thread: Re: A couple of oops.
- Index(es):
 |