Date: Fri, 11 May 2001 11:47:24 -0500 From: "Jacques A. Vidrine" <n@nectar.com> To: freebsd-mobile@freebsd.org Subject: Re: faults re-inserting network card Message-ID: <20010511114724.B19480@shade.nectar.com> In-Reply-To: <20001115115023.A8682@hamlet.nectar.com>; from n@nectar.com on Wed, Nov 15, 2000 at 11:50:24AM -0600 References: <20001115115023.A8682@hamlet.nectar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I'm following-up on an old message, so please forgive my quoting it in
entirety.
I'm now using the same OS version and same PC Card on a ThinkPad X20
(instead of the Sony VAIO Z505sx), and I've yet to panic on the
ThinkPad when doing re-insertion. Often I'm not nearly as careful as
I tried to be with the Sony, either.
So I'm writing this off to a quirk of the Sony hardware. I haven't
noticed any reports of similar (consistent) problems.
Cheers,
--
Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org
On Wed, Nov 15, 2000 at 11:50:24AM -0600, Jacques A. Vidrine wrote:
> Hi,
>
> I'm trying to track down the source of faults when re-inserting a
> network card into my laptop.
>
> [Short version]
>
> = Are folks able to remove & re-insert their network cards on Sony VAIO
> Z505s?
> = Are folks able to remove & re-insert their Aironet cards on any
> laptop?
>
>
> [Long (useful?) version]
>
> I've only run 4.1-STABLE and 4.2-BETA, each with Doug Ambrisko's an
> patches (which are now in -CURRENT, I believe) with this hardware.
>
> The hardware involved:
> Sony VAIO Z505SX
> Cisco Aironet 342
> pcic-pci0: <Ricoh RL5C475 PCI-CardBus Bridge> at device 10.0 on pci0
> pcic0: <Intel i82365> at port 0x3e0 iomem 0xd0000 irq 10 on isa0
> pcic0: management irq 10
> pccard0: <PC Card bus -- kludge version> on pcic0
> an0: <Aironet PC4500/PC4800> at port 0x240-0x27f irq 5 slot 0 on pccard0
>
> This card works well, until I remove it and then re-insert it (or
> equivalently suspend/resume). I always kill all network services,
> ifconfig down the interface, delete all IP addresses from the
> interface, et cetera, before removing the card. Once re-inserted, it
> is identified as usual, but shortly after configuring it with ifconfig
> or dhclient (or sometimes immediately), the kernel faults. This is
> very consistent, although the faults don't all come from the same
> places. Most of the faults I've seen are like the following:
>
>
> Script started on Wed Nov 15 11:12:11 2000
> # gdb -k kernel.debug /var/crash/vmcore.9
> GNU gdb 4.18
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-unknown-freebsd"...
> IdlePTD 4059136
> initial pcb at 340080
> panicstr: from debugger
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x104
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc019dabf
> stack pointer = 0x10:0xc8ccdda0
> frame pointer = 0x10:0xc8ccde28
> 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 = 20719 (dhclient)
> interrupt mask = none
> panic: from debugger
> Uptime: 22h35m29s
>
> dumping to dev #ad/0x40001, offset 265664
> dump ata0: resetting devices .. done
> 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
> ---
> #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:469
> 469 if (dumping++) {
> (kgdb) where
> #0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:469
> #1 0xc015d173 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:309
> #2 0xc015d509 in panic (fmt=0xc02bc634 "from debugger")
> at /usr/src/sys/kern/kern_shutdown.c:556
> #3 0xc013e4b5 in db_panic (addr=-1072047425, have_addr=0, count=1,
> modif=0xc8ccdc0c "") at /usr/src/sys/ddb/db_command.c:433
> #4 0xc013e455 in db_command (last_cmdp=0xc02f936c, cmd_table=0xc02f91cc,
> aux_cmd_tablep=0xc033c47c) at /usr/src/sys/ddb/db_command.c:333
> #5 0xc013e51a in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
> #6 0xc0140627 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:71
> #7 0xc0299e1e in kdb_trap (type=12, code=0, regs=0xc8ccdd60)
> at /usr/src/sys/i386/i386/db_interface.c:158
> #8 0xc02a5fe8 in trap_fatal (frame=0xc8ccdd60, eva=260)
> at /usr/src/sys/i386/i386/trap.c:946
> #9 0xc02a5cc1 in trap_pfault (frame=0xc8ccdd60, usermode=0, eva=260)
> at /usr/src/sys/i386/i386/trap.c:844
> #10 0xc02a5863 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
> tf_edi = 7532, tf_esi = -1077946096, tf_ebp = -926097880,
> tf_isp = -926098036, tf_ebx = -1061585336, tf_edx = 260, tf_ecx = 0,
> tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1072047425, tf_cs = 8,
> tf_eflags = 66050, tf_esp = -937054144, tf_ss = -1073190620})
> at /usr/src/sys/i386/i386/trap.c:443
> #11 0xc019dabf in ifconf (cmd=3221776676, data=0xc8ccdeac "")
> at /usr/src/sys/net/if.c:1080
> ---Type <return> to continue, or q <return> to quit---
> #12 0xc019d411 in ifioctl (so=0xc80a49c0, cmd=3221776676, data=0xc8ccdeac "",
> p=0xc825b040) at /usr/src/sys/net/if.c:774
> #13 0xc016e326 in soo_ioctl (fp=0xc0d24940, cmd=3221776676,
> data=0xc8ccdeac "", p=0xc825b040) at /usr/src/sys/kern/sys_socket.c:141
> #14 0xc016b35e in ioctl (p=0xc825b040, uap=0xc8ccdf80)
> at /usr/src/sys/sys/file.h:174
> #15 0xc02a62c1 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
> tf_edi = 134955092, tf_esi = -1077938110, tf_ebp = -1077938564,
> tf_isp = -926097452, tf_ebx = 0, tf_edx = -1077946756, tf_ecx = 7,
> tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 134568208, tf_cs = 31,
> tf_eflags = 663, tf_esp = -1077946896, tf_ss = 47})
> at /usr/src/sys/i386/i386/trap.c:1150
> #16 0xc029a765 in Xint0x80_syscall ()
> #17 0x8049bdd in ?? ()
> #18 0x8048135 in ?? ()
> (kgdb) frame 11
> #11 0xc019dabf in ifconf (cmd=3221776676, data=0xc8ccdeac "")
> at /usr/src/sys/net/if.c:1080
> 1080 register struct sockaddr *sa = ifa->ifa_addr;
> (kgdb) list
> 1075
> 1076 addrs = 0;
> 1077 ifa = ifp->if_addrhead.tqh_first;
> 1078 for ( ; space > sizeof (ifr) && ifa;
> 1079 ifa = ifa->ifa_link.tqe_next) {
> 1080 register struct sockaddr *sa = ifa->ifa_addr;
> 1081 if (curproc->p_prison && prison_if(curproc, sa))
> 1082 continue;
> 1083 addrs++;
> 1084 #ifdef COMPAT_43
> (kgdb) print ifa
> $1 = (struct ifaddr *) 0x104
> (kgdb) print space
> $2 = 7532
> (kgdb) quit
> #
>
> Script done on Wed Nov 15 11:12:57 2000
>
>
> In other words, most of them have to do with a corrupt interface list,
> though I've seen a couple blow up in the routing table. Sometimes
> this happens when calling down into the kernel, and sometimes it
> happens in something like ip_input (especially when traversing
> in_ifaddrhead).
>
> Clearly, something that needs to happen on detach is not happening.
> The detach code for the an driver looks the same to me as other
> drivers, but what do I know?
>
> I'm quite willing to go hunting, but it will help if I can get a
> feeling whether this could be a driver issue, a network card issue, or
> a laptop hardware issue -- so answers to the `short version' questions
> will be helpful. Unfortunately I don't have another network PC card
> to test with (bless the Z505's built-in fxp0! :-).
>
> Thanks for any hints!
>
> Cheers,
> --
> Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-mobile" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010511114724.B19480>