Re: panic possibly on on bridge member removal
On Monday, October 01, 2012 11:05:30 am Kim Culhan wrote:
> On Mon, Oct 1, 2012 at 9:49 AM, John Baldwin wrote:
> > On Monday, October 01, 2012 9:08:30 am Kim Culhan wrote:
> >> On Mon, Oct 1, 2012 at 8:04 AM, John Baldwin wrote:
> >> > On Saturday, September 29, 2012 8:40:03 am Kim Culhan wrote:
> >> >> After a few hours of operation involving tap0 added to the bridge
> >> >> running openvpn
> >> >> and shutting down openvpn which removes tap0 from the bridge, the
> >> >> machine is found to have a panic:
> >> >>
> >> >> Fatal trap 12: page fault while in kernel mode
> >> >> cpuid = 1; apic id = 01
> >> >> fault virtual address = 0x188
> >> >> fault code = supervisor read data, page not present
> >> >> instruction pointer = 0x20:0x82a14f96
> >> >> stack pointer = 0x28:0xff8000285670
> >> >> frame pointer = 0x28:0xff80002856b0
> >> >> 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 (swi5: fast taskq)
> >> >> [ thread pid 12 tid 100022 ]
> >> >> Stopped at bridge_enqueue+0x86:calll *0x188(%r12)
> >> >> db> bt
> >> >> Tracing pid 12 tid 100022 td 0xfe0003aff000
> >> >> bridge_enqueue() at bridge_enqueue+0x86
> >> >
> >> > Can you run 'gdb /boot/kernel/kernel' and do 'l *bridge_enqueue+0x86'?
> >> >
> >> > --
> >> > John Baldwin
> >>
> >> (gdb) l *bridge_enqueue+0x86
> >> No symbol "bridge_enqueue" in current context.
> >> (gdb)
> >
> > Oh, are you using if_bridge.ko as a module? If so, you can try running 'gdb
> > /boot/kernel/if_bridge.ko' instead.
>
> (gdb) l *bridge_enqueue+0x86
> 0x2f96 is in bridge_enqueue
> (/usr/src/sys/modules/if_bridge/../../net/if_bridge.c:1810).
> 1805continue;
> 1806}
> 1807m->m_flags &= ~M_VLANTAG;
> 1808}
> 1809
> 1810if ((err = dst_ifp->if_transmit(dst_ifp, m))) {
> 1811m_freem(m0);
> 1812break;
> 1813}
> 1814}
> (gdb)
Hmm, try this perhaps. I think there is a race where the departing bridge
member can be destroyed before the bridge code is finishing using it. The
way the bridge driver is supposed to prevent that is by ensuring that
bridge_ifdetach() doesn't return until all other references to the detaching
interface are known to be released in the bridge code. I think what is
happening for you is that a bridge_enqueue() performed outside the lock is
running into dst_ifp that has been if_free()'d and had its if_transmit set
to zero when it was reallocated for something else.
Index: if_bridge.c
===
--- if_bridge.c (revision 241096)
+++ if_bridge.c (working copy)
@@ -1833,6 +1833,7 @@ static void
bridge_dummynet(struct mbuf *m, struct ifnet *ifp)
{
struct bridge_softc *sc;
+ int error = 0;
sc = ifp->if_bridge;
@@ -1846,18 +1847,30 @@ bridge_dummynet(struct mbuf *m, struct ifnet *ifp)
return;
}
+ BRIDGE_LOCK(sc);
+ BRIDGE_LOCK2REF(sc, error);
+ if (error) {
+ m_freem(m);
+ return;
+ }
+
if (PFIL_HOOKED(&V_inet_pfil_hook)
#ifdef INET6
|| PFIL_HOOKED(&V_inet6_pfil_hook)
#endif
) {
- if (bridge_pfil(&m, sc->sc_ifp, ifp, PFIL_OUT) != 0)
+ if (bridge_pfil(&m, sc->sc_ifp, ifp, PFIL_OUT) != 0) {
+ BRIDGE_UNREF(sc);
return;
- if (m == NULL)
+ }
+ if (m == NULL) {
+ BRIDGE_UNREF(sc);
return;
+ }
}
bridge_enqueue(sc, ifp, m);
+ BRIDGE_UNREF(sc);
}
/*
@@ -1971,8 +1984,13 @@ sendunicast:
return (0);
}
- BRIDGE_UNLOCK(sc);
+ BRIDGE_LOCK2REF(sc, error);
+ if (error) {
+ m_freem(m);
+ return (0);
+ }
bridge_enqueue(sc, dst_if, m);
+ BRIDGE_UNREF(sc);
return (0);
}
@@ -2000,8 +2018,13 @@ bridge_transmit(struct ifnet *ifp, struct mbuf *m)
eh = mtod(m, struct ether_header *);
dst_if = bridge_rtlookup(sc, eh->ether_dhost, 1);
- BRIDGE_UNLOCK(sc);
- error = bridge_enqueue(sc, dst_if, m);
+ BRIDGE_LOCK2REF(sc, error);
+ if (error)
+ m_freem(m);
+ else {
+ error = bridge_enqueue(sc, dst_if, m);
+ BRIDGE_UNREF(sc);
+ }
} else
bridge_broadcast(sc, ifp, m, 0);
@@ -2145,20 +2168,29 @@ bridge_forward(struct bridge_s
Re: panic possibly on on bridge member removal
Sounds like dst_ifp is NULL at that point? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [patch] mmap() MAP_TEXT implementation (to use for shared libraries)
On Fri, Sep 7, 2012 at 9:40 PM, John Baldwin wrote: > On Friday, September 07, 2012 2:41:20 pm Konstantin Belousov wrote: >> > I think these would be rare? There's no good reason for anything to write >> > to >> > a shared library that I can think of. install(1) does an atomic rename to >> > swap >> > in the new libraries already. >> >> After a second thought, I do not like your proposal as well. +x is set for >> shebang scripts, and allowing PROT_EXEC to set VV_TEXT for them means >> that such scripts are subject for write denial. > > Yeah, that's fair. Also, I hunted around to find the description of MAP_TEXT > in Solaris 11. It seems from reading that that MAP_TEXT on Solaris isn't used > to prevent writes ala VV_TEXT. Instead, it is used as a hint that is > apparently used to use superpages for text. > > -- > John Baldwin Hi, I'd like to finish this thread somehow. For security sake, it looks that bounding VV_TEXT with MAP_TEXT is not good idea. Now, I see only two possibilities how to solve the shared libraries issue in general. 1. To have one more permission flag, first for files on which VV_TEXT can be set and second for files on which VV_TEXT may not be set. 2. To activate shared libraries in kernel. The whole situation is following. There are two basic kinds of binaries in system. The first ones only need to be activated, the second ones need to be interpreted by an interpreter which is activated already. While activation is a concern of kernel and should be done in kernel, an interpretation is a concern of an interpreter and as such is done in userland. Unfortunately, even so different in nature, both share x+ permission and can't be distinguished by it. The shared libraries issue is that even they can be activated only, they are interpreted by dynamic linker instead. As VV_TEXT is kernel flag and can be set safely by kernel only, there is no way how to protect them by the flag in this situation. Svata ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic possibly on on bridge member removal
On Mon, Oct 1, 2012 at 9:49 AM, John Baldwin wrote:
> On Monday, October 01, 2012 9:08:30 am Kim Culhan wrote:
>> On Mon, Oct 1, 2012 at 8:04 AM, John Baldwin wrote:
>> > On Saturday, September 29, 2012 8:40:03 am Kim Culhan wrote:
>> >> After a few hours of operation involving tap0 added to the bridge
>> >> running openvpn
>> >> and shutting down openvpn which removes tap0 from the bridge, the
>> >> machine is found to have a panic:
>> >>
>> >> Fatal trap 12: page fault while in kernel mode
>> >> cpuid = 1; apic id = 01
>> >> fault virtual address = 0x188
>> >> fault code = supervisor read data, page not present
>> >> instruction pointer = 0x20:0x82a14f96
>> >> stack pointer = 0x28:0xff8000285670
>> >> frame pointer = 0x28:0xff80002856b0
>> >> 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 (swi5: fast taskq)
>> >> [ thread pid 12 tid 100022 ]
>> >> Stopped at bridge_enqueue+0x86:calll *0x188(%r12)
>> >> db> bt
>> >> Tracing pid 12 tid 100022 td 0xfe0003aff000
>> >> bridge_enqueue() at bridge_enqueue+0x86
>> >
>> > Can you run 'gdb /boot/kernel/kernel' and do 'l *bridge_enqueue+0x86'?
>> >
>> > --
>> > John Baldwin
>>
>> (gdb) l *bridge_enqueue+0x86
>> No symbol "bridge_enqueue" in current context.
>> (gdb)
>
> Oh, are you using if_bridge.ko as a module? If so, you can try running 'gdb
> /boot/kernel/if_bridge.ko' instead.
(gdb) l *bridge_enqueue+0x86
0x2f96 is in bridge_enqueue
(/usr/src/sys/modules/if_bridge/../../net/if_bridge.c:1810).
1805continue;
1806}
1807m->m_flags &= ~M_VLANTAG;
1808}
1809
1810if ((err = dst_ifp->if_transmit(dst_ifp, m))) {
1811m_freem(m0);
1812break;
1813}
1814}
(gdb)
--
-lo,
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic possibly on on bridge member removal
On Monday, October 01, 2012 9:08:30 am Kim Culhan wrote: > On Mon, Oct 1, 2012 at 8:04 AM, John Baldwin wrote: > > On Saturday, September 29, 2012 8:40:03 am Kim Culhan wrote: > >> After a few hours of operation involving tap0 added to the bridge > >> running openvpn > >> and shutting down openvpn which removes tap0 from the bridge, the > >> machine is found to have a panic: > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 1; apic id = 01 > >> fault virtual address = 0x188 > >> fault code = supervisor read data, page not present > >> instruction pointer = 0x20:0x82a14f96 > >> stack pointer = 0x28:0xff8000285670 > >> frame pointer = 0x28:0xff80002856b0 > >> 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 (swi5: fast taskq) > >> [ thread pid 12 tid 100022 ] > >> Stopped at bridge_enqueue+0x86:calll *0x188(%r12) > >> db> bt > >> Tracing pid 12 tid 100022 td 0xfe0003aff000 > >> bridge_enqueue() at bridge_enqueue+0x86 > > > > Can you run 'gdb /boot/kernel/kernel' and do 'l *bridge_enqueue+0x86'? > > > > -- > > John Baldwin > > (gdb) l *bridge_enqueue+0x86 > No symbol "bridge_enqueue" in current context. > (gdb) Oh, are you using if_bridge.ko as a module? If so, you can try running 'gdb /boot/kernel/if_bridge.ko' instead. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart on macbook air
on Mon, 01 Oct 2012 12:29:02 +0400 "Andrey V. Elsukov" wrote: On 30.09.2012 23:06, Raoul MEGELAS wrote: >>> When you are deleting a partition, the kernel completely overwrites the >>> partition table and PMBR area. You can compare first 34 blocks before >>> deletion and after to see what is going on. >> >> I can understand that, but i would have thought >> that the deletion of the concerned partition was written preserving others??? >> >> something like: >> >> - read the gpt table >> - find the offset >> - zeroes the partition entry >> - rewrites the table? >> >> is not that logic? >> >> if it is not so, i does not understand this behaviour. > Hi, Raoul, > > The kernel has a copy of the partition table in the memory. > When you are deleting some partition, it removes the partition entry > from the memory, constructs updated GPT header and table, calculates > checksums and writes this data into corresponding places. > Any way, this should correctly work. > > My guess is that Apple's boot loader detects some changes and > just doesn't want to work. If you think that gpart incorrectly works, > please make a copy of first 34 blocks before and after deletion and > send them to me. Hi Andrey, You helped me to find the point: Apple maps the starting point of the first partition in the MBR like this: 01be 00 fe ff ff ee fe ff ff 01 when gpart maps: 01be: 80 00 02 00 ee ff ff ff 01 it is a 251G drive. a solution would be to inspect the gpt table and if an osx-boot is present to leave the starting point unchanged? i tested it on osx 10.8. Please note than geom mark active the partition when osx zeroes the 1be byte. but with this byte set or unset, osx starts (perhaps non checked at all). Regards Raoul rm...@free.fr ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic possibly on on bridge member removal
On Mon, Oct 1, 2012 at 8:04 AM, John Baldwin wrote: > On Saturday, September 29, 2012 8:40:03 am Kim Culhan wrote: >> After a few hours of operation involving tap0 added to the bridge >> running openvpn >> and shutting down openvpn which removes tap0 from the bridge, the >> machine is found to have a panic: >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0x188 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0x82a14f96 >> stack pointer = 0x28:0xff8000285670 >> frame pointer = 0x28:0xff80002856b0 >> 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 (swi5: fast taskq) >> [ thread pid 12 tid 100022 ] >> Stopped at bridge_enqueue+0x86:calll *0x188(%r12) >> db> bt >> Tracing pid 12 tid 100022 td 0xfe0003aff000 >> bridge_enqueue() at bridge_enqueue+0x86 > > Can you run 'gdb /boot/kernel/kernel' and do 'l *bridge_enqueue+0x86'? > > -- > John Baldwin (gdb) l *bridge_enqueue+0x86 No symbol "bridge_enqueue" in current context. (gdb) -- -kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic possibly on on bridge member removal
On Saturday, September 29, 2012 8:40:03 am Kim Culhan wrote: > After a few hours of operation involving tap0 added to the bridge > running openvpn > and shutting down openvpn which removes tap0 from the bridge, the > machine is found to have a panic: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x188 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x82a14f96 > stack pointer = 0x28:0xff8000285670 > frame pointer = 0x28:0xff80002856b0 > 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 (swi5: fast taskq) > [ thread pid 12 tid 100022 ] > Stopped at bridge_enqueue+0x86:calll *0x188(%r12) > db> bt > Tracing pid 12 tid 100022 td 0xfe0003aff000 > bridge_enqueue() at bridge_enqueue+0x86 Can you run 'gdb /boot/kernel/kernel' and do 'l *bridge_enqueue+0x86'? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-current Digest, Vol 464, Issue 3
On 2012-09-05 09:34, freebsd-current-requ...@freebsd.org wrote: Hi all, I recently performed a series of compiler performance tests on FreeBSD 10.0-CURRENT, particularly comparing gcc 4.2.1 and gcc 4.7.1 against clang 3.1 and clang 3.2. Hey, you've got a cool idea, but the implementation ain't good...you can't compare optimising compilers w/out comparing optimisation quality. If you don't go all-out in one dimension, both are necessary. You conclude that Clang is faster. But maybe if you lowered optimisation level on gcc, it would become faster and stronger than Clang at the same time? We don't know, it hasn't been tested. Regards, -- Twoje radio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
high interrupts load xhci
Hello. I have a very high interrupts load on my FreeBSD machine. It happens when I plug any USB device (like a keyboard), and the load is still high after disconnecting the device. It becomes normal after reboot. My system based on ASUS P8Z68-V Pro/Gen3 motherboard. MYKERNEL is the GENERIC kernel with ipfw support. Sorry for bad English. Some debug information below: # uname -a FreeBSD servergate 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Wed Mar 28 15:00:36 MSK 2012 root@servergate:/usr/src/sys/amd64/compile/MYKERNEL amd64 # vmstat -i interrupt total rate irq16: xhci1 12027577930 19620 irq23: ehci0 ehci1 1853306 3 cpu0:timer 628564836 1025 irq256: em0:rx 056064005 91 irq257: em0:tx 043550786 71 irq258: em0:link 2 0 irq262: em2:rx 0 553904449903 irq263: em2:tx 0 512166987835 irq264: em2:link 1 0 irq265: em3:rx 0 308737867503 irq266: em3:tx 0 607085499990 irq268: ahci05885008 9 cpu1:timer 130146122212 cpu3:timer 103306335168 cpu2:timer 60072912 97 Total15038916045 24533 # sysctl hw.usb.xhci.debug=16 ; sleep 1; sysctl hw.usb.xhci.debug=0 /var/log/messages Oct 1 12:46:28 servergate kernel: xhci_interrupt: real interrupt (sts=0x, iman=0x0002) Oct 1 12:46:29 servergate last message repeated 4239 times # sysctl hw.usb.xhci.debug=16 ; sleep 2 ; sysctl hw.usb.xhci.debug=0 /var/log/messages Oct 1 12:47:42 servergate last message repeated 8490 times # systat -vmstat 1 usersLoad 0.63 0.55 0.55 Oct 1 13:41 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 1485876 159184 5740552 176552 2857720 count All 1585844 165036 1079661k 210368 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Fltcow175k total 140 353k 41 938 172k 10443 2 zfod 165k xhci1 16 ozfod 3 ehci0 ehci 0.1%Sys 17.0%Intr 0.0%User 0.0%Nice 82.9%Idle%ozfod 1127 cpu0:timer ||||||||||| daefr 809 em0:rx 0 + prcfr 473 em0:tx 0 41 dtbuf2 totfr em0:link Namei Name-cache Dir-cache204931 desvn react 1496 em2:rx 0 Callshits %hits %172501 numvn pdwak 1537 em2:tx 0 391 385 98 49267 frevn pdpgs em2:link intrn 1339 em3:rx 0 Disks ada0 ada1 pass0 pass1 875960 wire 2201 em3:tx 0 KB/t 30.73 30.73 0.00 0.00 1122584 act 9 ahci0 268 tps 4 4 0 0 3145672 inact 962 cpu1:timer MB/s 0.13 0.13 0.00 0.00 276 cache 254 cpu3:timer %busy 0 0 0 0 2857444 free105 cpu2:timer 837152 buf # pciconf -lv hostb0@pci0:0:0:0: class=0x06 card=0x844d1043 chip=0x01008086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family DRAM Controller' class = bridge subclass = HOST-PCI - - - - - xhci0@pci0:4:0:0: class=0x0c0330 card=0x84881043 chip=0x10421b21 rev=0x00 hdr=0x00 vendor = 'ASMedia Technology Inc.' device = 'ASM1042 SuperSpeed USB Host Controller' class = serial bus subclass = USB - - - - - xhci1@pci0:7:0:0: class=0x0c0330 card=0x84881043 chip=0x10421b21 rev=0x00 hdr=0x00 vendor = 'ASMedia Technology Inc.' device = 'ASM1042 SuperSpeed USB Host Controller' class = serial bus subclass = USB ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart on macbook air
On Mon, 01 Oct 2012 12:29:02 +0400 From: "Andrey V. Elsukov" wrote: On 30.09.2012 23:06, Raoul MEGELAS wrote: >>> When you are deleting a partition, the kernel completely overwrites the >>> partition table and PMBR area. You can compare first 34 blocks before >>> deletion and after to see what is going on. >> >> I can understand that, but i would have thought >> that the deletion of the concerned partition was written preserving others??? >> >> something like: >> >> - read the gpt table >> - find the offset >> - zeroes the partition entry >> - rewrites the table? >> >> is not that logic? >> >> if it is not so, i does not understand this behaviour. > Hi, Raoul, > > The kernel has a copy of the partition table in the memory. > When you are deleting some partition, it removes the partition entry > from the memory, constructs updated GPT header and table, calculates > checksums and writes this data into corresponding places. > Any way, this should correctly work. > > My guess is that Apple's boot loader detects some changes and > just doesn't want to work. If you think that gpart incorrectly works, > please make a copy of first 34 blocks before and after deletion and > send them to me. Hi Andrey, thanks for your clear explaination; that make sense. in all case i will backup my 18g freebsd partition and and delete it. as soon as possible will send privately the two copy of the first 34 blocks of the disk, before and after deletion. Thanks again. Raoul rm...@free.fr ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart on macbook air
On 30.09.2012 23:06, Raoul MEGELAS wrote: >> When you are deleting a partition, the kernel completely overwrites the >> partition table and PMBR area. You can compare first 34 blocks before >> deletion and after to see what is going on. > > I can understand that, but i would have thought > that the deletion of the concerned partition was written preserving others??? > > something like: > > - read the gpt table > - find the offset > - zeroes the partition entry > - rewrites the table? > > is not that logic? > > if it is not so, i does not understand this behaviour. Hi, Raoul, The kernel has a copy of the partition table in the memory. When you are deleting some partition, it removes the partition entry from the memory, constructs updated GPT header and table, calculates checksums and writes this data into corresponding places. Any way, this should correctly work. My guess is that Apple's boot loader detects some changes and just doesn't want to work. If you think that gpart incorrectly works, please make a copy of first 34 blocks before and after deletion and send them to me. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
