Quoting The Eclectic One (eclectic@sdf.lonestar.org): > >First of all, it would be nice if you could precise what exact version you > >tested. > > I tried both the rc1 debian-testing-i386-netinst.iso and the daily > build as of a few days ago. Same result. OK. Are you in the position of testing with something else than a USB stick boot ? The best would be using the "netboot" ISO (called mini.iso) from a CD. > Ok, I downloaded these 4 again. It turns out that the daily build iso > was the exact same I had tried last. The boot.imb.gz was different so Yes, daily builds have not been rebuilt since Dec 18th. Though this is not the source of your problems, we might prefer really testing with the version we will release. > Actually, I was able to capture the problem in non-expert mode. > I figure the least amount of changes made in the flow of execution > of the program, the easier it would be to duplicate the problem. There are no changes in the flow of execution, but more places where the process is stopped, which might help narrowing things down. > Ok, it happens immediately after the identifying network hardware > screen. So soon after in fact that I thought I would have no time to "after identifying network HW" means 'after the system displays a progress bar saying "Identifying network hardware", right? This is where we would need to really narrow things down and where using the expert mode could help. > [ 23.523397] EAX: ffffffff EBX: df6f0000 ECX: ffffffff EDX: df413440 > [ 23.523397] ESI: df6f0000 EDI: 00000000 EBP: ffffffff ESP: df449f84 > [ 23.523397] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 > [ 23.523397] Process events/0 (pid: 5, ti=df448000 task=df43e860 task.ti=df448000) > [ 23.523397] Stack: c025d42d df6f0000 00000002 c025830e df413440 c0356f00 c025833e 00000000 > [ 23.523397] c025835b c012716d df413440 c01276e9 df413448 c0127794 00000000 df43e860 > [ 23.523397] c012990b df449fc8 df449fc8 df413440 00000000 c0129763 c012972d 00000000 > [ 23.523397] Call Trace: > [ 23.523397] [<c025d42d>] dev_deactivate+0x1e/0xbd > [ 23.523397] [<c025830e>] __linkwatch_run_queue+0x118/0x148 > [ 23.523397] [<c025833e>] linkwatch_event+0x0/0x22 > [ 23.523397] [<c025835b>] linkwatch_event+0x1d/0x22 > [ 23.523397] [<c012716d>] run_workqueue+0x75/0xee > [ 23.523397] [<c01276e9>] worker_thread+0x0/0xb5 > [ 23.523397] [<c0127794>] worker_thread+0xab/0xb5 > [ 23.523397] [<c012990b>] autoremove_wake_function=0x0/0x2d > [ 23.523397] [<c0129763>] kthread+0x36/0x5b > [ 23.523397] [<c012972d>] kthread+0x0/0x5b > [ 23.523397] [<c0104937>] kernel_thread_helper+0x7/0x10 > [ 23.523397] ======================= > [ 23.523397] Code: ff 42 50 5b c3 89 c1 8d 90 80 00 00 00 89 12 8d 81 a4 00 00 00 89 52 04 c7 42 08 00 00 00 00 83 c2 0c 39 c2 75 e7 31 c0 c3 89 c1 <8b> 40 10 8b 50 30 85 d2 74 04 89 c8 ff d2 c3 53 89 c3 e8 a8 af > [ 23.523397] EIP: [<c025d074>] qdisc_reset+0x2/0x11 SS:ESP 0068:df449f84 > [ 23.915430] Kernel panic - not syncing: Fatall exception in interrupt OK. Thanks for the help trying to narrow things. Being an obvious problem with the kernel, we really need to triple check that it happens or not with the last kernel package from unstable (which is likely, but still...)
Attachment:
signature.asc
Description: Digital signature