Re: SUJ problem
On Tue, Jun 22, 2010 at 6:56 AM, Alex Keda ad...@lissyara.su wrote: On 22.06.2010 03:26, Alexander Best wrote: i experienced the same problem running r209391. this might have to do something with a fs being full. i saw these warnings during buildworld when eventuall / ran out of space: Jun 21 21:32:55 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full I have 160Gb disk used as one pat for / Only 16% space used... i see. so it's not an issue with / being full. maybe commit r209408 takes care of the problem. i'll update my sources and see if the problem occurs again. cheers. alex Jun 21 21:32:59 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:00 otaku kernel: pid 76033 (dd), uid 2 inumber 2591139 on /: filesystem full Jun 21 21:33:02 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:07 otaku kernel: pid 75215 (chrome), uid 1001 inumber 18205737 on /: filesystem full Jun 21 21:33:08 otaku kernel: pid 1467 (script), uid 1001 inumber 14226185 on /: filesystem full Jun 21 21:33:08 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:11 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:18 otaku kernel: pid 75215 (chrome), uid 1001 inumber 18205702 on /: filesystem full Jun 21 21:33:28 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661461 on /: filesystem full Jun 21 21:33:39 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661461 on /: filesystem full Jun 21 21:33:47 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:48 otaku kernel: pid 75215 (chrome), uid 1001 inumber 16086093 on /: filesystem full Jun 21 21:33:50 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661461 on /: filesystem full followed by lots of Jun 21 21:35:25 otaku kernel: bad block 7020785329444114652, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -315669439672768816, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -3220207053503867546, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -6419917778393221405, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block 3919397040058727880, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -6888424595660707789, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: g_vfs_done():ufs/rootfs[READ(offset=100240429127958528, length=16384)]error = 5 Jun 21 21:35:25 otaku kernel: bad block -1173790944229704887, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block 5537349803492323867, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block 882554538064816358, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -2565060229441336925, ino 7468267 ~ 2 minutes later (see timestamp). i then did a `find / -inum 7468267` but couldn't find the file. i then did a clean reboot using `shutdown -r now`. the buffers got synched down to 0 however it said something like / cannot be unmounted filesystem busy. i then was thrown into single user mode due to the same problem alex kada reported. at some point i did a `mount -f /` and did `dmesg -a /FEHLER`. strange thing is that everything seems to have been piped to that file twice. after that i did `fastboot` and freebsd came up with / being clean (although the last fsck report said / was marked dirty). i've attached the file. cheers. -- Alexander Best ___ 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
Timer panic on boot (r209434)
Howdy, I tried upgrading from r209351 to r209434 and got a panic related to the timer stuff while booting. You can see the panic and the backtrace here: http://people.freebsd.org/~dougb/timer-panic-1.jpg http://people.freebsd.org/~dougb/timer-panic-2.jpg http://people.freebsd.org/~dougb/timer-panic-3.jpg hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: Timer panic on boot (r209434)
On 06/22/10 12:55, Doug Barton wrote: Howdy, I tried upgrading from r209351 to r209434 and got a panic related to the timer stuff while booting. You can see the panic and the backtrace here: http://people.freebsd.org/~dougb/timer-panic-1.jpg http://people.freebsd.org/~dougb/timer-panic-2.jpg http://people.freebsd.org/~dougb/timer-panic-3.jpg Hmmm, that could use a little more detail. :) I have a Dell laptop with a core 2 duo processor, running 9-current SMP i386. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: building world with debugging symbols [broken?]
On Wednesday 31 March 2010 14:52:53 Giorgos Keramidas wrote: On Tue, 30 Mar 2010 15:10:58 -0400, John Baldwin j...@freebsd.org wrote: On Tuesday 30 March 2010 11:48:58 am Giorgos Keramidas wrote: +.It Va DEBUG_FLAGS +Defines a set of debugging flags that will be used to build all userland +binaries under +.Pa /usr/src . +When +.Va DEBUG_FLAGS +is defined, the +.Cm install +and +.Cm installworld +targets install binaries from the current +.Va MAKEOBJDIRPREFIX +without stripping too, so that debugging information is retained in the +installed binaries. I would drop the too and start 'so' on a new line (at least that is my interpretation of the line-break rules we use for mdoc). Other than that I think this looks fine. Fixed and committed in r205978. Thanks :) Hi, I've gotten several reports that cuse4bsd and other kernel modules built outside the kernel tree no longer load. Any clues about what is wrong? Is this a compiler issue, or has it got to do with missing/wrong symbols? For example one guy writes: On Tue, 22 Jun 2010 19:11:09 +0200 Hans Petter Selasky hsela...@freebsd.org wrote: On Tuesday 22 June 2010 18:06:58 Ted Faber wrote: FWIW, I'm seeing the same thing on 8.1-PRERELEASE csupped from yesterday. It's been going on foe a while, but I haven't been able to find the bug. (I was literally sitting down to type an e-mail about it when I saw this thread.) Same symptom: cuse4bsd loads but no device file appears in the /dev I also don't see the printfs from cuse_kern_init show up in the log. It seems like something's changed in the kernel module load path somehow. FWIW, the example in /usr/share/examples/kld/cdev/ doesn't work for me either. I've attached the verbose boot. Cuse4bsd is current from ports, recompiled after the new kernel install: $ pkg_info | grep cuse cuse4bsd-kmod-0.1.11 Cuse4BSD character device loopback driver for userspace Here's my loader.conf: $ cat /boot/loader.conf beastie_disable=YES acpi_ibm_load=YES snd_ich_load=YES cuse4bsd_load=YES The module is in the right place and seems to load: $ ls -l /boot/modules/ total 18 -r-xr-xr-x 1 root wheel 16505 Jun 21 19:02 cuse4bsd.ko $ kldstat Id Refs AddressSize Name 1 36 0xc040 bb8ea8 kernel 21 0xc0fb9000 7224 snd_ich.ko 32 0xc0fc1000 577a4sound.ko 41 0xc1019000 5244 acpi_ibm.ko 51 0xc101f000 4610 cuse4bsd.ko 61 0xc59c9000 8000 linprocfs.ko 71 0xc5a1d000 26000linux.ko 81 0xc5b07000 11000ipfw.ko 91 0xc5b18000 d000 libalias.ko 101 0xc5e2e000 2000 green_saver.ko 111 0xc5f0d000 68000radeon.ko 121 0xc5f84000 14000drm.ko $ uname -a FreeBSD praxis.lunabase.org 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #38: Mon Jun 21 17:14:31 PDT 2010 r...@praxis.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386 I'm happy to try fixes or provide information. Are you sure the kernel sources are matched with your kernel. I find this rather odd. laptop# svn info Path: . URL: svn://svn.freebsd.by/base/head Repository Root: svn://svn.freebsd.by/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 209412 Node Kind: directory Schedule: normal Last Changed Author: delphij Last Changed Rev: 209408 Last Changed Date: 2010-06-22 03:26:07 +0300 (Tue, 22 Jun 2010) svn.freebsd.by - nearest svn mirror for me. [usern...@svn]~%crontab -l|grep svn 0 */2 * * * /usr/local/bin/svnsync sync file:///usr/local/repositories/freebsd/base/ %uname -a FreeBSD laptop.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #7 r209412M: Tue Jun 22 11:23:15 EEST 2010 r...@laptop.domain:/usr/obj/usr/src/sys/b450 i386 laptop# pwd /usr/src laptop# svn st laptop# The Cuse4BSD printout is called from a SYSINIT. If sysinits don't work then something fundamental is wrong. Also check: find /boot -name cuse4bsd* laptop# find /boot -name 'cuse*' /boot/modules/cuse4bsd.ko laptop# printf(Cuse4BSD v%d.%d.%d @ /dev/cuse\n, (CUSE_VERSION 16) 0xFF, (CUSE_VERSION 8) 0xFF, (CUSE_VERSION 0) 0xFF); } SYSINIT(cuse_kern_init, SI_SUB_DEVFS, SI_ORDER_ANY, cuse_kern_init, 0); --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: Timer panic on boot (r209434)
Doug Barton wrote:
On 06/22/10 12:55, Doug Barton wrote:
Howdy,
I tried upgrading from r209351 to r209434 and got a panic related to the
timer stuff while booting. You can see the panic and the backtrace here:
http://people.freebsd.org/~dougb/timer-panic-1.jpg
http://people.freebsd.org/~dougb/timer-panic-2.jpg
http://people.freebsd.org/~dougb/timer-panic-3.jpg
Hmmm, that could use a little more detail. :) I have a Dell laptop with
a core 2 duo processor, running 9-current SMP i386.
Your ACPI seems reports that attimer uses IRQ2, instead of usual IRQ0.
It is either a bug, or it is a very rare feature.
I am not sure it is not a hack, but you may try attached patch. If it
helps, it would be nice it you tried to use i8254 event timer, to check
is this a bug or feature.
--
Alexander Motin
diff -ruNp sys/isa.prev/atrtc.c sys/isa/atrtc.c
--- sys/isa.prev/atrtc.c2010-06-22 23:01:13.0 +0300
+++ sys/isa/atrtc.c 2010-06-22 23:01:38.0 +0300
@@ -259,6 +259,7 @@ atrtc_attach(device_t dev)
if (!atrtcclock_disable
(resource_int_value(device_get_name(dev), device_get_unit(dev),
clock, i) != 0 || i != 0)) {
+ sc-intr_rid = -1;
if (!(sc-intr_res = bus_alloc_resource(dev, SYS_RES_IRQ,
sc-intr_rid, 8, 8, 1, RF_ACTIVE))) {
device_printf(dev,Can't map interrupt.\n);
diff -ruNp sys/isa.prev/clock.c sys/isa/clock.c
--- sys/isa.prev/clock.c2010-06-22 20:19:00.0 +0300
+++ sys/isa/clock.c 2010-06-22 23:01:27.0 +0300
@@ -535,6 +535,7 @@ attimer_attach(device_t dev)
tc_init(sc-tc);
if (resource_int_value(device_get_name(dev), device_get_unit(dev),
clock, i) != 0 || i != 0) {
+ sc-intr_rid = -1;
if (!(sc-intr_res = bus_alloc_resource(dev, SYS_RES_IRQ,
sc-intr_rid, 0, 0, 1, RF_ACTIVE))) {
device_printf(dev,Can't map interrupt.\n);
___
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: building world with debugging symbols [broken?]
I saw similar behaviour a couple of years ago when I switched from using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. The problem ended up being a change in the linker script used by GNU ld for linking kernel modules. It used to always put some magic symbols used by the linker to implement things like sysinits into the module. It was changed to only provide those symbols, which apparently means that the linker would discard those symbols if nothing referenced them(and nothing did reference them). I had to work around it by adding the following to my link line: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set ___ 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: Timer panic on boot (r209434)
On 06/22/10 13:10, Alexander Motin wrote: Doug Barton wrote: On 06/22/10 12:55, Doug Barton wrote: Howdy, I tried upgrading from r209351 to r209434 and got a panic related to the timer stuff while booting. You can see the panic and the backtrace here: http://people.freebsd.org/~dougb/timer-panic-1.jpg http://people.freebsd.org/~dougb/timer-panic-2.jpg http://people.freebsd.org/~dougb/timer-panic-3.jpg Hmmm, that could use a little more detail. :) I have a Dell laptop with a core 2 duo processor, running 9-current SMP i386. Your ACPI seems reports that attimer uses IRQ2, instead of usual IRQ0. It is either a bug, or it is a very rare feature. I am not sure it is not a hack, but you may try attached patch. Ok, I updated to r209441, then applied your patch. FYI, I applied it in src/sys/x86/isa/ using -p2. This allowed me to boot, verbose dmesg is at http://people.freebsd.org/~dougb/dmesg-verbose-norid-patch.txt If it helps, it would be nice it you tried to use i8254 event timer, to check is this a bug or feature. Ok, I'm willing to give that a try if you tell me how. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: building world with debugging symbols [broken?]
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: I saw similar behaviour a couple of years ago when I switched from using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. The problem ended up being a change in the linker script used by GNU ld for linking kernel modules. It used to always put some magic symbols used by the linker to implement things like sysinits into the module. It was changed to only provide those symbols, which apparently means that the linker would discard those symbols if nothing referenced them(and nothing did reference them). I had to work around it by adding the following to my link line: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set HPS: I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Here's a diff relative to /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so it's clear what I did. --- Makefile.kmod.orig 2010-02-11 03:28:02.0 -0800 +++ Makefile.kmod 2010-06-22 14:02:52.0 -0700 @@ -30,4 +30,10 @@ KMOD= cuse4bsd SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set + + .include bsd.kmod.mk Running nm -o on the two modules, the difference seems to be that the -u results in some additional absolute symbols being defined: Bad module: $ nm -o /boot/modules/cuse4bsd.ko| grep sys /boot/modules/cuse4bsd.ko:275c r __set_sysinit_set_sym_cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:2758 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit /boot/modules/cuse4bsd.ko:3194 d cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit Good module: $ nm -o ./cuse4bsd.ko | grep sys ./cuse4bsd.ko:28cc r __set_sysinit_set_sym_cuse_kern_init_sys_init ./cuse4bsd.ko:28c8 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit ./cuse4bsd.ko: U __start_set_sysctl_set ./cuse4bsd.ko:28cc A __start_set_sysinit_set ./cuse4bsd.ko:28c8 A __start_set_sysuninit_set ./cuse4bsd.ko: U __stop_set_sysctl_set ./cuse4bsd.ko:28d0 A __stop_set_sysinit_set ./cuse4bsd.ko:28cc A __stop_set_sysuninit_set ./cuse4bsd.ko:3194 d cuse_kern_init_sys_init ./cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpQWyNSjmQCd.pgp Description: PGP signature
Re: Timer panic on boot (r209434)
Doug Barton wrote: On 06/22/10 13:10, Alexander Motin wrote: Doug Barton wrote: On 06/22/10 12:55, Doug Barton wrote: Howdy, I tried upgrading from r209351 to r209434 and got a panic related to the timer stuff while booting. You can see the panic and the backtrace here: http://people.freebsd.org/~dougb/timer-panic-1.jpg http://people.freebsd.org/~dougb/timer-panic-2.jpg http://people.freebsd.org/~dougb/timer-panic-3.jpg Hmmm, that could use a little more detail. :) I have a Dell laptop with a core 2 duo processor, running 9-current SMP i386. Your ACPI seems reports that attimer uses IRQ2, instead of usual IRQ0. It is either a bug, or it is a very rare feature. I am not sure it is not a hack, but you may try attached patch. Ok, I updated to r209441, then applied your patch. FYI, I applied it in src/sys/x86/isa/ using -p2. This allowed me to boot, verbose dmesg is at http://people.freebsd.org/~dougb/dmesg-verbose-norid-patch.txt If it helps, it would be nice it you tried to use i8254 event timer, to check is this a bug or feature. Ok, I'm willing to give that a try if you tell me how. :) Run `sysctl kern.eventtimer.timer2=i8254`, then after few seconds check messages to see if system liked this timer (it should fall back automatically if it's not), then check 'vmstat -ia' to see whether irq0 interrupts are arriving, then run 'systat -vm 1' to be absolutely sure. If `vmstat -ia` won't show irq0 interrupts, try to figure out what else can arrive instead of it. -- 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: Timer panic on boot (r209434)
On 06/22/10 14:17, Alexander Motin wrote: Run `sysctl kern.eventtimer.timer2=i8254`, then after few seconds check messages to see if system liked this timer (it should fall back automatically if it's not), Seems ok. Here is what I got on the console, no error messages in /var/log/all. sysctl kern.eventtimer.timer2=i8254 kern.eventtimer.timer2: HPET1Starting kernel event timers: HPET @ 100Hz, i8254 @ 128Hz - i8254 t_delta 16.01a20d312197c8b0 too long then check 'vmstat -ia' to see whether irq0 interrupts are arriving, This also seems fine: interrupt total rate ???0 0 irq1: atkbd03448 1 stray irq1 0 0 irq0: attimer0 15756 6 stray irq0 0 0 irq3: 0 0 stray irq3 0 0 The total for irq0 is going up consistently. then run 'systat -vm 1' to be absolutely sure. That also seemed fine. Here is a sample: 104 hpet0 uhci If I did nothing but stare at the screen the value was fairly consistently 100, with occasional values of 99 or 107. Once I started moving the mouse it jumped around a little, but stabilized again when I left the mouse alone. Should I continue using the HPET timer? Is it better in some way? Anything else I can do to help? Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: Timer panic on boot (r209434)
Doug Barton wrote: On 06/22/10 14:17, Alexander Motin wrote: Run `sysctl kern.eventtimer.timer2=i8254`, then after few seconds check messages to see if system liked this timer (it should fall back automatically if it's not), Seems ok. Here is what I got on the console, no error messages in /var/log/all. sysctl kern.eventtimer.timer2=i8254 kern.eventtimer.timer2: HPET1Starting kernel event timers: HPET @ 100Hz, i8254 @ 128Hz - i8254 t_delta 16.01a20d312197c8b0 too long then check 'vmstat -ia' to see whether irq0 interrupts are arriving, This also seems fine: interrupt total rate ???0 0 irq1: atkbd03448 1 stray irq1 0 0 irq0: attimer0 15756 6 stray irq0 0 0 irq3: 0 0 stray irq3 0 0 The total for irq0 is going up consistently. OK, thanks. It means that your ACPI is lying for some reason. I'll probably commit this patch tomorrow. Should I continue using the HPET timer? As you wish. Is it better in some way? Comparing to what? Comparing to LAPIC - it is not dying in C3. Comparing to RTC - if is faster and much more flexible. Comparing to i8254 - it can work per-CPU and supports one-shot mode, both not very important now, but should benefit later. Anything else I can do to help? Find any more issues to fix. :) As you have latest HEAD, you may try my latest addition (r209440) - HPET legacy route support. It should allow HPET to work per-CPU on your hardware. To enable it, add such lines to /boot/loader.conf: hint.atrtc.0.clock=0 hint.attimer.0.clock=0 hint.hpet.0.legacy_route=1 -- 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
CFT: ZFS v15 patch
Dear developers, I would like to do a call for testing for my ZFS v15 patch. As the user/group quotas feature is too much attractive for my needs, I couldn't resist and have created (and debugged + tested) a ZFS v15 patch for head (applies cleanly against stable/8 as well). It is a backport of several onnv-revisions, always consulting pjd's p4 tree and includes four post-9396 related user/groupquota bugfixes. The bootcode (zfsimpl.h) is properly updated to support v15 as well, the python part is modified (paths, smb support, ioctls). The patch, list of imported revisions and a preliminary but working version of the pyzfs port can be downloaded from this link: http://people.freebsd.org/~mm/patches/zfs/v15/ You can download 8.1-RC1-amd64 with zfsv15 (incl. boot support) mfsBSD ISOs from here: http://mfsbsd.vx.sk/iso/8.1rc1-zfsv15.iso (without symbols, 98.7M) http://mfsbsd.vx.sk/iso/8.1rc1-zfsv15-debug.iso (with symbols, 187.5M) Login/password into the ISOs: root/mfsroot run zfsinstall for a zfs-on-root installation (don't forget -V 15 if trying to install) The amd64 ISO's may be tested in virtualbox or real-world systems as well. Regarding new ioctl's: I have added all new ioctl's in the patch as new ones (numbers 49 to 52). This makes the old kernel module work with new library / utilities (tested) or any other binary that references these ioctl's. Regarding the python port: The current port installs the library into PYTHON_SITELIBDIR and pyzfs.py into /usr/lib/zfs/ Later, we may install all necessary sources and pyzfs.py and the port may be a full-dummy that doesn't need kernel/world sources. Version 15 introduces user and group quota accounting and could be a very good step in preparation towards v26. The code runs impressingly stable (I didn't manage to reproduce any panics or deadlocks yet after polishing). It would be very great if this could get widely tested. I guess we could go with this code in direction stable/8 (head first), because it is backwards compatible (zfs and zpool work with older kernel module - only new features don't work, the same for the boot changes, boot from older pools is supported). Any ideas, suggetions, and bug reports are welcome! Cheers, mm ___ 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 during boot on 8.0-RELEASE
Hey all, Screenshot of panic message is attached. Machine is a VM running under Parallels Server Bare Metal 4. The cdrom device was enabled but not connected during boot. System was attempting to boot into single user mode. This occurred after a fresh install of 8.0-RELEASE. Let me know how I can provide more useful info. Thanks, Nick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
Hi, I'm creating a new thread on this issue. On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote: I saw similar behaviour a couple of years ago when I switched from using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules. The problem ended up being a change in the linker script used by GNU ld for linking kernel modules. It used to always put some magic symbols used by the linker to implement things like sysinits into the module. It was changed to only provide those symbols, which apparently means that the linker would discard those symbols if nothing referenced them(and nothing did reference them). I had to work around it by adding the following to my link line: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set It appears many kmods are broken because the linker is stripping away static data declared with the section attribute in FreeBSD 8.1-RC1. cite I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Here's a diff relative to /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so it's clear what I did. --- Makefile.kmod.orig 2010-02-11 03:28:02.0 -0800 +++ Makefile.kmod 2010-06-22 14:02:52.0 -0700 @@ -30,4 +30,10 @@ KMOD= cuse4bsd SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ + -u __start_set_sysctl_set -u __start_set_modmetadata_set \ + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set + + .include bsd.kmod.mk Running nm -o on the two modules, the difference seems to be that the -u results in some additional absolute symbols being defined: Bad module: $ nm -o /boot/modules/cuse4bsd.ko| grep sys /boot/modules/cuse4bsd.ko:275c r __set_sysinit_set_sym_cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:2758 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit /boot/modules/cuse4bsd.ko:3194 d cuse_kern_init_sys_init /boot/modules/cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit Good module: $ nm -o ./cuse4bsd.ko | grep sys ./cuse4bsd.ko:28cc r __set_sysinit_set_sym_cuse_kern_init_sys_init ./cuse4bsd.ko:28c8 r __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit ./cuse4bsd.ko: U __start_set_sysctl_set ./cuse4bsd.ko:28cc A __start_set_sysinit_set ./cuse4bsd.ko:28c8 A __start_set_sysuninit_set ./cuse4bsd.ko: U __stop_set_sysctl_set ./cuse4bsd.ko:28d0 A __stop_set_sysinit_set ./cuse4bsd.ko:28cc A __stop_set_sysuninit_set ./cuse4bsd.ko:3194 d cuse_kern_init_sys_init ./cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit /cite --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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wed, Jun 23, 2010 at 02:38:06AM +0200, Hans Petter Selasky wrote: It appears many kmods are broken because the linker is stripping away static data declared with the section attribute in FreeBSD 8.1-RC1. cite I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port made the module and the result loads and creates the /dev/cuse file. Hi. I'm the fellow in Hans's cite.../cite. If someone's looking into this, it's worth mentioning that the sample cdev kmodule in /usr/share/examples/kld/cdev/ also exhibits the behavior. On my 8.1-PRERELEASE system that module does not create the /dev/cedv device, but if you add the line LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set right before the .include bsd.kmod.mk in /usr/share/examples/kld/cdev/module/Makefile and remake everything, the module creates the /dev/cdev file when it's loaded. That magical line was suggested by Ryan Stone in another thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=120718+0+current/freebsd-hackers Happy hunting, and I'm happy to test patches or provide more information. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgploXUNQKXc1.pgp Description: PGP signature
