Re: Fixing X220 Video The Right Way
when did it start working? -adrian On 9 August 2013 20:10, matt sendtom...@gmail.com wrote: hw.acpi.reset_video used to send this machine X220 into a reboot loop, with flashing thinklight. Interesting that it no longer causes this problem. I kind of paused since the trackpad sucks so much in X. I think since ssh still works, that just the display or graphics port is off. It may be worth trying to do some acpi_calls via ssh to try to hack the display back on... Matt On 08/09/13 08:57, John Baldwin wrote: On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote: Hi! Hm, resurrecting this thread, I'll try this on my X230 tomorrow and see if it makes the (non-xorg, console only) video work on resume. If it does, what will it take to automatically determine that this kind of work-around is needed? This does not affect suspend/resume. It only fixes LCD brightness handling via acpi_video(4). ___ 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: CFT: PCI Command Register fixups
Hi, I'll test out the iwn patch, thanks! -adrian On 9 August 2013 20:56, Scott Long sco...@samsco.org wrote: All, Subversion rev 250418 affected approximately 63 drivers by making them vulnerable to resource allocation failures on motherboards with buggy BIOSes. The revision itself is good, but it needs to address these drivers and bring them up to what is, in effect, a modified way for drivers to manage their PCI resources. If you've been seeing something like the following message since June 24/27, then you need this patch: mps0: LSI SAS2116 port 0xd000-0xd0ff mem 0xfb79c000-0xfb79 irq 19 at device 0.0 on pci4 mps0: PCI memory window not available device_attach: mps0 attach returned 6 The patch originated from John Baldwin, I merely fixed up a few nits and am passing it around for review and testing. Please find it here: http://people.freebsd.org/~scottl/pci_command_fixes.patch Thanks, Scott ___ 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: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present
On Fri, 9 Aug 2013 10:12:37 -0700
David Wolfskill da...@catwhisker.org wrote:
On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote:
...
On 8 August 2013 11:10, O. Hartmann ohart...@zedat.fu-berlin.de
wrote:
The most recent CURRENT doesn't work with the x11/nvidia-driver
(which is at 319.25 in the ports and 325.15 from nVidia).
After build- and installworld AND successfully rebuilding port
x11/nvidia-driver, the system crashes immediately after a reboot
as soon the kernel module nvidia.ko seems to get loaded (in my
case, I load nvidia.ko via /etc/rc.conf.local since the nVidia
BLOB doesn't load cleanly everytime when loaded
from /boot/loader.conf).
The crash occurs on systems with default compilation options set
while building world and with settings like -O3 -march=native. It
doesn't matter.
FreeBSD and the port x11/nvidia-driver has been compiled with
CLANG.
Most recent FreeBSD revision still crashing is r254097.
When vmcore is saved, I always see something like
savecore: reboot after panic: vm_radix_insert: key 23c078 is
already present
Does anyone has any idea what's going on?
Thanks for helping in advance,
Oliver
I'm seeing a complete deadlock on my T520 with today's current and
latest portsnap'd versions of ports for the nvidia-driver updates.
A little bisection and help from others seems to point the finger at
Jeff's r254025
I'm getting a complete deadlock on X starting, but loading the module
seems to have no ill effects.
Sean
Rigth, I loaded the module also via /boot/loader.conf and it loads
cleanly. I start xdm and then the deadlock occurs.
I tried recompiling the whole xorg suite via portmaster -f xorg xdm,
it took a while, but no effect, still dying.
.
Sorry to be rather late to the party; the Internet connection I'm using
at the moment is a bit flaky. (I'm out of town.)
I managed to get head/i386 @r254135 built and booting ... by removing
the options DEBUG_MEMGUARD from my kernel.
However, that merely prevented a (very!) early panic, and got me to the
point where trying to start xdm with the x11/nvidia-driver as the
display driver causes an immediate reboot (no crash dump, despite
'dumpdev=AUTO' in /etc/rc.conf). No drop to debugger, either.
Booting starting xdm with the nv driver works -- that's my present
environment as I am typing this.
However, the panic with DEBUG_MEMGUARD may offer a clue. Unfortunately,
it's early enough that screen lock/scrolling doesn't work, and I only
had the patience to write down partof the panic information. (This is
on my laptop; no serial console, AFAICT -- and no device to capture the
output if I did, since I'm not at home.)
The top line of the screen (at the panic) reads:
s/kern/subr_vmem.c:1050
The backtrace has the expected stuff near the top (about kbd, panic, and
memguard stuff); just below that is:
vmem_alloc(c1226100,6681000,2,c1820cc0,3b5,...) at
0xc0ac5673=vmem_alloc+0x53/frame 0xc1820ca0
Caveat: that was hand-transcribed from the screen to papaer, then
hand-transcribed from paper to this email message. And my highest grade
in Penmanship was a D+.
Be that as it may, here's the relevant section of subr_vmem.c with line
numbers (cut/pasted, so tabs get munged):
1039 /*
1040 * vmem_alloc: allocate resource from the arena.
1041 */
1042 int
1043 vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t
*addrp)
1044 {
1045 const int strat __unused = flags VMEM_FITMASK;
1046 qcache_t *qc;
1047
1048 flags = VMEM_FLAGS;
1049 MPASS(size 0);
1050 MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT);
1051 if ((flags M_NOWAIT) == 0)
1052 WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
vmem_alloc);
1053
1054 if (size = vm-vm_qcache_max) {
1055 qc = vm-vm_qcache[(size - 1)
vm-vm_quantum_shift];
1056 *addrp = (vmem_addr_t)uma_zalloc(qc-qc_cache, flags);
1057 if (*addrp == 0)
1058 return (ENOMEM);
1059 return (0);
1060 }
1061
1062 return vmem_xalloc(vm, size, 0, 0, 0, VMEM_ADDR_MIN,
VMEM_ADDR_MAX,
1063 flags, addrp);
1064 }
This is at r254025.
The REINPLACE_CMD at line 160 of nvidia-driver/Makefile is incorrect.
How do I know that? Because I made a patch which results in a working
nvidia-driver-319.32 with r254050. That's what I'm running right now.
Here's the patch (loaded with :r in vi, so all spaces etc. are correct):
--- src/nvidia_subr.c.orig 2013-08-09 11:32:26.0 +0200
+++ src/nvidia_subr.c 2013-08-09 11:33:23.0 +0200
@@ -945,7 +945,7 @@
Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present
Am 10.08.2013 10:37, schrieb Gary Jennejohn:
On Fri, 9 Aug 2013 10:12:37 -0700
David Wolfskill da...@catwhisker.org wrote:
On Fri, Aug 09, 2013 at 07:32:51AM +0200, O. Hartmann wrote:
...
On 8 August 2013 11:10, O. Hartmann ohart...@zedat.fu-berlin.de
wrote:
The most recent CURRENT doesn't work with the x11/nvidia-driver
(which is at 319.25 in the ports and 325.15 from nVidia).
After build- and installworld AND successfully rebuilding port
x11/nvidia-driver, the system crashes immediately after a reboot
as soon the kernel module nvidia.ko seems to get loaded (in my
case, I load nvidia.ko via /etc/rc.conf.local since the nVidia
BLOB doesn't load cleanly everytime when loaded
from /boot/loader.conf).
The crash occurs on systems with default compilation options set
while building world and with settings like -O3 -march=native. It
doesn't matter.
FreeBSD and the port x11/nvidia-driver has been compiled with
CLANG.
Most recent FreeBSD revision still crashing is r254097.
When vmcore is saved, I always see something like
savecore: reboot after panic: vm_radix_insert: key 23c078 is
already present
Does anyone has any idea what's going on?
Thanks for helping in advance,
Oliver
I'm seeing a complete deadlock on my T520 with today's current and
latest portsnap'd versions of ports for the nvidia-driver updates.
A little bisection and help from others seems to point the finger at
Jeff's r254025
I'm getting a complete deadlock on X starting, but loading the module
seems to have no ill effects.
Sean
Rigth, I loaded the module also via /boot/loader.conf and it loads
cleanly. I start xdm and then the deadlock occurs.
I tried recompiling the whole xorg suite via portmaster -f xorg xdm,
it took a while, but no effect, still dying.
.
Sorry to be rather late to the party; the Internet connection I'm using
at the moment is a bit flaky. (I'm out of town.)
I managed to get head/i386 @r254135 built and booting ... by removing
the options DEBUG_MEMGUARD from my kernel.
However, that merely prevented a (very!) early panic, and got me to the
point where trying to start xdm with the x11/nvidia-driver as the
display driver causes an immediate reboot (no crash dump, despite
'dumpdev=AUTO' in /etc/rc.conf). No drop to debugger, either.
Booting starting xdm with the nv driver works -- that's my present
environment as I am typing this.
However, the panic with DEBUG_MEMGUARD may offer a clue. Unfortunately,
it's early enough that screen lock/scrolling doesn't work, and I only
had the patience to write down partof the panic information. (This is
on my laptop; no serial console, AFAICT -- and no device to capture the
output if I did, since I'm not at home.)
The top line of the screen (at the panic) reads:
s/kern/subr_vmem.c:1050
The backtrace has the expected stuff near the top (about kbd, panic, and
memguard stuff); just below that is:
vmem_alloc(c1226100,6681000,2,c1820cc0,3b5,...) at
0xc0ac5673=vmem_alloc+0x53/frame 0xc1820ca0
Caveat: that was hand-transcribed from the screen to papaer, then
hand-transcribed from paper to this email message. And my highest grade
in Penmanship was a D+.
Be that as it may, here's the relevant section of subr_vmem.c with line
numbers (cut/pasted, so tabs get munged):
1039 /*
1040 * vmem_alloc: allocate resource from the arena.
1041 */
1042 int
1043 vmem_alloc(vmem_t *vm, vmem_size_t size, int flags, vmem_addr_t
*addrp)
1044 {
1045 const int strat __unused = flags VMEM_FITMASK;
1046 qcache_t *qc;
1047
1048 flags = VMEM_FLAGS;
1049 MPASS(size 0);
1050 MPASS(strat == M_BESTFIT || strat == M_FIRSTFIT);
1051 if ((flags M_NOWAIT) == 0)
1052 WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL,
vmem_alloc);
1053
1054 if (size = vm-vm_qcache_max) {
1055 qc = vm-vm_qcache[(size - 1)
vm-vm_quantum_shift];
1056 *addrp = (vmem_addr_t)uma_zalloc(qc-qc_cache,
flags);
1057 if (*addrp == 0)
1058 return (ENOMEM);
1059 return (0);
1060 }
1061
1062 return vmem_xalloc(vm, size, 0, 0, 0, VMEM_ADDR_MIN,
VMEM_ADDR_MAX,
1063 flags, addrp);
1064 }
This is at r254025.
The REINPLACE_CMD at line 160 of nvidia-driver/Makefile is incorrect.
How do I know that? Because I made a patch which results in a working
nvidia-driver-319.32 with r254050. That's what I'm running right now.
Here's the patch (loaded with :r in vi, so all spaces etc. are correct):
--- src/nvidia_subr.c.orig2013-08-09 11:32:26.0 +0200
+++ src/nvidia_subr.c 2013-08-09 11:33:23.0 +0200
@@ -945,7 +945,7 @@
return ENOMEM;
}
-address = kmem_alloc_contig(kernel_map, size, flags, 0,
+address =
Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present
On Sat, 10 Aug 2013 11:10:40 +0200 Rainer Hurling rhur...@gwdg.de wrote: Yes, I can confirm, that it builds, installs and runs fine for me. The patch should be placed as x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it? Many thanks for this work. Thanks for testing. Yes, putting the patch into files/ with that name works also and is much simpler than the steps I outlined. -- Gary Jennejohn ___ 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: Fixing X220 Video The Right Way
Not sure that it did :) I tried it once early on, and it concerned me enough I never tried again. It was clearly in a violently erroneous state! At one point, X *could* resume the display. This makes me think the problem is solved via the graphics chip state, but it could be an acpi thing. I can't remember if I ever tried to startx after the resume on the blind console. Matt On 08/09/13 23:00, Adrian Chadd wrote: when did it start working? -adrian On 9 August 2013 20:10, matt sendtom...@gmail.com wrote: hw.acpi.reset_video used to send this machine X220 into a reboot loop, with flashing thinklight. Interesting that it no longer causes this problem. I kind of paused since the trackpad sucks so much in X. I think since ssh still works, that just the display or graphics port is off. It may be worth trying to do some acpi_calls via ssh to try to hack the display back on... Matt On 08/09/13 08:57, John Baldwin wrote: On Friday, August 09, 2013 4:37:50 am Adrian Chadd wrote: Hi! Hm, resurrecting this thread, I'll try this on my X230 tomorrow and see if it makes the (non-xorg, console only) video work on resume. If it does, what will it take to automatically determine that this kind of work-around is needed? This does not affect suspend/resume. It only fixes LCD brightness handling via acpi_video(4). ___ 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
loader don't load loader.conf if device.hints has errors
Hello, Current. I've make simple mistake (DOS-style EOL) in /boot/device.hints and /boot/loader.conf was skipped too with strange (device.hints-related) message: FreeBSD/x86 bootstrap loader, Revision 1.1 (r...@fbsd-c-64.vm.home.serebryakov.spb.ru, Sat Aug 10 14:02:41 MSK 2013) Loading /boot/defaults/loader.conf Warning: syntax error on file /boot/device.hints hint.uart.0.flags=0x00 ^ Warning: syntax error on file /boot/loader.conf hint.uart.0.flags=0x00 ^ /boot/kernel/kernel text=0x5dfed8 data=0x69078+0xd6b10 syms=[0x8+0x9cd50+0x8+0x930ab] Is it Ok? -- // Black Lion AKA Lev Serebryakov l...@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
nanobsd-built system doesn't have SVN revision in uname (and it looks like regression)
Hello, Freebsd-embedded. Latest revisions of -CURRENT built with nanobsd script haven't revision in uname -a output: FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013 r...@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC amd64 System was built from /data/src directory, which IS subversion working copy and `svn' and `svnversion' PRESENTS in $PATH. It is r254177, really. I don't remeber exactly, but I have feeling, that earlier revisions didn't have this problem. -- // Black Lion AKA Lev Serebryakov l...@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: nanobsd-built system doesn't have SVN revision in uname (and it looks like regression)
Hello, Lev. You wrote 10 августа 2013 г., 15:08:49: LS Latest revisions of -CURRENT built with nanobsd script haven't revision LS in uname -a output: LS FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD LS 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013 LS r...@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC amd64 LS System was built from /data/src directory, which IS subversion working LS copy and `svn' and `svnversion' PRESENTS in $PATH. Ok, problem is, that svnliteversion presents too, but WC version is old one (for 1.7.x). I'm not sure, is this bug worth fixing. -- // Black Lion AKA Lev Serebryakov l...@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
panic on boot with fresh current
Hi, I just rebuilt a fresh current on my laptop. It panics on boot with: panic: witness_init: pending locks list is too small, increase WITNESS_PENDLIST I'm in a hurry right now so I can't gather much more info at the moment, but I thought I'd mention it. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present
On Sat, 10 Aug 2013 11:31:19 +0200
Gary Jennejohn gljennj...@googlemail.com wrote:
On Sat, 10 Aug 2013 11:10:40 +0200
Rainer Hurling rhur...@gwdg.de wrote:
Yes, I can confirm, that it builds, installs and runs fine for me.
The patch should be placed as
x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it?
Many thanks for this work.
Thanks for testing.
Yes, putting the patch into files/ with that name works also and
is much simpler than the steps I outlined.
Placing the patch in files as recommended here doesn't play well with
the obvious intention of the REINPLACE command:
the patch only applies to 319.25.
I use the cutting edge 325.15. The patch doesn't apply since some lines
shifted - here comes the tricky REINPLACE part of the Makefile in place.
I simply adapted your patches discussed and introduced here and
adapted the REINPLACE statements/pattern around line 160 in the
toplevel Makefile of port x11/nvidia-driver.
Find the patch attached - I forgot to raise PORTREVISION=1.
I'm now sending this email from the prior crashing box with the patch
discussed applied via the Makefile to 325.15.
Thanks a lot for the fast help.
Regards,
Oliver
diff -Nur nvidia-driver.orig/Makefile nvidia-driver/Makefile
--- nvidia-driver.orig/Makefile 2013-08-10 14:46:08.0 +0200
+++ nvidia-driver/Makefile 2013-08-10 14:41:52.0 +0200
@@ -158,8 +158,8 @@
.endif
# Catch up with KVA space allocation API changes in recent -CURRENT
.if ${OSVERSION} 140
- ${REINPLACE_CMD} -e 's/kmem_free(kernel_map,/kva_free(/ ; \
- /kmem_alloc_contig/s/map/arena/' ${WRKSRC}/src/nvidia_subr.c
+ ${REINPLACE_CMD} -e 's/kmem_free(kernel_map,/kmem_free(kmem_arena,/ ; \
+ /kmem_alloc_contig/s/kernel_map/kmem_arena/'
${WRKSRC}/src/nvidia_subr.c
.endif
# Process OPTIONS
.if ${PORT_OPTIONS:MFREEBSD_AGP}
signature.asc
Description: PGP signature
Re: Problems with usb bluetooth device
On Sat, Mar 28, 2009 at 11:00:32AM +0100, Hans Petter Selasky wrote: On Saturday 28 March 2009, Lars Engels wrote: Hi all, yesterday I bought a shiny new hama usb bluetooth dongle but I am having some problems using it: before loading ng_ubt: usb2_alloc_device:1480: set address 2 failed (ignored) usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: at usbus0 (disconnected) after loading ng_ubt: uhub_reattach_port:413: could not allocate new device! ubt0: Broadcom Corp Foxconn Bluetooth 2.0 plus EDR, class 224/1, rev 2.00/1.00, addr 2 on usbus2 ^^ internal bluetooth device WARNING: attempt to net_add_domain(bluetooth) after domainfinalize() WARNING: attempt to net_add_domain(netgraph) after domainfinalize() ugen0.2: Cambridge Silicon Radio at usbus0 ubt1: Cambridge Silicon Radio Bluetooth USB dongle, class 224/1, rev 2.00/48.39, addr 2 on usbus0 ubt1: ubt_bulk_read_callback:837: bulk-in transfer failed: USB_ERR_STALLED ubt1: ubt_intr_read_callback:741: interrupt transfer failed: USB_ERR_STALLED ubt1: at uhub0, port 1, addr 2 (disconnected) ugen0.2: Cambridge Silicon Radio at usbus0 (disconnected) device re-inserted: usb2_alloc_device:1480: set address 2 failed (ignored) usb2_alloc_device:1516: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! usb2_req_re_enumerate:1421: addr=2, set address failed! (ignored) usb2_req_re_enumerate:1434: getting device descriptor at addr 2 failed! ugen0.2: at usbus0 (disconnected) uhub_reattach_port:413: could not allocate new device! So the device is no longer recognized after I re-connect it. usbconfig does not show it: ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: UHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: UHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: UHCI root HUB Intel at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: EHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen2.2: Foxconn Bluetooth 2.0 plus EDR Broadcom Corp at usbus2, cfg=0 md=HOST spd=FULL (12Mbps pwr=ON It only lists the internal device... My CURRENT was compiled two days ago, so I should be up-to-date. Does it work when you use an external USB HUB? Does this device have some kind of autoinstall on it? You could try enabling uhci/ehci debugging. sysctl hw.usb2.uhci.debug = 15 Then we would know the exact cause of the error. Just for your info: Aug 10 15:21:45 milhouse kernel: ubt1: vendor 0x0a12 product 0x0001, class 224/1, rev 2.00/48.39, addr 2 on usbus3 Aug 10 15:21:45 milhouse devd: Executing '/etc/rc.d/bluetooth quietstart ubt1' After 4 years, the device now works without an external hub. ;-)) Lars pgptpC7GOmMki.pgp Description: PGP signature
Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present
On Sat, 10 Aug 2013 14:59:22 +0200 O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Sat, 10 Aug 2013 11:31:19 +0200 Gary Jennejohn gljennj...@googlemail.com wrote: On Sat, 10 Aug 2013 11:10:40 +0200 Rainer Hurling rhur...@gwdg.de wrote: Yes, I can confirm, that it builds, installs and runs fine for me. The patch should be placed as x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it? Many thanks for this work. Thanks for testing. Yes, putting the patch into files/ with that name works also and is much simpler than the steps I outlined. Placing the patch in files as recommended here doesn't play well with the obvious intention of the REINPLACE command: the patch only applies to 319.25. I use the cutting edge 325.15. The patch doesn't apply since some lines shifted - here comes the tricky REINPLACE part of the Makefile in place. I simply adapted your patches discussed and introduced here and adapted the REINPLACE statements/pattern around line 160 in the toplevel Makefile of port x11/nvidia-driver. Find the patch attached - I forgot to raise PORTREVISION=1. I'm now sending this email from the prior crashing box with the patch discussed applied via the Makefile to 325.15. Thanks a lot for the fast help. Yes, this is a better approach. I made my patch before realizing that the REINPLACE_CMD was the source of the errors. Any real advantage to using 325.15? You should submit a PR with this patch. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present
On Sat, 10 Aug 2013 15:39:48 +0200 Gary Jennejohn gljennj...@googlemail.com wrote: On Sat, 10 Aug 2013 14:59:22 +0200 O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Sat, 10 Aug 2013 11:31:19 +0200 Gary Jennejohn gljennj...@googlemail.com wrote: On Sat, 10 Aug 2013 11:10:40 +0200 Rainer Hurling rhur...@gwdg.de wrote: Yes, I can confirm, that it builds, installs and runs fine for me. The patch should be placed as x11/nvidia-driver/files/patch-src__nvidia_subr.c, shoudn't it? Many thanks for this work. Thanks for testing. Yes, putting the patch into files/ with that name works also and is much simpler than the steps I outlined. Placing the patch in files as recommended here doesn't play well with the obvious intention of the REINPLACE command: the patch only applies to 319.25. I use the cutting edge 325.15. The patch doesn't apply since some lines shifted - here comes the tricky REINPLACE part of the Makefile in place. I simply adapted your patches discussed and introduced here and adapted the REINPLACE statements/pattern around line 160 in the toplevel Makefile of port x11/nvidia-driver. Find the patch attached - I forgot to raise PORTREVISION=1. I'm now sending this email from the prior crashing box with the patch discussed applied via the Makefile to 325.15. Thanks a lot for the fast help. Yes, this is a better approach. I made my patch before realizing that the REINPLACE_CMD was the source of the errors. Any real advantage to using 325.15? Well, nvidia claims they have fixed bugs and it is the successor in line after 319.25. It is stable, it is the newest, it is so far nice :-) You should submit a PR with this patch. Well, I do. I thought it isn't my honour since I simply made a profit from the labor of others here and I simply picked up crumps. Well, I added a followup to port/181144. Oliver signature.asc Description: PGP signature
Re: nanobsd-built system doesn't have SVN revision in uname (and it looks like regression)
Hello, Freebsd-current. You wrote 10 августа 2013 г., 15:18:46: LS Latest revisions of -CURRENT built with nanobsd script haven't revision LS in uname -a output: LS FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD LS 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013 LS r...@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC amd64 LS System was built from /data/src directory, which IS subversion working LS copy and `svn' and `svnversion' PRESENTS in $PATH. LS Ok, problem is, that svnliteversion presents too, but WC version is old LS one (for 1.7.x). I'm not sure, is this bug worth fixing. Nope, upgrading working copy doesn't help :((( -- // Black Lion AKA Lev Serebryakov l...@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: nanobsd-built system doesn't have SVN revision in uname (and it looks like regression)
Try running the svnlite version of svn upgrade. (svnlite upgrade) -adrian On 10 August 2013 07:02, Lev Serebryakov l...@freebsd.org wrote: Hello, Freebsd-current. You wrote 10 августа 2013 г., 15:18:46: LS Latest revisions of -CURRENT built with nanobsd script haven't revision LS in uname -a output: LS FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD LS 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013 LS r...@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC amd64 LS System was built from /data/src directory, which IS subversion working LS copy and `svn' and `svnversion' PRESENTS in $PATH. LS Ok, problem is, that svnliteversion presents too, but WC version is old LS one (for 1.7.x). I'm not sure, is this bug worth fixing. Nope, upgrading working copy doesn't help :((( -- // Black Lion AKA Lev Serebryakov l...@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 ___ 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: nanobsd-built system doesn't have SVN revision in uname (and it looks like regression)
Hmm. I suspect r254094 is to blame here, although I did extensive testing with different svn versions before the commit. :( I'll take another look at this, in case I missed an edge case. Glen On Sat, Aug 10, 2013 at 07:03:29AM -0700, Adrian Chadd wrote: Try running the svnlite version of svn upgrade. (svnlite upgrade) -adrian On 10 August 2013 07:02, Lev Serebryakov l...@freebsd.org wrote: Hello, Freebsd-current. You wrote 10 августа 2013 г., 15:18:46: LS Latest revisions of -CURRENT built with nanobsd script haven't revision LS in uname -a output: LS FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD LS 10.0-CURRENT #0: Sat Aug 10 14:17:32 MSK 2013 LS r...@fbsd-c-64.vm.home.serebryakov.spb.ru:/data/obj.nano/gateway.v2/data/src/sys/D2500CC amd64 LS System was built from /data/src directory, which IS subversion working LS copy and `svn' and `svnversion' PRESENTS in $PATH. LS Ok, problem is, that svnliteversion presents too, but WC version is old LS one (for 1.7.x). I'm not sure, is this bug worth fixing. Nope, upgrading working copy doesn't help :((( -- // Black Lion AKA Lev Serebryakov l...@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 ___ 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 pgpjmgC96mkNb.pgp Description: PGP signature
Re: loader don't load loader.conf if device.hints has errors
Hello, Lev. You wrote 10 августа 2013 г., 15:01:57: LS Hello, Current. LS I've make simple mistake (DOS-style EOL) in /boot/device.hints and LS /boot/loader.conf was skipped too with strange (device.hints-related) LS message: LS FreeBSD/x86 bootstrap loader, Revision 1.1 LS (r...@fbsd-c-64.vm.home.serebryakov.spb.ru, Sat Aug 10 14:02:41 MSK 2013) LS Loading /boot/defaults/loader.conf LS Warning: syntax error on file /boot/device.hints LS hint.uart.0.flags=0x00 LS ^ LS Warning: syntax error on file /boot/loader.conf LS hint.uart.0.flags=0x00 LS ^ LS /boot/kernel/kernel text=0x5dfed8 data=0x69078+0xd6b10 syms=[0x8+0x9cd50+0x8+0x930ab] Also, loader doesn't say anything about reading /boot/device.hints and /boot/loader.conf, but it reads them for sure: FreeBSD/x86 bootstrap loader, Revision 1.1 (r...@fbsd-c-64.vm.home.serebryakov.spb.ru, Sat Aug 10 18:35:18 MSK 2013) Loading /boot/defaults/loader.conf /boot/kernel/kernel text=0x5e5fb0 data=0x69cf8+0xd6c10 syms=[0x8+0x9db48+0x8+0x93be1] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... GDB: no debug ports present -- // Black Lion AKA Lev Serebryakov l...@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: nanobsd-built system doesn't have SVN revision in uname (and it looks like regression)
Hello, Glen. You wrote 10 августа 2013 г., 18:13:24: GB Hmm. I suspect r254094 is to blame here, although I did extensive GB testing with different svn versions before the commit. :( GB I'll take another look at this, in case I missed an edge case. It doesn't look like edge case... Sources in /data/src. It is SVN WC. # cd /data/src svnversion 254178M # cd /data/src svnliteversion 254178M # host system is -CURRENT too, already without revision in uname -a output (!), from Sat Jul 20. System is built with nanobsd script, but it looks like nanobsd.sh doesn't do any special here. It sets MAKEOBJDIRPREFIX to /data/obj.nano/gateway.v2 and call: env TARGET_ARCH=amd64 make -j4 __MAKE_CONF=/some/path/to/generated/make.conf buildworld Generated make.conf looks like: === XCC=/usr/bin/cc XCXX=/usr/bin/c++ XCPP=/usr/bin/cpp COMPILER_TYPE=clang MALLOC_PRODUCTION=yes BOOT_COMCONSOLE_SPEED=115200 BOOT_COMCONSOLE_PORT=0x2E8 WITHOUT_ACCT=yes WITHOUT_ACPI=yes WITHOUT_AMD=yes WITHOUT_APM=yes WITHOUT_ATM=yes WITHOUT_AUDIT=yes WITHOUT_AUTHPF=yes WITHOUT_BIND_DNSSEC=yes WITHOUT_CALENDAR=yes WITHOUT_CDDL=yes WITHOUT_CLANG=yes WITHOUT_CROSS_COMPILER=yes WITHOUT_CTM=yes WITHOUT_DICT=yes WITHOUT_EXAMPLES=yes WITHOUT_FLOPPY=yes WITHOUT_FREEBSD_UPDATE=yes WITHOUT_GAMES=yes WITHOUT_GCC=yes WITHOUT_GCOV=yes WITHOUT_GDB=yes WITHOUT_GPIB=yes WITHOUT_GPIO=yes WITHOUT_GROFF=yes WITHOUT_GSSAPI=yes WITHOUT_HTML=yes WITHOUT_INFO=yes WITHOUT_IPFILTER=yes WITHOUT_IPX=yes WITHOUT_JAIL=yes WITHOUT_LEGACY_CONSOLE=yes WITHOUT_LIB32=yes WITHOUT_LOCALES=yes WITHOUT_LOCATE=yes WITHOUT_LPR=yes WITHOUT_KERBEROS=yes WITHOUT_KERBEROS_SUPPORT=yes WITHOUT_MAN=yes WITHOUT_NCP=yes WITHOUT_NDIS=yes WITHOUT_NIS=yes WITHOUT_NLS=yes WITHOUT_NLS_CATALOGS=yes WITHOUT_NS_CACHING=yes WITHOUT_OBJC=yes WITHOUT_PC_SYSINSTALL=yes WITHOUT_PF=yes WITHOUT_PORTSNAP=yes WITHOUT_PROFILE=yes WITHOUT_QUOTAS=yes WITHOUT_RCMDS=yes WITHOUT_RCS=yes WITHOUT_ROUTED=yes WITHOUT_SHAREDOCS=yes WITHOUT_SVNLITE=yes WITHOUT_SYSCONS=yes WITHOUT_ZFS=yes SRCCONF=/dev/null === -- // Black Lion AKA Lev Serebryakov l...@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: panic on boot with fresh current
On 8/10/2013 6:24 AM, Joel Dahl wrote: Hi, I just rebuilt a fresh current on my laptop. It panics on boot with: panic: witness_init: pending locks list is too small, increase WITNESS_PENDLIST I'm in a hurry right now so I can't gather much more info at the moment, but I thought I'd mention it. I also get this. The last stable revision for me was r254150 -- Regards, Bryan Drewery ___ 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 boot with fresh current
On 8/10/2013 11:44 AM, Bryan Drewery wrote: On 8/10/2013 6:24 AM, Joel Dahl wrote: panic: witness_init: pending locks list is too small, increase WITNESS_PENDLIST I also get this. The last stable revision for me was r254150 r254150 stable, r254171 panic. backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg -- Regards, Bryan Drewery ___ 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
Fun with nvi
I've been tinkering with the nvi refresh from the GSoC in 2011, aka nvi2. https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1 https://github.com/lichray/nvi2 The goal was to update the multibyte handling in nvi-1.79 (the one we have in our tree) in such a way we could import it. Anyway.. an early WIP: http://people.freebsd.org/~peter/nvi2.tgz peter@overcee[ 9:37AM]~/head/contrib/nvi/catalog-1643 echo $LANG en_US.UTF-8 peter@overcee[ 9:38AM]~/head/contrib/nvi/catalog-1644 vi -c 'set fileencoding=GB2312' zh_CN.GB2312.base .. leads to fun things like: http://people.freebsd.org/~peter/nvi2-transcoding.png that's editing the file in GB2312 format, but converting to utf-8 on the fly for my terminal. This is with the WITH_ICONV=yes in make.conf. nvi2 will build without it but obviously won't be able to work with non-default encoding methods. In straight up UTF-8 mode: http://people.freebsd.org/~peter/nvi2-utf8-4.png How to use the tarball.. 1) rm -rf contrib/nvi usr.bin/vi 2) extract tarball into src tree 3) patch -p0 nvi.diff (this adds a built-tool to world) Note that I haven't actually done a buildworld yet. I've just been building it directly from src/usr.bin/vi with make obj make depend make all make install .. to save time. But you'll need to have WITH_ICONV=yes in make.conf to do the fancy stuff. Note that the ports tree is a long way from being WITH_ICONV=yes safe, so don't do this on an important machine. An example of the tweaks to make ports happier: http://people.freebsd.org/~peter/iconv.diff - that's not complete. Most of the ports tree was updated to use Mk/Uses/iconv.mk but there's still some oddballs scattered around in weird places. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. brueffer ZFS must be the bacon of file systems. everything's better with ZFS ___ 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 boot with fresh current
On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote: On 8/10/2013 11:44 AM, Bryan Drewery wrote: On 8/10/2013 6:24 AM, Joel Dahl wrote: panic: witness_init: pending locks list is too small, increase WITNESS_PENDLIST I also get this. The last stable revision for me was r254150 r254150 stable, r254171 panic. backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg So could you point to exact commit which causes panic ? pgpci7am3AOaR.pgp Description: PGP signature
Re: panic on boot with fresh current
On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote: On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote: On 8/10/2013 11:44 AM, Bryan Drewery wrote: On 8/10/2013 6:24 AM, Joel Dahl wrote: panic: witness_init: pending locks list is too small, increase WITNESS_PENDLIST I also get this. The last stable revision for me was r254150 r254150 stable, r254171 panic. backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg So could you point to exact commit which causes panic ? It is r254167, right ? pgpN3VVMpSXEV.pgp Description: PGP signature
Re: nanobsd-built system doesn't have SVN revision in uname (and it looks like regression)
Same problems here ... sometime after 10.0-CURRENT r253918 ... Two other systems stopped working and they have a mixture of svn / svnlite version combinations: working system: #1: ports svn installed at newer version root@borg:/usr/src # svnversion ; svnversion --version | head -1 253918 svnversion, version 1.8.0 (r1490375) root@borg:/usr/src # svnliteversion ; svnliteversion --version | head -1 253918 svnversion, version 1.8.1 (r1503906) root@borg:/usr/src # uname -a FreeBSD borg.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r253918: Sat Aug 3 15:16:58 CDT 2013 r...@borg.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 Systems not working: #2: no ports svn installed root@olive:/usr/src # uname -a FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #5: Sat Aug 10 08:30:25 CDT 2013 r...@olive.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 root@olive:/usr/src # svnversion ; svnversion --version | head -1 svnversion: Command not found. svnversion: Command not found. root@olive:/usr/src # svnliteversion ; svnliteversion --version | head -1 254178 svnversion, version 1.8.1 (r1503906) #3: ports version installed at newer version root@darkstor:/usr/src # uname -a FreeBSD darkstor.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #7: Sat Aug 10 08:35:47 CDT 2013 r...@darkstor.example.com:/usr/obj/usr/src/sys/MACKGEN amd64 root@darkstor:/usr/src # svnversion ; svnversion --version | head -1 254178 svnversion, version 1.8.0 (r1490375) root@darkstor:/usr/src # svnliteversion ; svnliteversion --version | head -1 254178 svnversion, version 1.8.1 (r1503906) Dan On Sat, 10 Aug 2013, Lev Serebryakov wrote: Hello, Glen. You wrote 10 ??? 2013 ?., 18:13:24: GB Hmm. I suspect r254094 is to blame here, although I did extensive GB testing with different svn versions before the commit. :( GB I'll take another look at this, in case I missed an edge case. It doesn't look like edge case... Sources in /data/src. It is SVN WC. # cd /data/src svnversion 254178M # cd /data/src svnliteversion 254178M # host system is -CURRENT too, already without revision in uname -a output (!), from Sat Jul 20. System is built with nanobsd script, but it looks like nanobsd.sh doesn't do any special here. It sets MAKEOBJDIRPREFIX to /data/obj.nano/gateway.v2 and call: env TARGET_ARCH=amd64 make -j4 __MAKE_CONF=/some/path/to/generated/make.conf buildworld Generated make.conf looks like: === XCC=/usr/bin/cc XCXX=/usr/bin/c++ XCPP=/usr/bin/cpp COMPILER_TYPE=clang MALLOC_PRODUCTION=yes BOOT_COMCONSOLE_SPEED=115200 BOOT_COMCONSOLE_PORT=0x2E8 WITHOUT_ACCT=yes WITHOUT_ACPI=yes WITHOUT_AMD=yes WITHOUT_APM=yes WITHOUT_ATM=yes WITHOUT_AUDIT=yes WITHOUT_AUTHPF=yes WITHOUT_BIND_DNSSEC=yes WITHOUT_CALENDAR=yes WITHOUT_CDDL=yes WITHOUT_CLANG=yes WITHOUT_CROSS_COMPILER=yes WITHOUT_CTM=yes WITHOUT_DICT=yes WITHOUT_EXAMPLES=yes WITHOUT_FLOPPY=yes WITHOUT_FREEBSD_UPDATE=yes WITHOUT_GAMES=yes WITHOUT_GCC=yes WITHOUT_GCOV=yes WITHOUT_GDB=yes WITHOUT_GPIB=yes WITHOUT_GPIO=yes WITHOUT_GROFF=yes WITHOUT_GSSAPI=yes WITHOUT_HTML=yes WITHOUT_INFO=yes WITHOUT_IPFILTER=yes WITHOUT_IPX=yes WITHOUT_JAIL=yes WITHOUT_LEGACY_CONSOLE=yes WITHOUT_LIB32=yes WITHOUT_LOCALES=yes WITHOUT_LOCATE=yes WITHOUT_LPR=yes WITHOUT_KERBEROS=yes WITHOUT_KERBEROS_SUPPORT=yes WITHOUT_MAN=yes WITHOUT_NCP=yes WITHOUT_NDIS=yes WITHOUT_NIS=yes WITHOUT_NLS=yes WITHOUT_NLS_CATALOGS=yes WITHOUT_NS_CACHING=yes WITHOUT_OBJC=yes WITHOUT_PC_SYSINSTALL=yes WITHOUT_PF=yes WITHOUT_PORTSNAP=yes WITHOUT_PROFILE=yes WITHOUT_QUOTAS=yes WITHOUT_RCMDS=yes WITHOUT_RCS=yes WITHOUT_ROUTED=yes WITHOUT_SHAREDOCS=yes WITHOUT_SVNLITE=yes WITHOUT_SYSCONS=yes WITHOUT_ZFS=yes SRCCONF=/dev/null === -- // Black Lion AKA Lev Serebryakov l...@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 dan -- Dan Mack ___ 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: nanobsd-built system doesn't have SVN revision in uname (and it looks like regression)
Here's the before and after looks like FWIW:
'
+ LC_ALL=C
+ export LC_ALL
+ [ ! -r version ]
+ echo 0
+ touch version
+ cat version
+ pwd
+ hostname
+ date
+ v=0 u=root d=/usr/src/sys/conf h=borg.macktronics.com t='Sat Aug 10
12:59:21 CDT 2013'
+ make -V KERN_IDENT
+ i=''
+ make -V CC
+ grep version
+ cc -v
+ compiler_v='FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502)
20130610'
+ [ -x /usr/bin/svnliteversion ]
+ svnversion=/usr/bin/svnliteversion
+ [ ! -z /usr/bin/svnliteversion ]
+ break
+ [ -x /usr/bin/p4 ]
+ [ -x /usr/local/bin/p4 ]
+ [ -d ./../../.git ]
+ [ -n /usr/bin/svnliteversion ]
+ cd ./..
+ /usr/bin/svnliteversion
+ svn=253918
+ svn=' r253918'
+ [ -n '' ]
+ [ -n '' ]
+ cat
+ echo 1
BAD:
'
+ LC_ALL=C
+ export LC_ALL
+ [ ! -r version ]
+ echo 0
+ touch version
+ cat version
+ pwd
+ hostname
+ date
+ v=0 u=root d=/usr/src/sys/conf h=olive.macktronics.com t='Sat Aug 10
12:58:47 CDT 2013'
+ make -V KERN_IDENT
+ i=''
+ make -V CC
+ grep version
+ cc -v
+ compiler_v='FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502)
20130610'
+ [ ! -z '' ]
+ [ -x /usr/bin/svnversion ]
+ [ ! -z '' ]
+ [ -x /usr/local/bin/svnversion ]
+ [ -z '' ]
+ [ -x /usr/bin/svnliteversion ]
+ basename newvers.sh
+ /usr/bin/svnversion newvers.sh
+ [ 127 -eq 0 ]
+ svnversion=''
+ [ -x /usr/bin/p4 ]
+ [ -x /usr/local/bin/p4 ]
+ [ -d ./../../.git ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -n '' ]
+ cat
+ echo 1
It looks like you are doing the first [! -z '${svnversion}' ] before
$svnversion is being set. In the old version, this was being set via:
if [ -x /usr/bin/svnliteversion ] ; then
svnversion=/usr/bin/svnliteversion
fi
But I'm not sure if that's intentional or not ...
Dan
On Sat, 10 Aug 2013, Dan Mack wrote:
Same problems here ... sometime after 10.0-CURRENT r253918 ... Two other
systems stopped working and they have a mixture of svn / svnlite version
combinations:
working system:
#1: ports svn installed at newer version
root@borg:/usr/src # svnversion ; svnversion --version | head -1
253918
svnversion, version 1.8.0 (r1490375)
root@borg:/usr/src # svnliteversion ; svnliteversion --version | head -1
253918
svnversion, version 1.8.1 (r1503906)
root@borg:/usr/src # uname -a
FreeBSD borg.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r253918: Sat
Aug 3 15:16:58 CDT 2013 r...@borg.example.com:/usr/obj/usr/src/sys/MACKGEN
amd64
Systems not working:
#2: no ports svn installed
root@olive:/usr/src # uname -a
FreeBSD olive.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #5: Sat Aug 10
08:30:25 CDT 2013 r...@olive.example.com:/usr/obj/usr/src/sys/MACKGEN amd64
root@olive:/usr/src # svnversion ; svnversion --version | head -1
svnversion: Command not found.
svnversion: Command not found.
root@olive:/usr/src # svnliteversion ; svnliteversion --version | head -1
254178
svnversion, version 1.8.1 (r1503906)
#3: ports version installed at newer version
root@darkstor:/usr/src # uname -a
FreeBSD darkstor.example.com 10.0-CURRENT FreeBSD 10.0-CURRENT #7: Sat Aug 10
08:35:47 CDT 2013 r...@darkstor.example.com:/usr/obj/usr/src/sys/MACKGEN
amd64
root@darkstor:/usr/src # svnversion ; svnversion --version | head -1
254178
svnversion, version 1.8.0 (r1490375)
root@darkstor:/usr/src # svnliteversion ; svnliteversion --version | head -1
254178
svnversion, version 1.8.1 (r1503906)
Dan
On Sat, 10 Aug 2013, Lev Serebryakov wrote:
Hello, Glen.
You wrote 10 ??? 2013 ?., 18:13:24:
GB Hmm. I suspect r254094 is to blame here, although I did extensive
GB testing with different svn versions before the commit. :(
GB I'll take another look at this, in case I missed an edge case.
It doesn't look like edge case...
Sources in /data/src. It is SVN WC.
# cd /data/src svnversion
254178M
# cd /data/src svnliteversion
254178M
#
host system is -CURRENT too, already without revision in uname -a output
(!), from Sat Jul 20.
System is built with nanobsd script, but it looks like nanobsd.sh doesn't
do any special here. It sets MAKEOBJDIRPREFIX to /data/obj.nano/gateway.v2
and call:
env TARGET_ARCH=amd64 make -j4
__MAKE_CONF=/some/path/to/generated/make.conf buildworld
Generated make.conf looks like:
===
XCC=/usr/bin/cc
XCXX=/usr/bin/c++
XCPP=/usr/bin/cpp
COMPILER_TYPE=clang
MALLOC_PRODUCTION=yes
BOOT_COMCONSOLE_SPEED=115200
BOOT_COMCONSOLE_PORT=0x2E8
WITHOUT_ACCT=yes
WITHOUT_ACPI=yes
WITHOUT_AMD=yes
WITHOUT_APM=yes
WITHOUT_ATM=yes
WITHOUT_AUDIT=yes
WITHOUT_AUTHPF=yes
WITHOUT_BIND_DNSSEC=yes
WITHOUT_CALENDAR=yes
WITHOUT_CDDL=yes
WITHOUT_CLANG=yes
WITHOUT_CROSS_COMPILER=yes
WITHOUT_CTM=yes
WITHOUT_DICT=yes
WITHOUT_EXAMPLES=yes
WITHOUT_FLOPPY=yes
WITHOUT_FREEBSD_UPDATE=yes
WITHOUT_GAMES=yes
WITHOUT_GCC=yes
WITHOUT_GCOV=yes
WITHOUT_GDB=yes
WITHOUT_GPIB=yes
WITHOUT_GPIO=yes
WITHOUT_GROFF=yes
WITHOUT_GSSAPI=yes
WITHOUT_HTML=yes
WITHOUT_INFO=yes
WITHOUT_IPFILTER=yes
WITHOUT_IPX=yes
WITHOUT_JAIL=yes
WITHOUT_LEGACY_CONSOLE=yes
WITHOUT_LIB32=yes
Re: nanobsd-built system doesn't have SVN revision in uname (and it looks like regression)
On Sat, Aug 10, 2013 at 01:09:20PM -0500, Dan Mack wrote:
It looks like you are doing the first [! -z '${svnversion}' ]
before $svnversion is being set. In the old version, this was
being set via:
if [ -x /usr/bin/svnliteversion ] ; then
svnversion=/usr/bin/svnliteversion
fi
But I'm not sure if that's intentional or not ...
Ugh. No, this was not intentional. I'll have this fixed shortly.
Thank you for the report and the investigation.
Glen
pgpuiL2yYxXQL.pgp
Description: PGP signature
Re: panic on boot with fresh current
On Sat, Aug 10, 2013 at 08:45:47PM +0300, Konstantin Belousov wrote: On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote: On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote: On 8/10/2013 11:44 AM, Bryan Drewery wrote: On 8/10/2013 6:24 AM, Joel Dahl wrote: panic: witness_init: pending locks list is too small, increase WITNESS_PENDLIST I also get this. The last stable revision for me was r254150 r254150 stable, r254171 panic. backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg So could you point to exact commit which causes panic ? It is r254167, right ? So I cannot reproduce it locally. The problem is that r254167 moved sleepq initialization before witness is operational, and witness has a backlog of locks initialized before witness init. The backlog overflown. The right fix looks to be just what the panic message told, please try this: diff --git a/sys/kern/subr_witness.c b/sys/kern/subr_witness.c index 3b4d7a2..37e8cf2 100644 --- a/sys/kern/subr_witness.c +++ b/sys/kern/subr_witness.c @@ -135,7 +135,7 @@ __FBSDID($FreeBSD$); #defineWITNESS_COUNT 1024 #defineWITNESS_CHILDCOUNT (WITNESS_COUNT * 4) #defineWITNESS_HASH_SIZE 251 /* Prime, gives load factor 2 */ -#defineWITNESS_PENDLIST768 +#defineWITNESS_PENDLIST1024 /* Allocate 256 KB of stack data space */ #defineWITNESS_LO_DATA_COUNT 2048 If this does not help, try to increse PENDLIST even more. But, sleepq uses 256 elements, which means that my increase should be enough. pgplJa4OJUjKh.pgp Description: PGP signature
Re: nanobsd-built system doesn't have SVN revision in uname (and it looks like regression)
On Sat, Aug 10, 2013 at 02:11:52PM -0400, Glen Barber wrote:
On Sat, Aug 10, 2013 at 01:09:20PM -0500, Dan Mack wrote:
It looks like you are doing the first [! -z '${svnversion}' ]
before $svnversion is being set. In the old version, this was
being set via:
if [ -x /usr/bin/svnliteversion ] ; then
svnversion=/usr/bin/svnliteversion
fi
But I'm not sure if that's intentional or not ...
Ugh. No, this was not intentional. I'll have this fixed shortly.
Fixed in r254184. The problem is that I was evaluating ${svnversion}
being set before looking for /usr/bin/svnliteversion; however when
_running_ /usr/bin/svnliteversion, it was being run as
/usr/bin/svnversion by mistake.
Thank you for the reports, and Dan, thank you for your help.
Glen
pgpB4p2lnx78G.pgp
Description: PGP signature
Re: crash with cpucontrol/microcode update : Today's -CURRENT
On Sat, Aug 10, 2013 at 02:06:10PM -0500, Larry Rosenman wrote: I'm getting the following @R254183: when I try to run the microcode_update. Just started with yesterday's -CURRENT. (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:236 #1 0x8051d6f0 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x8051da77 in panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x80780d9a in trap_fatal (frame=value optimized out, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:873 #4 0x80781199 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:731 #5 0x80780792 in trap (frame=0xff900d55c7b0) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0x8076ad02 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0x80709be9 in vm_page_unwire (m=0x0, activate=0) at /usr/src/sys/vm/vm_page.c:2356 #8 0x806fb4ed in kmem_unback (object=0x80c57550, addr=value optimized out, size=4096) at /usr/src/sys/vm/vm_kern.c:404 #9 0x806fb5a4 in kmem_free (vmem=0x80bd7780, addr=18446741884987129872, size=4096) at /usr/src/sys/vm/vm_kern.c:421 #10 0x80506597 in contigfree (addr=0x0, size=4048, type=0x812d5ea0) at /usr/src/sys/kern/kern_malloc.c:435 #11 0x812d5a79 in cpuctl_ioctl (dev=value optimized out, cmd=value optimized out, data=0xfe000d2a2f80 0?c, flags=value optimized out, td=value optimized out) at /usr/src/sys/modules/cpuctl/../../dev/cpuctl/cpuctl.c:480 #12 0x8041962f in devfs_ioctl_f (fp=0xfe001e68cbe0, com=399396, data=0xfe000d2a2f80, cred=value optimized out, td=0xfe0252ebd490) at /usr/src/sys/fs/devfs/devfs_vnops.c:757 #13 0x8056b3be in kern_ioctl (td=0xfe0252ebd490, fd=value optimized out, com=0) at file.h:306 #14 0x8056b13f in sys_ioctl (td=0xfe0252ebd490, uap=0xff900d55cb80) at /usr/src/sys/kern/sys_generic.c:693 #15 0x80781697 in amd64_syscall (td=0xfe0252ebd490, traced=0) at subr_syscall.c:134 #16 0x8076afeb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 Try this. diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c index 742ef0db..4e5abb2 100644 --- a/sys/dev/cpuctl/cpuctl.c +++ b/sys/dev/cpuctl/cpuctl.c @@ -346,8 +346,7 @@ update_intel(int cpu, cpuctl_update_args_t *args, struct thread *td) else ret = EEXIST; fail: - if (ptr != NULL) - contigfree(ptr, args-size, M_CPUCTL); + free(ptr, M_CPUCTL); return (ret); } @@ -476,8 +475,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct thread *td) else ret = 0; fail: - if (ptr != NULL) - contigfree(ptr, args-size, M_CPUCTL); + free(ptr, M_CPUCTL); return (ret); } pgpTGC3OzzH_B.pgp Description: PGP signature
Re: crash with cpucontrol/microcode update : Today's -CURRENT
On 2013-08-10 15:02, Konstantin Belousov wrote: Try this. diff --git a/sys/dev/cpuctl/cpuctl.c b/sys/dev/cpuctl/cpuctl.c index 742ef0db..4e5abb2 100644 --- a/sys/dev/cpuctl/cpuctl.c +++ b/sys/dev/cpuctl/cpuctl.c @@ -346,8 +346,7 @@ update_intel(int cpu, cpuctl_update_args_t *args, struct thread *td) else ret = EEXIST; fail: - if (ptr != NULL) - contigfree(ptr, args-size, M_CPUCTL); + free(ptr, M_CPUCTL); return (ret); } @@ -476,8 +475,7 @@ update_via(int cpu, cpuctl_update_args_t *args, struct thread *td) else ret = 0; fail: - if (ptr != NULL) - contigfree(ptr, args-size, M_CPUCTL); + free(ptr, M_CPUCTL); return (ret); } Fixed it. # service microcode_update onestart Updating cpucodes... /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl0 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl1 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl2 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl3 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl4 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl5 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl6 from rev 0x60c to rev 0x60f... done. /usr/local/share/cpucontrol/m401067660F.fw: updating cpu /dev/cpuctl7 from rev 0x60c to rev 0x60f... done. Done. # ^D$ -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org US Mail: 108 Turvey Cove, Hutto, TX 78634-5688 ___ 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 boot with fresh current
Konstantin Belousov kostik...@gmail.com writes: The right fix looks to be just what the panic message told, please try this: The patch managed to fix the crash here at least. ___ 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
Entropy harvesting sysctl error messages as of r254181
After updating -CURRENT from a one or two-month old checkout, I get the following messages when /etc/rc.d/initrandom is run: Entropy harvesting:sysctl: unknown oid 'kern.random.sys.harvest.interrupt': No such file or directory interruptssysctl: unknown oid 'kern.random.sys.harvest.ethernet': No such file or directory ethernetsysctl: unknown oid 'kern.random.sys.harvest.point_to_point': No such file or directory point_to_point kickstart Is there something fishy I should look for? kern.random.adaptors is set to rdrandyarrow, and this is an IvyBridge laptop running 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: panic on boot with fresh current
On 8/10/2013 12:45 PM, Konstantin Belousov wrote: On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote: On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote: On 8/10/2013 11:44 AM, Bryan Drewery wrote: On 8/10/2013 6:24 AM, Joel Dahl wrote: panic: witness_init: pending locks list is too small, increase WITNESS_PENDLIST I also get this. The last stable revision for me was r254150 r254150 stable, r254171 panic. backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg So could you point to exact commit which causes panic ? It is r254167, right ? That was my guess based on the stack trace. I will try your patch. -- Regards, Bryan Drewery bdrewery@freenode/EFNet ___ 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 boot with fresh current
Hi, I can reproduce it locally, purely by booting an unchanged amd64 GENERIC. Are you testing it against an _unmodified_ GENERIC, on amd64? If it doesn't panic for you but it does panic for me (and I'll go and get the svn version once I reboot to the old kernel and test) then there may be a hidden problem here that needs solving as this could vary based upon the machine it's happening on. Thanks, -adrian ___ 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 boot with fresh current
On 8/10/2013 1:21 PM, Konstantin Belousov wrote: On Sat, Aug 10, 2013 at 08:45:47PM +0300, Konstantin Belousov wrote: On Sat, Aug 10, 2013 at 08:44:07PM +0300, Konstantin Belousov wrote: On Sat, Aug 10, 2013 at 12:15:35PM -0500, Bryan Drewery wrote: On 8/10/2013 11:44 AM, Bryan Drewery wrote: On 8/10/2013 6:24 AM, Joel Dahl wrote: panic: witness_init: pending locks list is too small, increase WITNESS_PENDLIST I also get this. The last stable revision for me was r254150 r254150 stable, r254171 panic. backtrace: https://dl.dropboxusercontent.com/u/8732004/r254171-panic.jpg So could you point to exact commit which causes panic ? It is r254167, right ? So I cannot reproduce it locally. The problem is that r254167 moved sleepq initialization before witness is operational, and witness has a backlog of locks initialized before witness init. The backlog overflown. The right fix looks to be just what the panic message told, please try this: Yup this patch fixed it, as stated. Thank you for looking at this. -- Regards, Bryan Drewery ___ 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: FYI: Advanced USB compliance testing tool now in the tree (10-current only)
On Fri, Aug 9, 2013 at 1:33 PM, Hans Petter Selasky h...@bitfrost.no wrote: Hi, For those of you that want to make sure your USB mass storage device behaves correctly when using FreeBSD, typically for critical applications, I've just added an advanced USB testing tool to the FreeBSD source tree. It can be used to stress your USB mass storage device in ways that are beyond what bonnie will do. See tools/tools/usbtest or the following commit: http://svnweb.freebsd.org/**changeset/base/254159http://svnweb.freebsd.org/changeset/base/254159 --HPS Looks very nice. While it is now only in head, is there a reason it could not be built and used on a 9.2-BETA system? (I have not tried. Just wondering if I should.) -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.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: CFT: PCI Command Register fixups
On Fri, Aug 09, 2013 at 09:56:48PM -0600, Scott Long wrote: All, Subversion rev 250418 affected approximately 63 drivers by making them vulnerable to resource allocation failures on motherboards with buggy BIOSes. The revision itself is good, but it needs to address these drivers and bring them up to what is, in effect, a modified way for drivers to manage their PCI resources. If you've been seeing something like the following message since June 24/27, then you need this patch: mps0: LSI SAS2116 port 0xd000-0xd0ff mem 0xfb79c000-0xfb79 irq 19 at device 0.0 on pci4 mps0: PCI memory window not available device_attach: mps0 attach returned 6 The patch originated from John Baldwin, I merely fixed up a few nits and am passing it around for review and testing. Please find it here: http://people.freebsd.org/~scottl/pci_command_fixes.patch In mpt_pci.c, there's a style nit/inconsistency regarding the other drivers touched by the above patch; if after these fixes, a driver still fiddles with PCIR_COMMAND, it should be just fine to also OR in PCIM_CMD_BUSMASTEREN as part of that and to not additionally call pci_enable_busmaster(). Apart from that, the patch looks good to me. Marius ___ 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: Light humour
On Sat, Apr 27, 2013 at 6:31 PM, Paul Webster paul.g.webs...@googlemail.com wrote: Just got this link on IRC, (freenode/##freebsd) was so funny I thought I would see if I could get any of you guys to spit out you're coffee :) http://antibsd.wordpress.com/ ___ Sorry I am REALLY late to this party, but wow this site made me laugh :) I straight up choked on my soda.. -- Sam Fourman Jr. ___ 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: Light humour
On Sat, Aug 10, 2013 at 7:07 PM, Sam Fourman Jr. sfour...@gmail.com wrote: On Sat, Apr 27, 2013 at 6:31 PM, Paul Webster paul.g.webs...@googlemail.com wrote: Just got this link on IRC, (freenode/##freebsd) was so funny I thought I would see if I could get any of you guys to spit out you're coffee :) http://antibsd.wordpress.com/ ___ Sorry I am REALLY late to this party, but wow this site made me laugh :) I straight up choked on my soda.. -- Sam Fourman Jr. he changed the link... http://aboutthebsds.wordpress.com/ -- Sam Fourman Jr. ___ 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 - ffs_valloc: dup alloc
Hi All: I am having a major problem on current at the moment, and I could really use some help. I am at R253966 on amd64, my problem is the machine is panicing with: ffs_valloc: dup alloc I have booted into single user mode and run fsck, it reports that it has fixed the file system but I still am getting the panic. I did an svn update to 254204 and tried to buildworld and the machine panics and reboots. If I try startx the machine reboots with no message on the console. Please let me know what info to provide to troubleshoot this. Any help is greatly appreciated. Thanks in advance. ___ 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 - ffs_valloc: dup alloc
On 10 August 2013 19:19, AN a...@neu.net wrote: Hi All: I am having a major problem on current at the moment, and I could really use some help. I am at R253966 on amd64, my problem is the machine is panicing with: ffs_valloc: dup alloc I have booted into single user mode and run fsck, it reports that it has fixed the file system but I still am getting the panic. I did an svn update to 254204 and tried to buildworld and the machine panics and reboots. If I try startx the machine reboots with no message on the console. Please let me know what info to provide to troubleshoot this. Any help is greatly appreciated. Have you run it twice, so it definitely doesn't use the journal? -adrian ___ 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 - ffs_valloc: dup alloc
On Sat, 10 Aug 2013, Adrian Chadd wrote: On 10 August 2013 19:19, AN a...@neu.net wrote: Hi All: I am having a major problem on current at the moment, and I could really use some help. I am at R253966 on amd64, my problem is the machine is panicing with: ffs_valloc: dup alloc I have booted into single user mode and run fsck, it reports that it has fixed the file system but I still am getting the panic. I did an svn update to 254204 and tried to buildworld and the machine panics and reboots. If I try startx the machine reboots with no message on the console. Please let me know what info to provide to troubleshoot this. Any help is greatly appreciated. Have you run it twice, so it definitely doesn't use the journal? -adrian Hi Adrian: Thanks for replying. Yes, I rebooted to single user mode and did a full fsck _without_ using the journal, it found some problems and fixed them. I rebooted and am now rebuilding world. It seems to be working now. If I have any more problems I'll report back. Thanks for the response and info. Cheers! Andy ___ 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
