On Thu, 04 Sep 2008, Josip Rodin wrote: > Here we go again :/ This is the failing boot log, attached is the config of > the kernel that doesn't work. > > boot: linux > Allocated 8 Megs of memory at 0x40000000 for kernel <snip> > qla2xxx 0001:00:04.0: LIP reset occured (f8ef).[34;48H > scsi1 : qla2xxx[34;16H > qla2xxx 0001:00:04.0: LIP occured (f8ef).[34;42H > qla2xxx 0001:00:04.0: LOOP UP detected (1 Gbps).[34;49H > Unable to handle kernel NULL pointer dereference[34;49H > tsk->{mm,active_mm}->context = 00000000000000e0[34;48H > tsk->{mm,active_mm}->pgd = fffff8007c90e000[34;44H > \|/ ____ \|/[34;27H > "@'/ .. \`@"[34;27H > /_| \__/ |_\[34;27H > \__U_/[34;24H > qla2xxx_1_dpc(771): Oops [#1][34;30H > TSTATE: 0000004480009604 TPC: 000000000058ecf4 TNPC: 000000000058ecf8 Y: 000003 > Not tainted[34;17H > TPC: <fc_flush_work+0x1c/0x40>[34;31H > g0: fffff8007cf770a1 g1: 0000000000000000 g2: fffff8007c014000 g3: 000000040020 > g4: fffff8007e0d0580 g5: fffff8007f6a0000 g6: fffff8007cf74000 g7: 20000004cf2b > o0: 0000000000692588 o1: 0000000000000003 o2: 0000000000000001 o3: 000000000000 > o4: 0000000000000000 o5: 00007fffffffe000 sp: fffff8007cf770c1 ret_pc: 00000000044e90c[34;8H > RPC: <complete+0x44/0x48>[34;26H > l0: fffff8007c016940 l1: 000000000000000f l2: fffff8007e4000b0 l3: 000000000000000[34;4H > l4: fffff8007e054870 l5: 0000000000000008 l6: fffff8007c89c000 l7: 00000000004fc40[34;4H > i0: fffff8007c014000 i1: 0000000000000000 i2: 0000000000000000 i3: fffff8007c984a0[34;4H > i4: 0000000000000000 i5: 0000000000000000 i6: fffff8007cf77181 i7: 0000000000512ac[34;4H > I7: <fc_remote_port_add+0x18/0x664>[34;36H > Caller[00000000005912ac]: fc_remote_port_add+0x18/0x664[34;56H > Caller[000000001003c0e4]: qla2x00_update_fcport+0x2b0/0x368 [qla2xxx][34;70H > Caller[000000001003ca98]: qla2x00_configure_loop+0x85c/0x1a18 [qla2xxx][34;72H > Caller[000000001003dcd0]: qla2x00_loop_resync+0x7c/0x10c [qla2xxx][34;67H > Caller[0000000010039f50]: qla2x00_do_dpc+0x60c/0x6e8 [qla2xxx][34;63H > Caller[000000000046aec4]: kthread+0x4c/0x78[34;44H > Caller[0000000000426df8]: kernel_thread+0x38/0x48[34;50H > Caller[000000000046acec]: kthreadd+0xc4/0x1a0[34;46H That's odd, as fc_flush_work() is quite minimal: static void fc_flush_work(struct Scsi_Host *shost) { if (!fc_host_work_q(shost)) { printk(KERN_ERR "ERROR: FC host '%s' attempted to flush work, " "when no workqueue created.\n", shost->hostt->name); dump_stack(); return; } flush_workqueue(fc_host_work_q(shost)); } there's not much chance here for a NULL-dereference. Since we have know good and bad points, could you possibly git-bisect this to help troubleshoot? Also, are you seeing similar problems with Linus' latest tree? -- AV -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html