Re: ata panic: mtx_lock of destroyed mutex
Matthew Jacob wrote: Hmm. I just fixed that at Panasas, and I'm pretty sure that I gave the patch to Alexander Motin to put in. Do you mean one committed at r207221 or something else? I've been setting up an amd64 VirtualBox machine with the latest 9-CURRENT and got the following panic when booting it (another machine updated and booting at the same time didn't panic): ata1: WARNING - READ_TOC read data overrun 1812 panic: mtx_lock of destroyed mutex @ /usr/src/sys/kern/kern_sema.c:79 cpuid = 0 with the following stack trace: kdb_enter panic _mtx_lock_flags _sema_post ata_completed taskqueue_run intr_event_execute_handlers ithread_loop fork_exit fork_trampoline -- 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: ata panic: mtx_lock of destroyed mutex
Bruce Cran wrote: I've been setting up an amd64 VirtualBox machine with the latest 9-CURRENT and got the following panic when booting it (another machine updated and booting at the same time didn't panic): ata1: WARNING - READ_TOC read data overrun 1812 panic: mtx_lock of destroyed mutex @ /usr/src/sys/kern/kern_sema.c:79 cpuid = 0 Are there any other related messages before it if boot with verbose? with the following stack trace: kdb_enter panic _mtx_lock_flags _sema_post ata_completed taskqueue_run intr_event_execute_handlers ithread_loop fork_exit fork_trampoline -- 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: ata panic: mtx_lock of destroyed mutex
On 6/3/2010 12:43 AM, Alexander Motin wrote: Matthew Jacob wrote: Hmm. I just fixed that at Panasas, and I'm pretty sure that I gave the patch to Alexander Motin to put in. Do you mean one committed at r207221 or something else? yes ___ 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: Xorg build error on -current-amd64
Hello. I've just had this error yesterday. It seems, that utmp.h file is still in the system. Make in /usr/src: make delete-old and try again . David Rhodus wrote: ===Verifying install for sessreg in /usr/ports/x11/sessreg === Building for sessreg-1.0.5 make all-am cc -std=gnu99 -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 -Wold-style-definition -Wdeclaration-after-statement -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o sessreg sessreg.o sessreg.o(.text+0xada): In function `main': : undefined reference to `ttyslot' *** Error code 1 Stop in /usr/ports/x11/sessreg/work/sessreg-1.0.5. *** Error code 1 Stop in /usr/ports/x11/sessreg/work/sessreg-1.0.5. *** Error code 1 Stop in /usr/ports/x11/sessreg. *** Error code 1 Stop in /usr/ports/x11/xorg-apps. *** Error code 1 Stop in /usr/ports/x11/xorg-apps. *** Error code 1 Stop in /usr/ports/x11/xorg. # uname -a FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Wed Jun 2 15:10:14 UTC 2010 root@:/usr/obj/usr/src/sys/GENERIC amd64 # ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- С уважением, Александр Пыхалов, системный администратор ЮГИНФО ЮФУ. ___ 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: ata panic: mtx_lock of destroyed mutex
On Thu, 03 Jun 2010 10:44:32 +0300 Alexander Motin m...@freebsd.org wrote: Bruce Cran wrote: I've been setting up an amd64 VirtualBox machine with the latest 9-CURRENT and got the following panic when booting it (another machine updated and booting at the same time didn't panic): ata1: WARNING - READ_TOC read data overrun 1812 panic: mtx_lock of destroyed mutex @ /usr/src/sys/kern/kern_sema.c:79 cpuid = 0 Are there any other related messages before it if boot with verbose? I've only seen it happen once, and didn't get any more details. I'll start booting with verbose in case it happens again. -- Bruce Cran ___ 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
Running all regression tests
Hi, I'd like to run the regression tests in src/tools/regression on a regular basis. What's the official way to do this? Is there some way I can run them all in one go? It seems it's necessary to enter every single subdirectory and execute any Makefiles located there before running 'prove -r'. Some of the tests don't contain .t files, so I assume they can't be run using 'prove'? Also, I'd like to filter out the tests that don't apply on my system, e.g. zfs tests. Thanks, Erik
Re: Fwd: umodem (4) recognize a CDC-ACM device
On Wed, Jun 02, 2010 at 06:25:25PM +0200, Hans Petter Selasky wrote: Hi, Can you dump the USB descriptors of your device? Hi, right now I can do this at FreeBSD 8.0-RELEASE-p2 #8 r206060M, but If you prefer tonight I can dump from 'freebsd-current' box. Thank you Hi, The problem is that LOW speed does not support BULK transfers according to the USB specification. I guess we could switch that support on, though I'd rather stick with the spec. I think the original sense is a bit outdated. It was when people had a single full speed controller on their systems and low speed transfers could easily drop overall performance, so it made sense to prohibid bulk transfers on low speed. Today however people have multiple channels and high speed chains where performance is only a matter up to the next transaction translator and even if they don't use a high speed hub it only harms performance on a single (of many) usb low/full channels, while bandwidth hungry devices usually are connected to other controllers. On the other hand - I never understood why people want to implement low speed devices. It has some many restrictions and isn't realy cheaper to build than full speed devices. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: Running all regression tests
On Thu, 3 Jun 2010, 12:02+0200, Erik Cederstrand wrote: Hi, I'd like to run the regression tests in src/tools/regression on a regular basis. What's the official way to do this? Is there some way I can run them all in one go? There is no one. Yet. It seems it's necessary to enter every single subdirectory and execute any Makefiles located there before running 'prove -r'. Some of the tests don't contain .t files, so I assume they can't be run using 'prove'? Yes, correct. Also, I'd like to filter out the tests that don't apply on my system, e.g. zfs tests. Thanks, Erik -- Maxim Konovalov ___ 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: Running all regression tests
On Thu, 3 Jun 2010 14:13:06 +0400 (MSD) Maxim Konovalov maxim.konova...@gmail.com wrote: On Thu, 3 Jun 2010, 12:02+0200, Erik Cederstrand wrote: Hi, I'd like to run the regression tests in src/tools/regression on a regular basis. What's the official way to do this? Is there some way I can run them all in one go? There is no one. Yet. It seems it's necessary to enter every single subdirectory and execute any Makefiles located there before running 'prove -r'. Some of the tests don't contain .t files, so I assume they can't be run using 'prove'? Yes, correct. Also, I'd like to filter out the tests that don't apply on my system, e.g. zfs tests. It seems the p5-Test-Harness may be too simple for our requirements. Has anyone looked into using NetBSD's ATF (http://www.netbsd.org/~jmmv/atf/) in FreeBSD? -- Bruce Cran ___ 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: Running all regression tests
Quoting Erik Cederstrand e...@cederstrand.dk (from Thu, 3 Jun 2010 12:02:51 +0200): Hi, I'd like to run the regression tests in src/tools/regression on a regular basis. What's the official way to do this? Is there some way I can run them all in one go? It seems it's necessary to enter every single subdirectory and execute any Makefiles located there before running 'prove -r'. Some You could write a Makefile which recurses into the subdirs. of the tests don't contain .t files, so I assume they can't be run using 'prove'? The effort to convert tests to prove-able tests got stuck at one point in time (probably time constraints / real-life-interupt). Bye, Alexander. -- Year, n.: A period of three hundred and sixty-five disappointments. -- Ambrose Bierce, The Devil's Dictionary 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: Running all regression tests
On Thu, Jun 3, 2010 at 6:13 AM, Maxim Konovalov maxim.konova...@gmail.comwrote: On Thu, 3 Jun 2010, 12:02+0200, Erik Cederstrand wrote: Hi, I'd like to run the regression tests in src/tools/regression on a regular basis. What's the official way to do this? Is there some way I can run them all in one go? There is no one. Yet. It seems it's necessary to enter every single subdirectory and execute any Makefiles located there before running 'prove -r'. Some of the tests don't contain .t files, so I assume they can't be run using 'prove'? Yes, correct. Also, I'd like to filter out the tests that don't apply on my system, e.g. zfs tests. Thanks, Erik -- Maxim Konovalov I do not know how to perform regression tests , but is it not possible to write a shell script to perform the above manual steps ? In that way it may be possible to apply any selected steps in succession . Thank you very much . Mehmet Erol Sanliturk ___ 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: Running all regression tests
Den 03/06/2010 kl. 14.53 skrev Mehmet Erol Sanliturk: I do not know how to perform regression tests , but is it not possible to write a shell script to perform the above manual steps ? I just wrote a shell script to recurse into the subdirectories and run make on the Makefiles found. Unfortunately, some of the Makefiles start running tests immediately, some have syntax errors etc., so I'll have to add some more logic. Erik
Re: Fwd: umodem (4) recognize a CDC-ACM device
On Wed, Jun 2, 2010 at 1:25 PM, Hans Petter Selasky hsela...@c2i.net wrote: Hi, The problem is that LOW speed does not support BULK transfers according to the USB specification. I guess we could switch that support on, though I'd rather stick with the spec. Try changing this line in: src/sys/dev/usb/usb_transfer.c [USB_SPEED_LOW] = 0, /* not supported */ Into: [USB_SPEED_LOW] = 8, /* not supported according to USB spec. */ Hi, Thanks again for the reply. I changed this line [1], but the result was the same: BARAD-DUR% uname -a FreeBSD BARAD-DUR.BUTECO 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r208760M: Thu Jun 3 10:13:44 BRT 2010 po...@barad-dur.buteco:/usr/obj/mnt/ad2s1d/data/src/sys/BARAD-DUR i386 BARAD-DUR# kldstat Id Refs AddressSize Name 1 29 0xc040 757368 kernel 21 0xc0b58000 5ad4 snd_cmi.ko 33 0xc0b5e000 574a4sound.ko 41 0xc0bb6000 4dfa90 nvidia.ko 53 0xc1096000 2eacclinux.ko 61 0xc4405000 8000 linprocfs.ko 71 0xc4753000 3000 logo_saver.ko 81 0xc4a9b000 4000 umodem.ko BARAD-DUR# tail -f /var/log/messages Jun 3 11:10:21 BARAD-DUR kernel: uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT Jun 3 11:10:21 BARAD-DUR kernel: uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 Jun 3 11:10:21 BARAD-DUR kernel: ugen0.3: www.recursion.jp at usbus0 Jun 3 11:10:21 BARAD-DUR kernel: umodem0: www.recursion.jp USB-232, class 2/0, rev 1.10/1.00, addr 3 on usbus0 Jun 3 11:10:21 BARAD-DUR kernel: umodem0: data interface 1, has CM over data, has no break Jun 3 11:10:21 BARAD-DUR kernel: device_attach: umodem0 attach returned 6 Jun 3 11:10:21 BARAD-DUR kernel: umodem0: www.recursion.jp USB-232, class 2/0, rev 1.10/1.00, addr 3 on usbus0 Jun 3 11:10:21 BARAD-DUR kernel: umodem0: data interface 1, has CM over data, has no break Jun 3 11:10:21 BARAD-DUR kernel: device_attach: umodem0 attach returned 6 BARAD-DUR# usbconfig -u 0 -a 3 dump_device_desc dump_curr_config_desc ugen0.3: USB-232 www.recursion.jp at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0110 bDeviceClass = 0x0002 bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0008 idVendor = 0x16c0 idProduct = 0x05e1 bcdDevice = 0x0100 iManufacturer = 0x0001 www.recursion.jp iProduct = 0x0002 USB-232 iSerialNumber = 0x no string bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0043 bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x0080 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x0002 bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x0001 iInterface = 0x no string Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x05, 0x24, 0x00, 0x10, 0x01 Additional Descriptor bLength = 0x04 bDescriptorType = 0x24 bDescriptorSubType = 0x02 RAW dump: 0x00 | 0x04, 0x24, 0x02, 0x02 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x05, 0x24, 0x06, 0x00, 0x01 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x01 RAW dump: 0x00 | 0x05, 0x24, 0x01, 0x03, 0x01 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 IN bmAttributes = 0x0003 INTERRUPT wMaxPacketSize = 0x0008 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x bNumEndpoints = 0x0002 bInterfaceClass = 0x000a bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0008 bInterval = 0x bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0008 bInterval = 0x bRefresh = 0x bSynchAddress = 0x [1] Actually the line is 3062 on current of 2010 Jun 2: http://fxr.watson.org/fxr/source/dev/usb/usb_transfer.c#L3060 -- Marcelo Rossi This
Re: Fwd: umodem (4) recognize a CDC-ACM device
On Thursday 03 June 2010 16:22:33 Marcelo/Porks wrote:
On Wed, Jun 2, 2010 at 1:25 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
Hi,
The problem is that LOW speed does not support BULK transfers according
to the USB specification. I guess we could switch that support on, though
I'd rather stick with the spec.
Try changing this line in:
src/sys/dev/usb/usb_transfer.c
[USB_SPEED_LOW] = 0,/* not supported */
Into:
[USB_SPEED_LOW] = 8,/* not supported according to USB
spec. */
Hi, Thanks again for the reply.
I changed this line [1], but the result was the same:
Hi,
You also need to update this structure above:
[UE_BULK] = {
[USB_SPEED_LOW] = {.fixed = {0, 0, 0, 0}}, /* invalid */
Change it into:
8, 8, 8, 8,
:-)
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Running all regression tests
On Thu, 3 Jun 2010, 15:15+0200, Erik Cederstrand wrote: Den 03/06/2010 kl. 14.53 skrev Mehmet Erol Sanliturk: I do not know how to perform regression tests , but is it not possible to write a shell script to perform the above manual steps ? I just wrote a shell script to recurse into the subdirectories and run make on the Makefiles found. Unfortunately, some of the Makefiles start running tests immediately, some have syntax errors etc., so I'll have to add some more logic. It would be nice to get patches while you are there. -- Maxim Konovalov ___ 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: Fwd: umodem (4) recognize a CDC-ACM device
On Thursday 03 June 2010 17:50:08 Hans Petter Selasky wrote:
On Thursday 03 June 2010 16:22:33 Marcelo/Porks wrote:
On Wed, Jun 2, 2010 at 1:25 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
Hi,
The problem is that LOW speed does not support BULK transfers according
to the USB specification. I guess we could switch that support on,
though I'd rather stick with the spec.
Try changing this line in:
src/sys/dev/usb/usb_transfer.c
[USB_SPEED_LOW] = 0,/* not supported */
Into:
[USB_SPEED_LOW] = 8,/* not supported according to
USB spec. */
Hi, Thanks again for the reply.
I changed this line [1], but the result was the same:
Hi,
You also need to update this structure above:
[UE_BULK] = {
[USB_SPEED_LOW] = {.fixed = {0, 0, 0, 0}}, /* invalid
*/
Change it into:
8, 8, 8, 8,
Oops, that seems to be some old code. Forget that patch. I will have another
look. And you are sure you built a new kernel and usb module with the initial
patch above?
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fwd: umodem (4) recognize a CDC-ACM device
Could you join: #bsdusb on efnet ? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fwd: umodem (4) recognize a CDC-ACM device
On Thursday 03 June 2010 17:54:17 Hans Petter Selasky wrote:
On Thursday 03 June 2010 17:50:08 Hans Petter Selasky wrote:
On Thursday 03 June 2010 16:22:33 Marcelo/Porks wrote:
On Wed, Jun 2, 2010 at 1:25 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
Hi,
The problem is that LOW speed does not support BULK transfers
according to the USB specification. I guess we could switch that
support on, though I'd rather stick with the spec.
Try changing this line in:
src/sys/dev/usb/usb_transfer.c
Hi,
Should be like this: Note the structure is called bulk_min:
static const uint16_t bulk_min[USB_SPEED_MAX] = {
[USB_SPEED_LOW] = 8,
[USB_SPEED_FULL] = 8,
[USB_SPEED_HIGH] = 512,
[USB_SPEED_VARIABLE] = 512,
[USB_SPEED_SUPER] = 1024,
};
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Panic on current when enabling SUJ
Boot into single user-mode # tunefs -j enable / # tunefs -j enable /usr # tunefs -j enable /tmp # tunefs -j enable /var # reboot The machine then panics. Looks like the machine is trying to write to a read-only filesystem. ___ 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: Xorg build error on -current-amd64
Thanks, make delete-old fixed everything. On Thu, Jun 3, 2010 at 4:43 AM, Alexander Pyhalov a...@rsu.ru wrote: Hello. I've just had this error yesterday. It seems, that utmp.h file is still in the system. Make in /usr/src: make delete-old and try again . David Rhodus wrote: === Verifying install for sessreg in /usr/ports/x11/sessreg === Building for sessreg-1.0.5 make all-am cc -std=gnu99 -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 -Wold-style-definition -Wdeclaration-after-statement -I/usr/local/include -O2 -pipe -fno-strict-aliasing -o sessreg sessreg.o sessreg.o(.text+0xada): In function `main': : undefined reference to `ttyslot' *** Error code 1 Stop in /usr/ports/x11/sessreg/work/sessreg-1.0.5. *** Error code 1 Stop in /usr/ports/x11/sessreg/work/sessreg-1.0.5. *** Error code 1 Stop in /usr/ports/x11/sessreg. *** Error code 1 Stop in /usr/ports/x11/xorg-apps. *** Error code 1 Stop in /usr/ports/x11/xorg-apps. *** Error code 1 Stop in /usr/ports/x11/xorg. # uname -a FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Wed Jun 2 15:10:14 UTC 2010 root@:/usr/obj/usr/src/sys/GENERIC amd64 # ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- С уважением, Александр Пыхалов, системный администратор ЮГИНФО ЮФУ. ___ 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: Running all regression tests
On Thu, Jun 3, 2010 at 5:46 AM, Bruce Cran br...@cran.org.uk wrote: On Thu, 3 Jun 2010 14:13:06 +0400 (MSD) Maxim Konovalov maxim.konova...@gmail.com wrote: On Thu, 3 Jun 2010, 12:02+0200, Erik Cederstrand wrote: Hi, I'd like to run the regression tests in src/tools/regression on a regular basis. What's the official way to do this? Is there some way I can run them all in one go? There is no one. Yet. It seems it's necessary to enter every single subdirectory and execute any Makefiles located there before running 'prove -r'. Some of the tests don't contain .t files, so I assume they can't be run using 'prove'? Yes, correct. Also, I'd like to filter out the tests that don't apply on my system, e.g. zfs tests. It seems the p5-Test-Harness may be too simple for our requirements. Has anyone looked into using NetBSD's ATF (http://www.netbsd.org/~jmmv/atf/) in FreeBSD? Yes. I'm waiting for miwi to import it into ports. Thanks, -Garrett ___ 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: Running all regression tests
It seems the p5-Test-Harness may be too simple for our requirements. Has anyone looked into using NetBSD's ATF (http://www.netbsd.org/~jmmv/atf/) in FreeBSD? I am not sure if it makes sense to import ATF into the *base* system, but it sure looks like a nice ports/ addition. The work of writing the actual test code is then going to be a bit of extra work on top of that, but we can start doing it in small mini-project chunks. I already have a few tests that I would love to convert to something more modular like ATF: : keram...@kobe:/hg/bsd/src$ hg qseries -s | fgrep regression : regression-chmod: Add a few regression tests for chmod(1) : regression-stdtime: Add a regression suite for libc/stdtime functions : keram...@kobe:/hg/bsd/src$ If anyone is already working on an ATF package/port, I'm very interested to help. pgpC3a5C5aDmX.pgp Description: PGP signature
Re: Running all regression tests
On Thu, 03 Jun 2010 14:50:13 +0200, Alexander Leidinger
alexan...@leidinger.net wrote:
Quoting Erik Cederstrand e...@cederstrand.dk (from Thu, 3 Jun 2010
12:02:51 +0200):
Hi,
I'd like to run the regression tests in src/tools/regression on a
regular basis. What's the official way to do this? Is there some way
I can run them all in one go?
It seems it's necessary to enter every single subdirectory and
execute any Makefiles located there before running 'prove -r'. Some
You could write a Makefile which recurses into the subdirs.
That's the easy way to run all the current tests. It should be possible
to add minimal makefile glue to run all the regression tests.
Skipping some of the tests may also be possible by using a technique
similar to the src/ tree, e.g.:
SUBDIRS = \
foo \
${_bar} \
baz
.if defined(WITH_BAR)
_bar = bar
.endif
___
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
Auto doadump()
Is there a rc.conf variable to automatically save core on a panic and reboot ? Setting dumpdev=AUTO doesn't seem to do the trick. # uname -a FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Jun 3 20:00:22 UTC 2010 root@:/usr/obj/usr/src/sys/GE amd64 # ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Auto doadump()
On Thu, 3 Jun 2010, David Rhodus wrote: Is there a rc.conf variable to automatically save core on a panic and reboot ? Setting dumpdev=AUTO doesn't seem to do the trick. dumpdev merely controls which swap device the dump gets written to. You probably want to either compile your kernel with KDB_UNATTENDED or set the debug.debugger_on_panic sysctl to 0. (I run my systems to drop into KDB interactively, but reading kern/kern_shutdown.c seems to indicate that this will do what you want.) -Ben Kaduk ___ 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: Auto doadump()
In response to David Rhodus sdrho...@gmail.com: Is there a rc.conf variable to automatically save core on a panic and reboot ? Setting dumpdev=AUTO doesn't seem to do the trick. Did you also set dumpdir? Is dumpdir set to a location with enough disk space to hold a kernel dump? Is the swap device large enough to hold the entire contents of memory + a little? The docs are here: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ 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: Running all regression tests
Den 03/06/2010 kl. 21.54 skrev Giorgos Keramidas: On Thu, 03 Jun 2010 14:50:13 +0200, Alexander Leidinger alexan...@leidinger.net wrote: Quoting Erik Cederstrand e...@cederstrand.dk (from Thu, 3 Jun 2010 12:02:51 +0200): Hi, I'd like to run the regression tests in src/tools/regression on a regular basis. What's the official way to do this? Is there some way I can run them all in one go? It seems it's necessary to enter every single subdirectory and execute any Makefiles located there before running 'prove -r'. Some You could write a Makefile which recurses into the subdirs. I ended up with the attached shell script which does the job (but not very elegantly) for the time being. As stated elsewhere in this thread, some tests need cleaning up and rewriting to the standard format. Erik test.sh Description: Binary data
Re: Running all regression tests
Doing a ./test.sh make crashes my -current machine pretty quickly. It stops inBuilding in /usr/src/tools/regression/bin/mv On Thu, Jun 3, 2010 at 6:19 PM, Erik Cederstrand e...@cederstrand.dk wrote: Den 03/06/2010 kl. 21.54 skrev Giorgos Keramidas: On Thu, 03 Jun 2010 14:50:13 +0200, Alexander Leidinger alexan...@leidinger.net wrote: Quoting Erik Cederstrand e...@cederstrand.dk (from Thu, 3 Jun 2010 12:02:51 +0200): Hi, I'd like to run the regression tests in src/tools/regression on a regular basis. What's the official way to do this? Is there some way I can run them all in one go? It seems it's necessary to enter every single subdirectory and execute any Makefiles located there before running 'prove -r'. Some You could write a Makefile which recurses into the subdirs. I ended up with the attached shell script which does the job (but not very elegantly) for the time being. As stated elsewhere in this thread, some tests need cleaning up and rewriting to the standard format. Erik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current when enabling SUJ
On Thu, 3 Jun 2010, John Doe wrote: Boot into single user-mode # tunefs -j enable / # tunefs -j enable /usr # tunefs -j enable /tmp # tunefs -j enable /var # reboot The machine then panics. Looks like the machine is trying to write to a read-only filesystem. Can you please give me information on the panic? What was the state of the filesystems upon reboot? Does dumpfs show suj enabled? Thanks, Jeff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
SUJ Patches for 8.X ???
Anyone have a SUJ patch set for 8.x ? ___ 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: [TESTING]: ClangBSD branch needs testing before the import to HEAD
I'm just catching up with this thread, so apologies if this has already been pointed out elsewhere. One of the things that has been discussed w/rt compilers for a while (not just at the devsummit) was bending our minds around separating the concept of base system compiler from default ports compiler. In -stable branches, we must and shall not do large compiler updates. But ports probably need a more recent compiler (of whatever flavor) just to keep as many of them building as possible. (As upstream authors switch to newer compilers, their ports often don't build on whatever is in our base). Despite my enthusiasm for the future of llvm, the reality is that even in the medium-term there are so many ports with hardwired assumptions that they are running on gcc (not to mention on linux on i386) that it will never be possible to fix them all. The current paradigm is that as ports stop building with both base gcc, unless they are switched to depending on a newer gcc from ports, they'll be marked 'broken' and go through the deprecation cycle. Further, I remind people that compile and run and run equally as well through all code-paths are three completely separate levels of effort, possibly having an order of magnitude more work between each. We're looking at a multi-year process here, and not every single port is going to survive. But again -- not all of them currently do, anwyays. mcl ___ 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: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote: Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang There are two types of compiler bug: a) bug that produces bad code; b) bug that makes the compiler crash. The latter number seems kind of low right now, but that's probably because some of them are now obscured by BROKEN tags: http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc_bug For comparison, bitrot that is probably due to older ports not keeping up with compiler changes is at: http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc4_error I don't have any statistic for produces bad code. mcl ___ 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: Running all regression tests
On Thu, Jun 3, 2010 at 12:45 PM, Giorgos Keramidas keram...@freebsd.org wrote: It seems the p5-Test-Harness may be too simple for our requirements. Has anyone looked into using NetBSD's ATF (http://www.netbsd.org/~jmmv/atf/) in FreeBSD? I am not sure if it makes sense to import ATF into the *base* system, but it sure looks like a nice ports/ addition. The work of writing the actual test code is then going to be a bit of extra work on top of that, but we can start doing it in small mini-project chunks. You're correct; it doesn't make sense given the agile approach of releasing the software that's being done today. I already have a few tests that I would love to convert to something more modular like ATF: : keram...@kobe:/hg/bsd/src$ hg qseries -s | fgrep regression : regression-chmod: Add a few regression tests for chmod(1) : regression-stdtime: Add a regression suite for libc/stdtime functions : keram...@kobe:/hg/bsd/src$ If anyone is already working on an ATF package/port, I'm very interested to help. Already in the works: ports/146754 . Thanks, -Garrett ___ 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: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 01:22:05PM +0100, Bruce Cran wrote: From previous messages I don't think sparc64 is currently supported by clang very well, if at all, so I think we'll still need gcc in the base system for some time. I'll put on my tier-2 package builder hat for a moment. IMHO it helps FreeBSD's robustness to have our other architectures. In particular, fixing bugs in sparc64 may be helping us fix bugs that would affect arm/mips/powerpc, which are key for our embedded userbase. Perhaps I'm just invested in this from having spent time on sparc64 ... But a counter-argument is that if the two archs that llvm currently does not support well (sparc64 and ia64) start holding back major progress on amd64/i386, then we should give the most weight to what 90%+ of our userbase is on, and act accordingly. Hopefully that just means keep gcc as the default for our tier-2 archs. I've been finding it intellectually interesting to work on these, but really, they shouldn't be allowed to hold up the parade. Final note: there is indeed active kernel work on sparc64, ia64, and powerpc, so things are not stalled. mcl ___ 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: Fwd: umodem (4) recognize a CDC-ACM device
On Thu, Jun 3, 2010 at 12:57 PM, Hans Petter Selasky hsela...@c2i.net wrote:
On Thursday 03 June 2010 17:54:17 Hans Petter Selasky wrote:
On Thursday 03 June 2010 17:50:08 Hans Petter Selasky wrote:
On Thursday 03 June 2010 16:22:33 Marcelo/Porks wrote:
On Wed, Jun 2, 2010 at 1:25 PM, Hans Petter Selasky hsela...@c2i.net
wrote:
Hi,
The problem is that LOW speed does not support BULK transfers
according to the USB specification. I guess we could switch that
support on, though I'd rather stick with the spec.
Try changing this line in:
src/sys/dev/usb/usb_transfer.c
Hi,
Should be like this: Note the structure is called bulk_min:
static const uint16_t bulk_min[USB_SPEED_MAX] = {
[USB_SPEED_LOW] = 8,
[USB_SPEED_FULL] = 8,
[USB_SPEED_HIGH] = 512,
[USB_SPEED_VARIABLE] = 512,
[USB_SPEED_SUPER] = 1024,
};
--HPS
Hi, This was what I changed at first. I tried in a FreeBSD current
(Jun 3) and at 8.0-p3.
At FreeBSD current I changed the line 3062.
From:
[USB_SPEED_LOW] = 0,/* not supported */
To:
[USB_SPEED_LOW] = 8,
Like you suggested I'll try to talk with you in #bsdusb at efnet
Thank you!
--
Marcelo Rossi
This e-mail is provided AS IS with no warranties, and confers no rights.
___
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: Auto doadump()
On Thu, Jun 3, 2010 at 2:30 PM, David Rhodus sdrho...@gmail.com wrote: Is there a rc.conf variable to automatically save core on a panic and reboot ? Setting dumpdev=AUTO doesn't seem to do the trick. # uname -a FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Jun 3 20:00:22 UTC 2010 root@:/usr/obj/usr/src/sys/GE amd64 dumpdev=AUTO in rc.conf has been broken for a while from what I've seen, despite what rc.conf(5) suggests: dumpdev (str) Indicates the device (usually a swap partition) to which a crash dump should be written in the event of a system crash. If the value of this variable is ``AUTO'', the first suitable swap device listed in /etc/fstab will be used as dump device. Otherwise, the value of this variable is passed as the argument to dumpon(8). To disable crash dumps, set this variable to ``NO''. You have to explicitly note the dump device in /boot/loader.conf and have to reboot the box (otherwise it won't pick up the appropriate value via kenv). Kind of lame if you ask me... HTH, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current when enabling SUJ
From: Jeff Roberson jrober...@jroberson.net To: John Doe lex...@ymail.com Cc: curr...@freebsd.org Sent: Thu, June 3, 2010 7:19:59 PM Subject: Re: Panic on current when enabling SUJ On Thu, 3 Jun 2010, John Doe wrote: Boot into single user-mode # tunefs -j enable / # tunefs -j enable /usr # tunefs -j enable /tmp # tunefs -j enable /var # reboot The machine then panics. Looks like the machine is trying to write to a read-only filesystem. Can you please give me information on the panic? What was the state of the filesystems upon reboot? Does dumpfs show suj enabled? I wasn't able to get a dump. The filesystem did not have SUJ enable before booting into single user more. It appears SUJ was correctly enable by tunefs while in single user-mode. The problem appears to be isolated to enabling SUJ for the first time while in single user-mode, then rebooting. Let me know if you need anymore information. ___ 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
