Re: Processes in swapped out states in recent CURRENT?
On 6 May 2011 00:33, Garrett Cooper yaneg...@gmail.com wrote: I was watching top output on my dev box and I noticed that there are more swapped out processes present on the system, shortly after boot (which doesn't make sense given that I'm not low on resources on the box). Also, the os when I run os.waitpid() in python claims that the child doesn't exist, so I'm wondering if there's an issue with the processes reported via ps, top, etc. I'm noting this because it's a behavior change over my 'stable'-ish workstation, running CURRENT/r220089/amd64, which is spec'ed out the same as the dev box, minus some multimedia hardware. Thanks, -Garrett # uname -a FreeBSD fallout.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221219M: Thu May 5 12:09:37 PDT 2011 root@fallout.local:/usr/obj/usr/src/sys/FALLOUT amd6 # fstat -p 1832 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root sshd 1832 root / 2 drwxr-xr-x 1024 r root sshd 1832 wd / 2 drwxr-xr-x 1024 r root sshd 1832 text /usr 730118 -r-xr-xr-x 240944 r root sshd 1832 0 /dev 6 crw-rw-rw- null r root sshd 1832 1 /dev 6 crw-rw-rw- null rw root sshd 1832 2 /dev 6 crw-rw-rw- null rw root sshd 1832 3* internet stream tcp fe01e56cf000 root sshd 1832 4* pseudo-terminal master pts/1 rw root sshd 1832 5* local stream fe0008f79960 - fe0008f79a50 # fstat -p 149 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root adjkerntz 149 root / 2 drwxr-xr-x 1024 r root adjkerntz 149 wd / 2 drwxr-xr-x 1024 r root adjkerntz 149 text / 329805 -r-xr-xr-x 8792 r root adjkerntz 149 0 /dev 6 crw-rw-rw- null rw root adjkerntz 149 1 /dev 6 crw-rw-rw- null rw root adjkerntz 149 2 /dev 6 crw-rw-rw- null rw # fstat -p 1479 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root syslogd 1479 root / 2 drwxr-xr-x 1024 r root syslogd 1479 wd / 2 drwxr-xr-x 1024 r root syslogd 1479 text /usr 739002 -r-xr-xr-x 39008 r root syslogd 1479 0 /dev 6 crw-rw-rw- null rw root syslogd 1479 1 /dev 6 crw-rw-rw- null rw root syslogd 1479 2 /dev 6 crw-rw-rw- null rw root syslogd 1479 3 /var 353301 -rw--- 4 w root syslogd 1479 4* local dgram fe0008cd31e0 root syslogd 1479 5* local dgram fe0008cd30f0 root syslogd 1479 6* internet6 dgram udp fe0008ced540 root syslogd 1479 7* internet dgram udp fe0008ced3f0 root syslogd 1479 8 /dev 29 crw--- klog r root syslogd 1479 10 /var 1389613 -rw-r--r-- 25389 w root syslogd 1479 11 /var 1389579 -rw--- 62 w root syslogd 1479 12 /var 1389572 -rw--- 10164 w root syslogd 1479 13 /var 1389601 -rw-r- 2814 w root syslogd 1479 14 /var 1389575 -rw-r--r-- 62 w root syslogd 1479 15 /var 1389580 -rw--- 62 w root syslogd 1479 16 /var 1389577 -rw--- 57212 w root syslogd 1479 17 /var 1389606 -rw--- 38046 w root syslogd 1479 18 /var 1389578 -rw-r- 62 w # fstat -p 1829 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W gcooper sh 1829 root / 2 drwxr-xr-x 1024 r gcooper sh 1829 wd /usr 1884160 drwxr-xr-x 1024 r gcooper sh 1829 text / 212057 -r-xr-xr-x 131784 r gcooper sh 1829 0 /dev 127 crw--w pts/0 rw gcooper sh 1829 1 /dev 127 crw--w pts/0 rw gcooper sh 1829 2 /dev 127 crw--w pts/0 rw gcooper sh 1829 10 /dev 127 crw--w pts/0 rw # python -c 'import os; os.waitpid(1825, 0)' Traceback (most recent call last): File string, line 1, in module OSError: [Errno 10] No child processes But pid 1825 (sshd) is not a child process of the python process , isn't it? from waitpid(2): [ECHILD] The calling process has no existing unwaited-for child processes. Look at /sys/kern/kern_exit.c:kern_wait(). The function returns ECHILD if a specified process was not found among p-p_children children group. # ps auxww | grep 1825 root 1825 0.0 0.0 47952 0 ?? IWs - 0:00.00 sshd: gcooper [priv] (sshd) root 88213 0.0 0.0 16340 1356 3 S+ 1:25PM 0:00.00 grep 1825 # top -b last pid: 96740; load averages: 1.07, 0.98, 0.92 up 0+01:15:32
Re: Processes in swapped out states in recent CURRENT?
On Thu, May 5, 2011 at 11:28 PM, Sergey Kandaurov pluk...@gmail.com wrote: On 6 May 2011 00:33, Garrett Cooper yaneg...@gmail.com wrote: I was watching top output on my dev box and I noticed that there are more swapped out processes present on the system, shortly after boot (which doesn't make sense given that I'm not low on resources on the box). Also, the os when I run os.waitpid() in python claims that the child doesn't exist, so I'm wondering if there's an issue with the processes reported via ps, top, etc. I'm noting this because it's a behavior change over my 'stable'-ish workstation, running CURRENT/r220089/amd64, which is spec'ed out the same as the dev box, minus some multimedia hardware. Thanks, -Garrett # uname -a FreeBSD fallout.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r221219M: Thu May 5 12:09:37 PDT 2011 root@fallout.local:/usr/obj/usr/src/sys/FALLOUT amd6 # fstat -p 1832 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root sshd 1832 root / 2 drwxr-xr-x 1024 r root sshd 1832 wd / 2 drwxr-xr-x 1024 r root sshd 1832 text /usr 730118 -r-xr-xr-x 240944 r root sshd 1832 0 /dev 6 crw-rw-rw- null r root sshd 1832 1 /dev 6 crw-rw-rw- null rw root sshd 1832 2 /dev 6 crw-rw-rw- null rw root sshd 1832 3* internet stream tcp fe01e56cf000 root sshd 1832 4* pseudo-terminal master pts/1 rw root sshd 1832 5* local stream fe0008f79960 - fe0008f79a50 # fstat -p 149 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root adjkerntz 149 root / 2 drwxr-xr-x 1024 r root adjkerntz 149 wd / 2 drwxr-xr-x 1024 r root adjkerntz 149 text / 329805 -r-xr-xr-x 8792 r root adjkerntz 149 0 /dev 6 crw-rw-rw- null rw root adjkerntz 149 1 /dev 6 crw-rw-rw- null rw root adjkerntz 149 2 /dev 6 crw-rw-rw- null rw # fstat -p 1479 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W root syslogd 1479 root / 2 drwxr-xr-x 1024 r root syslogd 1479 wd / 2 drwxr-xr-x 1024 r root syslogd 1479 text /usr 739002 -r-xr-xr-x 39008 r root syslogd 1479 0 /dev 6 crw-rw-rw- null rw root syslogd 1479 1 /dev 6 crw-rw-rw- null rw root syslogd 1479 2 /dev 6 crw-rw-rw- null rw root syslogd 1479 3 /var 353301 -rw--- 4 w root syslogd 1479 4* local dgram fe0008cd31e0 root syslogd 1479 5* local dgram fe0008cd30f0 root syslogd 1479 6* internet6 dgram udp fe0008ced540 root syslogd 1479 7* internet dgram udp fe0008ced3f0 root syslogd 1479 8 /dev 29 crw--- klog r root syslogd 1479 10 /var 1389613 -rw-r--r-- 25389 w root syslogd 1479 11 /var 1389579 -rw--- 62 w root syslogd 1479 12 /var 1389572 -rw--- 10164 w root syslogd 1479 13 /var 1389601 -rw-r- 2814 w root syslogd 1479 14 /var 1389575 -rw-r--r-- 62 w root syslogd 1479 15 /var 1389580 -rw--- 62 w root syslogd 1479 16 /var 1389577 -rw--- 57212 w root syslogd 1479 17 /var 1389606 -rw--- 38046 w root syslogd 1479 18 /var 1389578 -rw-r- 62 w # fstat -p 1829 USER CMD PID FD MOUNT INUM MODE SZ|DV R/W gcooper sh 1829 root / 2 drwxr-xr-x 1024 r gcooper sh 1829 wd /usr 1884160 drwxr-xr-x 1024 r gcooper sh 1829 text / 212057 -r-xr-xr-x 131784 r gcooper sh 1829 0 /dev 127 crw--w pts/0 rw gcooper sh 1829 1 /dev 127 crw--w pts/0 rw gcooper sh 1829 2 /dev 127 crw--w pts/0 rw gcooper sh 1829 10 /dev 127 crw--w pts/0 rw # python -c 'import os; os.waitpid(1825, 0)' Traceback (most recent call last): File string, line 1, in module OSError: [Errno 10] No child processes But pid 1825 (sshd) is not a child process of the python process , isn't it? from waitpid(2): [ECHILD] The calling process has no existing unwaited-for child processes. Look at /sys/kern/kern_exit.c:kern_wait(). The function returns ECHILD if a specified process was not found among p-p_children children group. Yeah, good point. I'd have to use kill(, 0) in that case. # ps auxww | grep 1825 root 1825 0.0 0.0 47952 0 ?? IWs - 0:00.00 sshd: gcooper [priv] (sshd) root 88213 0.0 0.0
dsp mmap change
I would like to ask for a review and/or testing of the following patch: http://people.freebsd.org/~avg/dev_dsp_mmap.diff It's supposed to fix an issue described here: http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-February/011691.html In short, the following pseudo-code should do the right thing: fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); Thank you! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Using Dtrace for Performance Evaluation
Quoting David Christensen davi...@broadcom.com (from Thu, 5 May 2011
13:08:56 -0700):
I was looking at using dtrace to help characterize performance
for the new bxe(4) driver but I'm having problems with the very
simple task of capturing time spent in a function. The D script
I'm using looks like the following:
#pragma D option quiet
fbt:if_bxe::entry
{
self-in = timestamp;
}
fbt:if_bxe::return
{
@callouts[((struct callout *)arg0)-c_func] = sum(timestamp -
self-in);
}
tick-10sec
{
printa(%40a %10@d\n, @callouts);
clear(@callouts);
printf(\n);
}
BEGIN
{
printf(%40s | %s\n, function, nanoseconds per second);
}
I think there is a more easy way of doing this. I have a script which
wants to do some statistics too (depends upon local changes, but it's
about the D code, not the providers used), it does this:
---snip---
#pragma D option dynvarsize=32m
linuxulator*:::entry
{
self-time[probefunc] = vtimestamp;
@calls[probeprov, execname, probefunc] = count();
}
linuxulator*:::return
/self-time[probefunc] != 0/
{
this-timediff = self-time[probefunc] - vtimestamp;
@stats[probeprov, execname, probefunc] = quantize(this-timediff);
@longest[probeprov, probefunc] = max(this-timediff);
self-time[probefunc] = 0;
}
END
{
printf(Number of calls per provider/application/kernel function:);
printa(@calls);
printf(CPU-timing statistics per provider/application/kernel
function (in ns):);
printa(@stats);
printf(Longest running (CPU-time!) functions per provider (in ns):);
printa(@longest);
}
---snip---
In your case you can forget about probeprov, but the probefunc should
be more convenient to use than the casting and dereferencing you do.
The constraint for the return is there to prevent problems in case one
starts the tracing when a CPU is inbetween entry and return.
Bye,
Alexander.
--
There is a multi-legged creature crawling on your shoulder.
-- Spock, A Taste of Armageddon, stardate 3193.9
http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
___
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: Switch from legacy ata(4) to CAM-based ATA
On 6 May 2011 12:33, Alexander Motin m...@freebsd.org wrote: Sergey Kandaurov wrote: XENHVM uses it's own naming scheme and can name disks as daN or adN, depending on virtual block device id. atapci0/ata0/ata1 devices still present there (such as in Bruce Cran's dmesg), but no any disks attached from it: instead, all of them hung from device/vbd/N. [In a non-XENHVM mode they are attached from ataN channels, as usual.] /* * Translate Linux major/minor to an appropriate name and unit * number. For HVM guests, this allows us to use the same drive names * with blkfront as the emulated drives, easing transition slightly. */ xenbusb_front0: Xen Frontend Devices on xenstore0 xenbusb_back0: Xen Backend Devices on xenstore0 xctrl0: Xen Control Device on xenstore0 xbd0: 17000MB Virtual Block Device at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). xbd1: 3812MB Virtual Block Device at device/vbd/2048 on xenbusb_front0 xbd1: attaching as da0 xbd2: 114439MB Virtual Block Device at device/vbd/2064 on xenbusb_front0 xbd2: attaching as da1 OK, interesting question. I have built amd64 XENHVM kernel and booted it under Xen 3.2. As result I've got double set of devices, via both atapci0/ata0 and via blkfront: ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: QEMU HARDDISK 0.9.0 ATA-7 device ada0: Serial Number QM1 ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: QEMU HARDDISK 0.9.0 ATA-7 device ada1: Serial Number QM2 ada1: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 xbd0: 476940MB Virtual Block Device at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 xbd1: 476940MB Virtual Block Device at device/vbd/832 on xenbusb_front0 xbd1: attaching as ad1 Both of them were exported to GEOM. Extra set of adX devices caused error messages. What am I doing wrong and why have I got those duplicates? Was I required to remove non-PV drivers from my kernel? Doh. This corresponds to errors omitted unintentionally in my previous mail. This is right after xbd2: attaching as da1: da0 at sym0 bus 0 scbus2 target 0 lun 0 da0: QEMU QEMU HARDDISK 0.10 Fixed Direct Access SCSI-3 device da0: 3.300MB/s transfers da0: Command Queueing enabled da0: 3812MB (7807527 512 byte sectors: 255H 63S/T 485C) can't re-use a leaf (led)! g_dev_taste: make_dev_p() failed (gp-name=da0, error=17) da1 at sym0 bus 0 scbus2 target 1 lun 0 da1: QEMU QEMU HARDDISK 0.10 Fixed Direct Access SCSI-3 device da1: 3.300MB/s transfers da1: Command Queueing enabled da1: 114439MB (23437 512 byte sectors: 255H 63S/T 14588C) can't re-use a leaf (led)! g_dev_taste: make_dev_p() failed (gp-name=da1, error=17) No ada devices detected though. -- wbr, pluknet ___ 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: Switch from legacy ata(4) to CAM-based ATA
Sergey Kandaurov wrote: On 6 May 2011 12:33, Alexander Motin m...@freebsd.org wrote: Sergey Kandaurov wrote: XENHVM uses it's own naming scheme and can name disks as daN or adN, depending on virtual block device id. atapci0/ata0/ata1 devices still present there (such as in Bruce Cran's dmesg), but no any disks attached from it: instead, all of them hung from device/vbd/N. [In a non-XENHVM mode they are attached from ataN channels, as usual.] /* * Translate Linux major/minor to an appropriate name and unit * number. For HVM guests, this allows us to use the same drive names * with blkfront as the emulated drives, easing transition slightly. */ xenbusb_front0: Xen Frontend Devices on xenstore0 xenbusb_back0: Xen Backend Devices on xenstore0 xctrl0: Xen Control Device on xenstore0 xbd0: 17000MB Virtual Block Device at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 GEOM: ad0s1: geometry does not match label (16h,63s != 255h,63s). xbd1: 3812MB Virtual Block Device at device/vbd/2048 on xenbusb_front0 xbd1: attaching as da0 xbd2: 114439MB Virtual Block Device at device/vbd/2064 on xenbusb_front0 xbd2: attaching as da1 OK, interesting question. I have built amd64 XENHVM kernel and booted it under Xen 3.2. As result I've got double set of devices, via both atapci0/ata0 and via blkfront: ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: QEMU HARDDISK 0.9.0 ATA-7 device ada0: Serial Number QM1 ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ata0 bus 0 scbus0 target 1 lun 0 ada1: QEMU HARDDISK 0.9.0 ATA-7 device ada1: Serial Number QM2 ada1: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 xbd0: 476940MB Virtual Block Device at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 xbd1: 476940MB Virtual Block Device at device/vbd/832 on xenbusb_front0 xbd1: attaching as ad1 Both of them were exported to GEOM. Extra set of adX devices caused error messages. What am I doing wrong and why have I got those duplicates? Was I required to remove non-PV drivers from my kernel? Doh. This corresponds to errors omitted unintentionally in my previous mail. This is right after xbd2: attaching as da1: da0 at sym0 bus 0 scbus2 target 0 lun 0 da0: QEMU QEMU HARDDISK 0.10 Fixed Direct Access SCSI-3 device da0: 3.300MB/s transfers da0: Command Queueing enabled da0: 3812MB (7807527 512 byte sectors: 255H 63S/T 485C) can't re-use a leaf (led)! g_dev_taste: make_dev_p() failed (gp-name=da0, error=17) da1 at sym0 bus 0 scbus2 target 1 lun 0 da1: QEMU QEMU HARDDISK 0.10 Fixed Direct Access SCSI-3 device da1: 3.300MB/s transfers da1: Command Queueing enabled da1: 114439MB (23437 512 byte sectors: 255H 63S/T 14588C) can't re-use a leaf (led)! g_dev_taste: make_dev_p() failed (gp-name=da1, error=17) No ada devices detected though. But you have duplicate daX here. It is just the same, except that you have different Xen configuration -- disks configured as SCSI instead of ATA. So the question is the same: how this supposed to work? To me, that double detection problem seems much more significant then names change. -- 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: dsp mmap change
On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: I would like to ask for a review and/or testing of the following patch: http://people.freebsd.org/~avg/dev_dsp_mmap.diff It's supposed to fix an issue described here: http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-February/011691.html In short, the following pseudo-code should do the right thing: fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); Thank you! I think that you have to call PCM_GIANT_LEAVE() when returning EINVAL on the vm_pager_alloc() failure. Your patch hardcodes an assumption that sndbufs are always contiguous. I was unable to convince myself that this is true. pgpIAGnL0po3Y.pgp Description: PGP signature
Re: dsp mmap change
on 06/05/2011 16:32 Kostik Belousov said the following: On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: I would like to ask for a review and/or testing of the following patch: http://people.freebsd.org/~avg/dev_dsp_mmap.diff It's supposed to fix an issue described here: http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-February/011691.html In short, the following pseudo-code should do the right thing: fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); Thank you! I think that you have to call PCM_GIANT_LEAVE() when returning EINVAL on the vm_pager_alloc() failure. Yes, thank you. Your patch hardcodes an assumption that sndbufs are always contiguous. I was unable to convince myself that this is true. I think that this should be true for the case when DMA is used? But, yes, very good point. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dsp mmap change
on 06/05/2011 16:38 Andriy Gapon said the following: on 06/05/2011 16:32 Kostik Belousov said the following: Your patch hardcodes an assumption that sndbufs are always contiguous. I was unable to convince myself that this is true. I think that this should be true for the case when DMA is used? But, yes, very good point. I've updated the patch in place. Should this work better? Thank you. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang error make buildworld
Olivier Smedts oliv...@gid0.org writes: 2011/5/5 Roman Divacky rdiva...@freebsd.org: Because with clang, -march=native often breaks buildworld, while -march=core2 is ok. Can you be more specific about this claim? On what CPU are seeing this breakage? Ok, with latest HEAD... %echo | gcc -march=native -E -v -x c -### - Using built-in specs. Target: amd64-undermydesk-freebsd Configured with: FreeBSD/amd64 system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=core2 -mtune=generic With -march=native, gcc adds -mtune=generic while the man pages says -march=xxx sets -mtune=xxx. No longer true for `-march=native' on more recent GCC versions. $ gcc46 -v -march=native foo.c | fgrep cc1 # C2D E8400 ...-march=core2 -mcx16 -msahf -msse4.1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=core2... $ gcc46 -v -march=core2 foo.c | fgrep cc1 ...-march=core2... $ clang -v -march=native foo.c | grep -o -- '-target-cpu \w*' -target-cpu penryn ___ 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: dsp mmap change
On Fri, May 06, 2011 at 04:38:00PM +0300, Andriy Gapon wrote: on 06/05/2011 16:32 Kostik Belousov said the following: On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: I would like to ask for a review and/or testing of the following patch: http://people.freebsd.org/~avg/dev_dsp_mmap.diff It's supposed to fix an issue described here: http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-February/011691.html In short, the following pseudo-code should do the right thing: fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); Thank you! I think that you have to call PCM_GIANT_LEAVE() when returning EINVAL on the vm_pager_alloc() failure. Yes, thank you. Your patch hardcodes an assumption that sndbufs are always contiguous. I was unable to convince myself that this is true. I think that this should be true for the case when DMA is used? In the current driver, yes, but there is nothing that theoretically prevents scatter-gather from be used. But, yes, very good point. Updated patch looks fine (for me). pgp1MaRsoL9XR.pgp Description: PGP signature
Re: Interrupt storm with MSI in combination with em1
On Thursday 05 May 2011 22:22:15 Jack Vogel wrote: On Thu, May 5, 2011 at 1:17 PM, Daan Vreeken d...@vehosting.nl wrote: Hi Peter, On Thursday 05 May 2011 21:28:02 Peter Jeremy wrote: On 2011-May-05 13:22:59 +0200, Daan Vreeken d...@vehosting.nl wrote: Not yet. I'll reboot the machine later today when I have physical access to it to check the BIOS version. I'll keep you informed as soon as I get another storm going. Depending on the quality of your BIOS (competence of the vendor), you might find that kenv(8) reports the BIOS version without needing a reboot. (Look at smbios.bios.* in the output). ... smbios.bios.version=0303 ... Version 0402 is the latest and greatest, so it's time to upgrade. According to Asus it Improves system stability, so let's see if this 'cures' IRQ 16. Cool, thanks for the update! Good luck. I've updated the BIOS and let the machine run for a couple of hours with MSI/MSIX enabled. After 3 hours of uptime I see the storm again. Here are the first couple of lines of output of top -S : last pid: 33218; load averages: 0.47, 0.35, 0.33up 0+03:52:1016:42:52 317 processes: 6 running, 289 sleeping, 22 waiting CPU: 0.4% user, 0.0% nice, 0.5% system, 11.6% interrupt, 87.5% idle Mem: 280M Active, 176M Inact, 1797M Wired, 8572K Cache, 32M Buf, 5545M Free Swap: 500M Total, 500M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 11 root 4 171 ki31 0K64K CPU00 893:17 351.95% idle 12 root23 -80- 0K 368K WAIT2 18:37 50.39% intr One core is spending half it's time handling interrupts. /var/log/messages doesn't show any new message since the storm started. vmstat -i now shows : # vmstat -i interrupt total rate irq3: uart1 917384 63 -- irq16: ehci0 809547235 55608 irq23: ehci1 1751385120 cpu0:timer 16380717 1125 irq256: em0:rx 0 1651907113 irq257: em0:tx 0 1495708102 irq258: em0:link 3 0 irq259: em1:rx 0 397227 27 irq260: em1:tx 0 257865 17 irq261: em1:link 6 0 irq262: re010549 0 irq263: ahci0 290926 19 cpu1:timer 1160008 79 cpu3:timer763939 52 cpu2:timer 4120133283 irq272: hdac0 819282 56 Total 839564274 57670 Apart from spending far too much time handling interrupts, the machine works fine, so I'll let it run in case anyone wants me to try something on it. As a next step to try to isolate the problem I could create a kernel with MSI/MSIX enabled, but with a modified 'em' driver so it doesn't try to attach the MSI/MSIX interrupts to see if the problem is really related to the network cards or not. If anyone has a better idea, I'm all ears :) Regards, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 ___ 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: Interrupt storm with MSI in combination with em1
- Original Message - From: Daan Vreeken d...@vehosting.nl # vmstat -i interrupt total rate irq3: uart1 917384 63 -- irq16: ehci0 809547235 55608 Have you tried removing USB from the kernel? USB seems to be a common course of this behaviour and here at least removing it from the kernel fixes in all cases assuming you don't need it for something? This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interrupt storm with MSI in combination with em1
Hi Steven, On Friday 06 May 2011 17:20:15 Steven Hartland wrote: From: Daan Vreeken d...@vehosting.nl # vmstat -i interrupt total rate irq3: uart1 917384 63 -- irq16: ehci0 809547235 55608 Have you tried removing USB from the kernel? USB seems to be a common course of this behaviour and here at least removing it from the kernel fixes in all cases assuming you don't need it for something? No, I haven't tried that yet. I could disable USB to run some tests, but I'll eventually need it enabled again. I'll wait for a couple of hours to see if anyone can come up with a test to run on the machine while the interrupt is still storming. After that I'll reboot it with USB disabled. Thanks, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 ___ 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: Interrupt storm with MSI in combination with em1
I don't see why you are blaming em, you can see its on MSIX vectors that are NOT storming, its something with USB as noted. Trying to disable em from using MSIX is in exactly the wrong direction IMHO. Jack On Fri, May 6, 2011 at 8:32 AM, Daan Vreeken d...@vehosting.nl wrote: Hi Steven, On Friday 06 May 2011 17:20:15 Steven Hartland wrote: From: Daan Vreeken d...@vehosting.nl # vmstat -i interrupt total rate irq3: uart1 917384 63 -- irq16: ehci0 809547235 55608 Have you tried removing USB from the kernel? USB seems to be a common course of this behaviour and here at least removing it from the kernel fixes in all cases assuming you don't need it for something? No, I haven't tried that yet. I could disable USB to run some tests, but I'll eventually need it enabled again. I'll wait for a couple of hours to see if anyone can come up with a test to run on the machine while the interrupt is still storming. After that I'll reboot it with USB disabled. Thanks, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 ___ 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: Interrupt storm with MSI in combination with em1
On 5/6/2011 11:02 AM, Daan Vreeken wrote: One core is spending half it's time handling interrupts. /var/log/messages doesn't show any new message since the storm started. vmstat -i now shows : # vmstat -i interrupt total rate irq3: uart1 917384 63 -- irq16: ehci0 809547235 55608 Apart from spending far too much time handling interrupts, the machine works fine, so I'll let it run in case anyone wants me to try something on it. Do you have any usb devices plugged in ? ie what does usbconfig show ? Also, what USB settings do you have in the BIOS ? I would try disabling usb legacy mode and and things like 80-64 translation. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dsp mmap change
On Friday, May 06, 2011 4:55:00 am Andriy Gapon wrote: I would like to ask for a review and/or testing of the following patch: http://people.freebsd.org/~avg/dev_dsp_mmap.diff It's supposed to fix an issue described here: http://lists.freebsd.org/pipermail/freebsd-multimedia/2011- February/011691.html In short, the following pseudo-code should do the right thing: fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); Are the buffers statically allocated? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Interrupt storm with MSI in combination with em1
Hi Jack, On Friday 06 May 2011 17:36:52 Jack Vogel wrote: On Fri, May 6, 2011 at 8:32 AM, Daan Vreeken d...@vehosting.nl wrote: Hi Steven, On Friday 06 May 2011 17:20:15 Steven Hartland wrote: From: Daan Vreeken d...@vehosting.nl # vmstat -i interrupt total rate irq3: uart1 917384 63 -- irq16: ehci0 809547235 55608 Have you tried removing USB from the kernel? USB seems to be a common course of this behaviour and here at least removing it from the kernel fixes in all cases assuming you don't need it for something? No, I haven't tried that yet. I could disable USB to run some tests, but I'll eventually need it enabled again. I'll wait for a couple of hours to see if anyone can come up with a test to run on the machine while the interrupt is still storming. After that I'll reboot it with USB disabled. I don't see why you are blaming em, you can see its on MSIX vectors that are NOT storming, its something with USB as noted. Trying to disable em from using MSIX is in exactly the wrong direction IMHO. I'm not blaming this on 'em' per se. The only thing I've noticed in the tests that I've done so far is that I haven't seen the storms with MSI/MSIX disabled. With respect to the devices on IRQ 16, disabling MSI/MSIX only seems to change the way interrupts are delivered to the em0/em1 cards. (This is what made me suspect the 'em' driver.) At this moment all devices on IRQ 16 (including the PCI bridge itself) could be the source of the problem. I'm just trying to find a way to isolate the problem, either by finding a way to proof it is NOT device X, or by finding a way to proof it IS device Y. I'll reboot the machine in a couple of minutes with USB disabled. Regards, -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 ___ 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: dsp mmap change
on 06/05/2011 16:00 John Baldwin said the following: On Friday, May 06, 2011 4:55:00 am Andriy Gapon wrote: I would like to ask for a review and/or testing of the following patch: http://people.freebsd.org/~avg/dev_dsp_mmap.diff It's supposed to fix an issue described here: http://lists.freebsd.org/pipermail/freebsd-multimedia/2011- February/011691.html In short, the following pseudo-code should do the right thing: fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); Are the buffers statically allocated? My reading of code indicates that the buffers are allocated on a sound driver attach and freed when it's detaching. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dsp mmap change
On Fri, May 06, 2011 at 11:55:00AM +0300, Andriy Gapon wrote: I would like to ask for a review and/or testing of the following patch: http://people.freebsd.org/~avg/dev_dsp_mmap.diff It's supposed to fix an issue described here: http://lists.freebsd.org/pipermail/freebsd-multimedia/2011-February/011691.html In short, the following pseudo-code should do the right thing: fd = open(/dev/dsp, O_RDWR); mmap(PROT_READ, fd); mmap(PROT_WRITE, fd); Thank you! Working here with skype 2.1.0.81 and pulseaudio without (and also still with) disabline mmap for the mic. Very nice! :) Note: I had to disable the checkbox `Allow Skype to automatically adjust my mixer levels', else it records garbage at least with my mic. (that is one of a webcam.) Thanx, Juergen ___ 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: Interrupt storm with MSI in combination with em1
On Friday, May 06, 2011 11:36:52 am Jack Vogel wrote: I don't see why you are blaming em, you can see its on MSIX vectors that are NOT storming, its something with USB as noted. Trying to disable em from using MSIX is in exactly the wrong direction IMHO. In the past Intel host bridges have exhibited very brain damaged behavior where em interrupts could trigger false interrupts on USB controllers. These host bridges did this because they assumed that if the interrupt line was masked in the I/O APIC, then the OS must be using the 8259A PICs and not the I/O APICs, so it would forward the interrupt down to the 8259A's in the ICH, and the effect was to trigger an interrupt on the line shared with the USB controllers creating phantom USB interrupts for each em(4) interrupt. FreeBSD triggered this because when using INTx and not using Scott's INTR_FAST changes, the kernel would mask em(4)'s interrupt in the I/O APIC which triggered the buggy behavior in the bridge. If for some reason em(4) is asserting both the INTx interrupt and the MSI-X interrupt now, then since the INTx interrupt is not enabled in FreeBSD, the I/O APIC pin will be masked and any INTx assertions would trigger similar phantom interrupts if this bridge was similarly broken. So given that, is there any chance that em(4) could still be asserting its INTx line (or the simulated INTx line rather) when MSI-X is being used? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: firewire debugging
On Tue, May 3, 2011 at 4:35 PM, Julian Elischer jul...@freebsd.org wrote:
does anyone know if there is a limitation on firewire debugging on a machine
with 4GB or memory?
I've successfully used firewire dcons on amd64 with 8GB of RAM.
I have 1394 {a,b} cards. does it make a difference?
Shouldn't make a difference.
also, the firewire card on one machine stops it from booting..
is there a way to disable it during boot other than recompiling the kernel
without firewire?
Not sure, since I've never ran into this problem.
Hope this helps,
Chris Ruiz
___
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
Heads Up: after r221543 you need a fresh make depend
Since r221543 moves nfs_kdtrace.h, you'll need to do a fresh make cleandepend; make depend to update your kernel dependencies. rick ___ 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
[CFT] Early Retransmit for TCP (rfc5827) patch
Hello all, I'd like to send another patch to support RFC5827 in TCP stack which could be found at: http://people.freebsd.org/~weongyo/patch_20110506_rfc5827.diff This patch supports all Early Retransmit logics (Byte-Based Early Retransmit and Segment-Based Early Retransmit) when net.inet.tcp.rfc5827 sysctl knob is turned on. Please note that Segment-Based Early Retransmit logic is separated using khelp module because it adds additional operations and requires variable spaces to track segment boundaries on the right side window. So if the khelp module is loaded, it's a preference but if not the default logic is `Byte-Based Early Retransmit'. I implemented based on DragonflyBSD's implementation but it looked it's not same with RFC specification what I thought so I changed most of parts. In my test environments it looks it's working correctly. Please review and test my work and tell me if you have any concerns and questions. regards, Weongyo Jeong Index: usr.bin/netstat/inet.c === --- usr.bin/netstat/inet.c (revision 221564) +++ usr.bin/netstat/inet.c (working copy) @@ -622,6 +622,7 @@ \t\t%lu data packet%s (%lu byte%s) retransmitted\n); p(tcps_sndrexmitbad, \t\t%lu data packet%s unnecessarily retransmitted\n); + p(tcps_sndearlyrexmit, \t%lu packet%s early retransmitted\n); p(tcps_mturesent, \t\t%lu resend%s initiated by MTU discovery\n); p2a(tcps_sndacks, tcps_delack, \t\t%lu ack-only packet%s (%lu delayed)\n); Index: share/man/man4/Makefile === --- share/man/man4/Makefile (revision 221564) +++ share/man/man4/Makefile (working copy) @@ -140,6 +140,7 @@ gpib.4 \ gre.4 \ h_ertt.4 \ + h_tcper.4 \ harp.4 \ hatm.4 \ hfa.4 \ Index: share/man/man4/h_tcper.4 === --- share/man/man4/h_tcper.4 (revision 0) +++ share/man/man4/h_tcper.4 (revision 0) @@ -0,0 +1,60 @@ +.\ +.\ Copyright (c) 2011 Weongyo Jeong weon...@freebsd.org +.\ All rights reserved. +.\ +.\ Redistribution and use in source and binary forms, with or without +.\ modification, are permitted provided that the following conditions +.\ are met: +.\ 1. Redistributions of source code must retain the above copyright +.\notice, this list of conditions and the following disclaimer. +.\ 2. Redistributions in binary form must reproduce the above copyright +.\notice, this list of conditions and the following disclaimer in the +.\documentation and/or other materials provided with the distribution. +.\ +.\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND +.\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +.\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +.\ ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR +.\ ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +.\ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS +.\ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) +.\ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT +.\ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY +.\ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF +.\ SUCH DAMAGE. +.\ +.\ $FreeBSD: share/man/man4/h_ertt.4 218912 2011-02-21 11:56:11Z lstewart $ +.\ +.Dd May 4, 2011 +.Dt h_tcper 9 +.Os +.Sh NAME +.Nm h_tcper +.Nd Segment Boundary Tracker Khelp module +.Sh SYNOPSIS +.In netinet/khelp/h_tcper.h +.Sh DESCRIPTION +The +.Nm +Khelp module works within the +.Xr khelp 9 +framework to provide TCP with a per-connection, segment boundary tracker. +It's to form an understanding as to how many actual segments have been +transmitted, but not acknowledged. +Its implementation is done by the sender by tracking the boundaries of +the four segments on the right side of the current window. +.Sh SEE ALSO +.Xr hhook 9 , +.Xr khelp 9 +.Sh HISTORY +The +.Nm +module first appeared in +.Fx 9.0 . +The module was first released in 2011 by Weongyo Jeong +.Sh AUTHORS +.An -nosplit +The +.Nm +Khelp module and this manual page were written by +.An Weongyo Jeong Aq weon...@freebsd.org . Index: sys/netinet/tcp_input.c === --- sys/netinet/tcp_input.c (revision 221564) +++ sys/netinet/tcp_input.c (working copy) @@ -55,6 +55,7 @@ #include sys/param.h #include sys/kernel.h #include sys/hhook.h +#include sys/khelp.h #include sys/malloc.h #include sys/mbuf.h #include sys/proc.h /* for proc0 declaration */ @@ -101,6 +102,7 @@ #ifdef TCPDEBUG #include netinet/tcp_debug.h #endif /* TCPDEBUG */ +#include netinet/khelp/h_tcper.h #ifdef IPSEC #include netipsec/ipsec.h @@ -161,6 +163,11 @@ VNET_NAME(tcp_abc_l_var), 2, Cap the max cwnd increment during slow-start to this
[head tinderbox] failure on i386/pc98
TB --- 2011-05-07 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-07 02:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2011-05-07 02:10:00 - cleaning the object tree TB --- 2011-05-07 02:10:24 - cvsupping the source tree TB --- 2011-05-07 02:10:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2011-05-07 02:10:40 - building world TB --- 2011-05-07 02:10:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 02:10:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 02:10:40 - TARGET=pc98 TB --- 2011-05-07 02:10:40 - TARGET_ARCH=i386 TB --- 2011-05-07 02:10:40 - TZ=UTC TB --- 2011-05-07 02:10:40 - __MAKE_CONF=/dev/null TB --- 2011-05-07 02:10:40 - cd /src TB --- 2011-05-07 02:10:40 - /usr/bin/make -B buildworld World build started on Sat May 7 02:10:41 UTC 2011 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 Sat May 7 04:06:56 UTC 2011 TB --- 2011-05-07 04:06:56 - generating LINT kernel config TB --- 2011-05-07 04:06:56 - cd /src/sys/pc98/conf TB --- 2011-05-07 04:06:56 - /usr/bin/make -B LINT TB --- 2011-05-07 04:06:56 - building LINT kernel TB --- 2011-05-07 04:06:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 04:06:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 04:06:56 - TARGET=pc98 TB --- 2011-05-07 04:06:56 - TARGET_ARCH=i386 TB --- 2011-05-07 04:06:56 - TZ=UTC TB --- 2011-05-07 04:06:56 - __MAKE_CONF=/dev/null TB --- 2011-05-07 04:06:56 - cd /src TB --- 2011-05-07 04:06:56 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat May 7 04:06:56 UTC 2011 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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/wi/if_wi_pci.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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe.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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe_pccard.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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg
[head tinderbox] failure on i386/i386
TB --- 2011-05-07 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-07 02:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-07 02:10:00 - cleaning the object tree TB --- 2011-05-07 02:10:28 - cvsupping the source tree TB --- 2011-05-07 02:10:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-07 02:10:41 - building world TB --- 2011-05-07 02:10:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 02:10:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 02:10:41 - TARGET=i386 TB --- 2011-05-07 02:10:41 - TARGET_ARCH=i386 TB --- 2011-05-07 02:10:41 - TZ=UTC TB --- 2011-05-07 02:10:41 - __MAKE_CONF=/dev/null TB --- 2011-05-07 02:10:41 - cd /src TB --- 2011-05-07 02:10:41 - /usr/bin/make -B buildworld World build started on Sat May 7 02:10:42 UTC 2011 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 Sat May 7 04:07:08 UTC 2011 TB --- 2011-05-07 04:07:08 - generating LINT kernel config TB --- 2011-05-07 04:07:08 - cd /src/sys/i386/conf TB --- 2011-05-07 04:07:08 - /usr/bin/make -B LINT TB --- 2011-05-07 04:07:08 - building LINT kernel TB --- 2011-05-07 04:07:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 04:07:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 04:07:08 - TARGET=i386 TB --- 2011-05-07 04:07:08 - TARGET_ARCH=i386 TB --- 2011-05-07 04:07:08 - TZ=UTC TB --- 2011-05-07 04:07:08 - __MAKE_CONF=/dev/null TB --- 2011-05-07 04:07:08 - cd /src TB --- 2011-05-07 04:07:08 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat May 7 04:07:08 UTC 2011 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 [...] ld -b binary -d -warn-common -r -d -o wpifw.fwo wpi.fw 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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe.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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe_pccard.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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xl/if_xl.c cc1: warnings being treated as errors /src/sys/dev/xl/if_xl.c: In function 'xl_poll_locked': /src/sys/dev/xl/if_xl.c:2383: warning: implicit declaration of function 'xl_stats_update_locked' /src/sys/dev/xl/if_xl.c:2383: warning: nested extern declaration of 'xl_stats_update_locked' *** Error code 1 Stop in /obj/i386.i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-05-07 04:18:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-05-07 04:18:07 - ERROR: failed to build lint kernel TB --- 2011-05-07 04:18:07 - 6186.30 user 1032.59 system 7686.92 real
[head tinderbox] failure on amd64/amd64
TB --- 2011-05-07 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-07 02:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-05-07 02:10:00 - cleaning the object tree TB --- 2011-05-07 02:10:28 - cvsupping the source tree TB --- 2011-05-07 02:10:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-05-07 02:15:53 - building world TB --- 2011-05-07 02:15:53 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 02:15:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 02:15:53 - TARGET=amd64 TB --- 2011-05-07 02:15:53 - TARGET_ARCH=amd64 TB --- 2011-05-07 02:15:53 - TZ=UTC TB --- 2011-05-07 02:15:53 - __MAKE_CONF=/dev/null TB --- 2011-05-07 02:15:53 - cd /src TB --- 2011-05-07 02:15:53 - /usr/bin/make -B buildworld World build started on Sat May 7 02:15:53 UTC 2011 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 Sat May 7 04:42:52 UTC 2011 TB --- 2011-05-07 04:42:53 - generating LINT kernel config TB --- 2011-05-07 04:42:54 - cd /src/sys/amd64/conf TB --- 2011-05-07 04:42:54 - /usr/bin/make -B LINT TB --- 2011-05-07 04:42:54 - building LINT kernel TB --- 2011-05-07 04:42:54 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 04:42:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 04:42:54 - TARGET=amd64 TB --- 2011-05-07 04:42:54 - TARGET_ARCH=amd64 TB --- 2011-05-07 04:42:54 - TZ=UTC TB --- 2011-05-07 04:42:54 - __MAKE_CONF=/dev/null TB --- 2011-05-07 04:42:54 - cd /src TB --- 2011-05-07 04:42:54 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat May 7 04:42:54 UTC 2011 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 [...] ld -b binary -d -warn-common -r -d -o wpifw.fwo wpi.fw cc -c -O2 -frename-registers -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe.c cc -c -O2 -frename-registers -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -frename-registers -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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xl/if_xl.c cc1: warnings being treated as errors /src/sys/dev/xl/if_xl.c: In function 'xl_poll_locked': /src/sys/dev/xl/if_xl.c:2383: warning: implicit declaration of function 'xl_stats_update_locked' /src/sys/dev/xl/if_xl.c:2383: warning: nested extern declaration of 'xl_stats_update_locked' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error
Re: [head tinderbox] failure on i386/i386
On Sat, May 07, 2011 at 04:18:08AM +, FreeBSD Tinderbox wrote: TB --- 2011-05-07 02:10:00 - tinderbox 2.7 running on freebsd-current.sentex.ca TB --- 2011-05-07 02:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-05-07 02:10:00 - cleaning the object tree TB --- 2011-05-07 02:10:28 - cvsupping the source tree TB --- 2011-05-07 02:10:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-05-07 02:10:41 - building world TB --- 2011-05-07 02:10:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 02:10:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 02:10:41 - TARGET=i386 TB --- 2011-05-07 02:10:41 - TARGET_ARCH=i386 TB --- 2011-05-07 02:10:41 - TZ=UTC TB --- 2011-05-07 02:10:41 - __MAKE_CONF=/dev/null TB --- 2011-05-07 02:10:41 - cd /src TB --- 2011-05-07 02:10:41 - /usr/bin/make -B buildworld World build started on Sat May 7 02:10:42 UTC 2011 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 Sat May 7 04:07:08 UTC 2011 TB --- 2011-05-07 04:07:08 - generating LINT kernel config TB --- 2011-05-07 04:07:08 - cd /src/sys/i386/conf TB --- 2011-05-07 04:07:08 - /usr/bin/make -B LINT TB --- 2011-05-07 04:07:08 - building LINT kernel TB --- 2011-05-07 04:07:08 - MAKEOBJDIRPREFIX=/obj TB --- 2011-05-07 04:07:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-05-07 04:07:08 - TARGET=i386 TB --- 2011-05-07 04:07:08 - TARGET_ARCH=i386 TB --- 2011-05-07 04:07:08 - TZ=UTC TB --- 2011-05-07 04:07:08 - __MAKE_CONF=/dev/null TB --- 2011-05-07 04:07:08 - cd /src TB --- 2011-05-07 04:07:08 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Sat May 7 04:07:08 UTC 2011 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 [...] ld -b binary -d -warn-common -r -d -o wpifw.fwo wpi.fw 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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe.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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xe/if_xe_pccard.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 -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/xl/if_xl.c cc1: warnings being treated as errors /src/sys/dev/xl/if_xl.c: In function 'xl_poll_locked': /src/sys/dev/xl/if_xl.c:2383: warning: implicit declaration of function 'xl_stats_update_locked' /src/sys/dev/xl/if_xl.c:2383: warning: nested extern declaration of 'xl_stats_update_locked' *** Error code 1 Sorry for the breakage. Should be fixed now. ___ freebsd-current@freebsd.org mailing list
