Re: vlan+iwn panic
On Mon, Jun 18, 2012 at 12:52 PM, David ROFFIAEN d...@roffiaen.com wrote: Hi list, I encoutered a panic with FreeBSD 9 Stable creating vlan with wlan0 (iwn0) parent. Panic occur when upping the vlan : Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff800024b3f0 frame pointer = 0x28:0xff800024b4b0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi4: clock) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x80625896 at kdb_backtrace+0x66 #1 0x805ed71e at panic+0x1ce #2 0x80887690 at trap_fatal+0x290 #3 0x808879fc at trap_pfault+0x21c #4 0x80887ff5 at trap+0x365 #5 0x80872713 at calltrap+0x8 #6 0x807b9968 at nd6_output+0x18 #7 0x807b41ed at ip6_output+0x11dd #8 0x807b4c8c at mld_dispatch_packet+0xdc #9 0x807b5121 at mld_dispatch_queue+0x21 #10 0x807b7ac0 at mld_fasttimo+0x640 #11 0x8064fdbb at pffasttimo+0x2b #12 0x80603540 at softclock+0x3c0 #13 0x805bf3e4 at intr_event_execute_handlers+0x104 #14 0x805c0b64 at ithread_loop+0xa4 #15 0x805bc04f at fork_exit+0x11f #16 0x80872c3e at fork_trampoline+0xe I don't see this on HEAD, so some commit might have fixed it, not certain which one though. I'm running into another panic though. This problem doesn't occur with atheros card on SOEKRIS (i386). Just the up works or can you even do traffic? I'm not so sure about the later, I'm not aware that wlan+vlan has ever be tested. If it works for ath though, I'll look into the iwn part. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vlan+iwn panic
On Mon, Jun 18, 2012 at 3:30 PM, Albert Shih albert.s...@obspm.fr wrote: Le 18/06/2012 ? 12:52:19+0200, David ROFFIAEN a écrit Hi list, I encoutered a panic with FreeBSD 9 Stable creating vlan with wlan0 (iwn0) parent. Panic occur when upping the vlan : I've same problem whitout vlan. Just sometime (rarely) when the signal of the wifi is very weak the system crash with something very close. Very close? Do you mean same backtrace? Write a report next time you run into it please, preferably with a way to reproduce. -- Bernhard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to bind a route to a network adapter and not IP
On Monday 18 June 2012 18:07 Hans Petter Selasky wrote: On Monday 18 June 2012 23:03:34 H wrote: On Monday 18 June 2012 12:54 Hans Petter Selasky wrote: On Monday 18 June 2012 00:00:51 H wrote: sth...@nethelp.no wrote: I loose packets because I use a WLAN adapter. Sometimes the link is down for various reasons, and then the routes start changing for manually created routes, and I want to prevent that. well that is certainly not a reason for changing routes I have the feeling you are not explaining good enough what really is going on and it may help sending your configurations and an example of routes and IP addresses before and after this route change Why is this so hard to understand? Link down leads to static route is deleted. This is standard FreeBSD behavior, and has been this way for as long as I can remember (btw, I believe this behavior is from the original BSD, not FreeBSD specific). You can show this by having a static default route pointing to an address on an Ethernet interface which has link. And then pulling the TP cable from the Ethernet interface. Observe that the default route is automatically removed. may be you have not understood your own problem yet because so far is nothing to be understood because none of your statements is correct, it is also not FreeBSD's standard behavior and never has been as long as there is the valid IP address on the related interface, no static route will be deleted, you can even boot without cable and the [default] static route is there so you need to explain better your problem in order to understand it probably you have some other stuff running, thirdparty network manager or something, incorrect or incomplete ppoe or dhc configuration or whatever leads to the problem FYI static routes usually are the manually configured routes, so what you say is redundant and not correct, I guess you're loosing some kind of dynamic route since WL networks usually do not run RIP/OSPF/BGP I guess the route you apparently loose is coming from some dhcp server and may be your dhclient configuration is incomplete or none existent, but here now it would be useful to see your config Hi, I think we need to distinguish between two matters. One is where the route is directly reachable on the local-net of the network adapter, and ARP is valid/responding. The second case is when the route is not directly reachable. The second case is where the problem happens, like Stian kindly explained. # For example: ifconfig wlan0 10.0.0.2 255.255.255.0 up # Assume the router is at 10.0.0.1 # And we want to reach a certain destination through 10.0.0.1 # Then we do: route add 10.22.1.1 10.0.0.1 no no no my friend, wrong again that is a static route and it goes away same way it was created, manually or by deleting the IP address 10.0.0.2 from the related interface wether there is or not an active link on that interface does not matter Hi, Can it be that dhclient which I'm running on this interface with manual routes disrupts stuff then ?? so now we're coming to the point ... on renewal of the IP address the interface is set do down, old IP removed and the new one (even if the same as before) is associated and the IF comes up again means, any route associated get lost, you may get a new one (default) from the dhcp server you could set some options in your /etc/dhclient.conf to match your needs you could request a longer lease time, eventually reduce the retry time to get less down time check your log what the dhcp server send to you may be you try something like: timeout 60; retry 60; send dhcp-lease-time 36000; (or more to cover your longest up time) if the longer lease time does not work, then I guess then you could use the 'script name' option to set your special route after renewal Hans -- HM +55 17 8111.3300 signature.asc Description: This is a digitally signed message part.
Re: PF to Preventing SMTP Brute Force Attacks
Better use something like fail2ban. -- Best regards, Adrian Minta ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vlan+iwn panic
Le 19/06/2012 ? 08:46:22+0200, Bernhard Schmidt a écrit On Mon, Jun 18, 2012 at 3:30 PM, Albert Shih albert.s...@obspm.fr wrote: Le 18/06/2012 ? 12:52:19+0200, David ROFFIAEN a écrit Hi list, I encoutered a panic with FreeBSD 9 Stable creating vlan with wlan0 (iwn0) parent. Panic occur when upping the vlan : I've same problem whitout vlan. Just sometime (rarely) when the signal of the wifi is very weak the system crash with something very close. Very close? Do you mean same backtrace? Write a report next time you run into it please, preferably with a way to reproduce. Yes I known, my bad. In fact I'm in very hury when the second time the problem appear so I just push poweroff buttom. When I say it's very close is «a look» on the console. So is'nt a good comparaisonnot a comparaison at all. All I can say is when I'm near the wifi router, everything works fine. Regards. -- Albert SHIH DIO bâtiment 15 Observatoire de Paris 5 Place Jules Janssen 92195 Meudon Cedex Téléphone : 01 45 07 76 26/06 86 69 95 71 xmpp: j...@jabber.obspm.fr Heure local/Local time: mar 19 jui 2012 11:12:40 CEST ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Kernel panic at early boot time
On Sunday, June 17, 2012 2:35:14 pm mnln.l4 wrote: I get a kernel panic at early boot time on 9.0-stable (r237150), GENERIC, AMD64. Repro step: 1. Boot, wait for welcome screen. 2. Repeat pressing Enter key rapidly (so kernel is loading, don't stop pressing Enter key). 3. See the following message at early boot So don't do that. All your key presses are triggering SMI# events that are interfering with the AP's ability to respond to its startup IPI. There is nothing we can do about this in the OS. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mpt: Unable to memory map registers
On Tuesday, June 19, 2012 9:03:57 am Andrey Zonov wrote: On Mon, Jun 18, 2012 at 6:26 PM, John Baldwin j...@freebsd.org wrote: On Saturday, June 16, 2012 6:10:47 am Andrey Zonov wrote: On 6/15/12 9:24 PM, John Baldwin wrote: On Friday, June 15, 2012 2:12:06 am Andrey Zonov wrote: On 6/13/12 7:10 PM, John Baldwin wrote: On Tuesday, June 12, 2012 5:57:34 pm Andrey Zonov wrote: On 6/13/12 12:51 AM, John Baldwin wrote: On Tuesday, June 12, 2012 3:53:09 pm Andrey Zonov wrote: On 6/12/12 10:06 PM, John Baldwin wrote: [snip] Ok, I've added some more debugging. The patch is a bit larger now and you can fetch it from www.freebsd.org/~jhb/patches/pcib_debug.patch New dmesg is in attach. Sheesh, found another bug (wasn't masking 'front' properly). Try updated patch (same URL). Great! It works! Excellent. I've committed the 2 bugs needed to fix your box. However, there is another bug that this exposed that I'd like you to test. Can you update to the latest HEAD, apply the updated pcib_debug.patch, and boot with 'hw.pci.pcib_clear=1' set from the loader? That should exercise the bug I'm worried about and see if my fixes for that (recursively growing windows) works correctly. Attached. Hmm, it doesn't seem like hw.pci.pcib_clear was set (the pcibX devices still tried to allocate their initial windows). Ooops. Thanks. Unfortunately, this didn't actually exercise what I wanted, but that is ok. However, this did uncover another bug it seems: pcib7: ACPI PCI-PCI bridge at device 0.3 on pci5 pci6: ACPI PCI bus on pcib7 pci6: domain=0, physical bus=6 found- vendor=0x1000, dev=0x0054, revid=0x02 pcib3: attempting to grow I/O port window for (0xd000-0xdfff,0x1000) front candidate range: 0xd000-0xdfff pcib3: bus_adjust_resource(0xc000, 0xefff) pci0: bus_adjust_resource(pcib3, 0x1c, 0xc000, 0xefff) pcib0: bus_adjust_resource(pcib3, 0x1c, 0xc000, 0xefff) acpi0: bus_adjust_resource(pcib3, 0x1c, 0xc000, 0xefff) nexus0: bus_adjust_resource(pcib3, 0x1c, 0xc000, 0xefff) pcib3: grew I/O port window to 0xc000-0xefff pcib3: allocated I/O port range (0xd000-0xdfff) for rid 1c of pcib7 pcib7: allocated initial I/O port window of 0xd000-0xdfff This grew the range too large resulting in this failure later on: pcib9: failed to allocate initial I/O port window (0xc000-0xcfff,0x1000) Can you try the updated pcib_debug.patch? It has some more printf's for this case. Sure. Ok, found the bug, thanks! -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Kernel modules are broken after updating to the latest FreeBSD9-STABLE
No I didn't miss the buildkernel/installkernel steps :) I've tried everything from deleting /usr/obj /usr/src, csup'ing a new source to make build/kernel/world without -j I see with uname -a that the kernel date is in february (last time updated this server). Why doesn't it update to june? /boot/kernel is created in june. Is it something wrong with my source files? Should I try updating with cvsup instead of csup? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Diskless ignore remount - fix (Re: conf/158127: [patch] remount_optional option in rc.initdiskless doesn#39; t actually work)
I notice that PR 158127 remains outstanding, June, 2011. I've enclosed a
patch for Stable 9.0, to correct diskless booting. When a mountpoint
fails, the failure may be ignored as required/documented.
--- /tmp/rc.initdiskless2012-06-19 19:01:33.0 +1000
+++ /etc/rc.initdiskless2012-06-19 19:02:16.0 +1000
@@ -166,7 +166,7 @@
chkerr() {
lastitem () ( n=$(($# - 1)) ; shift $n ; echo $1 )
mountpoint=$(lastitem $2)
-[ -r $mountpoint/remount_optional ] ( echo $2 failed: ignoring due
to remount_optional ; return )
+[ -r $mountpoint/remount_optional ] echo $2 failed: ignoring due
to remount_optional return
case $1 in
0)
The patch has been tested with/without /conf/default/etc/remount_optional
is functionally correct.
It would be appreciated if someone would verify and commit.
Regards, Dewayne.
PS My apologies if Outlook has corrupted the patches appearance,we have to
work with what we've got.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Seeking 6.4 make source for ports
Google is littered with messages from people who have 6.3 systems and can no longer upgrade ports. It appears that a recent change requires the version of make from 6.4. While it would be ideal if freebsd.org would build a 6.4 make on a 6.3 system and pseudo-officially support it, a reasonable alternative would be a simple way to download just the files required to build the 6.4 version of make on 6.3. Any possibility to get this tossed on a site someplace? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
