Re: Problems with the latest changes to ifconfig (I guess) - Bad guess...
[Niels Chr. Bank-Pedersen wrote:] After the recent changes to ifconfig and the xl driver I am getting a panic when rc.network runs ifconfig: Anybody else seeing this, or should I look somewhere else alltogether? I am seeing exactly the same breakage -- cvsup as of today, mid-evening EDT. This is the first -current build I've done since if_xl was converted to miibus. My card is identified as 3Com 3c905B-TX Fast Etherlink XL. Best; inw -- Ian Whalley first name @ last name . org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with the latest changes to ifconfig (I guess) - Bad guess...
Ian Whalley [EMAIL PROTECTED] wrote: My card is identified as 3Com 3c905B-TX Fast Etherlink XL. FWIW, I'm running a kernel about 30 hours old with a 3Com 3c905-TX Fast Etherlink XL and I'm not seeing this problem. At a quick quess, something in the miibus support broke the 3C905B support. Peter I got the same panic tonight. The xlphy attach function doesn't clean up appropriately when it aborts, here's the fix. Index: exphy.c === RCS file: /home/ncvs/src/sys/dev/mii/exphy.c,v retrieving revision 1.3 diff -u -r1.3 exphy.c --- exphy.c 1999/08/29 15:42:03 1.3 +++ exphy.c 1999/09/01 03:12:01 @@ -161,12 +161,6 @@ ma = device_get_ivars(dev); sc-mii_dev = device_get_parent(dev); mii = device_get_softc(sc-mii_dev); - LIST_INSERT_HEAD(mii-mii_phys, sc, mii_list); - - sc-mii_inst = mii-mii_instance; - sc-mii_phy = ma-mii_phyno; - sc-mii_service = exphy_service; - sc-mii_pdata = mii; /* * The 3Com PHY can never be isolated, so never allow non-zero @@ -176,6 +170,12 @@ device_printf(dev, "ignoring this PHY, non-zero instance\n"); return(ENXIO); } + LIST_INSERT_HEAD(mii-mii_phys, sc, mii_list); + + sc-mii_inst = mii-mii_instance; + sc-mii_phy = ma-mii_phyno; + sc-mii_service = exphy_service; + sc-mii_pdata = mii; mii-mii_instance++; -lq To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with the latest changes to ifconfig (I guess) - Bad
Of all the gin joints in all the towns in all the world, Peter Jeremy had to walk into mine and say: Ian Whalley [EMAIL PROTECTED] wrote: My card is identified as 3Com 3c905B-TX Fast Etherlink XL. FWIW, I'm running a kernel about 30 hours old with a 3Com 3c905-TX Fast Etherlink XL and I'm not seeing this problem. At a quick quess, something in the miibus support broke the 3C905B support. Not quite. The original 3c905-TX NIC used an external NatSemi PHY chip which was mapped to MII address 24. The 3c905B uses an internal transceiver, which is also mapped to MII address 24 for compatibility purposes. However, there are several different 3c905B ASIC revisions and at least one of them, for some peculiar reason, maps the transceiver to *all* MII addresses (0 through 31). Technically this isn't a big problem since if you always assume that the PHY is at address 24 (which I sure is what 3Com's drivers do) you'll never notice the difference. But you have to watch out for it. The old code in if_xl.c would probe for PHYs and stop the moment it encountered the first one, which would work fine: it would stop at address 0 for the broken ASIC and 24 for the working ones. But the miibus code probes at all addresses because there are some NICs that actually have more than one transceiver. But with the buggy 3Com ASIC, we end up incorrectly trying to map the same PHY several times over, which the xlphy driver doesn't like, so the probe fails, the miibus attach fails, and bad things happen later. I just committed a patch to -current to deal with this: the xl_miibus_readreg() and xl_miibus_writereg() routines will not only return values at MII address 24. This will make the buggy ASIC appear to work correctly so that only one PHY instance will be detected. Why didn't I catch this earlier? Well, the 3c905B NIC that I tested happens to work correctly. So did the 3c905C that I tried after it. In fact, I think the only place I encountered the buggy ASIC locally is with the embedded 3c905B NIC in some of the Dell machines in the lab, which aren't currently running FreeBSD. Don't you just love hardware programming? -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with the latest changes to ifconfig (I guess) - Bad guess...
Sorry to reply to my own mail -- never report problems before investigating what was committed. The $Id$ - $FreeBSD$ changes to ifconfig are probably not the cause -- more likely the changes to xl (1.52 - 1.53), and the addition of the mii-controller. Anybody else seeing this, or should I look somewhere else alltogether? Hi, After the recent changes to ifconfig and the xl driver I am getting a panic when rc.network runs ifconfig: [...] Doing initial network setup: hostname. UP,LOOPBACK,RUNN ING,MULTICAST m E®WioFnetmask 0xffa00 tal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0x0 stack pointer = 0x10:0xc8d18dc4 frame pointer = 0x10:0xc8d18ddc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 78 (ifconfig) interrupt mask = net kernel: type 12 trap, code=0 Stopped at 0: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc020cac4 stack pointer = 0x10:0xc8d18c3c frame pointer = 0x10:0xc8d18c40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 78 (ifconfig) interrupt mask = net kernel: type 12 trap, code=0 db This is after a make buildworld/installworld on -current (as of today). dmesg and config-file: FreeBSD/i386 bootstrap loader, Revision 0.7 639/65472kB ([EMAIL PROTECTED], Mon Aug 30 10:58:22 CEST 1999) /kernel text=0x164b84 data=0x1ee6c+0x1e1e8 syms=[0x4+0x24760+0x4+0x268f8] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Mon Aug 30 18:56:22 CEST 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/HOME Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (400.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134217728 (131072K bytes) avail memory = 127102976 (124124K bytes) Preloaded elf kernel "kernel" at 0xc02ef000. VESA: v2.0, 8192k memory, flags:0x0, mode table:0xc029d042 (122) VESA: ATI MACH64 Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 vga-pci0: ATI model 4742 graphics accelerator irq 15 at device 0.0 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 chip1: Intel PIIX4 IDE controller at device 7.1 on pci0 chip2: UHCI USB controller at device 7.2 on pci0 chip3: Intel 82371AB Power management controller at device 7.3 on pci0 ahc0: Adaptec 2940 SCSI adapter irq 15 at device 15.0 on pci0 ahc0: aic7870 Wide Channel A, SCSI Id=7, 16/255 SCBs pcm0: AudioPCI ES1370 irq 11 at device 16.0 on pci0 pcm0: using I/O space register mapping at 0xe800 xl0: 3Com 3c905B-TX Fast Etherlink XL irq 10 at device 18.0 on pci0 xl0: Ethernet address: 00:10:4b:7a:96:7d miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xlphy1: 3Com internal media interface on miibus0 xlphy1: ignoring this PHY, non-zero instance device_probe_and_attach: xlphy1 attach returned 6 Probing for PnP devices: atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 9 virtual consoles, flags=0x0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: generic printer on ppbus 0 Waiting 5 seconds for SCSI devices to settle changing root device to da0s1a
