[head tinderbox] failure on i386/pc98
TB --- 2013-04-22 02:50:50 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-22 02:50:50 - 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 --- 2013-04-22 02:50:50 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-04-22 02:50:50 - cleaning the object tree TB --- 2013-04-22 02:52:50 - /usr/local/bin/svn stat /src TB --- 2013-04-22 02:53:07 - At svn revision 249744 TB --- 2013-04-22 02:53:08 - building world TB --- 2013-04-22 02:53:08 - CROSS_BUILD_TESTING=YES TB --- 2013-04-22 02:53:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-22 02:53:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-22 02:53:08 - SRCCONF=/dev/null TB --- 2013-04-22 02:53:08 - TARGET=pc98 TB --- 2013-04-22 02:53:08 - TARGET_ARCH=i386 TB --- 2013-04-22 02:53:08 - TZ=UTC TB --- 2013-04-22 02:53:08 - __MAKE_CONF=/dev/null TB --- 2013-04-22 02:53:08 - cd /src TB --- 2013-04-22 02:53:08 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Apr 22 02:53:13 UTC 2013 >>> 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 >>> World build completed on Mon Apr 22 06:07:45 UTC 2013 TB --- 2013-04-22 06:07:45 - generating LINT kernel config TB --- 2013-04-22 06:07:45 - cd /src/sys/pc98/conf TB --- 2013-04-22 06:07:45 - /usr/bin/make -B LINT TB --- 2013-04-22 06:07:45 - cd /src/sys/pc98/conf TB --- 2013-04-22 06:07:45 - /usr/sbin/config -m LINT TB --- 2013-04-22 06:07:45 - building LINT kernel TB --- 2013-04-22 06:07:45 - CROSS_BUILD_TESTING=YES TB --- 2013-04-22 06:07:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-22 06:07:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-22 06:07:45 - SRCCONF=/dev/null TB --- 2013-04-22 06:07:45 - TARGET=pc98 TB --- 2013-04-22 06:07:45 - TARGET_ARCH=i386 TB --- 2013-04-22 06:07:45 - TZ=UTC TB --- 2013-04-22 06:07:45 - __MAKE_CONF=/dev/null TB --- 2013-04-22 06:07:45 - cd /src TB --- 2013-04-22 06:07:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Apr 22 06:07:45 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~ ./machine/bus.h:362:1: note: passing argument to parameter 'bsh' here _BUS_SPACE_WRITE(u_int32_t,4) ^ ./machine/bus.h:347:64: note: expanded from macro '_BUS_SPACE_WRITE' bus_space_write_##BWN (bus_space_tag_t tag, bus_space_handle_t bsh, \ ^ 4 errors generated. *** [uart_dev_lpc.o] Error code 1 Stop in /src/sys/modules/uart. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-22 06:32:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-22 06:32:20 - ERROR: failed to build LINT kernel TB --- 2013-04-22 06:32:20 - 10559.98 user 1542.43 system 13290.11 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.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: Supermicro 6027R-N3RF+head, usb trouble
On Mon, 22 Apr 2013 08:10:47 +0200 Hans Petter Selasky wrote: > On 04/21/13 21:38, Sergey V. Dyatko wrote: > > Hi, > > > > Can anybody explain why USB keyboard (and keyboard from > > integrated IPKVM) doesn't work when I boot with 'C606 > > chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? > > Also I can't boot that box from usb memstick and > > FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both > > loose(?) device and can't find root If I disable controller in bios > > system can't see any sata hdd connected to it:( > > booting with hw.usb.ehci.no_hs=1, kern.cam.boot_delay="1" > > and debug.acpi.disabled="hostres" without success. I setup dhcpd, > > tftp, nfs on my laptop and finally I install fbsd on that box, but > > question with kbd is open - It doesn't work.. > > dmesg: > > http://svn.freebsd.by/files/dmesg_N3RF.txt > > pciconf -lv: > > http://svn.freebsd.by/files/pciconf_N3RF.txt > > > > I would appreciate any hints > > > > Hi, > > This indicates a LOW memory problem, or unability to grab contiguous > memory for USB controller drivers: > > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_ctrl_transfer_setup: could not setup default USB transfer > usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) > usbd_ctrl_transfer_setup: could not setup default USB transfer > usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_ctrl_transfer_setup: could not setup default USB transfer > usbd_ctrl_transfer_setup: could not setup default USB transfer > > That's why USB doesn't work. Try to figure out who is using all that > memory. > Hi, how I can do that ? > --HPS -- wbr, tiger ___ 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: Supermicro 6027R-N3RF+head, usb trouble
On 04/21/13 21:38, Sergey V. Dyatko wrote: Hi, Can anybody explain why USB keyboard (and keyboard from integrated IPKVM) doesn't work when I boot with 'C606 chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? Also I can't boot that box from usb memstick and FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both loose(?) device and can't find root If I disable controller in bios system can't see any sata hdd connected to it:( booting with hw.usb.ehci.no_hs=1, kern.cam.boot_delay="1" and debug.acpi.disabled="hostres" without success. I setup dhcpd, tftp, nfs on my laptop and finally I install fbsd on that box, but question with kbd is open - It doesn't work.. dmesg: http://svn.freebsd.by/files/dmesg_N3RF.txt pciconf -lv: http://svn.freebsd.by/files/pciconf_N3RF.txt I would appreciate any hints Hi, This indicates a LOW memory problem, or unability to grab contiguous memory for USB controller drivers: usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_ctrl_transfer_setup: could not setup default USB transfer usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usb_alloc_device: set address 2 failed (USB_ERR_NOMEM, ignored) usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_ctrl_transfer_setup: could not setup default USB transfer usbd_ctrl_transfer_setup: could not setup default USB transfer That's why USB doesn't work. Try to figure out who is using all that memory. --HPS ___ 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: CURRENT: /usr/src/sbin/newfs_nandfs/newfs_nandfs.c:89:18: error: no previous extern declaration for non-static variable
Hi, 2013/4/21 O. Hartmann : > /usr/src/sbin/newfs_nandfs/newfs_nandfs.c:83:18: error: no previous > extern declaration for non-static variable > 'user_files' [-Werror,-Wmissing-variable-declarations] > struct file_info user_files[] = > ^ The following patch should fix this: http://80386.nl/pub/nandfs-warns-6.txt As of a couple of days ago, WARNS=6 requires that global variables either have an external declaration or are marked static. As newfs_nandfs only consists of a single C file, we can easily mark these variables static. In this specific case it allowed the compiler to find another peculiarity in the code, namely that the seg_segsum_size variable is unused. I'll commit this patch after I've done some testing. Thanks, -- Ed Schouten ___ 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: /usr/src/sbin/newfs_nandfs/newfs_nandfs.c:89:18: error: no previous extern declaration for non-static variable
While trying to build buildworld with
WITH_NAND= YES
in /etc/src.conf
I receive this error below.
[...]
ld -dc -r -o stty.lo
stty_stub.o /usr/obj/usr/src/rescue/rescue//usr/src/bin/stty/cchar.o
/usr/obj/usr/src/rescue/rescue//usr/src/bin/stty/gfmt.o
/usr/obj/usr/src/rescue/rescue//usr/src/bin/stty/key.o
/usr/obj/usr/src/rescue/rescue//usr/src/bin/stty/modes.o
/usr/obj/usr/src/rescue/rescue//usr/src/bin/stty/print.o
/usr/obj/usr/src/rescue/rescue//usr/src/bin/stty/stty.o
/usr/obj/usr/src/rescue/rescue//usr/src/bin/stty/util.o
crunchide -k _crunched_stty_stub stty.lo
ld -dc -r -o sync.lo
sync_stub.o /usr/obj/usr/src/rescue/rescue//usr/src/bin/sync/sync.o
crunchide -k _crunched_sync_stub sync.lo
ld -dc -r -o test.lo
test_stub.o /usr/obj/usr/src/rescue/rescue//usr/src/bin/test/test.o
crunchide -k _crunched_test_stub test.lo
ld -dc -r -o rcp.lo
rcp_stub.o /usr/obj/usr/src/rescue/rescue//usr/src/bin/rcp/rcp.o
/usr/obj/usr/src/rescue/rescue//usr/src/bin/rcp/util.o
crunchide -k _crunched_rcp_stub rcp.lo
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:83:18: error: no previous
extern declaration for non-static variable
'user_files' [-Werror,-Wmissing-variable-declarations]
struct file_info user_files[] =
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:88:18: error: no previous
extern declaration for non-static variable
'ifile' [-Werror,-Wmissing-variable-declarations]
struct file_info ifile = {NANDFS_IFILE_INO, NULL, 0, 0, -1, NULL, NULL};
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:89:18: error: no previous
extern declaration for non-static variable
'sufile' [-Werror,-Wmissing-variable-declarations]
struct file_info sufile = {NANDFS_SUFILE_INO, NULL, 0, 0, -1, NULL,
NULL};
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:90:18: error: no previous
extern declaration for non-static variable
'cpfile' [-Werror,-Wmissing-variable-declarations]
struct file_info cpfile = {NANDFS_CPFILE_INO, NULL, 0, 0, -1, NULL,
NULL};
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:91:18: error: no previous
extern declaration for non-static variable
'datfile' [-Werror,-Wmissing-variable-declarations]
struct file_info datfile = {NANDFS_DAT_INO, NULL, 0, 0, -1, NULL, NULL};
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:123:9: error: no previous
extern declaration for non-static variable
'volumelabel' [-Werror,-Wmissing-variable-declarations]
u_char *volumelabel = NULL;
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:109:22: error: no previous
extern declaration for non-static variable
'fsdata' [-Werror,-Wmissing-variable-declarations]
struct nandfs_fsdata fsdata;
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:110:27: error: no previous
extern declaration for non-static variable
'super_block' [-Werror,-Wmissing-variable-declarations]
struct nandfs_super_block super_block;
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:125:27: error: no previous
extern declaration for non-static variable
'sr' [-Werror,-Wmissing-variable-declarations]
struct nandfs_super_root *sr;
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:127:10: error: no previous
extern declaration for non-static variable
'nuserfiles' [-Werror,-Wmissing-variable-declarations]
uint32_t nuserfiles;
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:128:10: error: no previous
extern declaration for non-static variable
'seg_segsum_size' [-Werror,-Wmissing-variable-declarations]
uint32_t seg_segsum_size;
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:129:10: error: no previous
extern declaration for non-static variable
'seg_nblocks' [-Werror,-Wmissing-variable-declarations]
uint32_t seg_nblocks;
^
/usr/src/sbin/newfs_nandfs/newfs_nandfs.c:130:10: error: no previous
extern declaration for non-static variable
'seg_endblock' [-Werror,-Wmissing-variable-declarations]
uint32_t seg_endblock;
^
13 errors generated.
*** [newfs_nandfs.o] Error code 1
1 error
*** [all] Error code 2
1 error
*** [sbin.all__D] Error code 2
signature.asc
Description: This is a digitally signed message part
Supermicro 6027R-N3RF+head, usb trouble
Hi, Can anybody explain why USB keyboard (and keyboard from integrated IPKVM) doesn't work when I boot with 'C606 chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? Also I can't boot that box from usb memstick and FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both loose(?) device and can't find root If I disable controller in bios system can't see any sata hdd connected to it:( booting with hw.usb.ehci.no_hs=1, kern.cam.boot_delay="1" and debug.acpi.disabled="hostres" without success. I setup dhcpd, tftp, nfs on my laptop and finally I install fbsd on that box, but question with kbd is open - It doesn't work.. dmesg: http://svn.freebsd.by/files/dmesg_N3RF.txt pciconf -lv: http://svn.freebsd.by/files/pciconf_N3RF.txt I would appreciate any hints -- wbr, tiger ___ 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 i386/pc98
TB --- 2013-04-21 15:50:31 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-21 15:50:31 - 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 --- 2013-04-21 15:50:31 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-04-21 15:50:31 - cleaning the object tree TB --- 2013-04-21 15:52:17 - /usr/local/bin/svn stat /src TB --- 2013-04-21 15:52:34 - At svn revision 249722 TB --- 2013-04-21 15:52:35 - building world TB --- 2013-04-21 15:52:35 - CROSS_BUILD_TESTING=YES TB --- 2013-04-21 15:52:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-21 15:52:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-21 15:52:35 - SRCCONF=/dev/null TB --- 2013-04-21 15:52:35 - TARGET=pc98 TB --- 2013-04-21 15:52:35 - TARGET_ARCH=i386 TB --- 2013-04-21 15:52:35 - TZ=UTC TB --- 2013-04-21 15:52:35 - __MAKE_CONF=/dev/null TB --- 2013-04-21 15:52:35 - cd /src TB --- 2013-04-21 15:52:35 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Apr 21 15:52:40 UTC 2013 >>> 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 >>> World build completed on Sun Apr 21 19:06:49 UTC 2013 TB --- 2013-04-21 19:06:49 - generating LINT kernel config TB --- 2013-04-21 19:06:49 - cd /src/sys/pc98/conf TB --- 2013-04-21 19:06:49 - /usr/bin/make -B LINT TB --- 2013-04-21 19:06:50 - cd /src/sys/pc98/conf TB --- 2013-04-21 19:06:50 - /usr/sbin/config -m LINT TB --- 2013-04-21 19:06:50 - building LINT kernel TB --- 2013-04-21 19:06:50 - CROSS_BUILD_TESTING=YES TB --- 2013-04-21 19:06:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-21 19:06:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-21 19:06:50 - SRCCONF=/dev/null TB --- 2013-04-21 19:06:50 - TARGET=pc98 TB --- 2013-04-21 19:06:50 - TARGET_ARCH=i386 TB --- 2013-04-21 19:06:50 - TZ=UTC TB --- 2013-04-21 19:06:50 - __MAKE_CONF=/dev/null TB --- 2013-04-21 19:06:50 - cd /src TB --- 2013-04-21 19:06:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 21 19:06:50 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~ ./machine/bus.h:362:1: note: passing argument to parameter 'bsh' here _BUS_SPACE_WRITE(u_int32_t,4) ^ ./machine/bus.h:347:64: note: expanded from macro '_BUS_SPACE_WRITE' bus_space_write_##BWN (bus_space_tag_t tag, bus_space_handle_t bsh, \ ^ 4 errors generated. *** [uart_dev_lpc.o] Error code 1 Stop in /src/sys/modules/uart. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-21 19:31:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-21 19:31:27 - ERROR: failed to build LINT kernel TB --- 2013-04-21 19:31:27 - 10566.59 user 1533.19 system 13256.14 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.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: ipv6_addrs_IF aliases in rc.conf(5)
W dniu 2013-04-13 22:15, Michael Grimm pisze: > On 13.04.2013, at 14:29, Kimmo Paasiala wrote: > > [great deal of simplification by ipv6_addrs_IF] > >> Sorry to resurrect this thread but since nothing has happened in about >> three months I have to ask: What can I do to have this commited to >> HEAD? > > +1 > > Nowadays -where IPv6 becomes more and more available by ISPs- I *really* > would like to see this simplification implemented, soon, very soon. The > current scheme is way to much error prone, and, its a pain in the ass! Kimmo's patch worked for me. It would be great to have ipv6_addrs_if out of the box. -- best regards, Lukasz Wasikowski ___ 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 when booting HEAD on i386
On 4/21/2013 6:54 AM, Ganbold Tsagaankhuu wrote: As mentioned in one of my previous email I have 2GB machine which is probably not worth to have zfs on such system. Sorry for the noise. thanks, Ganbold Before I upgraded my system, I used 2GB of ram with ZFS on root, no UFS on the system. Right now my ARC is 17GB, and in some situations it seems slower with the excess caching. Here are the memory settings I used. vm.kmem_size="512M" vm.kmem_size_max="1024M" vfs.zfs.arc_max="512M" One major difference is I'm using amd64, not i386. Although ZFS works on i386, it uses a lot of 64 bit math, for performance reasons you should use ZFS on amd64. ___ 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: Any objections/comments on axing out old ATA stack?
ATA controller drivers are delaying conflicting commands, avoiding conflicts in device. 21.04.2013 14:32 пользователь "Jeremy Chadwick" написал: > On Sun, Apr 21, 2013 at 02:11:04PM +0300, Alexander Motin wrote: > > On 21.04.2013 00:29, Jeremy Chadwick wrote: > > >- The ATA commands which lead up to the error also vary. Many are for > > > write requests, and from some entries I can see that the OS was doing > > > NCQ writes (WRITE FPDMA QUEUED) and then suddenly decided to do a > > > classic 28-bit LBA write (WRITE DMA). I'm not sure why an OS would > do > > > this (there's nothing optimal about it) unless there were conditions > > > occurring where the OS/ATA driver said "this NCQ write isn't working > > > (timeout, etc.), let me retry with a classic 28-bit LBA write". > > > > ATA disk driver in CAM inserts non-queued command every several > > seconds of continuous load to limit possible command starvation > > inside the disk. SCSI driver does alike things, but inserts ordered > > command flag, that does not exist in SATA, instead of different > > command. > > Thanks for the insights Alexander, greatly appreciated. > > I'm a little confused by your description, because if I'm reading it > right, it sounds like it conflicts with what the ACS-2 spec states. > Quoting T13/2015-D rev 3 (I'm aware it's a working draft), section > 4.16.1: > > "If the device receives a command that is not an NCQ command while NCQ > commands are in the queue, then the device shall return command aborted > for the new command and for all of the NCQ commands that are in the > queue." > > I assume this means ABRT status is returned to the host controller; if > so (and by design of course), how do we differentiate between that > condition and any other I/O condition that induces ABRT? > > Possibly in the answer is in this admission: I should probably get > around to reading ATA8-AST sometime. :-) > > -- > | Jeremy Chadwick j...@koitsu.org | > | UNIX Systems Administratorhttp://jdc.koitsu.org/ | > | Mountain View, CA, US| > | Making life hard for others since 1977. PGP 4BD6C0CB | > ___ 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: Any objections/comments on axing out old ATA stack?
On Sun, Apr 21, 2013 at 02:11:04PM +0300, Alexander Motin wrote: > On 21.04.2013 00:29, Jeremy Chadwick wrote: > >- The ATA commands which lead up to the error also vary. Many are for > > write requests, and from some entries I can see that the OS was doing > > NCQ writes (WRITE FPDMA QUEUED) and then suddenly decided to do a > > classic 28-bit LBA write (WRITE DMA). I'm not sure why an OS would do > > this (there's nothing optimal about it) unless there were conditions > > occurring where the OS/ATA driver said "this NCQ write isn't working > > (timeout, etc.), let me retry with a classic 28-bit LBA write". > > ATA disk driver in CAM inserts non-queued command every several > seconds of continuous load to limit possible command starvation > inside the disk. SCSI driver does alike things, but inserts ordered > command flag, that does not exist in SATA, instead of different > command. Thanks for the insights Alexander, greatly appreciated. I'm a little confused by your description, because if I'm reading it right, it sounds like it conflicts with what the ACS-2 spec states. Quoting T13/2015-D rev 3 (I'm aware it's a working draft), section 4.16.1: "If the device receives a command that is not an NCQ command while NCQ commands are in the queue, then the device shall return command aborted for the new command and for all of the NCQ commands that are in the queue." I assume this means ABRT status is returned to the host controller; if so (and by design of course), how do we differentiate between that condition and any other I/O condition that induces ABRT? Possibly in the answer is in this admission: I should probably get around to reading ATA8-AST sometime. :-) -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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 when booting HEAD on i386
On Sun, Apr 21, 2013 at 7:27 PM, Konstantin Belousov wrote: > On Sun, Apr 21, 2013 at 01:57:03PM +0800, Ganbold Tsagaankhuu wrote: > > On Sat, Apr 20, 2013 at 11:21 PM, Konstantin Belousov > > wrote: > > > > > On Sat, Apr 20, 2013 at 10:52:35PM +0800, Ganbold Tsagaankhuu wrote: > > > > Hi, > > > > > > > > I'm trying to boot HEAD after updating, but unfortunately it panics > with > > > > following message: > > > > > > > > panic: kmem_suballoc: bad status return of 3. > > > > > > > > I was only able to get image of the panic. > > > > > > > > http://www.mnbsd.org/ganbold/IMG_20130420_222353-2.jpg > > > > > > > > Does anybody see same panic booting on i386 lately? > > > > Tried clang, and it panics also. > > > > > > How much memory do you have ? > > > Do you have any tunables in the loader.conf ? > > > > > > > Following settings caused the panic: > > > > vm.kmem_size="999M" > > vm.kmem_size_max="999M" > I cannot imagine how this could work earlier as well, except by chance. > Right, probably by chance it didn't cause panic in previous version. > > > > > Whether it is regression or not in previous version of kernel (r244046) > it > > didn't panic on boot. > > Seems no information on UPDATING either. > Do you propose to enumerate all non-working or panic-provoking settings in > loader.conf ? > Not really. > > Why did you set this value at all ? > These are the settings that I did for zfs, since my machine has zfs and probably it is not even worth to run zfs on 2GB system. It is my fault. > > KVA on i386 is limited to slightly less then 1GB, where all the kernel > maps must be instantiated. Kernel uses the value of the tunable > vm.kmem_size literally, except it makes a mild attempt to prevent > foot-shooting by capping kmem_size to 2 * physical memory size. > > You neglected to answer how much memory is installed on your machine, > As mentioned in one of my previous email I have 2GB machine which is probably not worth to have zfs on such system. Sorry for the noise. thanks, Ganbold > but I suspect you have enough so that overblown kmem_map cannot coexists > with other kernel VA consumers. > ___ 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: amd64 buildworld lib32 flags fail
Konstantin Belousov wrote: > > > rm: /usr/obj/usr/src/lib32: Directory not empty > > > *** [_worldtmp] Error code 1 > >=20 > > Maybe you buildworld is jailed? > > This is the usual consequence of the install -S usage, e.g. by setting > "INSTALL=install -CS" in the make.conf. Ah, thanks. That would be the difference, except that I have: INSTALL=install 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"
Re: panic when booting HEAD on i386
On Sun, Apr 21, 2013 at 01:57:03PM +0800, Ganbold Tsagaankhuu wrote: > On Sat, Apr 20, 2013 at 11:21 PM, Konstantin Belousov > wrote: > > > On Sat, Apr 20, 2013 at 10:52:35PM +0800, Ganbold Tsagaankhuu wrote: > > > Hi, > > > > > > I'm trying to boot HEAD after updating, but unfortunately it panics with > > > following message: > > > > > > panic: kmem_suballoc: bad status return of 3. > > > > > > I was only able to get image of the panic. > > > > > > http://www.mnbsd.org/ganbold/IMG_20130420_222353-2.jpg > > > > > > Does anybody see same panic booting on i386 lately? > > > Tried clang, and it panics also. > > > > How much memory do you have ? > > Do you have any tunables in the loader.conf ? > > > > Following settings caused the panic: > > vm.kmem_size="999M" > vm.kmem_size_max="999M" I cannot imagine how this could work earlier as well, except by chance. > > Whether it is regression or not in previous version of kernel (r244046) it > didn't panic on boot. > Seems no information on UPDATING either. Do you propose to enumerate all non-working or panic-provoking settings in loader.conf ? Why did you set this value at all ? KVA on i386 is limited to slightly less then 1GB, where all the kernel maps must be instantiated. Kernel uses the value of the tunable vm.kmem_size literally, except it makes a mild attempt to prevent foot-shooting by capping kmem_size to 2 * physical memory size. You neglected to answer how much memory is installed on your machine, but I suspect you have enough so that overblown kmem_map cannot coexists with other kernel VA consumers. pgp909eLEKQPT.pgp Description: PGP signature
Re: amd64 buildworld lib32 flags fail
On Sun, Apr 21, 2013 at 11:27:55AM +0200, Jeremie Le Hen wrote: > Hi Ian, > > On Sun, Apr 21, 2013 at 11:08:41AM +0200, Ian FREISLICH wrote: > > -- > > >>> Rebuilding the temporary build tree > > -- > > rm -rf /usr/obj/usr/src/tmp > > rm -rf /usr/obj/usr/src/lib32 > > rm: /usr/obj/usr/src/lib32/usr/lib32/libc.so.7: Operation not permitted > > rm: /usr/obj/usr/src/lib32/usr/lib32/libcrypt.so.5: Operation not permitted > > rm: /usr/obj/usr/src/lib32/usr/lib32/libthr.so.3: Operation not permitted > > rm: /usr/obj/usr/src/lib32/usr/lib32/librt.so.1: Operation not permitted > > rm: /usr/obj/usr/src/lib32/usr/lib32: Directory not empty > > rm: /usr/obj/usr/src/lib32/usr: Directory not empty > > rm: /usr/obj/usr/src/lib32: Directory not empty > > *** [_worldtmp] Error code 1 > > Maybe you buildworld is jailed? This is the usual consequence of the install -S usage, e.g. by setting "INSTALL=install -CS" in the make.conf. pgpImJwDs2vbo.pgp Description: PGP signature
Re: Any objections/comments on axing out old ATA stack?
On 21.04.2013 00:29, Jeremy Chadwick wrote: - The ATA commands which lead up to the error also vary. Many are for write requests, and from some entries I can see that the OS was doing NCQ writes (WRITE FPDMA QUEUED) and then suddenly decided to do a classic 28-bit LBA write (WRITE DMA). I'm not sure why an OS would do this (there's nothing optimal about it) unless there were conditions occurring where the OS/ATA driver said "this NCQ write isn't working (timeout, etc.), let me retry with a classic 28-bit LBA write". ATA disk driver in CAM inserts non-queued command every several seconds of continuous load to limit possible command starvation inside the disk. SCSI driver does alike things, but inserts ordered command flag, that does not exist in SATA, instead of different command. -- Alexander Motin ___ 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: amd64 buildworld lib32 flags fail
Hi Ian, On Sun, Apr 21, 2013 at 11:08:41AM +0200, Ian FREISLICH wrote: > > I have some amd64 systems that fail cleaning up lib32 and some that > don't. I have to chflags noschg these files before starting a > buildworld. I can't figure out what the difference is between the > systems that work and those that don't. > > -- > >>> Rebuilding the temporary build tree > -- > rm -rf /usr/obj/usr/src/tmp > rm -rf /usr/obj/usr/src/lib32 > rm: /usr/obj/usr/src/lib32/usr/lib32/libc.so.7: Operation not permitted > rm: /usr/obj/usr/src/lib32/usr/lib32/libcrypt.so.5: Operation not permitted > rm: /usr/obj/usr/src/lib32/usr/lib32/libthr.so.3: Operation not permitted > rm: /usr/obj/usr/src/lib32/usr/lib32/librt.so.1: Operation not permitted > rm: /usr/obj/usr/src/lib32/usr/lib32: Directory not empty > rm: /usr/obj/usr/src/lib32/usr: Directory not empty > rm: /usr/obj/usr/src/lib32: Directory not empty > *** [_worldtmp] Error code 1 Maybe you buildworld is jailed? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: Booting an alternative kernel from loader prompt fails the first time only
On 21.04.2013 04:36, Steven Hartland wrote: > This fails and trips the "Restart from the beginning" case which contains: > last_file_format = i = 0; > fp = NULL; > continue; > > So "i" gets set to 0 but the loop then increments it to 1 before running > the next iteration, so its impossible to use first handler in the retry > case; which I suspect is the kernel loader. > > This also explains why the second call to boot works as last_file_format > is now 0 due to the previous failure. > > If this is the issue the attached patch should fix it. I can't test it > ATM as my current box is at the office and doesn't have remote KVM, so > I need to be in front of it. > > If anyone can confirm this attached patch fixes the problem then I'll get > it committed, otherwise I'll test on Monday. Hi, yes, you are right. I just committed this with r249719. Thanks. -- 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"
amd64 buildworld lib32 flags fail
Hi I have some amd64 systems that fail cleaning up lib32 and some that don't. I have to chflags noschg these files before starting a buildworld. I can't figure out what the difference is between the systems that work and those that don't. -- >>> Rebuilding the temporary build tree -- rm -rf /usr/obj/usr/src/tmp rm -rf /usr/obj/usr/src/lib32 rm: /usr/obj/usr/src/lib32/usr/lib32/libc.so.7: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/libcrypt.so.5: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/libthr.so.3: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/librt.so.1: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32: Directory not empty rm: /usr/obj/usr/src/lib32/usr: Directory not empty rm: /usr/obj/usr/src/lib32: Directory not empty *** [_worldtmp] Error code 1 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"
[head tinderbox] failure on i386/pc98
TB --- 2013-04-21 04:42:31 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-04-21 04:42:31 - 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 --- 2013-04-21 04:42:31 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-04-21 04:42:31 - cleaning the object tree TB --- 2013-04-21 04:44:13 - /usr/local/bin/svn stat /src TB --- 2013-04-21 04:44:24 - At svn revision 249715 TB --- 2013-04-21 04:44:25 - building world TB --- 2013-04-21 04:44:25 - CROSS_BUILD_TESTING=YES TB --- 2013-04-21 04:44:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-21 04:44:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-21 04:44:25 - SRCCONF=/dev/null TB --- 2013-04-21 04:44:25 - TARGET=pc98 TB --- 2013-04-21 04:44:25 - TARGET_ARCH=i386 TB --- 2013-04-21 04:44:25 - TZ=UTC TB --- 2013-04-21 04:44:25 - __MAKE_CONF=/dev/null TB --- 2013-04-21 04:44:25 - cd /src TB --- 2013-04-21 04:44:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Apr 21 04:44:31 UTC 2013 >>> 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 >>> World build completed on Sun Apr 21 08:02:31 UTC 2013 TB --- 2013-04-21 08:02:31 - generating LINT kernel config TB --- 2013-04-21 08:02:31 - cd /src/sys/pc98/conf TB --- 2013-04-21 08:02:31 - /usr/bin/make -B LINT TB --- 2013-04-21 08:02:31 - cd /src/sys/pc98/conf TB --- 2013-04-21 08:02:31 - /usr/sbin/config -m LINT TB --- 2013-04-21 08:02:31 - building LINT kernel TB --- 2013-04-21 08:02:31 - CROSS_BUILD_TESTING=YES TB --- 2013-04-21 08:02:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-21 08:02:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-21 08:02:31 - SRCCONF=/dev/null TB --- 2013-04-21 08:02:31 - TARGET=pc98 TB --- 2013-04-21 08:02:31 - TARGET_ARCH=i386 TB --- 2013-04-21 08:02:31 - TZ=UTC TB --- 2013-04-21 08:02:31 - __MAKE_CONF=/dev/null TB --- 2013-04-21 08:02:31 - cd /src TB --- 2013-04-21 08:02:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Apr 21 08:02:31 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ^~~~ ./machine/bus.h:362:1: note: passing argument to parameter 'bsh' here _BUS_SPACE_WRITE(u_int32_t,4) ^ ./machine/bus.h:347:64: note: expanded from macro '_BUS_SPACE_WRITE' bus_space_write_##BWN (bus_space_tag_t tag, bus_space_handle_t bsh, \ ^ 4 errors generated. *** [uart_dev_lpc.o] Error code 1 Stop in /src/sys/modules/uart. *** [all] Error code 1 Stop in /src/sys/modules. *** [modules-all] Error code 1 Stop in /obj/pc98.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-21 08:27:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-21 08:27:26 - ERROR: failed to build LINT kernel TB --- 2013-04-21 08:27:26 - 10571.43 user 1522.24 system 13495.62 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.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: Booting an alternative kernel from loader prompt fails the first time only
On 21.04.2013 02:36 (UTC+2), Steven Hartland wrote: > > - Original Message - From: "Joshua Isom" > To: > Sent: Sunday, April 21, 2013 12:41 AM > Subject: Re: Booting an alternative kernel from loader prompt fails the > first time only > > >> On 4/20/2013 12:41 PM, Manfred Antar wrote: >>> At 10:24 AM 4/20/2013, Rainer Hurling wrote: On 20.04.2013 18:47 (UTC+2), Florian Smeets wrote: > On 20.04.13 18:05, Steven Hartland wrote: >> When trying to boot an alternative kernel from the loader prompt >> it fails the first time the command is run but succeeds the second >> time. >> >> Type '?' for a list of commands, 'help' for more detailed help. >> OK boot kernel.generic >> Booting... >> don't know how to load module '/boot/kernel.generic/kernel' >> OK boot kernel.generic >> Booting... >> /boot/kernel.generic/kernel text=0xd21288 data=.. >> > > Yes, I've been seeing the same thing for about 6-12 months maybe more. > None of the people I asked were able to confirm, so I'm happy that I'm > not imagining it :) I also can confirm this behaviour for month now (on 10.0-CURRENT amd64 with clang). Rainer >>> >>> Have you tried: >>> OK boot /boot/kernel.generic/kernel >>> >>> Use full path name always works for me >>> Manfred > > I believe this may well have been introduced by:- > http://svnweb.freebsd.org/base?view=revision&revision=241069 > > When booting with a /boot/loader.conf that contains a module load line > e.g. zfs_load="YES" then this is loaded before the kernel. > > Loading any module causes last_file_format to get set so when the next > file that's loaded is in fact a kernel it still try's to load it as a > "kernel module" using what was stored with last_file_format. > > This fails and trips the "Restart from the beginning" case which contains: > last_file_format = i = 0; > fp = NULL; > continue; > > So "i" gets set to 0 but the loop then increments it to 1 before running > the next iteration, so its impossible to use first handler in the retry > case; which I suspect is the kernel loader. > > This also explains why the second call to boot works as last_file_format > is now 0 due to the previous failure. > > If this is the issue the attached patch should fix it. I can't test it > ATM as my current box is at the office and doesn't have remote KVM, so > I need to be in front of it. > > If anyone can confirm this attached patch fixes the problem then I'll get > it committed, otherwise I'll test on Monday. I tried your patch with recent 10.0-CURRENT amd64 (r249715, clang), and it seems to work. I can set module path, load some modules, and afterwards load a kernel in one call. Thank you very much. Best wishes, Rainer > >Regards >Steve ___ 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"
