panic: in_pcblookup_local (?)
Hi I've been getting the following panic on recent current r249717. Sadly the crashdump is useless. Fatal trap 9: general protection fault while in kernel mode cpuid = 15; apic id = 0f instruction pointer = 0x20:0x80546fbc stack pointer = 0x28:0xff846b60 frame pointer = 0x28:0xff846b6777b0 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 = 4361 (zabbix_agentd) trap number = 9 panic: general protection fault cpuid = 15 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xff846b677410 panic() at panic+0x13d/frame 0xff846b677510 trap_fatal() at trap_fatal+0x290/frame 0xff846b677570 trap() at trap+0xff/frame 0xff846b6776b0 calltrap() at calltrap+0x8/frame 0xff846b6776b0 --- trap 0x9, rip = 0x80546fbc, rsp = 0xff846b60, rbp = 0xff846b6777b0 --- in_pcblookup_local() at in_pcblookup_local+0x5c/frame 0xff846b6777b0 in_pcb_lport() at in_pcb_lport+0x109/frame 0xff846b677820 in_pcbbind_setup() at in_pcbbind_setup+0x16a/frame 0xff846b6778a0 in_pcbconnect_setup() at in_pcbconnect_setup+0x71e/frame 0xff846b677990 in_pcbconnect_mbuf() at in_pcbconnect_mbuf+0x59/frame 0xff846b6779e0 udp_connect() at udp_connect+0x11e/frame 0xff846b677a30 kern_connectat() at kern_connectat+0x1f5/frame 0xff846b677a90 sys_connect() at sys_connect+0x41/frame 0xff846b677ad0 amd64_syscall() at amd64_syscall+0x572/frame 0xff846b677bf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xff846b677bf0 --- syscall (98, FreeBSD ELF64, sys_connect), rip = 0x80127104a, rsp = 0x7fff97a8, rbp = 0x8014f68d4 --- Uptime: 20m13s Dumping 1688 out of 16368 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 15 Ian -- 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"
CURRENT: still suffering from nscd(1) issue?
Since the overhaul of several core functions of P Davidek, the NSCD nameservice caching daemon seems to be broken. Just to test this, I enabled the nscd again and my most recent CURRENT box seems to have "forgotten" that there is a root: su: unknown login: root or when trying to installworld/installkernel root: no such user Is this problem addressed or should I send a PR? Regards, Oliver signature.asc Description: This is a digitally signed message part
config(8) -x headscratcher
I'm getting a core dump on 'config -x /boot/kernel/kernel' on 9.1-RELEASE i386.
Assertion failed: (r != '\0' && ("Char present in the configuration "
"string mustn't be equal to 0")), function kernconfdump, file
/usr/src/usr.sbin/config/main.c, line 710.
I have double checked that my config file is sane and does not have
any funny characters anywhere.
The system is i386 9.1-RELEASE r249856. The world and kernel are built
with clang and I'm suspecting that the use of clang has something to
do with this segfault.
Looking at the kernel files I can see one very obvious difference.
This is the 'elfdump -c kernel | grep -A 8 kern_conf' output (what
config -x seems to use for finding out the config file from the kernel
image) for the GENERIC kernel from the stock installation:
sh_name: kern_conf
sh_type: SHT_PROGBITS
sh_flags: SHF_ALLOC
sh_addr: 0xc1039f80
sh_offset: 12820352
sh_size: 3771
sh_link: 0
sh_info: 0
sh_addralign: 32
And this is from the kernel I have built myself using clang and a
custom config file:
sh_name: kern_conf
sh_type: SHT_PROGBITS
sh_flags: SHF_ALLOC
sh_addr: 0xc09aee9c
sh_offset: 5959324
sh_size: 1994
sh_link: 0
sh_info: 0
sh_addralign: 1
The align field looks suspicious, config -x seems to use it to check
for padding but to me it looks like the logic may not work if the
alignment is 1.
This the relevant bit from main.c of config(8)
if (r == '\0' && (size - i) < align)
break;
assert(r != '\0' && ("Char present in the configuration "
"string mustn't be equal to 0"));
fputc(r, stdout);
-Kimmo
___
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"
r249939+ not detecting ata trim
I had been updating/porting Steve Hartland's patches for zfs trim on mps for 8.3 stable. Trim was working fine for me before r249939. When I saw that this functionality was being added to current, I built world/kernel without the patches. Indeed, many of the commits are quite similar to the updated patch I worked on (patch claims most of it is 'already applied'). HOWEVER, I am not seeing a delete method detected for either of my Samsung 830s, which I did under my updated patch. It looks like scsi ata identify is not working. Are there still outstanding commits to enable this, or is something now a tunable/sysctl I'm missing? Previously it was working: kstat.zfs.misc.zio_trim.bytes: 47546368 kstat.zfs.misc.zio_trim.success: 2618 kstat.zfs.misc.zio_trim.unsupported: 0 kstat.zfs.misc.zio_trim.failed: 0 Current: kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 264 kstat.zfs.misc.zio_trim.failed: 0 kern.cam.da.3.delete_method: NONE kern.cam.da.3.delete_max: 0 kern.cam.da.4.delete_method: NONE kern.cam.da.4.delete_max: 0 Thanks, Matt ___ 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"
Light humour
Just got this link on IRC, (freenode/##freebsd) was so funny I thought I would see if I could get any of you guys to spit out you're coffee :) http://antibsd.wordpress.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: r249939+ not detecting ata trim
- Original Message - From: "matt" To: Sent: Saturday, April 27, 2013 10:00 PM Subject: r249939+ not detecting ata trim I had been updating/porting Steve Hartland's patches for zfs trim on mps for 8.3 stable. Trim was working fine for me before r249939. When I saw that this functionality was being added to current, I built world/kernel without the patches. Indeed, many of the commits are quite similar to the updated patch I worked on (patch claims most of it is 'already applied'). HOWEVER, I am not seeing a delete method detected for either of my Samsung 830s, which I did under my updated patch. It looks like scsi ata identify is not working. Are there still outstanding commits to enable this, or is something now a tunable/sysctl I'm missing? Previously it was working: kstat.zfs.misc.zio_trim.bytes: 47546368 kstat.zfs.misc.zio_trim.success: 2618 kstat.zfs.misc.zio_trim.unsupported: 0 kstat.zfs.misc.zio_trim.failed: 0 Current: kstat.zfs.misc.zio_trim.bytes: 0 kstat.zfs.misc.zio_trim.success: 0 kstat.zfs.misc.zio_trim.unsupported: 264 kstat.zfs.misc.zio_trim.failed: 0 kern.cam.da.3.delete_method: NONE kern.cam.da.3.delete_max: 0 kern.cam.da.4.delete_method: NONE kern.cam.da.4.delete_max: 0 I have one patch outstanding (attached) to enable ATA_TRIM support under controllers which don't support UNMAP, I was just finalising testing on this, which I completed this morning; I'm just waiting for approval. If your controller doesn't support UNMAP then this will be the reason, however mps should support this. Could you confirm if previously you where seeing UNMAP as the reported delete_method? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. cam-enable-trim.patch Description: Binary data ___ 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: r249939+ not detecting ata trim
- Original Message -
From: "Steven Hartland"
I had been updating/porting Steve Hartland's patches for zfs trim on mps
for 8.3 stable.
Trim was working fine for me before r249939.
When I saw that this functionality was being added to current, I built
world/kernel without the patches.
Indeed, many of the commits are quite similar to the updated patch I
worked on (patch claims most of it is 'already applied').
HOWEVER, I am not seeing a delete method detected for either of my
Samsung 830s, which I did under my updated patch.
It looks like scsi ata identify is not working.
Are there still outstanding commits to enable this, or is something now
a tunable/sysctl I'm missing?
Previously it was working:
kstat.zfs.misc.zio_trim.bytes: 47546368
kstat.zfs.misc.zio_trim.success: 2618
kstat.zfs.misc.zio_trim.unsupported: 0
kstat.zfs.misc.zio_trim.failed: 0
Current:
kstat.zfs.misc.zio_trim.bytes: 0
kstat.zfs.misc.zio_trim.success: 0
kstat.zfs.misc.zio_trim.unsupported: 264
kstat.zfs.misc.zio_trim.failed: 0
kern.cam.da.3.delete_method: NONE
kern.cam.da.3.delete_max: 0
kern.cam.da.4.delete_method: NONE
kern.cam.da.4.delete_max: 0
I have one patch outstanding (attached) to enable ATA_TRIM support under
controllers which don't support UNMAP, I was just finalising testing on
this, which I completed this morning; I'm just waiting for approval.
If your controller doesn't support UNMAP then this will be the reason,
however mps should support this.
Could you confirm if previously you where seeing UNMAP as the reported
delete_method?
Just tested here on an mps with 8.3 and all seems good without the final
patch; disks are correctly detected as UNMAP support.
I'd be interested in the output from your system after applying the
patch from my previous email plus this:-
--- sys/cam/scsi/scsi_da.c.orig 2013-04-27 23:33:07.413089199 +
+++ sys/cam/scsi/scsi_da.c 2013-04-27 23:10:40.0 +
@@ -198,6 +198,7 @@
};
#define dadeleteflag(softc, delete_method, enable) \
+printf("deleteflag: %s (%d) = %d\n", da_delete_method_names[delete_method],
delete_method, enable); \
if (enable) { \
softc->delete_available |= (1 << delete_method);\
} else {\
Regards
Steve
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.
___
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: r249939+ not detecting ata trim
On 04/27/13 15:58, Steven Hartland wrote: > > If your controller doesn't support UNMAP then this will be the reason, > however mps should support this. > > Could you confirm if previously you where seeing UNMAP as the reported > delete_method? > >Regards >Steve > > > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmas...@multiplay.co.uk. I am rebuilding world and kernel with the patches now. Congratulations/thanks on getting all this committed! I'll post the dmesg output from the printf patch afterward. Previously, the delete_method was reported as ATA_TRIM, with a very large delete max. Thanks, Matt ___ 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: r249939+ not detecting ata trim
- Original Message - From: "matt" On 04/27/13 15:58, Steven Hartland wrote: If your controller doesn't support UNMAP then this will be the reason, however mps should support this. Could you confirm if previously you where seeing UNMAP as the reported delete_method? I am rebuilding world and kernel with the patches now. Congratulations/thanks on getting all this committed! I'll post the dmesg output from the printf patch afterward. Previously, the delete_method was reported as ATA_TRIM, with a very large delete max. FYI: Change only requires kernel, world would be identical, which should save you some time. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: r249939+ not detecting ata trim
On 04/27/13 18:32, Steven Hartland wrote: > > FYI: Change only requires kernel, world would be identical, which > should save you some time. > >Regards >Steve > > And some untrimmed deletes! Thanks, with geom/cam/disk stuff I usually assume that it could affect userland out of caution. BTW...ata identify is working fine, as even before the patch camcontrol identify indicated trim support. Thanks, Matt ___ 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: r249939+ not detecting ata trim
- Original Message - From: "matt" FYI: Change only requires kernel, world would be identical, which should save you some time. And some untrimmed deletes! Thanks, with geom/cam/disk stuff I usually assume that it could affect userland out of caution. BTW...ata identify is working fine, as even before the patch camcontrol identify indicated trim support. Could you confirm the output you got from the debug as I would have expected to see UNMAP supported on your machine if you mps? I can envisage people wanting to know what delete methods are detected as supported so I've created a new little patch which will print this out from a verbose boot. Its attached if you want to try it, again only a kernel change, I'd be interested in the output you get. You should see something like:- da0: Delete methods: Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. cam-scsi-delete-verbose.patch Description: Binary data ___ 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: r249939+ not detecting ata trim
On 04/27/13 18:51, Steven Hartland wrote: > - Original Message - From: "matt" >>> FYI: Change only requires kernel, world would be identical, which >>> should save you some time. >> >> And some untrimmed deletes! >> >> Thanks, with geom/cam/disk stuff I usually assume that it could affect >> userland out of caution. >> >> BTW...ata identify is working fine, as even before the patch camcontrol >> identify indicated trim support. > > Could you confirm the output you got from the debug as I would have > expected to see UNMAP supported on your machine if you mps? Output for sysctls kern.cam.da.3.delete_method: ATA_TRIM kern.cam.da.3.delete_max: 17179607040 kern.cam.da.3.minimum_cmd_size: 6 kern.cam.da.3.sort_io_queue: 0 kern.cam.da.3.error_inject: 0 kern.cam.da.4.delete_method: ATA_TRIM kern.cam.da.4.delete_max: 17179607040 Output for printf deleteflag: ATA_TRIM (2) = 1 I thought UNMAP was a SCSI command (for SAS disks), unless we're calling it UNMAP and then running ATA's TRIM? > I can envisage people wanting to know what delete methods are detected > as supported so I've created a new little patch which will print this > out from a verbose boot. > > Its attached if you want to try it, again only a kernel change, I'd > be interested in the output you get. You should see something like:- > da0: Delete methods: I'll give it a try and send the results. Thanks, Matt ___ 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"
buildkernel fails in zlib (all)
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #62 r249867: Wed Apr 24 21:53:34 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Trying to buildkernel at: # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 250001 Node Kind: directory Schedule: normal Last Changed Author: wkoszek Last Changed Rev: 250001 Last Changed Date: 2013-04-27 18:59:15 -0500 (Sat, 27 Apr 2013) fails with: ===> zlib (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MYKERNEL -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/zlib/../../net/zlib.c ld -d -warn-common -r -d -o zlib.ko zlib.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko export_syms | xargs -J% objcopy % zlib.ko objcopy --strip-debug zlib.ko 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error Is anyone else seeing this? ___ 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: r249939+ not detecting ata trim
- Original Message - From: "matt" To: "Steven Hartland" Cc: Sent: Sunday, April 28, 2013 3:03 AM Subject: Re: r249939+ not detecting ata trim On 04/27/13 18:51, Steven Hartland wrote: - Original Message - From: "matt" FYI: Change only requires kernel, world would be identical, which should save you some time. And some untrimmed deletes! Thanks, with geom/cam/disk stuff I usually assume that it could affect userland out of caution. BTW...ata identify is working fine, as even before the patch camcontrol identify indicated trim support. Could you confirm the output you got from the debug as I would have expected to see UNMAP supported on your machine if you mps? Output for sysctls kern.cam.da.3.delete_method: ATA_TRIM kern.cam.da.3.delete_max: 17179607040 kern.cam.da.3.minimum_cmd_size: 6 kern.cam.da.3.sort_io_queue: 0 kern.cam.da.3.error_inject: 0 kern.cam.da.4.delete_method: ATA_TRIM kern.cam.da.4.delete_max: 17179607040 Output for printf deleteflag: ATA_TRIM (2) = 1 I thought UNMAP was a SCSI command (for SAS disks), unless we're calling it UNMAP and then running ATA's TRIM? Thats correct, the mps controllers I have here announce UNMAP support for SATA disks that support TRIM and then do firmware translation on the commands sent from the OS before passing them to the disks. This is why I was expecting your controller to still do support delete's eventhough ATA_TRIM wasn't enabled yet. I'd be interested to see the details of your controller e.g. Apr 28 01:36:17 host01 kernel: mps0: port 0xf000-0xf0ff mem 0xfbe0-0xfbe03fff,0xfbd8-0xfbdb irq 56 at device 0.0 on pci129 Apr 28 01:36:17 host01 kernel: mps0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xfbe0 Apr 28 01:36:17 host01 kernel: mps0: Firmware: 14.00.00.00, Driver: 14.00.00.01-fbsd Apr 28 01:36:17 host01 kernel: mps0: IOCCapabilities: 185c Apr 28 01:36:17 host01 kernel: mps0: attempting to allocate 1 MSI-X vectors (15 supported) Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: buildkernel fails in zlib (all)
- Original Message - From: "AN" To: Sent: Sunday, April 28, 2013 3:09 AM Subject: buildkernel fails in zlib (all) FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #62 r249867: Wed Apr 24 21:53:34 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Trying to buildkernel at: # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 250001 Node Kind: directory Schedule: normal Last Changed Author: wkoszek Last Changed Rev: 250001 Last Changed Date: 2013-04-27 18:59:15 -0500 (Sat, 27 Apr 2013) fails with: ===> zlib (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MYKERNEL -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/zlib/../../net/zlib.c ld -d -warn-common -r -d -o zlib.ko zlib.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko export_syms | xargs -J% objcopy % zlib.ko objcopy --strip-debug zlib.ko 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error Is anyone else seeing this? Are you building with a -jXX option to make as I don't see the source of the error in your output there, so I suspect its actually failing earlier elsewhere but that's what your seeing from because multiple compiles are being actioned by make. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: buildkernel fails in zlib (all)
On Sun, 28 Apr 2013, Steven Hartland wrote: - Original Message - From: "AN" To: Sent: Sunday, April 28, 2013 3:09 AM Subject: buildkernel fails in zlib (all) FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #62 r249867: Wed Apr 24 21:53:34 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Trying to buildkernel at: # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 250001 Node Kind: directory Schedule: normal Last Changed Author: wkoszek Last Changed Rev: 250001 Last Changed Date: 2013-04-27 18:59:15 -0500 (Sat, 27 Apr 2013) fails with: ===> zlib (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MYKERNEL -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/zlib/../../net/zlib.c ld -d -warn-common -r -d -o zlib.ko zlib.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko export_syms | xargs -J% objcopy % zlib.ko objcopy --strip-debug zlib.ko 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error Is anyone else seeing this? Are you building with a -jXX option to make as I don't see the source of the error in your output there, so I suspect its actually failing earlier elsewhere but that's what your seeing from because multiple compiles are being actioned by make. Regards Steve Hi Steve: Yes, I'm using time make -j6 buildkernel KERNCONF=MYKERNEL. How can I find out where it's failing? Should I post full output? ___ 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: buildkernel fails in zlib (all)
- Original Message - From: "AN" To: "Steven Hartland" Cc: Sent: Sunday, April 28, 2013 3:20 AM Subject: Re: buildkernel fails in zlib (all) On Sun, 28 Apr 2013, Steven Hartland wrote: - Original Message - From: "AN" To: Sent: Sunday, April 28, 2013 3:09 AM Subject: buildkernel fails in zlib (all) FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #62 r249867: Wed Apr 24 21:53:34 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Trying to buildkernel at: # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 250001 Node Kind: directory Schedule: normal Last Changed Author: wkoszek Last Changed Rev: 250001 Last Changed Date: 2013-04-27 18:59:15 -0500 (Sat, 27 Apr 2013) fails with: ===> zlib (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MYKERNEL -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/zlib/../../net/zlib.c ld -d -warn-common -r -d -o zlib.ko zlib.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko export_syms | xargs -J% objcopy % zlib.ko objcopy --strip-debug zlib.ko 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error Is anyone else seeing this? Are you building with a -jXX option to make as I don't see the source of the error in your output there, so I suspect its actually failing earlier elsewhere but that's what your seeing from because multiple compiles are being actioned by make. Regards Steve Hi Steve: Yes, I'm using time make -j6 buildkernel KERNCONF=MYKERNEL. How can I find out where it's failing? Should I post full output? Easy way to re-run the make like this:- make -DNO_CLEAN buildkernel KERNCONF=MYKERNEL This will continue your build without cleaning first, which will mean it should fail pretty quickly and you'll get the real error. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: buildkernel fails in zlib (all)
Do it this time without -j6, so we can see where it failed. adrian On 27 April 2013 19:27, Steven Hartland wrote: > > - Original Message - From: "AN" > To: "Steven Hartland" > Cc: > Sent: Sunday, April 28, 2013 3:20 AM > Subject: Re: buildkernel fails in zlib (all) > > > >> >> >> On Sun, 28 Apr 2013, Steven Hartland wrote: >> >>> >>> - Original Message - From: "AN" >>> To: >>> Sent: Sunday, April 28, 2013 3:09 AM >>> Subject: buildkernel fails in zlib (all) >>> >>> FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #62 r249867: Wed Apr 24 21:53:34 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Trying to buildkernel at: # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 250001 Node Kind: directory Schedule: normal Last Changed Author: wkoszek Last Changed Rev: 250001 Last Changed Date: 2013-04-27 18:59:15 -0500 (Sat, 27 Apr 2013) fails with: ===> zlib (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MYKERNEL -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/zlib/../../net/zlib.c ld -d -warn-common -r -d -o zlib.ko zlib.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko export_syms | xargs -J% objcopy % zlib.ko objcopy --strip-debug zlib.ko 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error Is anyone else seeing this? >>> >>> >>> Are you building with a -jXX option to make as I don't see the source >>> of the error in your output there, so I suspect its actually failing >>> earlier elsewhere but that's what your seeing from because multiple >>> compiles are being actioned by make. >>> >>> Regards >>> Steve >>> >> >> Hi Steve: >> >> Yes, I'm using time make -j6 buildkernel KERNCONF=MYKERNEL. >> >> How can I find out where it's failing? Should I post full output? > > > Easy way to re-run the make like this:- > make -DNO_CLEAN buildkernel KERNCONF=MYKERNEL > > This will continue your build without cleaning first, which will > mean it should fail pretty quickly and you'll get the real error. > > >Regards >Steve > > > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmas...@multiplay.co.uk. > > ___ > 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" ___ 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: r249939+ not detecting ata trim
On 04/27/13 19:13, Steven Hartland wrote: > > Thats correct, the mps controllers I have here announce UNMAP support for > SATA disks that support TRIM and then do firmware translation on the > commands sent from the OS before passing them to the disks. > > This is why I was expecting your controller to still do support delete's > eventhough ATA_TRIM wasn't enabled yet. > > > I'd be interested to see the details of your controller e.g. > Apr 28 01:36:17 host01 kernel: mps0: port 0xf000-0xf0ff > mem 0xfbe0-0xfbe03fff,0xfbd8-0xfbdb irq 56 at device 0.0 > on pci129 > Apr 28 01:36:17 host01 kernel: mps0: Reserved 0x4000 bytes for rid > 0x14 type 3 at 0xfbe0 > Apr 28 01:36:17 host01 kernel: mps0: Firmware: 14.00.00.00, Driver: > 14.00.00.01-fbsd > Apr 28 01:36:17 host01 kernel: mps0: IOCCapabilities: > 185c > Apr 28 01:36:17 host01 kernel: mps0: attempting to allocate 1 MSI-X > vectors (15 supported) > >Regards >Steve > > > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained in > it. > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 > or return the E.mail to postmas...@multiplay.co.uk. > > Here are the delete methods: deleteflag: ATA_TRIM (2) = 1 da4: Delete methods: deleteflag: ATA_TRIM (2) = 1 da3: Delete methods: deleteflag: ATA_TRIM (2) = 1 Here is a truncated dmesg | fgrep mps mps0: port 0xb000-0xb0ff mem 0xfe83c000-0xfe83,0xfe84-0xfe87 irq 32 at device 0.0 on pci3 mps0: Firmware: 15.00.00.00, Driver: 14.00.00.02-fbsd mps0: IOCCapabilities: 1285c mps0: attempting to allocate 1 MSI-X vectors (15 supported) mps0: using IRQ 263 for MSI-X My firmware is ahead of the driver, and the card itself is an IBM M1015 cross-flashed to what is supposedly identical to a 9210-8i. Thanks, Matt ___ 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: buildkernel fails in zlib (all)
On 04/27/13 19:33, Adrian Chadd wrote: > Do it this time without -j6, so we can see where it failed. > > Another good one is to add | tee buildworld.log to the end of the build command as a matter of course, since you can then search the log if the error was beyond scrollback. AN, if your sources are about 12h old, they are probably failing because of the removal of MAKE_IDEA from some makefiles but not others. If that's the case, update sources and run it again...Buildworld failed for me last night for this reason. Matt ___ 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: r249939+ not detecting ata trim
- Original Message - From: "matt" Here are the delete methods: deleteflag: ATA_TRIM (2) = 1 da4: Delete methods: deleteflag: ATA_TRIM (2) = 1 da3: Delete methods: deleteflag: ATA_TRIM (2) = 1 Here is a truncated dmesg | fgrep mps mps0: port 0xb000-0xb0ff mem 0xfe83c000-0xfe83,0xfe84-0xfe87 irq 32 at device 0.0 on pci3 mps0: Firmware: 15.00.00.00, Driver: 14.00.00.02-fbsd mps0: IOCCapabilities: 1285c mps0: attempting to allocate 1 MSI-X vectors (15 supported) mps0: using IRQ 263 for MSI-X My firmware is ahead of the driver, and the card itself is an IBM M1015 cross-flashed to what is supposedly identical to a 9210-8i. Hmmm that's unexpected, it could be a FW change, but I'll get an mps box updated to current tomorrow and do some digging. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: buildkernel fails in zlib (all)
On Sat, 27 Apr 2013, Adrian Chadd wrote: Do it this time without -j6, so we can see where it failed. adrian On 27 April 2013 19:27, Steven Hartland wrote: - Original Message - From: "AN" To: "Steven Hartland" Cc: Sent: Sunday, April 28, 2013 3:20 AM Subject: Re: buildkernel fails in zlib (all) On Sun, 28 Apr 2013, Steven Hartland wrote: - Original Message - From: "AN" To: Sent: Sunday, April 28, 2013 3:09 AM Subject: buildkernel fails in zlib (all) FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #62 r249867: Wed Apr 24 21:53:34 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Trying to buildkernel at: # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 250001 Node Kind: directory Schedule: normal Last Changed Author: wkoszek Last Changed Rev: 250001 Last Changed Date: 2013-04-27 18:59:15 -0500 (Sat, 27 Apr 2013) fails with: ===> zlib (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MYKERNEL/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MYKERNEL -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector -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 -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -c /usr/src/sys/modules/zlib/../../net/zlib.c ld -d -warn-common -r -d -o zlib.ko zlib.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko export_syms | xargs -J% objcopy % zlib.ko objcopy --strip-debug zlib.ko 1 error *** [buildkernel] Error code 2 1 error *** [buildkernel] Error code 2 1 error Is anyone else seeing this? Are you building with a -jXX option to make as I don't see the source of the error in your output there, so I suspect its actually failing earlier elsewhere but that's what your seeing from because multiple compiles are being actioned by make. Regards Steve Hi Steve: Yes, I'm using time make -j6 buildkernel KERNCONF=MYKERNEL. How can I find out where it's failing? Should I post full output? Easy way to re-run the make like this:- make -DNO_CLEAN buildkernel KERNCONF=MYKERNEL This will continue your build without cleaning first, which will mean it should fail pretty quickly and you'll get the real error. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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" Looks like the failure is here: make -DNO_CLEAN buildkernel KERNCONF=MYKERNEL ... -- stage 3.2: building everything -- cd /usr/obj/usr/src/sys/MYKERNEL; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp _LDSCRIPTROOT= VERSION="FreeBSD 10.0-CURRENT amd64 130" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin COMPILER_TYPE=clang /usr/obj/usr/src/make.amd64/make -D NO_CLEAN KERNCONF=MYKERNEL -m /usr/src/share/mk TARGET=amd64 TARGET_ARCH=amd64 KERNEL=kernel all -DNO_MODULES_OBJ linking kernel if_ath_pci.o: In function `ath_pci_probe': /usr/src/sys/dev/ath/if_ath_pci.c:(.text+0xb9): undefined reference to `ath_hal_probe' if_ath_pci.o: In function `ath_pci_attach': /usr/src/sys/dev/ath/if_ath_pci.c:(.text+0x36c): undefined reference to `ath_intr' /usr/src/sys/dev/ath/if_ath_pci.c:(.text+0x62a): undefined reference to `ath_attach' if_ath_pci.o: In
Re: panic: in_pcblookup_local (?)
On Sat, Apr 27, 2013 at 10:17:32AM +0200, Ian FREISLICH wrote:
> Hi
>
> I've been getting the following panic on recent current r249717.
> Sadly the crashdump is useless.
>
I just saw similar panic on 10-CURRENT r249588.
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 15; apic id = 0f
> instruction pointer = 0x20:0x80546fbc
> stack pointer = 0x28:0xff846b60
> frame pointer = 0x28:0xff846b6777b0
> 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 = 4361 (zabbix_agentd)
Hmm.. This is interests me. In my case, cf-agent was the current
process.
Backtrace of my panic follows. Any pointers on how to debug this
further would be appreciated.
Glen
Script started on Sat Apr 27 23:53:53 2013
root@orion:/usr/obj/usr/src/sys/ORION # kgdb ./kernel.debug /var/crash/vmcore.4
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer = 0x20:0x80736cec
stack pointer = 0x28:0xff81aad4e760
frame pointer = 0x28:0xff81aad4e7a0
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 = 78664 (cf-agent)
trap number = 9
panic: general protection fault
cpuid = 1
KDB: stack backtrace:
#0 0x80642a56 at kdb_backtrace+0x66
#1 0x80606eeb at panic+0x13b
#2 0x808e3b10 at trap_fatal+0x290
#3 0x808e4331 at trap+0x241
#4 0x808cdbb3 at calltrap+0x8
#5 0x807371d8 at in_pcb_lport+0x128
#6 0x8073745a at in_pcbbind_setup+0x16a
#7 0x80737d8e at in_pcbconnect_setup+0x71e
#8 0x80737df9 at in_pcbconnect_mbuf+0x59
#9 0x807bf29f at udp_connect+0x11f
#10 0x80680615 at kern_connectat+0x275
#11 0x80680731 at sys_connect+0x41
#12 0x808e32cb at amd64_syscall+0x63b
#13 0x808cde97 at Xfast_syscall+0xf7
Uptime: 3d19h38m52s
(ada0:ahcich0:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00
(ada0:ahcich0:0:0:0): CAM status: CCB request is in progress
(ada0:ahcich0:0:0:0): Error 5, Retries exhausted
(ada0:ahcich0:0:0:0): Synchronize cache failed
(ada1:ahcich1:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00
(ada1:ahcich1:0:0:0): CAM status: CCB request is in progress
(ada1:ahcich1:0:0:0): Error 5, Retries exhausted
(ada1:ahcich1:0:0:0): Synchronize cache failed
(ada2:ahcich4:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00
(ada2:ahcich4:0:0:0): CAM status: CCB request is in progress
(ada2:ahcich4:0:0:0): Error 5, Retries exhausted
(ada2:ahcich4:0:0:0): Synchronize cache failed
(ada3:ahcich5:0:0:0): FLUSHCACHE48. ACB: ea 00 00 00 00 40 00 00 00 00 00 00
(ada3:ahcich5:0:0:0): CAM status: CCB request is in progress
(ada3:ahcich5:0:0:0): Error 5, Retries exhausted
(ada3:ahcich5:0:0:0): Synchronize cache failed
Dumping 1014 out of 6049 MB:..2%..12%..21%..32%..42%..51%..62%..71%..81%..92%
Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
#0 doadump (textdump=) at pcpu.h:231
231 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0 doadump (textdump=) at pcpu.h:231
#1 0x80606a56 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:447
#2 0x80606ed5 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:754
#3 0x808e3b10 in trap_fatal (frame=0x9, eva=)
at /usr/src/sys/amd64/amd64/trap.c:872
#4 0x808e4331 in trap (frame=0xff81aad4e6b0)
at /usr/src/sys/amd64/amd64/trap.c:605
#5 0x808cdbb3 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:228
#6 0x80736cec in in_pcblookup_local (pcbinfo=0x80dc9180, laddr=
{s_addr = 50374848}, lport=339, lookupflags=1, cred=0xfe016cdad100)
at /usr/src/sys/netinet/in_pcb.c:1438
#7 0x807371d8 in in_pcb_lport (inp=0xfe016c2fb7a8,
laddrp=0xff81aad4e860,
lportp=0xff81aad4e86e, cred=0xfe016cdad100, lookupflags=1)
at /usr/src/sys/netinet/in_pcb.c:457
#8 0x8073745a in in_pcbbind_setup (inp=0xfe016c2fb7a8, nam=0x0,
laddrp=0xff81aad4e90
new FreeBSD kernel failed to load mobile disk
I rebuilt the FreeBSD 10.0 kernel, found it can't load my mobile disk: (da0:umass-sim0:0:0:0): ATA COMMAND PASS THROUGH(16). CDB: 85 0 8 0a 00 00 02 00 00 00 00 00 00 00 40 ec 00 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command The shutdown will be paused by it. When I pull out the mobile disk, the computer is shutdown normally. This is the information when I insert the disk: ugen0.4: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4100 umass0:4:0:-1: Attached to scbus4 xpt_release_devq(): requested 1 > present 0 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 476940MB (976773164 512 byte sectors: 255H 63S/T 60801C) ___ 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"
