From owner-freebsd-hackers Wed Mar 15 15:46:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0AE1437BF9C for ; Wed, 15 Mar 2000 15:46:14 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA97552 for ; Wed, 15 Mar 2000 16:46:12 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA90746 for ; Wed, 15 Mar 2000 16:46:02 -0700 (MST) Message-Id: <200003152346.QAA90746@harmony.village.org> To: hackers@freebsd.org Subject: Odd crash Date: Wed, 15 Mar 2000 16:46:02 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just got an odd crash: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01d16ac stack pointer = 0x10:0xc031e704 frame pointer = 0x10:0xc031e70c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = kernel: type 12 trap, code=0 Stopped at arpintr+0x9c: movl 0x8(%ebx),%ecx db> trace arpintr(c02a997b,0,10,10,c5d20010) at arpintr+0x9c swi_net_next() at swi_net_next db> I'm using the realtek driver with a RealTek 8139 built into the SBC that I have sitting on my desk. rl0: port 0x6000-0x60ff mem 0xf9000000-0xf90000ff irq 11 at device 6.0 on pci0 rl0: Ethernet address: 00:60:e0:00:7f:c8 Looking at the disassembled output of ddb, I think that I'm crashing at the following place. if (m->m_len < sizeof(struct arphdr) && (m = m_pullup(m, sizeof(struct arphdr)) == NULL)) { log(LOG_ERR, "arp: runt packet -- m_pullup failed."); continue; } ar = mtod(m, struct arphdr *); ==> if (ntohs(ar->ar_hrd) != ARPHRD_ETHER && ntohs(ar->ar_hrd) != ARPHRD_IEEE802) { log(LOG_ERR, "arp: unknown hardware address format (%2D)", (unsigned char *)&ar->ar_hrd, ""); m_freem(m); continue; } since ar is NULL for some reason. I have no clue at all why this would happen. This means that m->m_data has to be NULL. But that doesn't make sense because of the m_pullup just before this. If it doesn't return NULL, then I thought that m->m_data was guaranteed to be valid. I think that there might be a bug in the code generation, but I don't know for sure. If we look at the disassembled output: arpintr+0x79: testl %eax,%eax arpintr+0x7b: setz %al arpintr+0x7e: movzbl %al,%ebx arpintr+0x81: testl %ebx,%ebx arpintr+0x83: jz arpintr+0x9c arpintr+0x85: pushl $0xc02f5c60 arpintr+0x8a: pushl $0x3 arpintr+0x8c: call log arpintr+0x91: addl $0x8,%esp arpintr+0x94: jmp arpintr+0x5 arpintr+0x99: leal 0(%esi),%esi arpintr+0x9c: movl 0x8(%ebx),%ecx arpintr+0x9f: movzwl 0(%ecx),%eax arpintr+0xa2: xchgb %ah,%al arpintr+0xa4: cmpw $0x1,%ax arpintr+0xa8: jz arpintr+0xd8 arpintr+0xaa: movzwl 0(%ecx),%eax arpintr+0xad: xchgb %ah,%al arpintr+0xaf: cmpw $0x6,%ax arpintr+0xb3: jz arpintr+0xd8 arpintr+0xb5: pushl $0xc02f5c0e arpintr+0xba: pushl %ecx arpintr+0xbb: pushl $0xc02f5ca0 arpintr+0xc0: pushl $0x3 arpintr+0xc2: call log So we're between the two log calls, which is good. Notice that we effectively zero %ebx at 7e. We then jump to 9c if it isss zero, and then dereference 3bx. Bang, we're dead. I think that the jz should be a jnz, no? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message