Re: Tons of sa6_recoverscope: assumption failure on recent -current
Andrey Chernov a...@freebsd.org wrote in 50a88d0e.1070...@freebsd.org: ac On every IPv6 address of my card and router and every broadcast and ac link-local scope addresses I see now: ac kernel: sa6_recoverscope: assumption failure (non 0 ID): ipv6 address ac ac What does it mean and why there are so many of them? I have plain local ac net with IPv6 router, nothing unusual. ac ac IPv6 continues to work despite of those failures. René Ladan r...@freebsd.org wrote in 50a9e4d1.8000...@freebsd.org: re I'm also seeing them when using a teredo-tunnel over an IPv4 router, re r243234-amd64 This warning message itself is not harmful actually, but my commit triggered it. It should be fixed at r243235. Can you let me know if this problem persists even at this revision or later? Thank you. -- Hiroki pgpHXYXaI13TI.pgp Description: PGP signature
[head tinderbox] failure on sparc64/sparc64
TB --- 2012-11-19 07:12:07 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-19 07:12:07 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-19 07:12:07 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-11-19 07:12:07 - cleaning the object tree TB --- 2012-11-19 07:13:51 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-19 07:13:51 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2012-11-19 07:13:51 - /usr/local/bin/svn cleanup /src TB --- 2012-11-19 07:15:43 - /usr/local/bin/svn update /src TB --- 2012-11-19 07:15:50 - At svn revision 243261 TB --- 2012-11-19 07:15:51 - building world TB --- 2012-11-19 07:15:51 - CROSS_BUILD_TESTING=YES TB --- 2012-11-19 07:15:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-19 07:15:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-19 07:15:51 - SRCCONF=/dev/null TB --- 2012-11-19 07:15:51 - TARGET=sparc64 TB --- 2012-11-19 07:15:51 - TARGET_ARCH=sparc64 TB --- 2012-11-19 07:15:51 - TZ=UTC TB --- 2012-11-19 07:15:51 - __MAKE_CONF=/dev/null TB --- 2012-11-19 07:15:51 - cd /src TB --- 2012-11-19 07:15:51 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Mon Nov 19 07:15:59 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] cc -O2 -pipe -mcmodel=medlow -Os -I/src/sys/boot/sparc64/boot1/../../common -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/boot1/boot1.c In file included from /obj/sparc64.sparc64/src/tmp/usr/include/ufs/ffs/fs.h:36, from /src/sys/boot/sparc64/boot1/../../common/ufsread.c:51, from /src/sys/boot/sparc64/boot1/boot1.c:451: /obj/sparc64.sparc64/src/tmp/usr/include/sys/mount.h:824: error: conflicting types for 'mount' /src/sys/boot/sparc64/boot1/boot1.c:63: error: previous declaration of 'mount' was here /src/sys/boot/sparc64/boot1/boot1.c:501: error: conflicting types for 'mount' /obj/sparc64.sparc64/src/tmp/usr/include/sys/mount.h:824: error: previous declaration of 'mount' was here *** [boot1.o] Error code 1 Stop in /src/sys/boot/sparc64/boot1. *** [all] Error code 1 Stop in /src/sys/boot/sparc64. *** [all] Error code 1 Stop in /src/sys/boot. *** [all] Error code 1 Stop in /src/sys. *** [sys.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-19 08:12:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-19 08:12:19 - ERROR: failed to build world TB --- 2012-11-19 08:12:19 - 2695.95 user 485.55 system 3612.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ 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: No ATA disks on 9.1-RC3
19.11.2012 10:24, Alex Keda wrote: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: WDC WD1600BEVT-00A0RT0 01.01A01 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 152627MB (312581809 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 Looking for this one? ATA_CAM was made default for now. -- Sphinx of black quartz, judge my vow. ___ 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: No ATA disks on 9.1-RC3
19.11.2012 10:59, Volodymyr Kostyrko wrote: 19.11.2012 10:24, Alex Keda wrote: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: WDC WD1600BEVT-00A0RT0 01.01A01 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 152627MB (312581809 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 Looking for this one? ATA_CAM was made default for now. Damn I'm sorry. Looks like I need my coffee back... The change actually is at: ahci0: ATI IXP600 AHCI SATA controller port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported and ahci0: ATI IXP600 AHCI SATA controller port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 52 ahci0: AHCI v0.00 with 1 ?Gbps ports, Port Multiplier not supported with FBS ahci0: Caps: ?Gbps FBS 2cmd 1ports The bad thing about that is that there was no major rewrite of ahci code in this timeframe. There are some point that can be checked though: 1. What is your BIOS settings for controller? Can you try switching it between Legacy/Compatible mode? There was a change that fixed behavior for detecting different BIOS settings. 2. You can try using modular driver for this one, this means adding this to kernel: nodevice ata device atacore device ataati device ataahci -- Sphinx of black quartz, judge my vow. ___ 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: No ATA disks on 9.1-RC3
19.11.2012 13:19, Volodymyr Kostyrko пишет: 19.11.2012 10:59, Volodymyr Kostyrko wrote: 19.11.2012 10:24, Alex Keda wrote: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: WDC WD1600BEVT-00A0RT0 01.01A01 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 152627MB (312581809 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 Looking for this one? ATA_CAM was made default for now. Damn I'm sorry. Looks like I need my coffee back... The change actually is at: ahci0: ATI IXP600 AHCI SATA controller port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported and ahci0: ATI IXP600 AHCI SATA controller port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 52 ahci0: AHCI v0.00 with 1 ?Gbps ports, Port Multiplier not supported with FBS ahci0: Caps: ?Gbps FBS 2cmd 1ports The bad thing about that is that there was no major rewrite of ahci code in this timeframe. There are some point that can be checked though: 1. What is your BIOS settings for controller? Can you try switching it between Legacy/Compatible mode? There was a change that fixed behavior for detecting different BIOS settings. BIOS does not have SATA controller settings ___ 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: Tons of sa6_recoverscope: assumption failure on recent -current
On 19.11.2012 11:59, Hiroki Sato wrote: This warning message itself is not harmful actually, but my commit triggered it. It should be fixed at r243235. Can you let me know if this problem persists even at this revision or later? Thank you. I see no such messages after boot at r243235, thanx. signature.asc Description: OpenPGP digital signature
Re: problem booting to multi-vdev root pool
on 18/11/2012 13:48 Andriy Gapon said the following: on 18/11/2012 02:26 Bartosz Stec said the following: W dniu 2012-11-16 17:17, Guido Falsi pisze: On 11/16/12 16:45, Andriy Gapon wrote: Guido, Bartosz, could you please test the patch? I have just compiler an r242910 kernel with this patch (and just this one) applied. System booted so it seems to work fine! :) I've just compiled and installed fresh kernel with your patch, system booted without any problems, so apparently patch works as intended. Thank you both very much for testing! Committed as r243213. BTW, if you have some spare time and a desire to do some more testing, you can try the following patch: http://people.freebsd.org/~avg/zfs-spa-multi_vdev_root_support.diff It adds support for multi-vdev root pool probing in kernel. The best way to test is to remove zpool.cache before rebooting (but make sure to keep a copy somewhere and be able to recover). I'd use a boot environment (a root filesystem clone) for this. Thank you. -- Andriy Gapon ___ 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: No ATA disks on 9.1-RC3
19.11.2012 13:19, Volodymyr Kostyrko пишет: 19.11.2012 10:59, Volodymyr Kostyrko wrote: 19.11.2012 10:24, Alex Keda wrote: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: WDC WD1600BEVT-00A0RT0 01.01A01 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 152627MB (312581809 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 Looking for this one? ATA_CAM was made default for now. Damn I'm sorry. Looks like I need my coffee back... The change actually is at: ahci0: ATI IXP600 AHCI SATA controller port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier not supported and ahci0: ATI IXP600 AHCI SATA controller port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0409000-0xd04093ff irq 16 at device 18.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 52 ahci0: AHCI v0.00 with 1 ?Gbps ports, Port Multiplier not supported with FBS ahci0: Caps: ?Gbps FBS 2cmd 1ports The bad thing about that is that there was no major rewrite of ahci code in this timeframe. There are some point that can be checked though: 1. What is your BIOS settings for controller? Can you try switching it between Legacy/Compatible mode? There was a change that fixed behavior for detecting different BIOS settings. 2. You can try using modular driver for this one, this means adding this to kernel: nodevice ata device atacore device ataati device ataahci It's not build config: === root@HP:/usr/src # vim /usr/src/sys/amd64/conf/HP # include GENERIC ident HPKERNEL nodevice ata nodevice siis device atacore device ataati device ataahci = error: = MAKE=make sh /usr/src/sys/conf/newvers.sh HPKERNEL /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector vers.c linking kernel.debug ata-ahci.o: In function `ata_ahci_ata_attach': /usr/src/sys/dev/ata/chipsets/ata-ahci.c:128: undefined reference to `ata_pci_ch_attach' /usr/src/sys/dev/ata/chipsets/ata-ahci.c:129: undefined reference to `ata_pci_ch_detach' ata-ahci.o: In function `ata_ahci_probe': /usr/src/sys/dev/ata/chipsets/ata-ahci.c:97: undefined reference to `ata_pcivendor2str' /usr/src/sys/dev/ata/chipsets/ata-ahci.c:100: undefined reference to `ata_pcivendor2str' ata-ahci.o: In function `ata_ahci_chipinit': /usr/src/sys/dev/ata/chipsets/ata-ahci.c:165: undefined reference to `ata_generic_intr' /usr/src/sys/dev/ata/chipsets/ata-ahci.c:165: undefined reference to `ata_setup_interrupt' ata-ahci.o:(.data+0x1c0): undefined reference to `ata_pci_devclass' ata-ahci.o:(.data+0x200): undefined reference to `ata_pci_devclass' ata-ahci.o:(.data+0x2c8): undefined reference to `ata_pci_detach' ata-ahci.o:(.data+0x2d8): undefined reference to `ata_pci_suspend' ata-ahci.o:(.data+0x2e8): undefined reference to `ata_pci_resume' ata-ahci.o:(.data+0x308): undefined reference to `ata_pci_read_ivar' ata-ahci.o:(.data+0x318): undefined reference to `ata_pci_write_ivar' ata-ahci.o:(.data+0x328): undefined reference to `ata_pci_alloc_resource' ata-ahci.o:(.data+0x338): undefined reference to `ata_pci_release_resource' ata-ahci.o:(.data+0x368): undefined reference to `ata_pci_setup_intr' ata-ahci.o:(.data+0x378): undefined reference to `ata_pci_teardown_intr' ata-ahci.o:(.data+0x3b8): undefined reference to `ata_pci_attach' ata-ahci.o:(.data+0x3c8): undefined reference to `ata_pci_detach' ata-ahci.o:(.data+0x3d8): undefined reference to `ata_pci_suspend' ata-ahci.o:(.data+0x3e8): undefined reference to `ata_pci_resume' ata-ahci.o:(.data+0x408): undefined reference to `ata_pci_read_ivar' ata-ahci.o:(.data+0x418): undefined reference to `ata_pci_write_ivar' ata-ahci.o:(.data+0x428): undefined reference to `ata_pci_alloc_resource' ata-ahci.o:(.data+0x438): undefined reference to `ata_pci_release_resource' ata-ahci.o:(.data+0x468): undefined reference to `ata_pci_setup_intr' ata-ahci.o:(.data+0x478): undefined reference to `ata_pci_teardown_intr' ata-ahci.o:(.data+0x488): undefined reference to `ata_pci_read_config' ata-ahci.o:(.data+0x498): undefined reference to `ata_pci_write_config' ata-ahci.o:(.data+0x4a8): undefined reference to `ata_pci_print_child'
Re: No ATA disks on 9.1-RC3
19.11.2012 15:01, Alex Keda wrote: It's not build config: === root@HP:/usr/src # vim /usr/src/sys/amd64/conf/HP # include GENERIC ident HPKERNEL nodevice ata nodevice siis device atacore device ataati device ataahci Looks like I have missed `device atapci` here. = error: = MAKE=make sh /usr/src/sys/conf/newvers.sh HPKERNEL /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector vers.c linking kernel.debug ata-ahci.o: In function `ata_ahci_ata_attach': /usr/src/sys/dev/ata/chipsets/ata-ahci.c:128: undefined reference to `ata_pci_ch_attach' -- Sphinx of black quartz, judge my vow. ___ 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: No ATA disks on 9.1-RC3
19.11.2012 17:18, Volodymyr Kostyrko пишет: 19.11.2012 15:01, Alex Keda wrote: It's not build config: === root@HP:/usr/src # vim /usr/src/sys/amd64/conf/HP # include GENERIC ident HPKERNEL nodevice ata nodevice siis device atacore device ataati device ataahci Looks like I have missed `device atapci` here. OK, I rebuild kernel - no happy - error remains ___ 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: No ATA disks on 9.1-RC3
19.11.2012 15:59, Alex Keda wrote: 19.11.2012 17:18, Volodymyr Kostyrko пишет: 19.11.2012 15:01, Alex Keda wrote: It's not build config: === root@HP:/usr/src # vim /usr/src/sys/amd64/conf/HP # include GENERIC ident HPKERNEL nodevice ata nodevice siis device atacore device ataati device ataahci Looks like I have missed `device atapci` here. OK, I rebuild kernel - no happy - error remains So this is rather IXP600 support problem, try hitting freebsd-stable or... freebsd-hardware? -- Sphinx of black quartz, judge my vow. ___ 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: netisr panic?
Ian FREISLICH wrote:
Gleb Smirnoff wrote:
On Sat, Nov 17, 2012 at 05:07:54PM +0200, Ian FREISLICH wrote:
I I have this consistently with:
I
I FreeBSD firewall2.jnb1.gp-online.net 10.0-CURRENT FreeBSD 10.0-CURRENT #
30
r243156: Fri Nov 16 20:12:33 SAST 2012 i...@firewall2.jnb1.gp-online.net
:/
usr/obj/usr/src/sys/FIREWALL amd64
Pretty sure this is a new version of wrong byte order panic, which
no longer can happen in HEAD.
Can you please try this patch?
It survived the night, which it hasn't managed before. I'll keep you posted.
Jubilation short lived:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xc
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8050f494
stack pointer = 0x28:0xff84637a19d0
frame pointer = 0x28:0xff84637a1a10
code segment= base 0x0, limit 0xf, type 0x1b
Fatal trap 12: page fault while in kernel mode
= DPL 0, pres 1, long 1, def32 0, gran 1
cpuid = 7; apic id = 07
processor eflags= fault virtual address = 0xc
interrupt enabled, fault code = supervisor read data, page not present
resume, IOPL = 0
instruction pointer = 0x20:0x8050f494
stack pointer = 0x28:0xff846386c9d0
current process = 11 (irq261: igb0:que 0)
frame pointer = 0x28:0xff846386ca10
trap number = 12
code segment= base 0x0, limit 0xf, type 0x1b
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x1ce
trap_fatal() at trap_fatal+0x290
trap_pfault() at trap_pfault+0x21f
trap() at trap+0x2b4
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0x8050f494, rsp = 0xff84637a19d0, rbp =
0xff84637a1a10 ---
ether_nh_input() at ether_nh_input+0x94
netisr_dispatch_src() at netisr_dispatch_src+0x212
igb_rxeof() at igb_rxeof+0x384
igb_msix_que() at igb_msix_que+0xfa
intr_event_execute_handlers() at intr_event_execute_handlers+0xfd
ithread_loop() at ithread_loop+0x9e
fork_exit() at fork_exit+0x11e
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff84637a1cb0, rbp = 0 ---
Uptime: 19h5m45s
Dumping 2654 out of 16368 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
#0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266
266 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:266
#1 0x8044ae64 in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:449
#2 0x8044b3e7 in panic (fmt=0x1 Address 0x1 out of bounds)
at /usr/src/sys/kern/kern_shutdown.c:637
#3 0x80605b30 in trap_fatal (frame=0xc, eva=value optimized out)
at /usr/src/sys/amd64/amd64/trap.c:872
#4 0x80605e9f in trap_pfault (frame=0xff84637a1920, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:789
#5 0x80606254 in trap (frame=0xff84637a1920)
at /usr/src/sys/amd64/amd64/trap.c:463
#6 0x805efecf in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#7 0x8050f494 in ether_nh_input (m=0xfe004f3bde00)
at /usr/src/sys/net/if_ethersubr.c:484
#8 0x8051a562 in netisr_dispatch_src (proto=9,
source=value optimized out, m=value optimized out)
at /usr/src/sys/net/netisr.c:1013
#9 0x80318844 in igb_rxeof (que=0xfe000a183a00, count=499,
done=0x0) at /usr/src/sys/dev/e1000/if_igb.c:4688
#10 0x8032183a in igb_msix_que (arg=value optimized out)
at /usr/src/sys/dev/e1000/if_igb.c:1596
#11 0x8042082d in intr_event_execute_handlers (
p=value optimized out, ie=0xfe000a109e00)
at /usr/src/sys/kern/kern_intr.c:1272
#12 0x8042205e in ithread_loop (arg=0xfe000a1a16e0)
at /usr/src/sys/kern/kern_intr.c:1285
#13 0x8041d48e in fork_exit (
callout=0x80421fc0 ithread_loop, arg=0xfe000a1a16e0,
frame=0xff84637a1c00) at /usr/src/sys/kern/kern_fork.c:995
#14 0x805f038e in fork_trampoline ()
at /usr/src/sys/amd64/amd64/exception.S:602
#15 0x in ?? ()
--
Meditating Guru
Ian Freislich
___
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: No ATA disks on 9.1-RC3
On Mon, 19 Nov 2012, Alex Keda wrote: I try update my laptop - Compaq 6715s from 9.0 to 9.1-rc3 it cannot boot, because no HDD found dmesg from 9.0/9.1 and pciconf in attached files If there is an IDE/AHCI mode setting in the BIOS, switch it to the other setting. ___ 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: problem booting to multi-vdev root pool
On 11/19/12 14:00, Andriy Gapon wrote: on 18/11/2012 13:48 Andriy Gapon said the following: on 18/11/2012 02:26 Bartosz Stec said the following: Thank you both very much for testing! Committed as r243213. BTW, if you have some spare time and a desire to do some more testing, you can try the following patch: http://people.freebsd.org/~avg/zfs-spa-multi_vdev_root_support.diff It adds support for multi-vdev root pool probing in kernel. The best way to test is to remove zpool.cache before rebooting (but make sure to keep a copy somewhere and be able to recover). I'd use a boot environment (a root filesystem clone) for this. Hi! Thank you again for the fast work. I tested this one on that machine and it was able to boot without zpool.cache. No file zpool.cache was created after boot. Are there any further test I should perform? -- Guido Falsi m...@madpilot.net ___ 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: problem booting to multi-vdev root pool
on 19/11/2012 17:07 Guido Falsi said the following: On 11/19/12 14:00, Andriy Gapon wrote: on 18/11/2012 13:48 Andriy Gapon said the following: on 18/11/2012 02:26 Bartosz Stec said the following: Thank you both very much for testing! Committed as r243213. BTW, if you have some spare time and a desire to do some more testing, you can try the following patch: http://people.freebsd.org/~avg/zfs-spa-multi_vdev_root_support.diff It adds support for multi-vdev root pool probing in kernel. The best way to test is to remove zpool.cache before rebooting (but make sure to keep a copy somewhere and be able to recover). I'd use a boot environment (a root filesystem clone) for this. Thank you again for the fast work. I tested this one on that machine and it was able to boot without zpool.cache. Great! Thank you for testing. No file zpool.cache was created after boot. This is expected. Are there any further test I should perform? This was sufficient. Thanks again. -- Andriy Gapon ___ 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: No ATA disks on 9.1-RC3
On 19.11.2012 18:50, Warren Block wrote: On Mon, 19 Nov 2012, Alex Keda wrote: I try update my laptop - Compaq 6715s from 9.0 to 9.1-rc3 it cannot boot, because no HDD found dmesg from 9.0/9.1 and pciconf in attached files If there is an IDE/AHCI mode setting in the BIOS, switch it to the other setting. It's HP. No BIOS settings for hard drive/SATA controller ___ 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: prompt w/ uid 0 for cshrc
On 18 November 2012 18:44, Mateusz Guzik mjgu...@gmail.com wrote: Just take user name from id -nu. While that does provide the $user value I want, id is in /usr/bin/ which may not be mounted. Is there a builtin which provides similar functionality? -- Eitan Adler ___ 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: prompt w/ uid 0 for cshrc
Eitan Adler lists at eitanadler.com writes: On 18 November 2012 18:44, Mateusz Guzik mjguzik at gmail.com wrote: Just take user name from id -nu. While that does provide the $user value I want, id is in /usr/bin/ which may not be mounted. /rescue/id jb ___ 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
[head tinderbox] failure on sparc64/sparc64
TB --- 2012-11-19 17:30:22 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-11-19 17:30:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-11-19 17:30:22 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2012-11-19 17:30:22 - cleaning the object tree TB --- 2012-11-19 17:33:02 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-11-19 17:33:02 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2012-11-19 17:33:02 - /usr/local/bin/svn cleanup /src TB --- 2012-11-19 17:34:03 - /usr/local/bin/svn update /src TB --- 2012-11-19 17:34:09 - At svn revision 243290 TB --- 2012-11-19 17:34:10 - building world TB --- 2012-11-19 17:34:10 - CROSS_BUILD_TESTING=YES TB --- 2012-11-19 17:34:10 - MAKEOBJDIRPREFIX=/obj TB --- 2012-11-19 17:34:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-11-19 17:34:10 - SRCCONF=/dev/null TB --- 2012-11-19 17:34:10 - TARGET=sparc64 TB --- 2012-11-19 17:34:10 - TARGET_ARCH=sparc64 TB --- 2012-11-19 17:34:10 - TZ=UTC TB --- 2012-11-19 17:34:10 - __MAKE_CONF=/dev/null TB --- 2012-11-19 17:34:10 - cd /src TB --- 2012-11-19 17:34:10 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Mon Nov 19 17:34:15 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything [...] cc -O2 -pipe -mcmodel=medlow -Os -I/src/sys/boot/sparc64/boot1/../../common -ffreestanding -std=gnu99 -c /src/sys/boot/sparc64/boot1/boot1.c In file included from /obj/sparc64.sparc64/src/tmp/usr/include/ufs/ffs/fs.h:36, from /src/sys/boot/sparc64/boot1/../../common/ufsread.c:51, from /src/sys/boot/sparc64/boot1/boot1.c:451: /obj/sparc64.sparc64/src/tmp/usr/include/sys/mount.h:824: error: conflicting types for 'mount' /src/sys/boot/sparc64/boot1/boot1.c:63: error: previous declaration of 'mount' was here /src/sys/boot/sparc64/boot1/boot1.c:501: error: conflicting types for 'mount' /obj/sparc64.sparc64/src/tmp/usr/include/sys/mount.h:824: error: previous declaration of 'mount' was here *** [boot1.o] Error code 1 Stop in /src/sys/boot/sparc64/boot1. *** [all] Error code 1 Stop in /src/sys/boot/sparc64. *** [all] Error code 1 Stop in /src/sys/boot. *** [all] Error code 1 Stop in /src/sys. *** [sys.all__D] Error code 1 Stop in /src. *** [everything] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-11-19 18:28:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-11-19 18:28:18 - ERROR: failed to build world TB --- 2012-11-19 18:28:18 - 2688.14 user 484.05 system 3475.62 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ 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: prompt w/ uid 0 for cshrc
On Mon, Nov 19, 2012 at 10:45:35AM -0500, Eitan Adler wrote: On 18 November 2012 18:44, Mateusz Guzik mjgu...@gmail.com wrote: Just take user name from id -nu. While that does provide the $user value I want, id is in /usr/bin/ which may not be mounted. Is there a builtin which provides similar functionality? Valid point, but should not happen a lot when unprivileged accounts are involved, so I suggest the following (pseudo-sh-code): if [ -x /usr/bin/id ]; then up=$(id -nu); else if [ $uid = 0 ]; then up=root; else up=($uid) fi -- Mateusz Guzik mjguzik gmail.com ___ 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
syscall cost freebsd vs linux ?
today i was comparing the performance of some netmap-related code on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that our system calls are significantly slower. On comparable hardware (i7-2600k vs E5-1650) the syscall getppid() takes about 95ns on FreeBSD and 38ns on linux. (i make sure not to use gettimeofday(), which in linux is through vdso, and getpid(), which is cached by glibc). Any idea on why there is this difference and whether/how we can reduce it ? cheers luigi ___ 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: pw keeps setting /etc/group to 0600
On Sat, Nov 17, 2012 at 11:20:21AM -0500, Ryan Stone wrote:
My original complaint that /etc/group gets permissions of 0600 is a result
of a bug in libutil, which bapt@ ported pw to use in r242349. The new
group manipulation API using mktemp to create a temporary file, writes the
new group database to the temp file and then renames the temp file to
/etc/group. The problem here is that mktemp creates a file with a mode of
600, and libutil never chmods it. That should be pretty trivial to fix.
My additional 0,03$:
I took closer look to this and I think that problems are much broader
than this. I don't know if similar problems were present before.
First, pw should not fail if other instance is running, it should wait
instead (think of parallel batch scripts adding some users/groups).
Second, current code has a race:
lockfd = open(group_file, O_RDONLY, 0);
if (lockfd 0 || fcntl(lockfd, F_SETFD, 1) == -1)
err(1, %s, group_file);
if (flock(lockfd, LOCK_EX|LOCK_NB) == -1) {
[..]
gr_copy(pfd, tfd, gr, old_gr); /* copy from groupfile to tempfile */
[..]
rename(tempfile,groupfile);
Now let's consider threads A and B:
A: open()
A: lock();
A: gr_copy
B: open()
Now B has file descriptor to /etc/group that is about to be removed.
A: rename()
A: unlock()
B: lock()
Now B has a lock on unlinked file.
B: gr_copy()
B: rename()
... and stores new content losing modifications done by A
Third, I don't like current api.
gr_lock and gr_tmp have no arguments (that matter anyway)
gr_copy operates on two descriptors given as arguments
gr_mkdb takes nothing and is expected to do The Right Thing
I think descriptos should be hidden. Also I think that passing around
struct gr_something (sorry, never had talent for names) that would
contain all necessary data would be nice.
--
Mateusz Guzik mjguzik gmail.com
___
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: pw keeps setting /etc/group to 0600
On Mon, Nov 19, 2012 at 11:28:43PM +0100, Mateusz Guzik wrote:
On Sat, Nov 17, 2012 at 11:20:21AM -0500, Ryan Stone wrote:
My original complaint that /etc/group gets permissions of 0600 is a result
of a bug in libutil, which bapt@ ported pw to use in r242349. The new
group manipulation API using mktemp to create a temporary file, writes the
new group database to the temp file and then renames the temp file to
/etc/group. The problem here is that mktemp creates a file with a mode of
600, and libutil never chmods it. That should be pretty trivial to fix.
My additional 0,03$:
I took closer look to this and I think that problems are much broader
than this. I don't know if similar problems were present before.
First, pw should not fail if other instance is running, it should wait
instead (think of parallel batch scripts adding some users/groups).
Second, current code has a race:
lockfd = open(group_file, O_RDONLY, 0);
if (lockfd 0 || fcntl(lockfd, F_SETFD, 1) == -1)
err(1, %s, group_file);
if (flock(lockfd, LOCK_EX|LOCK_NB) == -1) {
[..]
gr_copy(pfd, tfd, gr, old_gr); /* copy from groupfile to tempfile */
[..]
rename(tempfile,groupfile);
Now let's consider threads A and B:
A: open()
A: lock();
A: gr_copy
B: open()
Now B has file descriptor to /etc/group that is about to be removed.
A: rename()
A: unlock()
B: lock()
Now B has a lock on unlinked file.
B: gr_copy()
B: rename()
... and stores new content losing modifications done by A
Third, I don't like current api.
gr_lock and gr_tmp have no arguments (that matter anyway)
gr_copy operates on two descriptors given as arguments
gr_mkdb takes nothing and is expected to do The Right Thing
gr_mkdb should chmod 0644 after renaming if rename worked.
I should work on this soon.
The API has been design to match the exact same api of pw_utils, I don't like it
either but at least this is consistent.
regards,
Bapt
pgp1Gs42KMCjY.pgp
Description: PGP signature
Programmer dvorak layout for syscons
I've been using this layout for a long time in X and I create kbdmap for syscons. Does it any chance to be put in source tree? So my question is, is it worth. ___ 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: Programmer dvorak layout for syscons
On 2012-Nov-20 02:42:50 +0200, mbsd m...@isgroup.com.ua wrote: I've been using this layout for a long time in X and I create kbdmap for syscons. Does it any chance to be put in source tree? So my question is, is it worth. I suggest you write a PR that includes the keymap and an appropriate patch for /usr/share/syscons/keymaps/INDEX.keymaps as well as explaining how it differs from the 9 existing Dvorak keymaps. -- Peter Jeremy pgpSNEQbnvSGA.pgp Description: PGP signature
Re: prompt w/ uid 0 for cshrc
On 18 November 2012 18:32, Eitan Adler li...@eitanadler.com wrote: Hey, at the moment the current default csh prompt looks like user@hostname:directory% command This leads to an unexpected[*] result when using su (without -). In particular the user part is *not* changed to root (or toor or any other superuser indication) although the promptchar is changed to #. This causes some confusion for new users and even some experienced ones. I worked around this issue by including the following if ($uid == 0) then set user = root endif which I'm not certain is a good idea. I would like to replace this with logic like if $uid = 0 AND $user != toor AND $user != root set user = +$user endif does anyone think this is a bad idea? can anyone propose a better idea? Is the status quo okay? ... I was pointed in the right direction. I should use %N instead of %n. -- Eitan Adler ___ 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
Upgrading FreeBSD to use the NEW pf syntax. (Copied from freebsd-pf)
Forward notice: I sent this to freebsd-pf originally and did not CC -current, but as the issue would affect current and the more opinions the better... I have sent it here too. -- Cheers, daemon -- original message Good day all, I am aware this is a much discussed subject since the upgrade of PF, I believe the final decision was that to many users are used to the old style pf and an upgrade to the new syntax would cause to much confusion. There was a recent debate on ##freebsd about this issue and I was inclined to mail in and get your opinions; basically it boiled down to the majority of users wanting either: 1) To move to the newer pf and just add to releases notes what had happened, and 2) my own personal opinion: creating 'pf2-*' as a kernel option tree, basically using the newer pf syntax and allowing users to choose. I would be interested to know the feedback from you guys as to be honest there seems to be quite a few users who actually DO want the new style format and functionality that comes with. I Attached the log of the conversation just for reference. -- Thank you for your time -- Paul G Webster 'daemon' Using Opera's revolutionary email client: http://www.opera.com/mail/* daemonik (~ad...@mail.originate.com) has joined ##freebsd daemonik Is the implementation of PF on FreeBSD up to date yet? blakkheim no * stormcrow (~phyde...@c-24-126-183-121.hsd1.ga.comcast.net) has left ##freebsd blakkheim and it won't ever be, we (retardedly) forked it with some random guy's patches rather than updating it wallshot it's rare that that question asked about *any* part of the base OS will be answered with yes wallshot doh. booo @ random patches illuminated blakkheim that was truly a stupid move blakkheim i agree illuminated any chance of getting them to 'take it back' blakkheim they think freebsd users are too stupid to adapt to the newer pf syntax and thousands will upgrade without knowing and be left with an unreachable system or some bs like that daemon is there anything that pf can do that ipfw cannot do blakkheim check the freebsd-pf mailing list illuminated (or feel free to post and complain) daemonik blakkheim: That's pretty damn . . wow daemon might be worth a few emails to all the lists asking for other users to post into the pf list to support moving to the correct pf daemon maybe we can implement the newer pf as 'pf2' daemonik FreeBSD presently doesn't have ALTQ support included in the generic kernel, correct? Is there an alternative to ALTQ? blakkheim daemon: i think so too daemonik daemon: Is it really that hard to shout in the appropriate places to properly inform users? What about release notes? Anybody who doesn't read release notes deserves what's coming to them. blakkheim that's what i said! * chrisb has learned to read MOVED and UPDATING closely daemonik Huh . . that kind of behavior is why no one respects anyone/thing associated with GNOME anymore . . daemon daemonik, I dont see it being that hard to use both the 'ramdon guys patches' version of pf as the default for a few releases putting the newer version of pf as 'pf2' daemon therefor satisfying both channels of thought daemon there certainly should be A WAY of using the newer version blakkheim posting these thoughts to freebsd-pf@ is much more likely to invoke a change (or at least a poll or something) than on irc daemonik daemon: No . . the noobs are the ones who should have to use a pf-something. I bother to read the release notes, I want to use the correct version of the software. Why should I have to suffer? Why should I change when they're the ones who suck? * nightwalk has quit (Ping timeout: 276 seconds) daemonik I'll make a post later tonight. I hope that others see these messages and also articulate their thoughts on the mailing list. FreeBSD should hold a high standard for something as important as PF. daemon daemonik, if you did read release notes you would see 'ad the new version of pf is pf2' there is no need to upset users without cause; as the 'patched' pf is the default for the tag 'pf' at the moment making the new version 'pf2' is literally much more sane daemon and certainly a huge degree less antagonistic SlitazMint How do I find the size of a folder? SlitazMint And for that matter how do I search a man page? blakkheim du -sh dirname and use /string to search SlitazMint Thanks blakkheim daemonik I would rather read the release notes seeing that the WRONG version of PF gets deprecated to pf-legacy as it ought to be knowing that those who don't read the release notes will have a bad day. daemonik Referring to the CORRECT and latest stable version of PF as PF2 would make FreeBSD . . well, look about as incompetent as certain Linux distros sometimes do to say the least. daemon daemonik, transistion time should always be taken into account on any system; if we did was I was suggesting then 'pf' would be the new version in -CURRENT but for later 9.x releases it would still
Re: pw keeps setting /etc/group to 0600
On Mon, Nov 19, 2012 at 11:37:45PM +0100, Baptiste Daroussin wrote:
On Mon, Nov 19, 2012 at 11:28:43PM +0100, Mateusz Guzik wrote:
On Sat, Nov 17, 2012 at 11:20:21AM -0500, Ryan Stone wrote:
My original complaint that /etc/group gets permissions of 0600 is a result
of a bug in libutil, which bapt@ ported pw to use in r242349. The new
group manipulation API using mktemp to create a temporary file, writes the
new group database to the temp file and then renames the temp file to
/etc/group. The problem here is that mktemp creates a file with a mode of
600, and libutil never chmods it. That should be pretty trivial to fix.
My additional 0,03$:
I took closer look to this and I think that problems are much broader
than this. I don't know if similar problems were present before.
First, pw should not fail if other instance is running, it should wait
instead (think of parallel batch scripts adding some users/groups).
Second, current code has a race:
lockfd = open(group_file, O_RDONLY, 0);
if (lockfd 0 || fcntl(lockfd, F_SETFD, 1) == -1)
err(1, %s, group_file);
if (flock(lockfd, LOCK_EX|LOCK_NB) == -1) {
[..]
gr_copy(pfd, tfd, gr, old_gr); /* copy from groupfile to tempfile */
[..]
rename(tempfile,groupfile);
Now let's consider threads A and B:
A: open()
A: lock();
A: gr_copy
B: open()
Now B has file descriptor to /etc/group that is about to be removed.
A: rename()
A: unlock()
B: lock()
Now B has a lock on unlinked file.
B: gr_copy()
B: rename()
... and stores new content losing modifications done by A
Third, I don't like current api.
gr_lock and gr_tmp have no arguments (that matter anyway)
gr_copy operates on two descriptors given as arguments
gr_mkdb takes nothing and is expected to do The Right Thing
gr_mkdb should chmod 0644 after renaming if rename worked.
I should work on this soon.
The API has been design to match the exact same api of pw_utils, I don't like
it
either but at least this is consistent.
regards,
Bapt
Should be fixed now,
regards,
Bapt
pgpiLVOJMrFr3.pgp
Description: PGP signature
