ae(4) Wake-on-Lan MFC
Hi, I noticed that ae(4) got MFC'ed to RELENG_7 before Wake-on-Lan support did. However, WOL support is now there, and it looks like the change can just go in: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ae/if_ae.c.diff?r1=1.1.2%3ARELENG_7tr1=1.1r2=1.3%3AHEADtr2=1.3 I am tied up looking at other stuff at the moment, it would be nice to merge the change, but low priority for me right now. BTW, it still seems easier to use cvsweb to pull a diff between FreeBSD branches since the SVN change, does anyone know an easier way? thanks BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ae(4) Wake-on-Lan MFC
Bruce Simpson wrote: Hi, I noticed that ae(4) got MFC'ed to RELENG_7 before Wake-on-Lan support did. However, WOL support is now there, and it looks like the change can just go in: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ae/if_ae.c.diff?r1=1.1.2%3ARELENG_7tr1=1.1r2=1.3%3AHEADtr2=1.3 I am tied up looking at other stuff at the moment, it would be nice to merge the change, but low priority for me right now. BTW, it still seems easier to use cvsweb to pull a diff between FreeBSD branches since the SVN change, does anyone know an easier way? that's basically what I do.. thanks BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()
Sam Leffler wrote: It is the same issue but the root cause is unclear. There is much code that does assumes ifma_protospec might be NULL and checks for it. In my case (creating a wlan ifnet and then destroying it on eject) the patch below is sufficient. I don't care to dig right now to understand how this stuff is supposed to work; it should be clear from comments etc but the code is lacking. This is just to say I've tried to reproduce the 802.11 related panics, however have hit a brick wall because the PCI-CardBus bridge does not seem to detect anything in its slot. (1U Itox Expanding Dragon industrial PC w/a SiteCom branded Ricoh RL475 cardbus card). I tried unloading if_fxp with IGMPv3 active on the ifnet, and didn't see any panic, I'm assuming this is OK for the time being. Qing Li volunteered to test IGMPv3 out for any VLAN related issues -- I understand it stacks ifnets in a similar way to that of 802.11 -- however I have had no feedback from him since last week. So I'm waiting for a HEAD build to a USB2 stick to finish, so I can try testing nondestructively on my laptop, where I know for sure that the PCI-CardBus bridge slot works, and I can detach an 802.11 card on the fly. Re ifma_protospec: Yes, there are tricks in the ifnet/in layer which set it to NULL and look for it to be NULL. I ended up doing it this way mainly because adding reference counting to ifnet would have simply been too much work, and it's really a ball that needs to be kicked around at a dev summit. However time presses on and it's better to get SOMETHING out there. Most likely the IGMPv3 changes are hitting this in the 802.11 case somehow, I don't have a complete picture of how/why/what's going on, and have been relying on feedback from others so far. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Old Synopsis: Wifi ath0 associates fine with AP, but DHCP or IP does not work New Synopsis: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Mar 17 08:21:07 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132722 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Hi, Can you please try cvsupping RELENG_7 sources to after this date: %%% Date: Thu Mar 12 03:09:11 2009 New Revision: 189720 URL: http://svn.freebsd.org/changeset/base/189720 %%% The Atheros open source HAL from HEAD was MFC'd and this may or may not fix your problem. thanks, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Bruce Simpson b...@incunabulum.net To: freebsd-gnats-sub...@freebsd.org Cc: lini...@freebsd.org, freebsd-b...@freebsd.org, freebsd-net@FreeBSD.org, Matthias Apitz g...@unixarea.de, Sam Leffler s...@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 08:31:38 + Hi, Can you please try cvsupping RELENG_7 sources to after this date: %%% Date: Thu Mar 12 03:09:11 2009 New Revision: 189720 URL: http://svn.freebsd.org/changeset/base/189720 %%% The Atheros open source HAL from HEAD was MFC'd and this may or may not fix your problem. thanks, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Matthias Apitz g...@unixarea.de To: bug-follo...@freebsd.org, g...@unixarea.de Cc: Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 09:42:43 +0100 I forgot to mention that I've applied this patch from Sam to my RELENG_7 kernel: http://article.gmane.org/gmane.os.freebsd.stable/60383/match=cft+ath+hal+src I think, updating to Date: Thu Mar 12 03:09:11 2009 New Revision: 189720 URL: http://svn.freebsd.org/changeset/base/189720 as suggested will not change anything, or I'm wrong? matthias ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Hi, One crucial piece of info missing is exactly which Atheros part you are using, can you please attach this to the PR? you can get this from pciconf -lv and look for the ath0, also please post your boot time dmesg / or when you insert the part. thanks. Matthias Apitz wrote: The following reply was made to PR kern/132722; it has been noted by GNATS. From: Matthias Apitz g...@unixarea.de To: bug-follo...@freebsd.org, g...@unixarea.de Cc: Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 09:42:43 +0100 I forgot to mention that I've applied this patch from Sam to my RELENG_7 kernel: http://article.gmane.org/gmane.os.freebsd.stable/60383/match=cft+ath+hal+src I think, updating to Date: Thu Mar 12 03:09:11 2009 New Revision: 189720 URL: http://svn.freebsd.org/changeset/base/189720 as suggested will not change anything, or I'm wrong? I didn't make many changes apart from fixups in a few files for the diff, so if you're running with the updated HAL, then in theory an svn update/cvsup should make no change. Of course the only way to be sure is to look under the hood. I didn't see any issues with the backported HAL, and I don't really know enough about ath(4) to suggest any workarounds at this point other than reversing your application of the patch, and cvsupping to before the date the patch was MFCed, can we be absolutely sure that the regression you observe happens with the new HAL? Sam would know more, but of course one of the reasons I've taken this on is because a project I'm involved with needs working ath(4) on pci-e in 7.x, I don't know about chip specific problems at this point in time, so I'm just as in the dark as you are! thanks, BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
SA add notification to externa module
Hi all This is my first posting. I want the notifications about the SA (security association) add/delete events, from the kernel to my externel kernel module. How can I do this... ? Thanks in advance for ur suggestions. Sriknath ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: SA add notification to externa module
On Tue, Mar 17, 2009 at 02:23:13PM +0530, srikanth jampala wrote: Hi all Hi. This is my first posting. I want the notifications about the SA (security association) add/delete events, from the kernel to my externel kernel module. How can I do this... ? Such events are notified to all PFKey registered sockets. Usually, those notifications are sent to userland, but I guess you could start searching from there (see key_sendup_mbuf(x, y, KEY_SENDUP_REGISTERED) in netipsec/keysock.c). Yvan. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Matthias Apitz g...@unixarea.de To: bug-follo...@freebsd.org Cc: freebsd-net@FreeBSD.org, Bruce Simpson b...@incunabulum.net Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 11:36:51 +0100 as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-STABLE #1: Tue Mar 10 11:42:48 CET 2009 g...@rebelion.sisis.de:/usr/src/sys/i386/compile/REBELION Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 900MHz (900.10-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6d8 Stepping = 8 Features=0xafe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE AMD Features=0x10NX real memory = 1064828928 (1015 MB) avail memory = 1028284416 (980 MB) ACPI APIC Table: A M I OEMAPIC ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: A M I OEMRSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3f70 (3) failed Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0x18 port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xec00-0xec07 mem 0xf7f0-0xf7f7,0xd000-0xdfff,0xf7ec-0xf7ef irq 16 at device 2.0 on pci0 agp0: Intel 82915GM (915GM GMCH) SVGA controller on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: VGA-compatible display mem 0xf7f8-0xf7ff at device 2.1 on pci0 hdac0: Intel 82801F High Definition Audio Controller mem 0xf7eb8000-0xf7ebbfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090131_0127 hdac0: [ITHREAD] pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci3: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 18 at device 28.2 on pci0 pci1: ACPI PCI bus on pcib2 ath0: Atheros 5424/2424 mem 0xfbff-0xfbff irq 18 at device 0.0 on pci1 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:15:af:b2:ae:e6 ath0: mac 14.2 phy 7.0 radio 10.2 uhci0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0xe400-0xe41f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0xe480-0xe49f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C port 0xe800-0xe81f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D port 0xe880-0xe89f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801FB (ICH6) USB 2.0 controller mem 0xf7eb7c00-0xf7eb7fff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801FB (ICH6) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb4 uhub4: 8 ports with 8 removable, self powered umass0: ENE UB6225, class 0/0, rev 2.00/1.00, addr 2 on uhub4 pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib3 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH6M SATA150 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Bruce Simpson b...@incunabulum.net To: Matthias Apitz matthias.ap...@oclc.org Cc: bug-follo...@freebsd.org, freebsd-net@FreeBSD.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 10:39:32 + Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
El día Tuesday, March 17, 2009 a las 10:39:32AM +, Bruce Simpson escribió: Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. It is an Asus EeePC 900, not the 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. as I said the Wifi works in all places, but not with this special AP (while a Nokia cellphone can associate and DHCP without problems); let me know if you need more info; Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e matthias.ap...@oclc.org - w http://www.oclc.org/ http://www.UnixArea.de/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-STABLE #1: Tue Mar 10 11:42:48 CET 2009 g...@rebelion.sisis.de:/usr/src/sys/i386/compile/REBELION Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) M processor 900MHz (900.10-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6d8 Stepping = 8 Features=0xafe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,PBE AMD Features=0x10NX real memory = 1064828928 (1015 MB) avail memory = 1028284416 (980 MB) ACPI APIC Table: A M I OEMAPIC ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: A M I OEMRSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3f70 (3) failed Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0x18 port 0x62,0x66 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xec00-0xec07 mem 0xf7f0-0xf7f7,0xd000-0xdfff,0xf7ec-0xf7ef irq 16 at device 2.0 on pci0 agp0: Intel 82915GM (915GM GMCH) SVGA controller on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M vgapci1: VGA-compatible display mem 0xf7f8-0xf7ff at device 2.1 on pci0 hdac0: Intel 82801F High Definition Audio Controller mem 0xf7eb8000-0xf7ebbfff irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090131_0127 hdac0: [ITHREAD] pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci3: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 18 at device 28.2 on pci0 pci1: ACPI PCI bus on pcib2 ath0: Atheros 5424/2424 mem 0xfbff-0xfbff irq 18 at device 0.0 on pci1 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:15:af:b2:ae:e6 ath0: mac 14.2 phy 7.0 radio 10.2 uhci0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0xe400-0xe41f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0xe480-0xe49f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C port 0xe800-0xe81f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D port 0xe880-0xe89f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801FB (ICH6) USB 2.0 controller mem 0xf7eb7c00-0xf7eb7fff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801FB (ICH6) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb4 uhub4: 8 ports with 8 removable, self powered umass0: ENE UB6225, class 0/0, rev 2.00/1.00, addr 2 on uhub4 pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib3 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH6M SATA150 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.2 on pci0 ata0: ATA channel 0 on atapci0 ata0: [ITHREAD] ata1: ATA channel 1 on atapci0 ata1: [ITHREAD] pci0: serial bus, SMBus at device 31.3 (no driver attached) acpi_asus0: ASUS EeePC on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Sleep Button on acpi0 acpi_button1: Power Button on acpi0 acpi_tz0: Thermal Zone on acpi0 battery0: ACPI Control Method Battery on acpi0 acpi_acad0: AC Adapter on acpi0
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Matthias Apitz g...@unixarea.de To: Bruce Simpson b...@incunabulum.net Cc: Matthias Apitz matthias.ap...@oclc.org, freebsd-net@freebsd.org, bug-follo...@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 11:45:48 +0100 El día Tuesday, March 17, 2009 a las 10:39:32AM +, Bruce Simpson escribió: Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. It is an Asus EeePC 900, not the 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. as I said the Wifi works in all places, but not with this special AP (while a Nokia cellphone can associate and DHCP without problems); let me know if you need more info; Thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e matthias.ap...@oclc.org - w http://www.oclc.org/ http://www.UnixArea.de/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()
On Tue, 2009-03-17 at 08:12 +, Bruce Simpson wrote: Sam Leffler wrote: It is the same issue but the root cause is unclear. There is much code that does assumes ifma_protospec might be NULL and checks for it. In my case (creating a wlan ifnet and then destroying it on eject) the patch below is sufficient. I don't care to dig right now to understand how this stuff is supposed to work; it should be clear from comments etc but the code is lacking. This is just to say I've tried to reproduce the 802.11 related panics, however have hit a brick wall because the PCI-CardBus bridge does not seem to detect anything in its slot. (1U Itox Expanding Dragon industrial PC w/a SiteCom branded Ricoh RL475 cardbus card). I tried unloading if_fxp with IGMPv3 active on the ifnet, and didn't see any panic, I'm assuming this is OK for the time being. Qing Li volunteered to test IGMPv3 out for any VLAN related issues -- I understand it stacks ifnets in a similar way to that of 802.11 -- however I have had no feedback from him since last week. So I'm waiting for a HEAD build to a USB2 stick to finish, so I can try testing nondestructively on my laptop, where I know for sure that the PCI-CardBus bridge slot works, and I can detach an 802.11 card on the fly. Re ifma_protospec: Yes, there are tricks in the ifnet/in layer which set it to NULL and look for it to be NULL. I ended up doing it this way mainly because adding reference counting to ifnet would have simply been too much work, and it's really a ball that needs to be kicked around at a dev summit. However time presses on and it's better to get SOMETHING out there. Most likely the IGMPv3 changes are hitting this in the 802.11 case somehow, I don't have a complete picture of how/why/what's going on, and have been relying on feedback from others so far. cheers BMS Today I played with it a bit. I've been unable to produce the crash on my wired (if_bge) interface, however it happens regularly on my wireless (ndis0/wlan0) interface. I was unable to get a core dump for other reasons. However, on my system I do not get the crash if I turn off avahi_daemon (set avahi_daemon_enable=NO in /etc/rc.conf). I tried booting to single user, ran dhclient on wlan0 (after setting it up properly), and then proceeded to boot the system multi-user. As soon as avahi went live, the kernel panicked, as above. If you are looking for a reliable test case, this might be it for you, but I think you need a wlan interface to test it with: * Install net/avahi from ports * Set avahi_daemon_enable=YES in rc.conf * Configure VAP params for wlan0 card in rc.conf * Log in and run dhclient wlan0 to trigger the panic -- Coleman Kane signature.asc Description: This is a digitally signed message part
Re: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()
Coleman Kane wrote: If you are looking for a reliable test case, this might be it for you, but I think you need a wlan interface to test it with: * Install net/avahi from ports * Set avahi_daemon_enable=YES in rc.conf * Configure VAP params for wlan0 card in rc.conf * Log in and run dhclient wlan0 to trigger the panic Actually I was able to panic the kernel right away with the 802.11 code, just by joining a multicast group with mtest(8) on the wlan interface. i.e. # mtest j 224.0.0.2 192.168.x.x - boom I believe I've found the symptom, but the root cause I don't fully understand. Sam indicated that the VAP code is using ifma's in some nested way between the ifnets which comprise the VAP's member interfaces. A workaround is pending cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()
A suitably kludgy fix for this issue has now been committed to HEAD. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
On Tue, 17 Mar 2009, Matthias Apitz wrote: El día Tuesday, March 17, 2009 a las 10:39:32AM +, Bruce Simpson escribió: Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. It is an Asus EeePC 900, not the 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. as I said the Wifi works in all places, but not with this special AP (while a Nokia cellphone can associate and DHCP without problems); let me know if you need more info; Is the AP made by Aruba Networks? On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of wpa_supplicant for it to associate correctly. With v0.5.10, I could see DHCP requests from my laptop but no responses. This is the patch I am using currently: http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. Sean -- s...@freebsd.org___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Sean C. Farley s...@freebsd.org To: Matthias Apitz g...@unixarea.de Cc: Bruce Simpson b...@incunabulum.net, freebsd-net@FreeBSD.org, Matthias Apitz matthias.ap...@oclc.org, bug-follo...@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 11:55:32 -0500 (CDT) This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --56599777-302749604-1237308518=:51892 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: alpine.bsf.2.00.0903171149121.51...@thor.farley.org On Tue, 17 Mar 2009, Matthias Apitz wrote: El día Tuesday, March 17, 2009 a las 10:39:32AM +, Bruce Simpson escribió: Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. It is an Asus EeePC 900, not the 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. as I said the Wifi works in all places, but not with this special AP (while a Nokia cellphone can associate and DHCP without problems); let me know if you need more info; Is the AP made by Aruba Networks? On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of wpa_supplicant for it to associate correctly. With v0.5.10, I could see DHCP requests from my laptop but no responses. This is the patch I am using currently: http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. Sean -- s...@freebsd.org --56599777-302749604-1237308518=:51892-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
Sean C. Farley wrote: On Tue, 17 Mar 2009, Matthias Apitz wrote: El día Tuesday, March 17, 2009 a las 10:39:32AM +, Bruce Simpson escribió: Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. It is an Asus EeePC 900, not the 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. as I said the Wifi works in all places, but not with this special AP (while a Nokia cellphone can associate and DHCP without problems); let me know if you need more info; Is the AP made by Aruba Networks? On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of wpa_supplicant for it to associate correctly. With v0.5.10, I could see DHCP requests from my laptop but no responses. This is the patch I am using currently: http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. His setup is static key wep; not wpa so I don't think wpa_supplicant is the issue. Matthias, your tcpdump of the dhclient packets isn't usable; please try: tcpdump -i ath0 -n -y IEEE802_11_RADIO I reviewed the driver to the code in HEAD and the only difference in the crypto area should not matter in this case. It's possible wme is somehow enabled and causing problems but the ifconfig output doesn't indicate that. If you can find out the model of ap that might be helpful. Unfortunately the best thing to try is HEAD. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: IGMP+WiFi panic on recent kernel - in igmp_fasttimo()
Bruce Simpson wrote: Coleman Kane wrote: If you are looking for a reliable test case, this might be it for you, but I think you need a wlan interface to test it with: * Install net/avahi from ports * Set avahi_daemon_enable=YES in rc.conf * Configure VAP params for wlan0 card in rc.conf * Log in and run dhclient wlan0 to trigger the panic Actually I was able to panic the kernel right away with the 802.11 code, just by joining a multicast group with mtest(8) on the wlan interface. i.e. # mtest j 224.0.0.2 192.168.x.x - boom I believe I've found the symptom, but the root cause I don't fully understand. Sam indicated that the VAP code is using ifma's in some nested way between the ifnets which comprise the VAP's member interfaces. A workaround is pending net80211 uses the public api's to push mcast addresses from the vap's to the parent ifnet. It does not directly frob any internal data structures except to workaround the ioctl-based callback out of the mcast code when adding an address. Look at ieee80211_ioctl_updatemulti for details. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work
The following reply was made to PR kern/132722; it has been noted by GNATS. From: Sam Leffler s...@freebsd.org To: Sean C. Farley s...@freebsd.org Cc: Matthias Apitz g...@unixarea.de, Matthias Apitz matthias.ap...@oclc.org, freebsd-net@freebsd.org, Bruce Simpson b...@incunabulum.net, bug-follo...@freebsd.org Subject: Re: kern/132722: [ath] Wifi ath0 associates fine with AP, but DHCP or IP does not work Date: Tue, 17 Mar 2009 11:56:24 -0700 Sean C. Farley wrote: On Tue, 17 Mar 2009, Matthias Apitz wrote: El día Tuesday, March 17, 2009 a las 10:39:32AM +, Bruce Simpson escribió: Matthias Apitz wrote: as requested the output of dmesg(1) and the ath0 related part of 'pciconf -lv'; pls note also that the Wifi works fine in general, i.e. with the AP in my office (WPA) and in my home (WEP); Is this an ASUS Eee PC? If so, which model is it? It looks like a 901. It is an Asus EeePC 900, not the 901. I tested OK with the 701. Sam said that there may be models of ath(4) requiring further changes to be back-ported from -CURRENT, this could well be one of them. as I said the Wifi works in all places, but not with this special AP (while a Nokia cellphone can associate and DHCP without problems); let me know if you need more info; Is the AP made by Aruba Networks? On RELENG_7, I needed a newer version (v0.5.11 instead of v0.5.10) of wpa_supplicant for it to associate correctly. With v0.5.10, I could see DHCP requests from my laptop but no responses. This is the patch I am using currently: http://people.freebsd.org/~scf/wpa_supplicant-0.5.11-RELENG_7.patch Note: sam@ updated HEAD to v0.5.11 then to the v0.6.x series. His setup is static key wep; not wpa so I don't think wpa_supplicant is the issue. Matthias, your tcpdump of the dhclient packets isn't usable; please try: tcpdump -i ath0 -n -y IEEE802_11_RADIO I reviewed the driver to the code in HEAD and the only difference in the crypto area should not matter in this case. It's possible wme is somehow enabled and causing problems but the ifconfig output doesn't indicate that. If you can find out the model of ap that might be helpful. Unfortunately the best thing to try is HEAD. Sam ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Dynamic loading of network kernel modules?
I made a minor change to ifconfig to try kldloading the interface name
specified on the create wlandev (ifconfig already tries for
normal invocations, just needed to try with the wlandev interface)
/usr/src/sbin/ifconfig/ifieee80211.c
--- ifieee80211.c.original 2009-03-17 16:53:29.0 -0400
+++ ifieee80211.c 2009-03-17 16:53:43.0 -0400
@@ -4673,6 +4673,7 @@
memcmp(params.icp_bssid, zerobssid, sizeof(zerobssid)) == 0)
errx(1, no bssid specified for WDS (use wlanbssid));
ifr-ifr_data = (caddr_t) params;
+ ifmaybeload(params.icp_parent);
if (ioctl(s, SIOCIFCREATE2, ifr) 0)
err(1, SIOCIFCREATE2);
}
This works nicely, however at startup, I still do not get the
interface up, or the kernel module loaded, so a second patch is
needed.
At issue is the list_net_interfaces() function in
/etc/rc.d/network.subr, which assumes that the greatest possible list
of interfaces is that which 'ifconfig -l' can give us. Unfortunately,
this puts us in a bit of a chicken and egg situation for network
interfaces that are modules.
I also have a patch to network.subr that will look for any manually
configured interfaces in rc.conf that are not in the list of 'ifconfig
-l', and will try to start those interfaces as well. {specifically
looking for ifconfig_xxx and wlans_xxx and ipv6_ifconfig_xxx}
/etc/network.subr
--- network.subr.base_0317 2009-03-17 17:00:01.0 -0400
+++ network.subr2009-03-17 17:10:15.0 -0400
@@ -690,6 +690,34 @@
return 0
}
+# getconf_ifnames
+# Return the value of all of the interfaces names referenced in rc.conf
+# This is used to attempt to dynamically load kernel modules that
+# are not already loaded, but could also be useful elsewhere
+#
+# wlans_IF, ifconfig_IF, ipv6_ifconfig_IF are currently used
+getconf_ifnames()
+{
+ local val
+ matching_vars=`set | grep -e ifconfig_ -e ^wlans_ | tr \n
| tr -d '=.`
+ debug Here is a list of all of the matching variables: $matching_vars
+ for i in ${matching_vars}; do
+ val=
+ val=`expr ${i} : 'ifconfig_\([a-zA-Z]*[0-9]*\).*'`
+ if [ -z $val ]; then
+ val=`expr ${i} : 'wlans_\([a-zA-Z]*[0-9]*\).*'`
+ fi
+ if [ val != 0 -a -n $val ]; then
+ interfaces=${interfaces} $val
+ fi
+ done
+
+ debug Here are the rc.conf potential interfaces: $interfaces
+ echo $interfaces
+ exit 0
+}
+
+
#
# list_net_interfaces type
# List all network interfaces. The type of interface returned
@@ -712,6 +740,9 @@
[Aa][Uu][Tt][Oo])
_prefix=''
_autolist=`ifconfig -l`
+ _manuallist=`getconf_ifnames`
+ _autolist=$_autolist$_manuallist
+ debug list of all interfaces: $_autolist
_lo=
for _if in ${_autolist} ; do
if autoif $_if; then
Is this something that people would be interested in having commited?
If so, I can clean up a little bit and remove the duplicate interfaces
and debugging, and add getconf_ifnames() in more places. Both patches
are against current from today (031709).
--Thanks!
-_Dave Horn
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ae(4) Wake-on-Lan MFC
On 03/17/09 07:44, Bruce Simpson wrote:
Hi,
I noticed that ae(4) got MFC'ed to RELENG_7 before Wake-on-Lan support did.
However, WOL support is now there, and it looks like the change can just
go in:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ae/if_ae.c.diff?r1=1.1.2%3ARELENG_7tr1=1.1r2=1.3%3AHEADtr2=1.3
I am tied up looking at other stuff at the moment, it would be nice to
merge the change, but low priority for me right now.
BTW, it still seems easier to use cvsweb to pull a diff between FreeBSD
branches since the SVN change,
does anyone know an easier way?
thanks
BMS
The following can be used:
svn diff svn://svn.freebsd.org/base/stable/7/sys/dev/ae/if_ae.c \
svn://svn.freebsd.org/base/head/sys/dev/ae/if_ae.c
For exact revisions, append @{rev} to URLs (consult ``svn diff --help``).
It also works for directories and trees but you need to be play with
that a bit.
Volker
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: ae(4) Wake-on-Lan MFC
On Tue, Mar 17, 2009 at 07:44:43AM +, Bruce Simpson wrote:
Hi,
I noticed that ae(4) got MFC'ed to RELENG_7 before Wake-on-Lan support did.
I think WOL MFC was done before ae(4) MFC.
However, WOL support is now there, and it looks like the change can just
go in:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ae/if_ae.c.diff?r1=1.1.2%3ARELENG_7tr1=1.1r2=1.3%3AHEADtr2=1.3
I am tied up looking at other stuff at the moment, it would be nice to
merge the change, but low priority for me right now.
Do you have ae(4) hardware? I'm not sure why stas@ removed WOL part
in the MFC but it could be lack of testing(CCed to stas@). I've
attached diff that includes WOL support from HEAD.
BTW, it still seems easier to use cvsweb to pull a diff between FreeBSD
branches since the SVN change,
does anyone know an easier way?
thanks
BMS
Index: sys/dev/ae/if_ae.c
===
--- sys/dev/ae/if_ae.c (revision 189940)
+++ sys/dev/ae/if_ae.c (working copy)
@@ -380,8 +380,10 @@
ifp-if_snd.ifq_drv_maxlen = IFQ_MAXLEN;
IFQ_SET_MAXLEN(ifp-if_snd, ifp-if_snd.ifq_drv_maxlen);
IFQ_SET_READY(ifp-if_snd);
- if (pci_find_extcap(dev, PCIY_PMG, pmc) == 0)
+ if (pci_find_extcap(dev, PCIY_PMG, pmc) == 0) {
+ ifp-if_capabilities |= IFCAP_WOL_MAGIC;
sc-flags |= AE_FLAG_PMG;
+ }
ifp-if_capenable = ifp-if_capabilities;
/*
@@ -1329,6 +1331,7 @@
struct ifnet *ifp;
uint32_t val;
uint16_t pmstat;
+ struct mii_data *mii;
int pmc;
AE_LOCK_ASSERT(sc);
@@ -1340,8 +1343,41 @@
return;
}
- ae_powersave_enable(sc);
+ /*
+ * Configure WOL if enabled.
+ */
+ if ((ifp-if_capenable IFCAP_WOL) != 0) {
+ mii = device_get_softc(sc-miibus);
+ mii_pollstat(mii);
+ if ((mii-mii_media_status IFM_AVALID) != 0
+ (mii-mii_media_status IFM_ACTIVE) != 0) {
+ AE_WRITE_4(sc, AE_WOL_REG, AE_WOL_MAGIC | \
+ AE_WOL_MAGIC_PME);
+ /*
+ * Configure MAC.
+ */
+ val = AE_MAC_RX_EN | AE_MAC_CLK_PHY | \
+ AE_MAC_TX_CRC_EN | AE_MAC_TX_AUTOPAD | \
+ ((AE_HALFBUF_DEFAULT AE_HALFBUF_SHIFT) \
+ AE_HALFBUF_MASK) | \
+ ((AE_MAC_PREAMBLE_DEFAULT \
+ AE_MAC_PREAMBLE_SHIFT) AE_MAC_PREAMBLE_MASK) | \
+ AE_MAC_BCAST_EN | AE_MAC_MCAST_EN;
+ if ((IFM_OPTIONS(mii-mii_media_active) \
+ IFM_FDX) != 0)
+val |= AE_MAC_FULL_DUPLEX;
+ AE_WRITE_4(sc, AE_MAC_REG, val);
+
+ } else { /* No link. */
+ AE_WRITE_4(sc, AE_WOL_REG, AE_WOL_LNKCHG | \
+ AE_WOL_LNKCHG_PME);
+ AE_WRITE_4(sc, AE_MAC_REG, 0);
+ }
+ } else {
+ ae_powersave_enable(sc);
+ }
+
/*
* PCIE hacks. Magic numbers.
*/
@@ -1358,6 +1394,8 @@
pci_find_extcap(sc-dev, PCIY_PMG, pmc);
pmstat = pci_read_config(sc-dev, pmc + PCIR_POWER_STATUS, 2);
pmstat = ~(PCIM_PSTAT_PME | PCIM_PSTAT_PMEENABLE);
+ if ((ifp-if_capenable IFCAP_WOL) != 0)
+ pmstat |= PCIM_PSTAT_PME | PCIM_PSTAT_PMEENABLE;
pci_write_config(sc-dev, pmc + PCIR_POWER_STATUS, pmstat, 2);
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: kern/132734: [if_mib] [panic] panic in net/if_mib.c
Old Synopsis: panic in net/if_mib.c New Synopsis: [if_mib] [panic] panic in net/if_mib.c Responsible-Changed-From-To: freebsd-bugs-freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Mar 18 03:23:58 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=132734 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
netgraph modules won't unload after use
I'm developing a kernel module that will be doing inspection and needed access to raw network frames, so I turned to netgraph as the solution.However it seems that netgraph will not permit a module to unload once it's participated in a mkpeer/connect operation. Rebooting to remove a module is angrymaking (not like mtx/sleep crashes). This going into the kernel because my bpf based userland stuff is probably not going to hold up to the packet rate. Should I file a PR? Or is there magic in the documentation I havn't found? I've observed the trouble in 7.0 release, and tonight's 7_RELENG, with GENERIC + WITNESS/INVARIANTS The module code ( cobbled together from netgraph/ng_sample.c / ng_echo.c) http://pastebin.com/m31b6ece6 The module loads and unloads fine until connected to a netgraph hook: #make load :ro:~/tmp/ food.ko:3:06:42:20 /sbin/kldload -v /root/tmp/food.ko/food.ko Loaded /root/tmp/food.ko/food.ko, id=3 #Mar 18 03:06:44 kernel: foodmod loaded:ro:~/tmp/ food.ko:3:06:44:21 #make unload:ro:~/tmp/ food.ko:3:10:16:21 /sbin/kldunload -v food.ko Unloading food.ko, id=3 #Mar 18 03:10:19 kernel: quiesced :ro:~/tmp/ food.ko:3:10:19:22 Mar 18 03:10:19 kernel: foodmod unloaded Fine.. so let's connect it: #make ath :ro:~/tmp/ food.ko:3:10:59:23 kldload ng_ether ifconfig ath0 ssid ')(allmightytallest' ifconfig ath0 promisc #Mar 18 03:11:04 kernel: ath0: permanently promiscuous mode enabledo:3:11:04:24 make connect #make load :ro:~/tmp/ food.ko:3:11:13:26 /sbin/kldload -v /root/tmp/food.ko/food.ko Loaded /root/tmp/food.ko/food.ko, id=7 #Mar 18 03:12:05 kernel: foodmod loaded make connect ngctl mkpeer ath0: food lower fredhook ngctl name ath0:lower eater sleep 1 Mar 18 03:12:15 kernel: ngconstruct ifconfig ath0 down ifconfig ath0 up #Mar 18 03:12:18 kernel: not our messageunrecognized command/ food.ko:3:12:16:28 Mar 18 03:12:18 kernel: ath0: link state changed to UP # :ro:~/tmp/ food.ko:3:12:18:28 #Mar 18 03:12:21 kernel: Fine; we get packets to the ng_rx_data procedure .. now we pull the plug on the netgraph #make discon:ro:~/tmp/ food.ko:3:12:35:28 ngctl shutdown eater: #Mar 18 03:12:37 kernel: discondiconnecting last ng nodengshutdownko:3:12:36:29 #ngctl list :ro:~/tmp/ food.ko:3:12:39:29 There are 3 total nodes: Name: bge0Type: ether ID: 0001 Num hooks: 0 Name: ngctl1058 Type: socket ID: 0008 Num hooks: 0 Name: ath0Type: ether ID: 0002 Num hooks: 0 But the module will never unload: ( but the UNLOAD and QUIESE event handlers are invoked) #make unload:ro:~/tmp/ food.ko:3:14:28:31 /sbin/kldunload -vf food.ko Unloading food.ko, id=7 kldunload: can't unload file: Device busy *** Error code 1 Stop in /root/tmp/food.ko. Exit 1 #Mar 18 03:14:31 kernel: quiesced :ro:~/tmp/ food.ko:3:14:31:32 Mar 18 03:14:31 kernel: foodmod unloaded Seems that I can't unload some of the other netgraph types either ( it's not just me): #kldunload ng_ether :ro:~/tmp/ food.ko:3:24:07:41 kldunload: can't unload file: Device busy Exit 1 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
