Re: ale(4) cannot negotiate as GigE
On Tue, Mar 05, 2013 at 06:59:10AM +, Alexey Dokuchaev wrote: > On Tue, Mar 05, 2013 at 02:49:20PM +0900, YongHyeon PYUN wrote: > > On Mon, Mar 04, 2013 at 08:18:58AM +, Alexey Dokuchaev wrote: > > > Yes, multiple reboots was a good idea, it's not very stable: [...] > > > > > > I've tried various combinations of just reboot, shutdown -r +1m and > > > pinging some host while waiting for reboot. > > > > Could you disable WOL before rebooting your box? > > # ifconfig ale0 -wol > # reboot > > It came up as 100baseTX. :( You don't use any manual link configuration, right? When you see the controller established a 100Mbps link, how about restarting auto-negotiation? Does that also result in 100Mbps link? #ifconfig ale0 media auto > > ./danfe ___ 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: ale(4) cannot negotiate as GigE
On Tue, Mar 05, 2013 at 02:49:20PM +0900, YongHyeon PYUN wrote: > On Mon, Mar 04, 2013 at 08:18:58AM +, Alexey Dokuchaev wrote: > > Yes, multiple reboots was a good idea, it's not very stable: [...] > > > > I've tried various combinations of just reboot, shutdown -r +1m and > > pinging some host while waiting for reboot. > > Could you disable WOL before rebooting your box? # ifconfig ale0 -wol # reboot It came up as 100baseTX. :( ./danfe ___ 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: access to hard drives is "blocked" by writes to a flash drive
Content-Type: text/plain; charset=ISO-8859-1 In message <201303050519.r255jbau012...@gw.catspoiler.org>, Don Lewis writes: >That's been my opinion for a long time as well, though I think it would >be better to have one thread per device to avoid syncer threads for >multiple partitions on the same drive all contending for the same >actuator. That would require that you move the syncer to the bottom of GEOM and initiate syncs by upcalls to the consumers above. But how does that work in the case of a mirrored drive ? Doesn't sound like a good idea to me. >Multiple threads would allow us to better exploit the parallelism >provided by the hardware and prevent a slow drive from impacting the >performance of the other drives in the system. It would also allow us to have different sync-intervals for different filesystems. >> I'm not sure if the syncer is untangled enough that we can have >> per mount-point threads yet, but as soon as we can, we should do that. > >I'm not aware of any fundamental issues preventing this from being >implemented, though I haven't spent much time looking at recent versions >of the code. It used to be impossible because of all the implicit locking based on pseudo-vnodes and whats-not... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: ale(4) cannot negotiate as GigE
On Mon, Mar 04, 2013 at 08:18:58AM +, Alexey Dokuchaev wrote: > On Mon, Mar 04, 2013 at 04:06:32PM +0900, YongHyeon PYUN wrote: > > On Mon, Mar 04, 2013 at 06:59:40AM +, Alexey Dokuchaev wrote: > > > Better this time, I'm having 1000baseT again! :-) > > > > Thanks a lot for testing and patience! > > Could you reboot multiple times and check whether you reliably get > > a gigabit link? > > Yes, multiple reboots was a good idea, it's not very stable: > > 1st reboot: 100baseTX (!) > 2nd reboot: 1000baseT > 3rd reboot: 1000baseT > 4th reboot: 1000baseT > 5th reboot: 100baseTX (!) > 6th reboot: 100baseTX (!) > 7th reboot: 1000baseT > 8th reboot: 100baseTX (!) > 9th reboot: 1000baseT > 10th reboot: 1000baseT > > I've tried various combinations of just reboot, shutdown -r +1m and pinging > some host while waiting for reboot. Could you disable WOL before rebooting your box? You can disable WOL like the following. #ifconfig ale0 -wol > > ./danfe ___ 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: access to hard drives is "blocked" by writes to a flash drive
On 4 Mar, Ian Lepore wrote: > On Sun, 2013-03-03 at 20:28 +, Steven Hartland wrote: >> - Original Message - >> From: "Ian Lepore" >> To: "Poul-Henning Kamp" >> Cc: "deeptech71" ; ; >> "Peter Jeremy" >> Sent: Sunday, March 03, 2013 1:54 PM >> Subject: Re: access to hard drives is "blocked" by writes to a flash drive >> >> >> > On Sun, 2013-03-03 at 13:35 +, Poul-Henning Kamp wrote: >> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> >> >> In message <1362317291.1195.216.ca...@revolution.hippie.lan>, Ian Lepore >> >> writes >> >> : >> >> >> >> >I run into this behavior all the time too, mostly on arm systems that >> >> >have an sd card or usb thumb driver as their main/only drive. >> >> >> >> This is really a FAQ and I belive I have answered it N times already: >> >> >> >> There are, broadly speaking, two classes of flash-storage: "Camera-grade" >> >> and "the real thing". >> >> >> >> "Camera-grade" have a very limited "Flash adaptation layer" which >> >> typically >> >> only can hold one flash-block open for writing at a time, and is typically >> >> found in CF and SD cards, USB sticks etc. >> >> >> >> Some of them gets further upset if the filesystem is not the FAT they >> >> expect, because they implement "M-Systems" (patented) trick with >> >> monitoring >> >> block deletes in FAT to simulate a TRIM facility. >> >> >> >> A number of products exist with such designs, typically a CF-style, is >> >> put behind a SATA-PATA bridge and sold as 2.5" SSD SATA devices. >> >> "Transcend" have done this for instance. >> >> >> >> If you use this class of devices for anything real, gstat will show >> >> you I/O write-times of several seconds in periodic pile-ups, even >> >> 100 seconds if you are doing something heavy. >> >> >> >> For various reasons (see: Lemming-syncer) FreeBSD will block all I/O >> >> traffic to other disks too, when these pileups gets too bad. >> > >> > Hmmm, so the problem has been known and unfixed for 10 years. That's >> > not encouraging. One of the messages in the lemming-syncer mail thread >> > might explain why I've been seeing this a lot lately in hobbyist work, >> > but not so much at $work where we use sd cards heavily... we use very >> > short syncer timeouts on SD and CF storage at $work: >> > >> > kern.metadelay: 3 >> > kern.dirdelay: 4 >> > kern.filedelay: 5 >> > >> > I might play with similar settings on some of my arm boards here. >> >> Interesting, are these relevant for all filesystems e.g. ZFS? >> >> Regards >> Steve > > I'm not sure, I know almost nothing about zfs. I do know we used those > tunings for a specific reason and I sure wouldn't recommend them for > general use. There's a comment block at the top of kern/vfs_subr.c with > some information on those delay values and how they're used that you > might find useful. I think in general such small numbers on a system > doing lots of IO would be counter-productive. > > In our case we arrived at those tunings this way... We have embedded > systems with CF and SD cards as their only mass storage, and we do a > relatively small amount of writing to the cards (occasional config > changes, low-volume routine logging via syslog, not much else). > Occasionally when newsyslog kicks in there'll be a short burst of IO to > compress and rotate, then back to a trickle again. Once upon a time we > mounted the filesystem without softupdates and with the sync option. > That was fairly robust against users pulling the plug right after making > a config change, but very very slow during syslog rotation, sometimes to > the point of peturbing our apps (the CF cards run in PIO mode, and a > burst of PIO activity is hard on time-critical apps). > > So we switched using softupdates and turned off the sync option. That > was nicer to our apps, but left a long window during which updates > didn't get flushed to the card. So we lowered those 3 tuning values to > the lowest numbers supported by the code (as I vaguely remember it, this > was years ago), not to get any sort of change in performance, but to > reduce the window during which data just sat around in memory waiting > for potential further updates before being flushed. The further updates > would never happen for us, so the long delays had no benefit. This tuning could potentially increase the amount of I/O that actually occurs. The only advantage would be that large files that are sequentially written would be flushed to disk more frequently but in smaller amounts. To avoid the potential problem of lost config changes, could you put a wrapper around the editor to fsync the config file? ___ 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: access to hard drives is "blocked" by writes to a flash drive
On 4 Mar, Ian Lepore wrote: > On Sun, 2013-03-03 at 19:01 -0800, Don Lewis wrote: >> On 3 Mar, Poul-Henning Kamp wrote: >> >> > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O >> > traffic to other disks too, when these pileups gets too bad. >> >> The Lemming-syncer problem should have mostly been fixed by 231160 in >> head (231952 in stable/9 and 231967 in stable/8) a little over a year >> ago. The exceptions are atime updates, mmaped files with dirty pages, >> and quotas. Under certain workloads I still notice periodic bursts of >> seek noise. After thinking about it for a bit, I suspect that it could >> be atime updates, but I haven't tried to confirm that. >> >> When using TCQ or NCQ, perhaps we should limit the number of outstanding >> writes per device to leave some slots open for reads. We should >> probably also prioritize reads over writes unless we are under memory >> pressure. >> > > Then either those changes didn't have the intended effect, or the > problem we're seeing with lack of system responsiveness when there's a > large backlog of writes to a slow device is not the lemming-syncer > problem. It's also not a lack of TCQ/NCQ slots, given that no such > thing exists with SD card IO. > > When this is going on, the process driving the massive output spends > almost all its time in a wdrain wait, and if you try to launch an app > that isn't already in cache, a siginfo generally shows it to be in a > getblk wait. If your only drive is a single SD card, then you're pretty much hosed when I/O is blocked because the SD card is doing an erase. It can only handle one command at a time, and if a write blocks, there's nothing that we can do to get it to execute a read until it is done with the write command that it is hung up on. I'm not familiar with the lower layers, but things might be less bad if read ops can jump ahead and get sent to the drive before any queued writes. ___ 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: access to hard drives is "blocked" by writes to a flash drive
On 4 Mar, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > > In message <201303040712.r247cejp008...@gw.catspoiler.org>, Don Lewis writes: > >>Prior to 231160, the syncer thread would call sync_vnode() for the >>syncer vnode of each mountpoint every 30 seconds [...] > > I agree that the lemming syncer is better, but the fundamental mistake of > only having one syncer thread is probably the root-cause in this case: > One camera-grade flash syncing may take (a lot) more than 30 seconds. That's been my opinion for a long time as well, though I think it would be better to have one thread per device to avoid syncer threads for multiple partitions on the same drive all contending for the same actuator. One complication is that the notion of a device gets pretty hazy given that we have the geom layer in between the syncer and the hardware. I'd still have a separate worklist for each mountpoint. Multiple threads would allow us to better exploit the parallelism provided by the hardware and prevent a slow drive from impacting the performance of the other drives in the system. > One mountpoint having trouble (of whatever kind) should not affect > the rest of the mountpoints. > > I'm not sure if the syncer is untangled enough that we can have > per mount-point threads yet, but as soon as we can, we should do that. I'm not aware of any fundamental issues preventing this from being implemented, though I haven't spent much time looking at recent versions of the code. ___ 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: access to hard drives is "blocked" by writes to a flash drive
On 4 Mar, Peter Jeremy wrote: > On 2013-Mar-03 23:12:40 -0800, Don Lewis wrote: >>On 4 Mar, Konstantin Belousov wrote: >>> It could be argued that the current typical value of 16MB for the >>> hirunningbufspace is too low, but experiments with increasing it did >>> not provided any measureable change in the throughput or latency for >>> some loads. >> >>The correct value is probably proportional to the write bandwidth >>available. > > The problem is that write bandwidth varies widely depending on the > workload. For spinning rust, this will vary between maybe 64KBps > (512B random writes) and 100-150MBps (single-theaded large sequential > writes). The (low-end) SSD in my Netbook also has about 100:1 variance > due to erase blocking. How do you tune hirunningbufspace in the face > of 2 or 3 orders of magnitude variance in throughput? Especially since > SSDs don't gradually degrade - they hit a brick wall. I think a latency target would be desirable. As a first cut, maybe a limit on the number of write ops per device instead of a limit on the amount of data. That should more or less do the correct thing for small random I/O vs. large sequential writes. It could be somewhat self tuning if we kept track of the average service time, which should probably be measured with write caching off. There might still need to be a higher size limit to avoid excessive memory consumption. If you only have a single drive and it is an SSD, then there's probably not much you can do about the erase blocking problem. About the best you could do is if it supports NCQ is to turn off write caching so that you can keep track of how many writes are outstanding so that you can limit the write load to something less than the maximum number of outstanding commands that it supports, and then hope that when you run into the erase blocking situation, that *maybe* it will still process reads. If you have multiple drives, then you don't want one backlogged drive to block writes to your other drive(s), which would require something other than a global hirunningbufspace limit. ___ 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: Import libyaml into base
On Mon, Mar 04, 2013 at 09:55:20PM +, Simon L. B. Nielsen wrote: > On 2 Mar 2013 16:52, "Baptiste Daroussin" wrote: > > I want to import libyaml into base as libbsdyml so that no ports will use > it > > like we do for expat. > > > > I need it for the pkg bootstrap, so it it can parse pkg.conf. > > > > I know that some of the bhyve people will also be glad to use it. > > > > libyaml is MIT licensed, it is stable: no abi/api revolution in it for a > while. > > > > Does anyone have an objection? > > I don't but please add a stub manual page telling people not to use it > outside base. > > Simon Sure I was planning to losely do the same as for libexpat. The only user outside base will be pkgng, but it is a bit special ;) regards, Bapt pgp0vpfoiUhTF.pgp Description: PGP signature
Re: Import libyaml into base
On 2 Mar 2013 16:52, "Baptiste Daroussin" wrote: > I want to import libyaml into base as libbsdyml so that no ports will use it > like we do for expat. > > I need it for the pkg bootstrap, so it it can parse pkg.conf. > > I know that some of the bhyve people will also be glad to use it. > > libyaml is MIT licensed, it is stable: no abi/api revolution in it for a while. > > Does anyone have an objection? I don't but please add a stub manual page telling people not to use it outside base. Simon ___ 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: serial console not accepting input?
On Thu, Jan 24, 2013 at 01:23:50PM +, Eggert, Lars wrote:
| Hi,
|
| On Jan 23, 2013, at 17:04, Dimitry Andric wrote:
| > CTS/RTS hardware flow control, maybe? E.g. add ":hw" to the default
| > settings in /etc/gettytab, or make a specific entry with an added ":hw"
| > setting.
|
| nope, I don't even get a login prompt if I do that.
|
| > If it is a physical serial console, you could also simply have a bad
| > cable. Try swapping it with working system. :)
|
| Spent the last few hours fiddling with the cabling and the various BIOS
| serial redirection options (it's a Dell 2950). My best guess is that
| the serial port on the box is physically broken.
Try to do a {Ctrl}D to see if works. We've seen that the TX on reset
hangs but input works fine. I'm not sure if we ran into this with
uart(4) but had a problem with sio(4).
Doug A.
___
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 powerpc/powerpc
TB --- 2013-03-04 17:08:43 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 17:08:43 - 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-03-04 17:08:43 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2013-03-04 17:08:43 - cleaning the object tree TB --- 2013-03-04 17:08:43 - /usr/local/bin/svn stat /src TB --- 2013-03-04 17:08:46 - At svn revision 247790 TB --- 2013-03-04 17:08:47 - building world TB --- 2013-03-04 17:08:47 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 17:08:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 17:08:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 17:08:47 - SRCCONF=/dev/null TB --- 2013-03-04 17:08:47 - TARGET=powerpc TB --- 2013-03-04 17:08:47 - TARGET_ARCH=powerpc TB --- 2013-03-04 17:08:47 - TZ=UTC TB --- 2013-03-04 17:08:47 - __MAKE_CONF=/dev/null TB --- 2013-03-04 17:08:47 - cd /src TB --- 2013-03-04 17:08:47 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 17:08:51 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 Mar 4 19:31:35 UTC 2013 TB --- 2013-03-04 19:31:35 - generating LINT kernel config TB --- 2013-03-04 19:31:35 - cd /src/sys/powerpc/conf TB --- 2013-03-04 19:31:35 - /usr/bin/make -B LINT TB --- 2013-03-04 19:31:35 - cd /src/sys/powerpc/conf TB --- 2013-03-04 19:31:35 - /usr/sbin/config -m LINT TB --- 2013-03-04 19:31:36 - building LINT kernel TB --- 2013-03-04 19:31:36 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 19:31:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 19:31:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 19:31:36 - SRCCONF=/dev/null TB --- 2013-03-04 19:31:36 - TARGET=powerpc TB --- 2013-03-04 19:31:36 - TARGET_ARCH=powerpc TB --- 2013-03-04 19:31:36 - TZ=UTC TB --- 2013-03-04 19:31:36 - __MAKE_CONF=/dev/null TB --- 2013-03-04 19:31:36 - cd /src TB --- 2013-03-04 19:31:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 19:31:36 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 [...] cc -c -O -pipe -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_thr.c cc -c -O -pipe -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_thread.c cc -c -O -pipe -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -Wa,-many -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_time.c cc -c -O -pipe -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_
[head tinderbox] failure on sparc64/sparc64
TB --- 2013-03-04 18:26:28 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 18:26:28 - 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-03-04 18:26:28 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2013-03-04 18:26:28 - cleaning the object tree TB --- 2013-03-04 18:26:28 - /usr/local/bin/svn stat /src TB --- 2013-03-04 18:26:31 - At svn revision 247790 TB --- 2013-03-04 18:26:32 - building world TB --- 2013-03-04 18:26:32 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 18:26:32 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 18:26:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 18:26:32 - SRCCONF=/dev/null TB --- 2013-03-04 18:26:32 - TARGET=sparc64 TB --- 2013-03-04 18:26:32 - TARGET_ARCH=sparc64 TB --- 2013-03-04 18:26:32 - TZ=UTC TB --- 2013-03-04 18:26:32 - __MAKE_CONF=/dev/null TB --- 2013-03-04 18:26:32 - cd /src TB --- 2013-03-04 18:26:32 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 18:26:37 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 Mar 4 19:29:02 UTC 2013 TB --- 2013-03-04 19:29:02 - generating LINT kernel config TB --- 2013-03-04 19:29:02 - cd /src/sys/sparc64/conf TB --- 2013-03-04 19:29:02 - /usr/bin/make -B LINT TB --- 2013-03-04 19:29:03 - cd /src/sys/sparc64/conf TB --- 2013-03-04 19:29:03 - /usr/sbin/config -m LINT TB --- 2013-03-04 19:29:03 - building LINT kernel TB --- 2013-03-04 19:29:03 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 19:29:03 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 19:29:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 19:29:03 - SRCCONF=/dev/null TB --- 2013-03-04 19:29:03 - TARGET=sparc64 TB --- 2013-03-04 19:29:03 - TARGET_ARCH=sparc64 TB --- 2013-03-04 19:29:03 - TZ=UTC TB --- 2013-03-04 19:29:03 - __MAKE_CONF=/dev/null TB --- 2013-03-04 19:29:03 - cd /src TB --- 2013-03-04 19:29:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 19:29:03 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_thr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_thread.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_time.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin
[head tinderbox] failure on i386/pc98
TB --- 2013-03-04 15:10:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 15:10:20 - 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-03-04 15:10:20 - starting HEAD tinderbox run for i386/pc98 TB --- 2013-03-04 15:10:20 - cleaning the object tree TB --- 2013-03-04 15:10:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 15:10:23 - At svn revision 247790 TB --- 2013-03-04 15:10:24 - building world TB --- 2013-03-04 15:10:24 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 15:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 15:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 15:10:24 - SRCCONF=/dev/null TB --- 2013-03-04 15:10:24 - TARGET=pc98 TB --- 2013-03-04 15:10:24 - TARGET_ARCH=i386 TB --- 2013-03-04 15:10:24 - TZ=UTC TB --- 2013-03-04 15:10:24 - __MAKE_CONF=/dev/null TB --- 2013-03-04 15:10:24 - cd /src TB --- 2013-03-04 15:10:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 15:10:28 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 Mar 4 18:02:26 UTC 2013 TB --- 2013-03-04 18:02:26 - generating LINT kernel config TB --- 2013-03-04 18:02:26 - cd /src/sys/pc98/conf TB --- 2013-03-04 18:02:26 - /usr/bin/make -B LINT TB --- 2013-03-04 18:02:26 - cd /src/sys/pc98/conf TB --- 2013-03-04 18:02:26 - /usr/sbin/config -m LINT TB --- 2013-03-04 18:02:26 - building LINT kernel TB --- 2013-03-04 18:02:26 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 18:02:26 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 18:02:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 18:02:26 - SRCCONF=/dev/null TB --- 2013-03-04 18:02:26 - TARGET=pc98 TB --- 2013-03-04 18:02:26 - TARGET_ARCH=i386 TB --- 2013-03-04 18:02:26 - TZ=UTC TB --- 2013-03-04 18:02:26 - __MAKE_CONF=/dev/null TB --- 2013-03-04 18:02:26 - cd /src TB --- 2013-03-04 18:02:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 18:02:26 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 [...] /src/sys/kern/kern_timeout.c:659:2: error: use of undeclared identifier 'sbt1'; did you mean 'bt1'? sbt1 = sbinuptime(); ^~~~ bt1 /src/sys/kern/kern_timeout.c:604:13: note: 'bt1' declared here sbintime_t bt1, bt2; ^ 1 error generated. *** [kern_timeout.o] 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-03-04 18:13:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 18:13:30 - ERROR: failed to build LINT kernel TB --- 2013-03-04 18:13:30 - 8860.64 user 1343.64 system 10990.31 real http://tinderbox.freebsd.org/tinderbox-head-ss-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"
[head tinderbox] failure on ia64/ia64
TB --- 2013-03-04 15:18:48 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 15:18:48 - 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-03-04 15:18:48 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-03-04 15:18:48 - cleaning the object tree TB --- 2013-03-04 15:18:48 - /usr/local/bin/svn stat /src TB --- 2013-03-04 15:18:53 - At svn revision 247790 TB --- 2013-03-04 15:18:54 - building world TB --- 2013-03-04 15:18:54 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 15:18:54 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 15:18:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 15:18:54 - SRCCONF=/dev/null TB --- 2013-03-04 15:18:54 - TARGET=ia64 TB --- 2013-03-04 15:18:54 - TARGET_ARCH=ia64 TB --- 2013-03-04 15:18:54 - TZ=UTC TB --- 2013-03-04 15:18:54 - __MAKE_CONF=/dev/null TB --- 2013-03-04 15:18:54 - cd /src TB --- 2013-03-04 15:18:54 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 15:18:58 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 Mar 4 16:54:14 UTC 2013 TB --- 2013-03-04 16:54:14 - generating LINT kernel config TB --- 2013-03-04 16:54:14 - cd /src/sys/ia64/conf TB --- 2013-03-04 16:54:14 - /usr/bin/make -B LINT TB --- 2013-03-04 16:54:14 - cd /src/sys/ia64/conf TB --- 2013-03-04 16:54:14 - /usr/sbin/config -m LINT TB --- 2013-03-04 16:54:14 - building LINT kernel TB --- 2013-03-04 16:54:14 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 16:54:14 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 16:54:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 16:54:14 - SRCCONF=/dev/null TB --- 2013-03-04 16:54:14 - TARGET=ia64 TB --- 2013-03-04 16:54:14 - TARGET_ARCH=ia64 TB --- 2013-03-04 16:54:14 - TZ=UTC TB --- 2013-03-04 16:54:14 - __MAKE_CONF=/dev/null TB --- 2013-03-04 16:54:14 - cd /src TB --- 2013-03-04 16:54:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 16:54:14 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_thr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_thread.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/kern/kern_time.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_
[head tinderbox] failure on amd64/amd64
TB --- 2013-03-04 13:20:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 13:20:20 - 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-03-04 13:20:20 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-03-04 13:20:20 - cleaning the object tree TB --- 2013-03-04 13:20:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 13:20:24 - At svn revision 247790 TB --- 2013-03-04 13:20:25 - building world TB --- 2013-03-04 13:20:25 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 13:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 13:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 13:20:25 - SRCCONF=/dev/null TB --- 2013-03-04 13:20:25 - TARGET=amd64 TB --- 2013-03-04 13:20:25 - TARGET_ARCH=amd64 TB --- 2013-03-04 13:20:25 - TZ=UTC TB --- 2013-03-04 13:20:25 - __MAKE_CONF=/dev/null TB --- 2013-03-04 13:20:25 - cd /src TB --- 2013-03-04 13:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 13:20:30 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Mar 4 16:40:28 UTC 2013 TB --- 2013-03-04 16:40:28 - generating LINT kernel config TB --- 2013-03-04 16:40:28 - cd /src/sys/amd64/conf TB --- 2013-03-04 16:40:28 - /usr/bin/make -B LINT TB --- 2013-03-04 16:40:28 - cd /src/sys/amd64/conf TB --- 2013-03-04 16:40:28 - /usr/sbin/config -m LINT TB --- 2013-03-04 16:40:29 - building LINT kernel TB --- 2013-03-04 16:40:29 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 16:40:29 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 16:40:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 16:40:29 - SRCCONF=/dev/null TB --- 2013-03-04 16:40:29 - TARGET=amd64 TB --- 2013-03-04 16:40:29 - TARGET_ARCH=amd64 TB --- 2013-03-04 16:40:29 - TZ=UTC TB --- 2013-03-04 16:40:29 - __MAKE_CONF=/dev/null TB --- 2013-03-04 16:40:29 - cd /src TB --- 2013-03-04 16:40:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 16:40:29 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 [...] /src/sys/kern/kern_timeout.c:659:2: error: use of undeclared identifier 'sbt1'; did you mean 'bt1'? sbt1 = sbinuptime(); ^~~~ bt1 /src/sys/kern/kern_timeout.c:604:13: note: 'bt1' declared here sbintime_t bt1, bt2; ^ 1 error generated. *** [kern_timeout.o] Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-04 16:53:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 16:53:25 - ERROR: failed to build LINT kernel TB --- 2013-03-04 16:53:25 - 10055.72 user 1720.80 system 12784.50 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-amd64-amd64.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"
[head tinderbox] failure on i386/i386
TB --- 2013-03-04 13:20:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 13:20:20 - 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-03-04 13:20:20 - starting HEAD tinderbox run for i386/i386 TB --- 2013-03-04 13:20:20 - cleaning the object tree TB --- 2013-03-04 13:20:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 13:20:24 - At svn revision 247790 TB --- 2013-03-04 13:20:25 - building world TB --- 2013-03-04 13:20:25 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 13:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 13:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 13:20:25 - SRCCONF=/dev/null TB --- 2013-03-04 13:20:25 - TARGET=i386 TB --- 2013-03-04 13:20:25 - TARGET_ARCH=i386 TB --- 2013-03-04 13:20:25 - TZ=UTC TB --- 2013-03-04 13:20:25 - __MAKE_CONF=/dev/null TB --- 2013-03-04 13:20:25 - cd /src TB --- 2013-03-04 13:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 13:20:30 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 Mar 4 16:06:42 UTC 2013 TB --- 2013-03-04 16:06:42 - generating LINT kernel config TB --- 2013-03-04 16:06:42 - cd /src/sys/i386/conf TB --- 2013-03-04 16:06:42 - /usr/bin/make -B LINT TB --- 2013-03-04 16:06:42 - cd /src/sys/i386/conf TB --- 2013-03-04 16:06:42 - /usr/sbin/config -m LINT TB --- 2013-03-04 16:06:42 - building LINT kernel TB --- 2013-03-04 16:06:42 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 16:06:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 16:06:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 16:06:42 - SRCCONF=/dev/null TB --- 2013-03-04 16:06:42 - TARGET=i386 TB --- 2013-03-04 16:06:42 - TARGET_ARCH=i386 TB --- 2013-03-04 16:06:42 - TZ=UTC TB --- 2013-03-04 16:06:42 - __MAKE_CONF=/dev/null TB --- 2013-03-04 16:06:42 - cd /src TB --- 2013-03-04 16:06:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 16:06:42 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 [...] /src/sys/kern/kern_timeout.c:659:2: error: use of undeclared identifier 'sbt1'; did you mean 'bt1'? sbt1 = sbinuptime(); ^~~~ bt1 /src/sys/kern/kern_timeout.c:604:13: note: 'bt1' declared here sbintime_t bt1, bt2; ^ 1 error generated. *** [kern_timeout.o] Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-03-04 16:21:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-03-04 16:21:01 - ERROR: failed to build LINT kernel TB --- 2013-03-04 16:21:01 - 8699.79 user 1337.14 system 10840.34 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-i386-i386.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: access to hard drives is "blocked" by writes to a flash drive
On Sun, 2013-03-03 at 20:28 +, Steven Hartland wrote: > - Original Message - > From: "Ian Lepore" > To: "Poul-Henning Kamp" > Cc: "deeptech71" ; ; > "Peter Jeremy" > Sent: Sunday, March 03, 2013 1:54 PM > Subject: Re: access to hard drives is "blocked" by writes to a flash drive > > > > On Sun, 2013-03-03 at 13:35 +, Poul-Henning Kamp wrote: > >> Content-Type: text/plain; charset=ISO-8859-1 > >> > >> In message <1362317291.1195.216.ca...@revolution.hippie.lan>, Ian Lepore > >> writes > >> : > >> > >> >I run into this behavior all the time too, mostly on arm systems that > >> >have an sd card or usb thumb driver as their main/only drive. > >> > >> This is really a FAQ and I belive I have answered it N times already: > >> > >> There are, broadly speaking, two classes of flash-storage: "Camera-grade" > >> and "the real thing". > >> > >> "Camera-grade" have a very limited "Flash adaptation layer" which typically > >> only can hold one flash-block open for writing at a time, and is typically > >> found in CF and SD cards, USB sticks etc. > >> > >> Some of them gets further upset if the filesystem is not the FAT they > >> expect, because they implement "M-Systems" (patented) trick with monitoring > >> block deletes in FAT to simulate a TRIM facility. > >> > >> A number of products exist with such designs, typically a CF-style, is > >> put behind a SATA-PATA bridge and sold as 2.5" SSD SATA devices. > >> "Transcend" have done this for instance. > >> > >> If you use this class of devices for anything real, gstat will show > >> you I/O write-times of several seconds in periodic pile-ups, even > >> 100 seconds if you are doing something heavy. > >> > >> For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > >> traffic to other disks too, when these pileups gets too bad. > > > > Hmmm, so the problem has been known and unfixed for 10 years. That's > > not encouraging. One of the messages in the lemming-syncer mail thread > > might explain why I've been seeing this a lot lately in hobbyist work, > > but not so much at $work where we use sd cards heavily... we use very > > short syncer timeouts on SD and CF storage at $work: > > > > kern.metadelay: 3 > > kern.dirdelay: 4 > > kern.filedelay: 5 > > > > I might play with similar settings on some of my arm boards here. > > Interesting, are these relevant for all filesystems e.g. ZFS? > > Regards > Steve I'm not sure, I know almost nothing about zfs. I do know we used those tunings for a specific reason and I sure wouldn't recommend them for general use. There's a comment block at the top of kern/vfs_subr.c with some information on those delay values and how they're used that you might find useful. I think in general such small numbers on a system doing lots of IO would be counter-productive. In our case we arrived at those tunings this way... We have embedded systems with CF and SD cards as their only mass storage, and we do a relatively small amount of writing to the cards (occasional config changes, low-volume routine logging via syslog, not much else). Occasionally when newsyslog kicks in there'll be a short burst of IO to compress and rotate, then back to a trickle again. Once upon a time we mounted the filesystem without softupdates and with the sync option. That was fairly robust against users pulling the plug right after making a config change, but very very slow during syslog rotation, sometimes to the point of peturbing our apps (the CF cards run in PIO mode, and a burst of PIO activity is hard on time-critical apps). So we switched using softupdates and turned off the sync option. That was nicer to our apps, but left a long window during which updates didn't get flushed to the card. So we lowered those 3 tuning values to the lowest numbers supported by the code (as I vaguely remember it, this was years ago), not to get any sort of change in performance, but to reduce the window during which data just sat around in memory waiting for potential further updates before being flushed. The further updates would never happen for us, so the long delays had no benefit. -- Ian ___ 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: access to hard drives is "blocked" by writes to a flash drive
On Mon, 2013-03-04 at 07:35 +0200, Konstantin Belousov wrote: > On Sun, Mar 03, 2013 at 07:01:27PM -0800, Don Lewis wrote: > > On 3 Mar, Poul-Henning Kamp wrote: > > > > > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > > > traffic to other disks too, when these pileups gets too bad. > > > > The Lemming-syncer problem should have mostly been fixed by 231160 in > > head (231952 in stable/9 and 231967 in stable/8) a little over a year > > ago. The exceptions are atime updates, mmaped files with dirty pages, > > and quotas. Under certain workloads I still notice periodic bursts of > > seek noise. After thinking about it for a bit, I suspect that it could > > be atime updates, but I haven't tried to confirm that. > I never got a definition what a Lemming syncer term means. The (current) > syncer model is to iterate over the list of the active vnodes, i.e. > vnodes for which an open file exists, or a mapping is established, and > initiate the neccessary writes. The iterations over the active list is > performed several times during the same sync run over the filesystem, > this is considered acceptable. > > (Mostly) independently, the syncer thread iterates over the list of the > dirty buffers and writes them. > > The "wdrain" wait is independend from the syncer model used. It is entered > by a thread which intends to write in some future, but the wait is performed > before the entry into VFS is performed, in particular, before any VFS > resources are acquired. The wait sleeps when the total amount of the > buffer space for which the writes are active (runningbufspace counter) > exceeds the hirunningbufspace threshold. This way buffer cache tries to > avoid creating too long queue of the write requests. > > If there is some device which has high latency with the write completion, > then it is easy to see that, for the load which creates intensive queue > of writes to the said device, regardless of amount of writes to other > devices, runningbufspace quickly gets populated with the buffers targeted > to the slow device. Then, the "wdrain" wait mechanism kicks in, slowing > all writers until the queue is processed. > > It could be argued that the current typical value of 16MB for the > hirunningbufspace is too low, but experiments with increasing it did > not provided any measureable change in the throughput or latency for > some loads. > Useful information. I might argue that 16MB is too big, not too small. If you've got a device that only does 2MB/sec write throughput, that's an 8 second backlog. Lest you think such slow devices aren't in everyday use, a couple years ago I struggled mightily to get an sd card driver on an embedded system UP to that speed (from 300K/sec). > And, just to wrestle with the misinformation, the unmapped buffer work > has nothing to do with either syncer or runningbufspace. > > > > > When using TCQ or NCQ, perhaps we should limit the number of outstanding > > writes per device to leave some slots open for reads. We should > > probably also prioritize reads over writes unless we are under memory > > pressure. > > Reads are allowed to start even when the runningbufspace is overflown. That seems to indicate that the problem isn't a failure of the runningbufspace regulation mechanism, because when this problem happens it's most noticible because reads take many seconds (often the read is an attempt to launch a tool to figure out why performance is bad). Hmm, on the other hand, I can't g'tee that I had 'noatime' on the mounts when I've seen this, so maybe I'd better not point any fingers at specific code until I have better information. I kind of like the suggestion someone else made of having a NOATIME kernel config option. I can't make a strong case for it, but it appeals to me. If it would allow signifcant pieces of kernel or filesystem code to be eliminated at compile time it would be worth it. If it complicated the code without such savings, probably not worth it. -- Ian ___ 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 arm/arm
TB --- 2013-03-04 13:20:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 13:20:20 - 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-03-04 13:20:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-03-04 13:20:20 - cleaning the object tree TB --- 2013-03-04 13:20:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 13:20:24 - At svn revision 247790 TB --- 2013-03-04 13:20:25 - building world TB --- 2013-03-04 13:20:25 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 13:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 13:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 13:20:25 - SRCCONF=/dev/null TB --- 2013-03-04 13:20:25 - TARGET=arm TB --- 2013-03-04 13:20:25 - TARGET_ARCH=arm TB --- 2013-03-04 13:20:25 - TZ=UTC TB --- 2013-03-04 13:20:25 - __MAKE_CONF=/dev/null TB --- 2013-03-04 13:20:25 - cd /src TB --- 2013-03-04 13:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 13:20:30 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 Mar 4 15:09:36 UTC 2013 TB --- 2013-03-04 15:09:36 - generating LINT kernel config TB --- 2013-03-04 15:09:36 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:36 - /usr/bin/make -B LINT TB --- 2013-03-04 15:09:37 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:37 - /usr/sbin/config -m LINT TB --- 2013-03-04 15:09:37 - building LINT kernel TB --- 2013-03-04 15:09:37 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 15:09:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 15:09:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 15:09:37 - SRCCONF=/dev/null TB --- 2013-03-04 15:09:37 - TARGET=arm TB --- 2013-03-04 15:09:37 - TARGET_ARCH=arm TB --- 2013-03-04 15:09:37 - TZ=UTC TB --- 2013-03-04 15:09:37 - __MAKE_CONF=/dev/null TB --- 2013-03-04 15:09:37 - cd /src TB --- 2013-03-04 15:09:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 4 15:09:37 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_thr.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_thread.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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-builtin -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_time.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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-builtin -mno-t
Re: access to hard drives is "blocked" by writes to a flash drive
On Sun, 2013-03-03 at 19:01 -0800, Don Lewis wrote: > On 3 Mar, Poul-Henning Kamp wrote: > > > For various reasons (see: Lemming-syncer) FreeBSD will block all I/O > > traffic to other disks too, when these pileups gets too bad. > > The Lemming-syncer problem should have mostly been fixed by 231160 in > head (231952 in stable/9 and 231967 in stable/8) a little over a year > ago. The exceptions are atime updates, mmaped files with dirty pages, > and quotas. Under certain workloads I still notice periodic bursts of > seek noise. After thinking about it for a bit, I suspect that it could > be atime updates, but I haven't tried to confirm that. > > When using TCQ or NCQ, perhaps we should limit the number of outstanding > writes per device to leave some slots open for reads. We should > probably also prioritize reads over writes unless we are under memory > pressure. > Then either those changes didn't have the intended effect, or the problem we're seeing with lack of system responsiveness when there's a large backlog of writes to a slow device is not the lemming-syncer problem. It's also not a lack of TCQ/NCQ slots, given that no such thing exists with SD card IO. When this is going on, the process driving the massive output spends almost all its time in a wdrain wait, and if you try to launch an app that isn't already in cache, a siginfo generally shows it to be in a getblk wait. -- Ian ___ 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 armv6/arm
TB --- 2013-03-04 13:20:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-03-04 13:20:20 - 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-03-04 13:20:20 - starting HEAD tinderbox run for armv6/arm TB --- 2013-03-04 13:20:20 - cleaning the object tree TB --- 2013-03-04 13:20:20 - /usr/local/bin/svn stat /src TB --- 2013-03-04 13:20:24 - At svn revision 247790 TB --- 2013-03-04 13:20:25 - building world TB --- 2013-03-04 13:20:25 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 13:20:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 13:20:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 13:20:25 - SRCCONF=/dev/null TB --- 2013-03-04 13:20:25 - TARGET=arm TB --- 2013-03-04 13:20:25 - TARGET_ARCH=armv6 TB --- 2013-03-04 13:20:25 - TZ=UTC TB --- 2013-03-04 13:20:25 - __MAKE_CONF=/dev/null TB --- 2013-03-04 13:20:25 - cd /src TB --- 2013-03-04 13:20:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Mar 4 13:20:30 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 Mar 4 15:09:36 UTC 2013 TB --- 2013-03-04 15:09:36 - generating LINT kernel config TB --- 2013-03-04 15:09:36 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:36 - /usr/bin/make -B LINT TB --- 2013-03-04 15:09:37 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:37 - /usr/sbin/config -m LINT TB --- 2013-03-04 15:09:37 - skipping LINT kernel TB --- 2013-03-04 15:09:37 - cd /src/sys/arm/conf TB --- 2013-03-04 15:09:37 - /usr/sbin/config -m AC100 TB --- 2013-03-04 15:09:37 - building AC100 kernel TB --- 2013-03-04 15:09:37 - CROSS_BUILD_TESTING=YES TB --- 2013-03-04 15:09:37 - MAKEOBJDIRPREFIX=/obj TB --- 2013-03-04 15:09:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-03-04 15:09:37 - SRCCONF=/dev/null TB --- 2013-03-04 15:09:37 - TARGET=arm TB --- 2013-03-04 15:09:37 - TARGET_ARCH=armv6 TB --- 2013-03-04 15:09:37 - TZ=UTC TB --- 2013-03-04 15:09:37 - __MAKE_CONF=/dev/null TB --- 2013-03-04 15:09:37 - cd /src TB --- 2013-03-04 15:09:37 - /usr/bin/make -B buildkernel KERNCONF=AC100 >>> Kernel build for AC100 started on Mon Mar 4 15:09:37 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 [...] cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_thr.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_thread.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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 -mno-thumb-interwork -ffreestanding -Werror /src/sys/kern/kern_time.c cc -c -O -pipe -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/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param la
Re: access to hard drives is "blocked" by writes to a flash drive
On Mon, Mar 04, 2013 at 01:44:30PM +, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > > In message <201303040712.r247cejp008...@gw.catspoiler.org>, Don Lewis writes: > > >Prior to 231160, the syncer thread would call sync_vnode() for the > >syncer vnode of each mountpoint every 30 seconds [...] > > I agree that the lemming syncer is better, but the fundamental mistake of > only having one syncer thread is probably the root-cause in this case: > One camera-grade flash syncing may take (a lot) more than 30 seconds. > > One mountpoint having trouble (of whatever kind) should not affect > the rest of the mountpoints. > > I'm not sure if the syncer is untangled enough that we can have > per mount-point threads yet, but as soon as we can, we should do that. The problem with "wdrain" is not due to any algorithm in the syncer. I explained it in some details in other mail. pgp2YOBMt8lMt.pgp Description: PGP signature
FreeBSD Quarterly Status Report, October-December 2012.
FreeBSD Quarterly Status Report, October-December 2012. Introduction This report covers FreeBSD-related projects between October and December 2012. This is the last of four reports planned for 2012. Highlights from this status report include a very successful EuroBSDCon 2012 conference and associated FreeBSD Developer Summit, both held in Warsaw, Poland. Other highlights are several projects related to the FreeBSD port to the ARM architecture, extending support for platforms, boards and CPUs, improvements to the performance of the pf(4) firewall, and a new native iSCSI target. Thanks to all the reporters for the excellent work! This report contains 27 entries and we hope you enjoy reading it. The deadline for submissions covering the period between January and March 2013 is April 21st, 2013. __ Projects * BHyVe * Native iSCSI Target * NFS Version 4 * pxe_http -- booting FreeBSD from apache * UEFI * Unprivileged install and image creation Userland Programs * BSD-licenced patch(1) * bsdconfig(8) FreeBSD Team Reports * FreeBSD Core Team * FreeBSD Documentation Engineering * FreeBSD Foundation * Postmaster Kernel * AMD GPUs kernel-modesetting support * Common Flash Interface (CFI) driver improvements * SMP-Friendly pf(4) * Unmapped I/O Documentation * The FreeBSD Japanese Documentation Project Architectures * Compiler improvements for FreeBSD/ARMv6 * FreeBSD on AARCH64 * FreeBSD on BeagleBone * FreeBSD on Raspberry Pi Ports * FreeBSD Haskell Ports * KDE/FreeBSD * Ports Collection * Xfce Miscellaneous * EuroBSDcon 2012 * FreeBSD Developer Summit, Warsaw __ AMD GPUs kernel-modesetting support URL: https://wiki.FreeBSD.org/AMD_GPU URL: http://people.FreeBSD.org/~kib/misc/ttm.1.patch Contact: Alexander Kabaev Contact: Jean-Sébastien Pédron Contact: Konstantin Belousov Jean-Sébastien Pédron started to port the AMD GPUs driver from Linux to FreeBSD 10-CURRENT in January 2013. This work is based on a previous effort by Alexander Kabaev. Konstantin Belousov provided the initial port of the TTM memory manager. As of this writing, the driver is building but the tested device fails to attach. Status updates will be posted to the FreeBSD wiki. __ BHyVe URL: https://wiki.FreeBSD.org/BHyVe URL: http://www.bhyve.org/ Contact: Neel Natu Contact: Peter Grehan BHyVe is a type-2 hypervisor for FreeBSD/amd64 hosts with Intel VT-x and EPT CPU support. The bhyve project branch was merged into CURRENT on Jan 18. Work is progressing on performance, ease of use, AMD SVM support, and being able to run non-FreeBSD operating systems. Open tasks: 1. 1. Booting Linux/*BSD/Windows 2. 2. Moving the codebase to a more modular design consisting of a small base and loadable modules 3. 3. Various hypervisor features such as suspend/resume/live migration/sparse disk support __ BSD-licenced patch(1) URL: http://code.google.com/p/bsd-patch/ Contact: Pedro Giffuni Contact: Gabor Kovesdan Contact: Xin Li FreeBSD has been using for a while a very old version of GNU patch that is partially under the GPLv2. The original GNU patch utility is based on an initial implementation by Larry Wall that was not actually copyleft. OpenBSD did many enhancements to an older non-copyleft version of patch, this version was later adopted and further refined by DragonFlyBSD and NetBSD but there was no centralized development of the tool and FreeBSD kept working independently. In less than a week we took the version in DragonFlyBSD and adapted the FreeBSD enhancements to make it behave nearer to the version used natively in FreeBSD. Most of the work was done by Pedro Giffuni, adapting patches from sepotvin@ and ed@, and additional contributions were done by Christoph Mallon, Gabor Kovesdan and Xin Li. As a result of this we now have a new version of patch committed in head/usr.bin/patch that you can try by using WITH_BSD_PATCH in your builds. The new patch(1) doesn't support the FreeBSD-specific -I and -S options which don't seem necessary. In GNU patch -I actually means 'ignore whitespaces' and we now support it too. Open tasks: 1. Testing. A lot more testing. __ bsdconfig(8) URL: http://svnweb.FreeBSD.org/base/head/usr.sbin/bsdconfig/ URL: http://freshports.org/sysutils/bsdconfig/ URL: http://druidbsd.sf.net/download/bsdconfig/ Contact: Devin Teske
FreeBSD Quarterly Status Report, July-September 2012.
FreeBSD Quarterly Status Report, July-September 2012. Introduction This report covers FreeBSD-related projects between July and September 2012. This is the third of the four reports planned for 2012. Highlights from this quarter include successful participation in Google Summer of Code, major work in areas of the source and ports trees, and a Developer Summit attended by over 30 developers. Thanks to all the reporters for the excellent work! This report contains 12 entries and we hope you enjoy reading it. __ Projects * FreeBSD on Altera FPGAs * Native iSCSI Target * Parallel rc.d execution FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD Foundation * The FreeBSD Core Team Kernel * FreeBSD on ARMv6/ARMv7 Documentation * The FreeBSD Japanese Documentation Project Ports * KDE/FreeBSD * Ports Collection Miscellaneous * FreeBSD Developer Summit, Cambridge, UK FreeBSD in Google Summer of Code * Google Summer of Code 2012 __ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: https://wiki.freebsd.org/BugBusting Contact: Eitan Adler Contact: Gavin Atkinson Contact: Oleksandr Tymoshenko In August, Eitan Adler (eadler@) and Oleksandr Tymoshenko (gonzo@) joined the Bugmeister team. At the same time, Remko Lodder and Volker Werth stepped down. We extend our thanks to Volker and Remko for their work in the past, and welcome Oleksandr and Eitan. Eitan and Oleksandr have been working hard on migrating from GNATS, and have made significant progress on evaluating new software, and creating scripts to export data from GNATS. The bugbusting team continue work on trying to make the contents of the GNATS PR database cleaner, more accessible and easier for committers to find and resolve PRs, by tagging PRs to indicate the areas involved, and by ensuring that there is sufficient info within each PR to resolve each issue. As always, anybody interested in helping out with the PR queue is welcome to join us in #freebsd-bugbusters on EFnet. We are always looking for additional help, whether your interests lie in triaging incoming PRs, generating patches to resolve existing problems, or simply helping with the database housekeeping (identifying duplicate PRs, ones that have already been resolved, etc). This is a great way of getting more involved with FreeBSD! Open tasks: 1. Further research into tools suitable to replace GNATS. 2. Get more users involved with triaging PRs as they come in. 3. Assist committers with closing PRs. __ FreeBSD Developer Summit, Cambridge, UK URL: https://wiki.freebsd.org/201208DevSummit Contact: Robert Watson In the end of August, there was an "off-season" Developer Summit held in Cambridge, UK at the University of Cambridge Computer Laboratory. This was a three-day event, with a documentation summit scheduled for the day before. The three days of the main event were split into three sessions, with two tracks in each. Some of them even involved ARM developers from the neighborhoods which proven to be productive, and led to further engagement between the FreeBSD community and ARM. The schedule was finalized on the first day, spawning a plethora of topics to discuss, followed by splitting into groups. A short summary from each of the groups was presented in the final session and then published at the event's home page on the FreeBSD wiki. This summit contributed greatly to arriving to a tentative plan for throwing the switch to make clang the default compiler on HEAD. This was further discussed on the mailing list, and has now happened, bringing us one big step closer to a GPL-free FreeBSD 10. As part of the program, an afternoon of short talks from researchers in the Cambridge Computer Laboratory involved either operating systems work in general or FreeBSD in particular. Robert Watson showed off a tablet running FreeBSD on a MIPS-compatible soft-core processor running on an Altera FPGA. In association with the event, a dinner was hosted by St. John's college and co-sponsored by Google and the FreeBSD Foundation. The day after the conference, a trip was organized to Bletchley Park, which was celebrating Turing's centenary in 2012. __ FreeBSD Foundation URL: http://www.freebsdfoundation.org/press/2012Jul-newsletter.shtml Contact: Deb Goodkin The Foundation hosted and sponsored the Cambridge FreeBSD developer summit in August 2012. We were represented at the following conferences: OSCON July 2012, Texas LinuxFes
Re: access to hard drives is "blocked" by writes to a flash drive
Content-Type: text/plain; charset=ISO-8859-1 In message <201303040712.r247cejp008...@gw.catspoiler.org>, Don Lewis writes: >Prior to 231160, the syncer thread would call sync_vnode() for the >syncer vnode of each mountpoint every 30 seconds [...] I agree that the lemming syncer is better, but the fundamental mistake of only having one syncer thread is probably the root-cause in this case: One camera-grade flash syncing may take (a lot) more than 30 seconds. One mountpoint having trouble (of whatever kind) should not affect the rest of the mountpoints. I'm not sure if the syncer is untangled enough that we can have per mount-point threads yet, but as soon as we can, we should do that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: access to hard drives is "blocked" by writes to a flash drive
On 2013-Mar-03 23:12:40 -0800, Don Lewis wrote: >On 4 Mar, Konstantin Belousov wrote: >> It could be argued that the current typical value of 16MB for the >> hirunningbufspace is too low, but experiments with increasing it did >> not provided any measureable change in the throughput or latency for >> some loads. > >The correct value is probably proportional to the write bandwidth >available. The problem is that write bandwidth varies widely depending on the workload. For spinning rust, this will vary between maybe 64KBps (512B random writes) and 100-150MBps (single-theaded large sequential writes). The (low-end) SSD in my Netbook also has about 100:1 variance due to erase blocking. How do you tune hirunningbufspace in the face of 2 or 3 orders of magnitude variance in throughput? Especially since SSDs don't gradually degrade - they hit a brick wall. -- Peter Jeremy pgpZfJbSDrVSA.pgp Description: PGP signature
Re: ale(4) cannot negotiate as GigE
On Mon, Mar 04, 2013 at 04:06:32PM +0900, YongHyeon PYUN wrote: > On Mon, Mar 04, 2013 at 06:59:40AM +, Alexey Dokuchaev wrote: > > Better this time, I'm having 1000baseT again! :-) > > Thanks a lot for testing and patience! > Could you reboot multiple times and check whether you reliably get > a gigabit link? Yes, multiple reboots was a good idea, it's not very stable: 1st reboot: 100baseTX (!) 2nd reboot: 1000baseT 3rd reboot: 1000baseT 4th reboot: 1000baseT 5th reboot: 100baseTX (!) 6th reboot: 100baseTX (!) 7th reboot: 1000baseT 8th reboot: 100baseTX (!) 9th reboot: 1000baseT 10th reboot:1000baseT I've tried various combinations of just reboot, shutdown -r +1m and pinging some host while waiting for reboot. ./danfe ___ 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"
