Re: radeon_cp_texture: page fault with non-sleepable locks held
on 08/11/2010 14:04 Kostik Belousov said the following: On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: on 05/11/2010 09:27 Andriy Gapon said the following: I use FreeSBD head and KDE 4 with all the bells and whistles enabled. Apparently recent KDE update has enabled even more of them, because I started to have panics with a kernel that has INVARIANTS and WITNESS enabled. I tried to solve the problem by changing drmdev from mutex to sx: http://people.freebsd.org/~avg/drm-sx.diff I remember that drm lock can be acquired from the interrupt thread, if the card supports interrupts. Changing it to sx cannot work then, because interrupt threads cannot sleep. Most likely, you are getting around it since r600 not yet used interrupts on FreeBSD. I think the solution is to drop drm lock around copyin. Kostik, I looked at this some more and now I think that using sx is a step in the right direction. Rationale: 1. it seems that on Linux mutex is a sleepable lock and thus can be safely held across a page fault; and Linux mutex - FreeBSD sx seems to be a porting technique used for kernel code before[*]. 2. DRM interrupt code uses a different lock - irq_lock, which is locked via DRM_SPINLOCK macro (expands to FreeBSD mutex); apparently even on Linux a sleep-able lock can't be acquired in interrupt handler. I use Linux this and Linux that as a justification, because the DRM code apparently originated with Linux model/idioms in mind, although the original purpose was for the code to be portable. So, what do you think about this aspect? Should you agree with the usage of sx, then the previous question pops back - how to resolve the lock order reversal between drmdev lock and user map lock (which both would be sx). [*] http://www.ukuug.org/events/eurobsdcon2009/papers/dvb_driver_paper.pdf -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Error: stack overflow on boot
On 08/11/10 06:37 PM, Etienne Robillard wrote: Hi, why is this message happening with 8.1 and sometimes CURRENT ? I tried recompiling the bootloader but the error still happens, forcing user to hit Enter to enter manual boot. Any takes ? :) Many thanks, Etienne ___ 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 forgot telling this is happening on amd64 architecture! I don't think its happens on i386 machines types! -- Etienne Robillard Company: Green Tea Hackers Club Occupation: Software Developer E-mail: e...@gthcfoundation.org Work phone: +1 514-962-7703 Website (Company): https://www.gthc.org/ Website (Blog): https://www.gthc.org/blog/ PGP public key fingerprint:F2A9 32EA 8E7C 460F 1728 A1A7 649C 7F17 A086 DDEC During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell ___ 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: Syscons and termcap
Hello Eir, * Eir Nym eir...@gmail.com, 20101109 05:10: I've compiled -CURRENT kernel with UTF-8 and CONS25 support. ( r214751 ) in xterm emulation mode I have problems with bindings for some keys, such as Home If I start vis(1) and press Home, I always get ^[[H sequence instead of ^[OH which is defined in termcap (5) file. I get correct results after switching to cons25. What do I wrong ? Does sc(4) driver in current correctly support xterm-like key bindings? Yes, but not only must you set TERM=xterm, you must also remove TEKEN_CONS25 from your kernel configuration or run vidcontrol -T xterm on that specific window. There is almost no reason why anyone would want to use the TEKEN_CONS25 option. Depending on whether the terminal is switched to cursor keys mode, it will return ^[[H or ^[OH. See /sys/teken/teken.c, teken_get_sequence(). Greetings, -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpphkXc4hfeS.pgp Description: PGP signature
kldunload(8) returns 0, although it fail
hi there,
i posted this message on freebsd-questions@, but nobody could help me with it.
to me this looks like a bug, so i assume posting it again here on
freebsd-current@ might be better.
please keep in mind that the issue here is not the fact that the second attempt
to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules
have dependencies. however it should fail with the first attempt. right now
kldunloadf() returns zero, whereas it should actually return EBUSY (just like
the second attempt).
i've attached two kdump outputs: one for the first 'kldunload' attempt and one
for the second. as you can see the problem is that for some reason kldunloadf()
returns zero, although it couldn't unload the module.
cheers.
alex
- Forwarded message from Alexander Best arun...@freebsd.org -
Date: Fri, 5 Nov 2010 01:15:24 +
From: Alexander Best arun...@freebsd.org
To: freebsd-questi...@freebsd.org
Subject: Re: kldunload(8) returns 0, although it fail
On Wed Nov 3 10, Alexander Best wrote:
hi there,
is this a known issue with kldunload(8)?
this is also very interesting:
***beginn***
otaku% kldstat -v|grep netgraph
73 0x80bfa000 15e68netgraph.ko (/boot/kernel/netgraph.ko)
6 netgraph
otaku% sudo kldunload netgraph
otaku% echo $?
0
otaku% kldstat -v|grep netgraph
72 0x80bfa000 15e68netgraph.ko (/boot/kernel/netgraph.ko)
6 netgraph
otaku%
***end***
there seems to be a logical error in the ref counting code.
cheers.
alex
***beginn***
otaku% kldunload sound
otaku% echo $?
0
otaku% kldstat
Id Refs AddressSize Name
1 35 0x8010 a2da40 kernel
21 0x80b2e000 295e8snd_hda.ko
31 0x80b58000 85110sound.ko
41 0x80bde000 da4bb8 nvidia.ko
54 0x81983000 418e0linux.ko
61 0x819c5000 80e8 ng_ubt.ko
72 0x819ce000 fa78 ng_hci.ko
82 0x819de000 2bd0 ng_bluetooth.ko
93 0x819e1000 15e68netgraph.ko
101 0x81c12000 3edb linprocfs.ko
113 0x81c16000 4698 pseudofs.ko
121 0x81c1b000 31b3 procfs.ko
131 0x81c1f000 a37 linsysfs.ko
otaku% kldunload sound
kldunload: attempt to unload file that was loaded by the kernel
kldunload: can't unload file: Device busy
otaku% echo $?
1
otaku%
***end***
cheers.
alex
--
a13x
--
a13x
- End forwarded message -
--
a13x
1765 ktrace RET ktrace 0
1765 ktrace CALL execve(0x7fffe580,0x7fffeb00,0x7fffeb18)
1765 ktrace NAMI /sbin/kldunload
1765 ktrace NAMI /libexec/ld-elf.so.1
1765 kldunload RET execve 0
1765 kldunload CALL
mmap(0,0x8000,0x3PROT_READ|PROT_WRITE,0x1002MAP_PRIVATE|MAP_ANON,0x,0)
1765 kldunload RET mmap 34365239296/0x80053f000
1765 kldunload CALL issetugid
1765 kldunload RET issetugid 0
1765 kldunload CALL open(0x80053a8b2,0O_RDONLY,unused0x1b6)
1765 kldunload NAMI /etc/libmap.conf
1765 kldunload RET open 3
1765 kldunload CALL fstat(0x3,0x7fffdc10)
1765 kldunload STRU struct stat {dev=98, ino=5841236, mode=-rw-r--r-- ,
nlink=1, uid=0, gid=0, rdev=23396840, atime=1289300105, stime=1285331572,
ctime=1285331572, birthtime=1268953179, size=235, blksize=16384, blocks=4,
flags=0x0 }
1765 kldunload RET fstat 0
1765 kldunload CALL read(0x3,0x800542000,0x4000)
1765 kldunload GIO fd 3 read 235 bytes
#libgcc_s.so.1 gcc46/libgcc_s.so.1
#libgomp.so.1 gcc46/libgomp.so.1
#libssp.so.0gcc46/libssp.so.0
#libstdc++.so.6 gcc46/libstdc++.so.6
#libz.so.5 libz.so.6
#libmd.so.5 libmd.so.1.0
#libmd.so.5 libcrypto.so
#libmd.so.5 libmd-test.so.5
1765 kldunload RET read 235/0xeb
1765 kldunload CALL read(0x3,0x800542000,0x4000)
1765 kldunload GIO fd 3 read 0 bytes
1765 kldunload RET read 0
1765 kldunload CALL close(0x3)
1765 kldunload RET close 0
1765 kldunload CALL open(0x800539a49,0O_RDONLY,unused0x2f)
1765 kldunload NAMI /var/run/ld-elf.so.hints
1765 kldunload RET open 3
1765 kldunload CALL read(0x3,0x7fffe220,0x80)
1765 kldunload GIO fd 3 read 128 bytes
0x 4568 6e74 0100 8000 db00 da00
|Ehnt|
0x0048
||
1765 kldunload RET read 128/0x80
1765 kldunload CALL
mmap(0,0x9000,0x3PROT_READ|PROT_WRITE,0x1002MAP_PRIVATE|MAP_ANON,0x,0)
Re: kldunload(8) returns 0, although it fail
On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: hi there, i posted this message on freebsd-questions@, but nobody could help me with it. to me this looks like a bug, so i assume posting it again here on freebsd-current@ might be better. please keep in mind that the issue here is not the fact that the second attempt to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules have dependencies. however it should fail with the first attempt. right now kldunloadf() returns zero, whereas it should actually return EBUSY (just like the second attempt). i've attached two kdump outputs: one for the first 'kldunload' attempt and one for the second. as you can see the problem is that for some reason kldunloadf() returns zero, although it couldn't unload the module. Did you get an error message in dmesg? If you have manually loaded netgraph.ko (via netgraph_load=YES in loader.conf or an explicit kldload) and then loaded other modules that depend on it (such as ng_foo.ko) then this is expected behavior. What your kldunload has done is to remove the manual reference from loader.conf or 'kldload netgraph.ko'. What this changes is what happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then netgraph.ko will also be unloaded when its last reference drops (in this case it looks like you actually have two ng_*.ko objects loaded, so you would have to unload both of them, but I will assume a single ng_foo.ko to make the explanation simpler). If you had not done 'kldunload netgraph.ko' but had done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko loaded. All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Only display ACPI bootmenu key if ACPI is present
On Tue, Nov 09, 2010 at 03:45:52PM +0200, Andriy Gapon wrote: on 09/11/2010 07:26 Lars Engels said the following: Maybe we should also import PCBSD's patches to the beastie menu? In PCBSD's beastie menu you can toggle some settings like safe mode, and ACPI, so the kernel is not loaded as soon as select an option. See http://trac.pcbsd.org/browser/pcbsd/current/system-overlay/boot/beastie.4th Lars, not sure if I got your suggestion correctly, this is what I have in my local tree: diff --git a/sys/boot/i386/loader/loader.rc b/sys/boot/i386/loader/loader.rc index 6443f3f..cb2f723 100644 --- a/sys/boot/i386/loader/loader.rc +++ b/sys/boot/i386/loader/loader.rc @@ -5,7 +5,7 @@ include /boot/loader.4th \ Reads and processes loader.conf variables -start +initialize \ Tests for password -- executes autoboot first if a password was defined check-password With this kernel and modules are _not_ loaded before presenting the menu. That's also an appreciated improvement, but what PCBSD does is that you can toggle several options, so when you select an option, the kernel is not loaded immediately after but you are still in the menu and can select / toggle another option. That way you have a multi-selection, e.g. select safe mode but enable acpi. Maybe we could also add a menu entry to boot without any modules, so loaders.conf gets overridden? pgpNyR4N1wYaD.pgp Description: PGP signature
Re: kldunload(8) returns 0, although it fail
On Tue Nov 9 10, John Baldwin wrote: On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: hi there, i posted this message on freebsd-questions@, but nobody could help me with it. to me this looks like a bug, so i assume posting it again here on freebsd-current@ might be better. please keep in mind that the issue here is not the fact that the second attempt to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules have dependencies. however it should fail with the first attempt. right now kldunloadf() returns zero, whereas it should actually return EBUSY (just like the second attempt). i've attached two kdump outputs: one for the first 'kldunload' attempt and one for the second. as you can see the problem is that for some reason kldunloadf() returns zero, although it couldn't unload the module. Did you get an error message in dmesg? If you have manually loaded netgraph.ko (via netgraph_load=YES in loader.conf or an explicit kldload) and then loaded other modules that depend on it (such as ng_foo.ko) then this is expected behavior. What your kldunload has done is to remove the manual reference from loader.conf or 'kldload netgraph.ko'. What this changes is what happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then netgraph.ko will also be unloaded when its last reference drops (in this case it looks like you actually have two ng_*.ko objects loaded, so you would have to unload both of them, but I will assume a single ng_foo.ko to make the explanation simpler). If you had not done 'kldunload netgraph.ko' but had done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko loaded. All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. i have ng_ubt_load=YES in my loader.conf and kldstat says: Id Refs AddressSize Name 1 37 0x8010 a2ddb8 kernel 21 0x80b2e000 295e8snd_hda.ko 31 0x80b58000 85110sound.ko 41 0x80bde000 cf79e0 nvidia.ko 55 0x818d6000 418c0linux.ko 61 0x81918000 80e8 ng_ubt.ko 72 0x81921000 fa78 ng_hci.ko 82 0x81931000 2bd0 ng_bluetooth.ko 93 0x81934000 15e68netgraph.ko 101 0x81a12000 3efb linprocfs.ko 113 0x81a16000 4698 pseudofs.ko 121 0x81a1b000 31b3 procfs.ko 131 0x81a1f000 a37 linsysfs.ko 141 0x81a2 6f4 rtc.ko also the same happens with sound.ko. i have snd_hda_load=yes. and i think snd_hda is the only dependecy for sound.ko. there was no error message in dmesg for the first kldunload attempt. i think i understand the logic, however the current behavior does not confirm to the description in kldunload(2). cheers. alex -- John Baldwin -- a13x ___ 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: minidump size on amd64
Andriy Gapon wrote:
So, here is the next version of the patch:
http://people.freebsd.org/~avg/amd64-minidump.4.diff
Changes since the last version:
1. libkvm - try to support both the new and the previous formats/versions of
amd64 minidump. I am not entirely sure about style in which I handled handling
of version 1 minidump. Identifier names like pmapsize (for page map size) and
page_map could also be improved, perhaps.
2. kernel - implemented dumping of 1GB pages via fake 512 x 2MB pages per
Alan's suggestion.
The change is only compile tested so far. Not sure if it's possible to test
handling 1GB pages yet :-)
As always, reviews, testing and suggestions are very welcome.
The kernel portion of the patch looks correct. If I were to make one
stylistic suggestion, it would be to make the control flow of the outer
and inner loops as similar as possible, that is,
for (...
if ((pdp[i] PG_V) == 0) {
...
continue;
}
if ((pdp[i] PG_PS) != 0) {
...
continue;
}
for (...
if ((pd[j] PG_V) == 0)
continue;
if ((pd[j] PG_PS) != 0) {
...
continue;
}
for (...
if ((pt[x] PG_V) == 0)
continue;
...
I think this would make the code a little easier to follow.
Alan
___
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: laptop Acer Aspire One D250 / snd_hda(4) internal mic not recording
El día Friday, November 05, 2010 a las 01:13:15AM +0200, Alexander Motin escribió: Matthias Apitz wrote: El día Friday, November 05, 2010 a las 12:46:50AM +0200, Alexander Motin escribió: Matthias Apitz wrote: mixer(1) let me set for recoding only 'mic' or 'rec'. I'm attaching as well the output of verbose messages grep'ed for pcm and hdac. Your CODEC configured to provide built-in microphone on separate device pcm1. You may record from there (Skype allows to choose device) or reconfigure CODEC using hints. In Skype in let me choose between /dev/dsp /dev/dsp0 /dev/dsp1 When I set mic to /dev/dsp0 it records from the jack (headphone mic), when I set it to /dev/dsp1 there is no recording. And the mixer for the pcm1 says: # mixer -f /dev/mixer1 Mixer rec is currently set to 100:100 Mixer monitor is currently set to 100:100 Recording source: monitor That's strange. I would expect it working. Would you be so kind and give me the lines for reconfigure CODEC using hints? I'm really lost in this. OK, try this: hint.hdac.0.cad0.nid18.config=as=2 seq=1 Hi Alexander, While trying to get understandig of the verbose boot messages of snd_hda(4), I found the following which seems to match the problem (only recording from Jack): hdac0: nid 18 0x99a30930 as 3 seq 0 Mic Fixed jack 3 loc 25 color Unknown misc 9 ... hdac0: nid 24 0x03a19820 as 2 seq 0 Mic Jack jack 1 loc 3 color Pink misc 8 i.e. the nid's are 18 (internal mic) and 24 (Jack); But in the DUMPING's Playback/Record Paths the nid=18 and nid=24 look different: 24: pcm0: Record: pcm0: pcm0: nid=8 [audio input] pcm0: | pcm0: + - nid=35 [audio mixer] [src: mic, mix] pcm0: | pcm0: + - nid=24 [pin: Mic (Pink Jack)] [src: mic] pcm0: + - nid=11 [audio mixer] [src: mix] pcm0: pcm0: Input Mix: pcm0: pcm0: nid=11 [audio mixer] pcm0: | pcm0: + - nid=24 [pin: Mic (Pink Jack)] [src: mic] 18: pcm1: Record: pcm1: pcm1: nid=9 [audio input] pcm1: | pcm1: + - nid=34 [audio mixer] [src: monitor] pcm1: | pcm1: + - nid=18 [pin: Mic (Fixed)] [src: monitor] (there is no 'Input Mix:' section part for nid=18) Can this cause the problem? What else could I debug to nail this down? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ ___ 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: Only display ACPI bootmenu key if ACPI is present
on 09/11/2010 16:08 Lars Engels said the following: That's also an appreciated improvement, but what PCBSD does is that you can toggle several options, so when you select an option, the kernel is not loaded immediately after but you are still in the menu and can select / toggle another option. That way you have a multi-selection, e.g. select safe mode but enable acpi. Maybe we could also add a menu entry to boot without any modules, so loaders.conf gets overridden? That sounds cool. Like e.g. selecting verbose single-user boot completely from the menu. Good idea. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ATA: driver bug: Unable to set devclass
Since one of the recent updates (not sure which revision though) I started to
get
Unable to set devclass messages in boot dmesg. I'd say that I see the message
every other boot, i.e. not always.
I added some more debug code there and here's a tack trace:
driver bug: Unable to set devclass (child = 0xff00070d0100, devname: (null))
#0 0x803ae127 at device_probe_child+0x127
#1 0x803ae40c at device_probe+0x7c
#2 0x803ae4a1 at device_probe_and_attach+0x11
#3 0x803ae56a at bus_generic_attach+0x1a
#4 0x801df93c at ata_identify+0x2ec
#5 0x801dfcdb at ata_boot_attach+0x6b
#6 0x803a8577 at run_interrupt_driven_config_hooks+0xf7
#7 0x803a8993 at boot_run_interrupt_driven_config_hooks+0x23
#8 0x8032f227 at mi_startup+0xc7
#9 0x801719cc at btext+0x2c
From kgdb:
(kgdb) p *(device_t)0xff00070d0100
$1 = {ops = 0xff0001b07000, link = {tqe_next = 0xff0001a65100, tqe_prev
=
0xff0006eb0130}, devlink = {tqe_next = 0xff0001a65100, tqe_prev =
0xff000706e318},
parent = 0xff0006eb0100, children = {tqh_first = 0xff0001a5b200,
tqh_last = 0xff0001a5b208}, driver = 0x8079bc80, devclass =
0xff0001add080, unit = 0,
nameunit = 0xff00070931a0 ad0, desc = 0xff000711e7c0
ST3320620A/3.AAF, busy = 0, state = DS_ATTACHED, devflags = 0, flags = 89,
order
= 0, ivars = 0xff000711e5e0,
softc = 0xff000706a400, sysctl_ctx = {tqh_first = 0xff000711e600,
tqh_last = 0xff000711e708}, sysctl_tree = 0xff00070f9500}
Apparently sometimes something happens too soon? :-)
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: radeon_cp_texture: page fault with non-sleepable locks held
On Tue, Nov 09, 2010 at 11:25:49AM +0200, Andriy Gapon wrote: on 08/11/2010 14:04 Kostik Belousov said the following: On Mon, Nov 08, 2010 at 01:50:25PM +0200, Andriy Gapon wrote: on 05/11/2010 09:27 Andriy Gapon said the following: I use FreeSBD head and KDE 4 with all the bells and whistles enabled. Apparently recent KDE update has enabled even more of them, because I started to have panics with a kernel that has INVARIANTS and WITNESS enabled. I tried to solve the problem by changing drmdev from mutex to sx: http://people.freebsd.org/~avg/drm-sx.diff I remember that drm lock can be acquired from the interrupt thread, if the card supports interrupts. Changing it to sx cannot work then, because interrupt threads cannot sleep. Most likely, you are getting around it since r600 not yet used interrupts on FreeBSD. I think the solution is to drop drm lock around copyin. Kostik, I looked at this some more and now I think that using sx is a step in the right direction. Rationale: 1. it seems that on Linux mutex is a sleepable lock and thus can be safely held across a page fault; and Linux mutex - FreeBSD sx seems to be a porting technique used for kernel code before[*]. 2. DRM interrupt code uses a different lock - irq_lock, which is locked via DRM_SPINLOCK macro (expands to FreeBSD mutex); apparently even on Linux a even on Linux. Heh. sleep-able lock can't be acquired in interrupt handler. I use Linux this and Linux that as a justification, because the DRM code apparently originated with Linux model/idioms in mind, although the original purpose was for the code to be portable. So, what do you think about this aspect? Should you agree with the usage of sx, then the previous question pops back - I do not agree. how to resolve the lock order reversal between drmdev lock and user map lock (which both would be sx). Easiest would be for DRM to provide wrappers for copyin/copyout that unlock, do operation and lock. Where is the reverse order (user map - drm) ? [*] http://www.ukuug.org/events/eurobsdcon2009/papers/dvb_driver_paper.pdf -- Andriy Gapon pgpU3HtCVdkuI.pgp Description: PGP signature
Re: Only display ACPI bootmenu key if ACPI is present
on 09/11/2010 07:26 Lars Engels said the following: Maybe we should also import PCBSD's patches to the beastie menu? In PCBSD's beastie menu you can toggle some settings like safe mode, and ACPI, so the kernel is not loaded as soon as select an option. See http://trac.pcbsd.org/browser/pcbsd/current/system-overlay/boot/beastie.4th Lars, not sure if I got your suggestion correctly, this is what I have in my local tree: diff --git a/sys/boot/i386/loader/loader.rc b/sys/boot/i386/loader/loader.rc index 6443f3f..cb2f723 100644 --- a/sys/boot/i386/loader/loader.rc +++ b/sys/boot/i386/loader/loader.rc @@ -5,7 +5,7 @@ include /boot/loader.4th \ Reads and processes loader.conf variables -start +initialize \ Tests for password -- executes autoboot first if a password was defined check-password With this kernel and modules are _not_ loaded before presenting the menu. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kldunload(8) returns 0, although it fail
On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: On Tue Nov 9 10, John Baldwin wrote: On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: hi there, i posted this message on freebsd-questions@, but nobody could help me with it. to me this looks like a bug, so i assume posting it again here on freebsd-current@ might be better. please keep in mind that the issue here is not the fact that the second attempt to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules have dependencies. however it should fail with the first attempt. right now kldunloadf() returns zero, whereas it should actually return EBUSY (just like the second attempt). i've attached two kdump outputs: one for the first 'kldunload' attempt and one for the second. as you can see the problem is that for some reason kldunloadf() returns zero, although it couldn't unload the module. Did you get an error message in dmesg? If you have manually loaded netgraph.ko (via netgraph_load=YES in loader.conf or an explicit kldload) and then loaded other modules that depend on it (such as ng_foo.ko) then this is expected behavior. What your kldunload has done is to remove the manual reference from loader.conf or 'kldload netgraph.ko'. What this changes is what happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then netgraph.ko will also be unloaded when its last reference drops (in this case it looks like you actually have two ng_*.ko objects loaded, so you would have to unload both of them, but I will assume a single ng_foo.ko to make the explanation simpler). If you had not done 'kldunload netgraph.ko' but had done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko loaded. All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. i have ng_ubt_load=YES in my loader.conf and kldstat says: Id Refs AddressSize Name 1 37 0x8010 a2ddb8 kernel 21 0x80b2e000 295e8snd_hda.ko 31 0x80b58000 85110sound.ko 41 0x80bde000 cf79e0 nvidia.ko 55 0x818d6000 418c0linux.ko 61 0x81918000 80e8 ng_ubt.ko 72 0x81921000 fa78 ng_hci.ko 82 0x81931000 2bd0 ng_bluetooth.ko 93 0x81934000 15e68netgraph.ko 101 0x81a12000 3efb linprocfs.ko 113 0x81a16000 4698 pseudofs.ko 121 0x81a1b000 31b3 procfs.ko 131 0x81a1f000 a37 linsysfs.ko 141 0x81a2 6f4 rtc.ko also the same happens with sound.ko. i have snd_hda_load=yes. and i think snd_hda is the only dependecy for sound.ko. there was no error message in dmesg for the first kldunload attempt. i think i understand the logic, however the current behavior does not confirm to the description in kldunload(2). Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko after boot? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
limits to memory on amd64
During the discussion at MeetBSD the question came up as to what the real limiting factors were with regard to how much RAM a system could have. it was put to us that the limit was currently around 512 GB, though no-one at teh discussion knew what the mechanism of the limitation was or what might ligh beyond it. Could anyone who knows, pipe upt and let use know what the factors are, and if the current limit is overcome, what the next one after that will be? Julian ___ 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: Syscons and termcap
On Tue, Nov 9, 2010 at 8:03 AM, Ed Schouten e...@80386.nl wrote: Hello Eir, * Eir Nym eir...@gmail.com, 20101109 05:10: I've compiled -CURRENT kernel with UTF-8 and CONS25 support. ( r214751 ) in xterm emulation mode I have problems with bindings for some keys, such as Home If I start vis(1) and press Home, I always get ^[[H sequence instead of ^[OH which is defined in termcap (5) file. I get correct results after switching to cons25. What do I wrong ? Does sc(4) driver in current correctly support xterm-like key bindings? Yes, but not only must you set TERM=xterm, you must also remove TEKEN_CONS25 from your kernel configuration or run vidcontrol -T xterm on that specific window. There is almost no reason why anyone would want to use the TEKEN_CONS25 option. Depending on whether the terminal is switched to cursor keys mode, it will return ^[[H or ^[OH. See /sys/teken/teken.c, teken_get_sequence(). Hi Ed, Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg environment, and after reading this I decided to make a test. I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel config, and after configure my syscons to use cp850-* fonts i can see UTF-8 chars properly \o/ The only thing i cannot do here is to type chars with accent like áé on console, because it seems to don't respect deadkeys, when I press ' the char ' is show and never wait the next char to compose a new one when necessary. Is it a knwon issue or i'm doing something wrong? I'm using us.iso.kbd Regards -- Renato Botelho ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ATA: driver bug: Unable to set devclass
Andriy Gapon wrote:
Since one of the recent updates (not sure which revision though) I started to
get
Unable to set devclass messages in boot dmesg. I'd say that I see the
message
every other boot, i.e. not always.
I added some more debug code there and here's a tack trace:
driver bug: Unable to set devclass (child = 0xff00070d0100, devname:
(null))
#0 0x803ae127 at device_probe_child+0x127
#1 0x803ae40c at device_probe+0x7c
#2 0x803ae4a1 at device_probe_and_attach+0x11
#3 0x803ae56a at bus_generic_attach+0x1a
#4 0x801df93c at ata_identify+0x2ec
#5 0x801dfcdb at ata_boot_attach+0x6b
#6 0x803a8577 at run_interrupt_driven_config_hooks+0xf7
#7 0x803a8993 at boot_run_interrupt_driven_config_hooks+0x23
#8 0x8032f227 at mi_startup+0xc7
#9 0x801719cc at btext+0x2c
From kgdb:
(kgdb) p *(device_t)0xff00070d0100
$1 = {ops = 0xff0001b07000, link = {tqe_next = 0xff0001a65100,
tqe_prev =
0xff0006eb0130}, devlink = {tqe_next = 0xff0001a65100, tqe_prev =
0xff000706e318},
parent = 0xff0006eb0100, children = {tqh_first = 0xff0001a5b200,
tqh_last = 0xff0001a5b208}, driver = 0x8079bc80, devclass =
0xff0001add080, unit = 0,
nameunit = 0xff00070931a0 ad0, desc = 0xff000711e7c0
ST3320620A/3.AAF, busy = 0, state = DS_ATTACHED, devflags = 0, flags = 89,
order
= 0, ivars = 0xff000711e5e0,
softc = 0xff000706a400, sysctl_ctx = {tqh_first = 0xff000711e600,
tqh_last = 0xff000711e708}, sysctl_tree = 0xff00070f9500}
Apparently sometimes something happens too soon? :-)
What controller is there? Any other differences/interesting things in
verbose dmesg? Any new CONNECT requested messages or anything else?
--
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: limits to memory on amd64
On Tue, 09 Nov 2010 08:45:14 PST Julian Elischer jul...@freebsd.org wrote: During the discussion at MeetBSD the question came up as to what the real limiting factors were with regard to how much RAM a system could have. it was put to us that the limit was currently around 512 GB, though no-one at teh discussion knew what the mechanism of the limitation was or what might ligh beyond it. Could anyone who knows, pipe upt and let use know what the factors are, and if the current limit is overcome, what the next one after that will be? You mean beyond architectural limits? From Wikipedia: Larger physical address space: The original implementation of the AMD64 architecture implemented 40-bit physical addresses and so could address up to 1 TB (2^40 bytes) of RAM. Current implementations of the AMD64 architecture (starting from AMD 10h microarchitecture) extend this to 48-bit physical addresses and therefore can address up to 256 TB of RAM. The architecture permits extending this to 52 bits in the future (limited by the page table entry format); this would allow addressing of up to 4 PB of RAM. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ATA: driver bug: Unable to set devclass
on 09/11/2010 19:04 Alexander Motin said the following:
Andriy Gapon wrote:
Since one of the recent updates (not sure which revision though) I started
to get
Unable to set devclass messages in boot dmesg. I'd say that I see the
message
every other boot, i.e. not always.
I added some more debug code there and here's a tack trace:
driver bug: Unable to set devclass (child = 0xff00070d0100, devname:
(null))
#0 0x803ae127 at device_probe_child+0x127
#1 0x803ae40c at device_probe+0x7c
#2 0x803ae4a1 at device_probe_and_attach+0x11
#3 0x803ae56a at bus_generic_attach+0x1a
#4 0x801df93c at ata_identify+0x2ec
#5 0x801dfcdb at ata_boot_attach+0x6b
#6 0x803a8577 at run_interrupt_driven_config_hooks+0xf7
#7 0x803a8993 at boot_run_interrupt_driven_config_hooks+0x23
#8 0x8032f227 at mi_startup+0xc7
#9 0x801719cc at btext+0x2c
From kgdb:
(kgdb) p *(device_t)0xff00070d0100
$1 = {ops = 0xff0001b07000, link = {tqe_next = 0xff0001a65100,
tqe_prev =
0xff0006eb0130}, devlink = {tqe_next = 0xff0001a65100, tqe_prev =
0xff000706e318},
parent = 0xff0006eb0100, children = {tqh_first = 0xff0001a5b200,
tqh_last = 0xff0001a5b208}, driver = 0x8079bc80, devclass =
0xff0001add080, unit = 0,
nameunit = 0xff00070931a0 ad0, desc = 0xff000711e7c0
ST3320620A/3.AAF, busy = 0, state = DS_ATTACHED, devflags = 0, flags = 89,
order
= 0, ivars = 0xff000711e5e0,
softc = 0xff000706a400, sysctl_ctx = {tqh_first = 0xff000711e600,
tqh_last = 0xff000711e708}, sysctl_tree = 0xff00070f9500}
Apparently sometimes something happens too soon? :-)
What controller is there? Any other differences/interesting things in
verbose dmesg? Any new CONNECT requested messages or anything else?
It's SB700 integrated controller (ATI IXP700/800 UDMA133 controller).
This happens during boot, there are no other unusual ata-related messages.
I have device ahci in kernel, but no ATA_CAM option, so PATA stuff works via
pure ata code.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: limits to memory on amd64
On 11/9/10 9:04 AM, Bakul Shah wrote: On Tue, 09 Nov 2010 08:45:14 PST Julian Elischerjul...@freebsd.org wrote: During the discussion at MeetBSD the question came up as to what the real limiting factors were with regard to how much RAM a system could have. it was put to us that the limit was currently around 512 GB, though no-one at teh discussion knew what the mechanism of the limitation was or what might ligh beyond it. Could anyone who knows, pipe upt and let use know what the factors are, and if the current limit is overcome, what the next one after that will be? You mean beyond architectural limits? no, though of course they are relevant. I was thinking more of details like limits to the KVM space or any limitations there may be on the size of the direct-map region, or maybe some limit on some data structure size in the kernel. Since I don 't know the details, this is exactly the question.. what IS the limit? From Wikipedia: Larger physical address space: The original implementation of the AMD64 architecture implemented 40-bit physical addresses and so could address up to 1 TB (2^40 bytes) of RAM. Current implementations of the AMD64 architecture (starting from AMD 10h microarchitecture) extend this to 48-bit physical addresses and therefore can address up to 256 TB of RAM. The architecture permits extending this to 52 bits in the future (limited by the page table entry format); this would allow addressing of up to 4 PB of RAM. ___ 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: Syscons and termcap
* Renato Botelho rbga...@gmail.com, 20101109 17:08: Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg environment, and after reading this I decided to make a test. I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel config, and after configure my syscons to use cp850-* fonts i can see UTF-8 chars properly \o/ Well, the point here is that it just performs some really hackish translation to CP437, not CP850, on the output path. It is really not robust. Copy-pasting is also broken because of it, because it pastes CP437 characters. The only thing i cannot do here is to type chars with accent like áé on console, because it seems to don't respect deadkeys, when I press ' the char ' is show and never wait the next char to compose a new one when necessary. Is it a knwon issue or i'm doing something wrong? This is a known issue, since there is no translation from Unicode code points to UTF-8 sequences. In other words, if you press ë, the keyboard layer will properly send a 235 to Syscons, but instead of encoding it as 0xC3 0xA9, will just emit a single byte, having value 0xE9. Maybe a patch like this could already get that working, but it's just a quick hack. http://80386.nl/pub/syscons-utf8.txt Greetings, -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpDFXZrgCmH7.pgp Description: PGP signature
Re: Syscons and termcap
On Tue, 9 Nov 2010 14:08:01 -0200 Renato Botelho rbga...@gmail.com wrote: [snip stuff from Ed] Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg environment, and after reading this I decided to make a test. I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel config, and after configure my syscons to use cp850-* fonts i can see UTF-8 chars properly \o/ The only thing i cannot do here is to type chars with accent like áé on console, because it seems to don't respect deadkeys, when I press ' the char ' is show and never wait the next char to compose a new one when necessary. Is it a knwon issue or i'm doing something wrong? I'm using us.iso.kbd This may seem like a stupid comment, but I'd say that the iso does not imply UTF-8 support. In fact, there seem to be only ISO or code page keymaps under /usr/share/syscons/keymaps. But I'm no keymap expert. -- 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: limits to memory on amd64
Julian Elischer wrote: On 11/9/10 9:04 AM, Bakul Shah wrote: On Tue, 09 Nov 2010 08:45:14 PST Julian Elischerjul...@freebsd.org wrote: During the discussion at MeetBSD the question came up as to what the real limiting factors were with regard to how much RAM a system could have. it was put to us that the limit was currently around 512 GB, though no-one at teh discussion knew what the mechanism of the limitation was or what might ligh beyond it. Could anyone who knows, pipe upt and let use know what the factors are, and if the current limit is overcome, what the next one after that will be? You mean beyond architectural limits? no, though of course they are relevant. I was thinking more of details like limits to the KVM space or any limitations there may be on the size of the direct-map region, or maybe some limit on some data structure size in the kernel. Since I don 't know the details, this is exactly the question.. what IS the limit? The changes to support more than 512GB RAM should be straightforward. Off the top of my head, it will require some constant definitions in vmparam.h to change, and the allocation of some additional PDP-level page table pages in create_pagetables(). In contrast, the changes to break the original 2GB KVM barrier involved touching a number of different places in the kernel. Alan ___ 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: Syscons and termcap
On Tue, Nov 9, 2010 at 3:45 PM, Ed Schouten e...@80386.nl wrote: * Renato Botelho rbga...@gmail.com, 20101109 17:08: Well, few weeks ago I moved from ISO-8859-1 to UTF-8 on my Xorg environment, and after reading this I decided to make a test. I rebuilt my 9.0-current (r215031) with option TEKEN_UTF8 in kernel config, and after configure my syscons to use cp850-* fonts i can see UTF-8 chars properly \o/ Well, the point here is that it just performs some really hackish translation to CP437, not CP850, on the output path. It is really not robust. Copy-pasting is also broken because of it, because it pastes CP437 characters. OK, i changed my fonts to cp437. The only thing i cannot do here is to type chars with accent like áé on console, because it seems to don't respect deadkeys, when I press ' the char ' is show and never wait the next char to compose a new one when necessary. Is it a knwon issue or i'm doing something wrong? This is a known issue, since there is no translation from Unicode code points to UTF-8 sequences. In other words, if you press ë, the keyboard layer will properly send a 235 to Syscons, but instead of encoding it as 0xC3 0xA9, will just emit a single byte, having value 0xE9. Maybe a patch like this could already get that working, but it's just a quick hack. http://80386.nl/pub/syscons-utf8.txt It had no effect on console but, i don't know why, screwed up my Xorg keymap, some meta keys (Mod4) stop working even if I run a setxkbmap like this: /usr/local/bin/setxkbmap -rules xorg -symbols pc(pc105)+sun_vndr/usb(sun_usb)+pc(pc105)+us(intl) Now i back old kernel and everything is working fine. It's not something I need, but would be nice to have console working with UTF-8 and accent keys :) -- Renato Botelho ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ATA: driver bug: Unable to set devclass
Andriy Gapon wrote:
on 09/11/2010 19:04 Alexander Motin said the following:
Andriy Gapon wrote:
Since one of the recent updates (not sure which revision though) I started
to get
Unable to set devclass messages in boot dmesg. I'd say that I see the
message
every other boot, i.e. not always.
I added some more debug code there and here's a tack trace:
driver bug: Unable to set devclass (child = 0xff00070d0100, devname:
(null))
#0 0x803ae127 at device_probe_child+0x127
#1 0x803ae40c at device_probe+0x7c
#2 0x803ae4a1 at device_probe_and_attach+0x11
#3 0x803ae56a at bus_generic_attach+0x1a
#4 0x801df93c at ata_identify+0x2ec
#5 0x801dfcdb at ata_boot_attach+0x6b
#6 0x803a8577 at run_interrupt_driven_config_hooks+0xf7
#7 0x803a8993 at boot_run_interrupt_driven_config_hooks+0x23
#8 0x8032f227 at mi_startup+0xc7
#9 0x801719cc at btext+0x2c
From kgdb:
(kgdb) p *(device_t)0xff00070d0100
$1 = {ops = 0xff0001b07000, link = {tqe_next = 0xff0001a65100,
tqe_prev =
0xff0006eb0130}, devlink = {tqe_next = 0xff0001a65100, tqe_prev =
0xff000706e318},
parent = 0xff0006eb0100, children = {tqh_first = 0xff0001a5b200,
tqh_last = 0xff0001a5b208}, driver = 0x8079bc80, devclass =
0xff0001add080, unit = 0,
nameunit = 0xff00070931a0 ad0, desc = 0xff000711e7c0
ST3320620A/3.AAF, busy = 0, state = DS_ATTACHED, devflags = 0, flags =
89, order
= 0, ivars = 0xff000711e5e0,
softc = 0xff000706a400, sysctl_ctx = {tqh_first = 0xff000711e600,
tqh_last = 0xff000711e708}, sysctl_tree = 0xff00070f9500}
Apparently sometimes something happens too soon? :-)
What controller is there? Any other differences/interesting things in
verbose dmesg? Any new CONNECT requested messages or anything else?
It's SB700 integrated controller (ATI IXP700/800 UDMA133 controller).
This happens during boot, there are no other unusual ata-related messages.
I have device ahci in kernel, but no ATA_CAM option, so PATA stuff works via
pure ata code.
Hmm. There was not much changes in ATA last time and I can't expect what
of them could affect PATA. Probe code wasn't changed for long time.
This check was actually added after some ata(4) bug found two years ago.
So I am not sure your problem is something new. May be something else
just triggered it again.
--
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: Syscons and termcap
* Gary Jennejohn gljennj...@googlemail.com, 20101109 18:58: This may seem like a stupid comment, but I'd say that the iso does not imply UTF-8 support. In fact, there seem to be only ISO or code page keymaps under /usr/share/syscons/keymaps. But I'm no keymap expert. Well, the funny thing about Unicode is that the first 256 codepoints are equal to ISO-8859-1, so if you recode ISO-8859-1 to the multibyte representation of UTF-8, it all works. This is why you could use such a keymap without issues. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgprWDwdQwCiP.pgp Description: PGP signature
Re: ATA: driver bug: Unable to set devclass
on 09/11/2010 20:14 Alexander Motin said the following: Hmm. There was not much changes in ATA last time and I can't expect what of them could affect PATA. Probe code wasn't changed for long time. This check was actually added after some ata(4) bug found two years ago. So I am not sure your problem is something new. May be something else just triggered it again. Added some more debugging code, will try to get more info. Thanks! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: issue with options DDB
On Fri Nov 5 10, Ulrich Spörlein wrote: On Sat, 30.10.2010 at 23:22:44 +, Alexander Best wrote: hi there, with options DDB in my kernel conf i run into the following issue with my kernel modules: link_elf_lookup_symbol: missing symbol hash table KLD file snd_hda.ko is missing dependencies KLD file sound.ko is missing dependencies KLD file nvidia.ko is missing dependencies KLD file linux.ko is missing dependencies KLD file ng_ubt.ko is missing dependencies KLD file ng_hci.ko is missing dependencies KLD file ng_bluetooth.ko is missing dependencies KLD file netgraph.ko is missing dependencies link_elf_lookup_symbol: missing symbol hash table removing the option solves the issue. any advice? cheers. alex ps: i'm running HEAD (r214542; amd64). You failed to mention the command that you run. I assume 'buildkernel'? Please note that you need and update-to-date buildworld for the kernel tools to be there, so please try the following (with options DDB): cd /usr/src make clean; make cleandir; make clean make buildworld make buildkernel KERNCONF=YOURKERNEL hmmmseems there is a problem with gcc. this is what i get during buildworld: clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c building static supc++ library ranlib libsupc++.a === gnu/lib/libobjc (all) gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c *** Signal 11 Stop in /usr/src/gnu/lib/libobjc. *** Error code 1 Stop in /usr/src/gnu/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. i've ran buildworld twice (with a clean /usr/src and non-existing /usr/obj/*) and got the error twice, so it's not a hardware problem it seems. if i'm not mistaken the gcc that is being used for buildworld is not the one in /usr/bin, but a fresh build in /usr/obj, right? this is
Re: minidump size on amd64
on 09/11/2010 10:02 Alan Cox said the following:
The kernel portion of the patch looks correct. If I were to make one
stylistic
suggestion, it would be to make the control flow of the outer and inner loops
as
similar as possible, that is,
for (...
if ((pdp[i] PG_V) == 0) {
...
continue;
}
if ((pdp[i] PG_PS) != 0) {
...
continue;
}
for (...
if ((pd[j] PG_V) == 0)
continue;
if ((pd[j] PG_PS) != 0) {
...
continue;
}
for (...
if ((pt[x] PG_V) == 0)
continue;
...
I think this would make the code a little easier to follow.
This is a very nice suggestion, thank you.
Besides the uniformity some horizontal space is saved too :-)
Updated patch (only kernel part) is here:
http://people.freebsd.org/~avg/amd64-minidump.5.diff
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: limits to memory on amd64
On 11/9/10 9:59 AM, Alan Cox wrote: Julian Elischer wrote: On 11/9/10 9:04 AM, Bakul Shah wrote: On Tue, 09 Nov 2010 08:45:14 PST Julian Elischerjul...@freebsd.org wrote: During the discussion at MeetBSD the question came up as to what the real limiting factors were with regard to how much RAM a system could have. it was put to us that the limit was currently around 512 GB, though no-one at teh discussion knew what the mechanism of the limitation was or what might ligh beyond it. Could anyone who knows, pipe upt and let use know what the factors are, and if the current limit is overcome, what the next one after that will be? You mean beyond architectural limits? no, though of course they are relevant. I was thinking more of details like limits to the KVM space or any limitations there may be on the size of the direct-map region, or maybe some limit on some data structure size in the kernel. Since I don 't know the details, this is exactly the question.. what IS the limit? The changes to support more than 512GB RAM should be straightforward. Off the top of my head, it will require some constant definitions in vmparam.h to change, and the allocation of some additional PDP-level page table pages in create_pagetables(). In contrast, the changes to break the original 2GB KVM barrier involved touching a number of different places in the kernel. Alan, since some people (e.g. Sean Bruno) were hitting this, do you think you could provide a patch to allow people to test this? Sean in Particular seemed keen to try go to 1TB ram in a machine he had access to. Julian Alan ___ 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: issue with options DDB
On Tue, Nov 09, 2010 at 06:25:12PM +, Alexander Best wrote: On Fri Nov 5 10, Ulrich Spörlein wrote: On Sat, 30.10.2010 at 23:22:44 +, Alexander Best wrote: hi there, with options DDB in my kernel conf i run into the following issue with my kernel modules: link_elf_lookup_symbol: missing symbol hash table KLD file snd_hda.ko is missing dependencies KLD file sound.ko is missing dependencies KLD file nvidia.ko is missing dependencies KLD file linux.ko is missing dependencies KLD file ng_ubt.ko is missing dependencies KLD file ng_hci.ko is missing dependencies KLD file ng_bluetooth.ko is missing dependencies KLD file netgraph.ko is missing dependencies link_elf_lookup_symbol: missing symbol hash table removing the option solves the issue. any advice? cheers. alex ps: i'm running HEAD (r214542; amd64). You failed to mention the command that you run. I assume 'buildkernel'? Please note that you need and update-to-date buildworld for the kernel tools to be there, so please try the following (with options DDB): cd /usr/src make clean; make cleandir; make clean make buildworld make buildkernel KERNCONF=YOURKERNEL hmmmseems there is a problem with gcc. this is what i get during buildworld: clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc clang++: warning: argument unused during compilation: '-fconserve-space' ^^^ clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -fstack-protector -fconserve-space -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc clang++: warning: argument unused during compilation: '-fconserve-space' clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c building static supc++ library ranlib libsupc++.a === gnu/lib/libobjc (all) gcc -O2 -pipe -fno-strict-aliasing -funroll-loops -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -g -std=gnu99 -fstack-protector -c /usr/src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c *** Signal 11 Stop in /usr/src/gnu/lib/libobjc. *** Error code 1 Stop in /usr/src/gnu/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. i've ran buildworld twice (with a clean /usr/src and non-existing /usr/obj/*)
Re: Only display ACPI bootmenu key if ACPI is present
On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin j...@freebsd.org wrote: This patch changes the Forth code for the Beastie menu to only display the menu option to enable or disable ACPI if the loader detects ACPI. This avoids displaying a menu item prompting to enable ACPI if the BIOS doesn't actually include ACPI. Any objections? Wouldn't that be a POLA violation? Some admins may be used to the current menu, and would be scratching head as what went wrong. Maybe it would be better to keep the menu option, but make it non-selectable and print next to it something like (not available)? -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: Only display ACPI bootmenu key if ACPI is present
On Tue, Nov 9, 2010 at 2:58 PM, C. P. Ghost cpgh...@cordula.ws wrote: On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin j...@freebsd.org wrote: This patch changes the Forth code for the Beastie menu to only display the menu option to enable or disable ACPI if the loader detects ACPI. This avoids displaying a menu item prompting to enable ACPI if the BIOS doesn't actually include ACPI. Any objections? Wouldn't that be a POLA violation? Some admins may be used to the current menu, and would be scratching head as what went wrong. Maybe it would be better to keep the menu option, but make it non-selectable and print next to it something like (not available)? Yeah... seems like it would be; besides, I'm kind of used to pressing numbers 4 and 6 when I have a boot menu :). Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Only display ACPI bootmenu key if ACPI is present
Date: Tue, 9 Nov 2010 15:45:00 -0800 From: Garrett Cooper gcoo...@freebsd.org Sender: owner-freebsd-curr...@freebsd.org On Tue, Nov 9, 2010 at 2:58 PM, C. P. Ghost cpgh...@cordula.ws wrote: On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin j...@freebsd.org wrote: This patch changes the Forth code for the Beastie menu to only display the menu option to enable or disable ACPI if the loader detects ACPI. This avoids displaying a menu item prompting to enable ACPI if the BIOS doesn't actually include ACPI. Any objections? Wouldn't that be a POLA violation? Some admins may be used to the current menu, and would be scratching head as what went wrong. Maybe it would be better to keep the menu option, but make it non-selectable and print next to it something like (not available)? Yeah... seems like it would be; besides, I'm kind of used to pressing numbers 4 and 6 when I have a boot menu :). Thanks! Wait a minute. The menu is a POLA violation. I'm used to hitting 'SPCboot -s' and entering just '4' is clearly not the way the Lord meant it to be. (I edit the loader.4th file to turn it off o my personal systems, being an old curmudgeon.) If you are going to use a menu at all, why not make it as functional as possible? If someone has menus on and hits '4' with the PCBSD menu, it won't do what it does now, but it won't really do anything at all until you tell it to go. As POLA violations go this is nothing compared to when the menu appeared. I say, Go 4 IT! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: Only display ACPI bootmenu key if ACPI is present
On Tue, Nov 9, 2010 at 3:58 PM, Kevin Oberman ober...@es.net wrote: Date: Tue, 9 Nov 2010 15:45:00 -0800 From: Garrett Cooper gcoo...@freebsd.org Sender: owner-freebsd-curr...@freebsd.org On Tue, Nov 9, 2010 at 2:58 PM, C. P. Ghost cpgh...@cordula.ws wrote: On Mon, Nov 8, 2010 at 11:14 PM, John Baldwin j...@freebsd.org wrote: This patch changes the Forth code for the Beastie menu to only display the menu option to enable or disable ACPI if the loader detects ACPI. This avoids displaying a menu item prompting to enable ACPI if the BIOS doesn't actually include ACPI. Any objections? Wouldn't that be a POLA violation? Some admins may be used to the current menu, and would be scratching head as what went wrong. Maybe it would be better to keep the menu option, but make it non-selectable and print next to it something like (not available)? Yeah... seems like it would be; besides, I'm kind of used to pressing numbers 4 and 6 when I have a boot menu :). Wait a minute. The menu is a POLA violation. I'm used to hitting 'SPCboot -s' and entering just '4' is clearly not the way the Lord meant it to be. (I edit the loader.4th file to turn it off o my personal systems, being an old curmudgeon.) I use a bit easier means on some systems: /boot/defaults/loader.conf:#beastie_disable=NO# Turn the beastie boot menu on and off If you are going to use a menu at all, why not make it as functional as possible? If someone has menus on and hits '4' with the PCBSD menu, it won't do what it does now, but it won't really do anything at all until you tell it to go. As POLA violations go this is nothing compared to when the menu appeared. Whatever... people are going to gripe either way with this change, so I guess making people think is more important than misleading them into thinking things work. It's just easier to slap someone on the hand if they hit ACPI, and less annoying for automated expect scripts because they don't have to hit a different number, but I suppose if they were smart they would use the loader prompt anyhow instead of the menu *shrugs*. So, this is a I understand, slap me on the hand if I hit 4 or 6 agreement :). Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: radeon_cp_texture: page fault with non-sleepable locks held
on 09/11/2010 16:05 Kostik Belousov said the following: Easiest would be for DRM to provide wrappers for copyin/copyout that unlock, do operation and lock. I am a little bit worried about this approach in general. Driver state may be changed by a process running in parallel while the lock is dropped. And I don't think that we have any mechanism in DRM to check for that and to restart operations or otherwise account for the state change. The code seems to be written with an assumption that it runs in exclusive mode from DRM ioctl start to its completion. Where is the reverse order (user map - drm) ? You mean the following or the opposite? 1st 0xff0001b968a0 drmdev (drmdev) @ /usr/src/sys/dev/drm/drm_drv.c:791 2nd 0xff000a621510 user map (user map) @ /usr/src/sys/vm/vm_map.c:3548 KDB: stack backtrace: db_trace_self_wrapper() at 0x801b8b3a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x803a7a8a = kdb_backtrace+0x3a _witness_debugger() at 0x803bd42c = _witness_debugger+0x2c witness_checkorder() at 0x803be899 = witness_checkorder+0x959 _sx_slock() at 0x80378af8 = _sx_slock+0x88 _vm_map_lock_read() at 0x80510a06 = _vm_map_lock_read+0x36 vm_map_lookup() at 0x805127d4 = vm_map_lookup+0x54 vm_fault() at 0x80509819 = vm_fault+0xf9 trap_pfault() at 0x80545d6f = trap_pfault+0x11f trap() at 0x805465f7 = trap+0x657 calltrap() at 0x80530628 = calltrap+0x8 --- trap 0xc, rip = 0x805440bd, rsp = 0xff8123fe37f0, rbp = 0xff8123fe3870 --- copyin() at 0x805440bd = copyin+0x3d radeon_cp_texture() at 0x8022fbd7 = radeon_cp_texture+0x167 drm_ioctl() at 0x8020fa38 = drm_ioctl+0x318 devfs_ioctl_f() at 0x802dd649 = devfs_ioctl_f+0x109 kern_ioctl() at 0x803c1127 = kern_ioctl+0x1f7 ioctl() at 0x803c12e8 = ioctl+0x168 syscallenter() at 0x803b57de = syscallenter+0x26e syscall() at 0x80545eb2 = syscall+0x42 Xfast_syscall() at 0x80530902 = Xfast_syscall+0xe2 If you meant the opposite order, how can I check it? I guess that it could be in a mmap() call for drm cdev. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: uma_zalloc_arg: Returning an empty bucket.
I've been doing some stress-testing for VM+ZFS on a kernel with WITNESS+INVARIANTS and I have already stumbled into some curious panics. Here's another one: Unread portion of the kernel message buffer: panic: uma_zalloc_arg: Returning an empty bucket. cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x801b8b3a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x803a7a8a = kdb_backtrace+0x3a panic() at 0x80370632 = panic+0x1d2 uma_zalloc_arg() at 0x80507850 = uma_zalloc_arg+0x300 kmem_cache_alloc() at 0x80dac385 = kmem_cache_alloc+0x15 arc_buf_alloc() at 0x80c016e4 = arc_buf_alloc+0x34 arc_read_nolock() at 0x80c0389d = arc_read_nolock+0x2bd arc_read() at 0x80c03dff = arc_read+0x7f dbuf_prefetch() at 0x80c0826a = dbuf_prefetch+0x15a dmu_zfetch_dofetch() at 0x80c21444 = dmu_zfetch_dofetch+0x104 dmu_zfetch() at 0x80c21c89 = dmu_zfetch+0x5e9 dbuf_read() at 0x80c06c04 = dbuf_read+0x454 dmu_buf_hold_array_by_dnode() at 0x80c0a58d = dmu_buf_hold_array_by_dnode+0x27d dmu_read() at 0x80c0a80f = dmu_read+0xbf zfs_freebsd_getpages() at 0x80c6c9b5 = zfs_freebsd_getpages+0x8c5 VOP_GETPAGES_APV() at 0x805a6618 = VOP_GETPAGES_APV+0xe8 vnode_pager_getpages() at 0x80523c09 = vnode_pager_getpages+0xb9 vm_fault() at 0x8050a67a = vm_fault+0xf5a trap_pfault() at 0x80545d6f = trap_pfault+0x11f trap() at 0x80546448 = trap+0x4a8 calltrap() at 0x80530628 = calltrap+0x8 (kgdb) bt #0 doadump () at pcpu.h:224 #1 0x8036fc9a in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:306 #2 0x80370668 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:609 #3 0x80507850 in uma_zalloc_arg (zone=0xff00071c6e00, udata=0xff00071c8380, flags=2) at /usr/src/sys/vm/uma_core.c:2132 #4 0x80dac385 in kmem_cache_alloc (cache=Variable cache is not available. ) at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_kmem.c:196 #5 0x80c016e4 in arc_buf_alloc (spa=0xff00071e5000, size=131072, tag=Variable tag is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1344 #6 0x80c0389d in arc_read_nolock (pio=0x0, spa=0xff00071e5000, bp=0xff8002c71e80, done=0, private=0x0, priority=6, zio_flags=3, arc_flags=0xff812673b2bc, zb=0xff812673b280) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2931 #7 0x80c03dff in arc_read (pio=0x0, spa=0xff00071e5000, bp=0xff8002c71e80, pbuf=0xff00abaa31b0, done=0, private=0x0, priority=6, zio_flags=3, arc_flags=0xff812673b2bc, zb=0xff812673b280) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2832 #8 0x80c0826a in dbuf_prefetch (dn=0xff00b440f000, blkid=221) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1641 #9 0x80c21444 in dmu_zfetch_dofetch (zf=0xff00b440f2b8, zs=0xff0126bb6480) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_zfetch.c:308 #10 0x80c21c89 in dmu_zfetch (zf=0xff00b440f2b8, offset=Variable offset is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_zfetch.c:526 #11 0x80c06c04 in dbuf_read (db=0xff0031970b60, zio=0xff0078bb2328, flags=54) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:568 #12 0x80c0a58d in dmu_buf_hold_array_by_dnode (dn=0xff00b440f000, offset=Variable offset is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:235 #13 0x80c0a80f in dmu_read (os=Variable os is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:572 #14 0x80c6c9b5 in zfs_freebsd_getpages (ap=Variable ap is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4348 #15 0x805a6618 in VOP_GETPAGES_APV (vop=0x80cd8680, a=0xff812673b740) at vnode_if.c:2666 #16 0x80523c09 in vnode_pager_getpages (object=Variable object is not available. ) at vnode_if.h:1154 #17 0x8050a67a in vm_fault (map=0xff00ab3d5c40, vaddr=35585523712, fault_type=1 '\001', fault_flags=Variable fault_flags is not available. ) at vm_pager.h:130 #18 0x80545d6f in trap_pfault (frame=0xff812673bc40, usermode=1) at /usr/src/sys/amd64/amd64/trap.c:729 #19 0x80546448 in trap (frame=0xff812673bc40) at /usr/src/sys/amd64/amd64/trap.c:403 #20 0x80530628 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #21 0x000800858fe6 in ?? () -- Andriy Gapon ___
Re: another fuse panic
on 08/11/2010 14:13 Andriy Gapon said the following: on 08/11/2010 13:55 Andriy Gapon said the following: I reliable got this panic when all I was doing is saving an attachment in thunderbird 3 that ran in KDE 4 environment. Not sure what was going on behind the scenes, but shouldn't have been anything out of the ordinary. Perhaps this is my local mistake. I can't see from code and crash dump how NULL pointer is possible there. So perhaps I have some ABI mismatch between kernel and fuse module. I will rebuild fuse kmod and re-test again. Yes, the rebuild has helped. I wish this could be nicely automated. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: uma_zalloc_arg: Returning an empty bucket.
on 10/11/2010 07:58 Andriy Gapon said the following: I've been doing some stress-testing for VM+ZFS on a kernel with WITNESS+INVARIANTS and I have already stumbled into some curious panics. Here's another one: Unread portion of the kernel message buffer: panic: uma_zalloc_arg: Returning an empty bucket. Looks like this particular panic was caused by my local changes for draining per-CPU caches in very low memory conditions. cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at 0x801b8b3a = db_trace_self_wrapper+0x2a kdb_backtrace() at 0x803a7a8a = kdb_backtrace+0x3a panic() at 0x80370632 = panic+0x1d2 uma_zalloc_arg() at 0x80507850 = uma_zalloc_arg+0x300 kmem_cache_alloc() at 0x80dac385 = kmem_cache_alloc+0x15 arc_buf_alloc() at 0x80c016e4 = arc_buf_alloc+0x34 arc_read_nolock() at 0x80c0389d = arc_read_nolock+0x2bd arc_read() at 0x80c03dff = arc_read+0x7f dbuf_prefetch() at 0x80c0826a = dbuf_prefetch+0x15a dmu_zfetch_dofetch() at 0x80c21444 = dmu_zfetch_dofetch+0x104 dmu_zfetch() at 0x80c21c89 = dmu_zfetch+0x5e9 dbuf_read() at 0x80c06c04 = dbuf_read+0x454 dmu_buf_hold_array_by_dnode() at 0x80c0a58d = dmu_buf_hold_array_by_dnode+0x27d dmu_read() at 0x80c0a80f = dmu_read+0xbf zfs_freebsd_getpages() at 0x80c6c9b5 = zfs_freebsd_getpages+0x8c5 VOP_GETPAGES_APV() at 0x805a6618 = VOP_GETPAGES_APV+0xe8 vnode_pager_getpages() at 0x80523c09 = vnode_pager_getpages+0xb9 vm_fault() at 0x8050a67a = vm_fault+0xf5a trap_pfault() at 0x80545d6f = trap_pfault+0x11f trap() at 0x80546448 = trap+0x4a8 calltrap() at 0x80530628 = calltrap+0x8 (kgdb) bt #0 doadump () at pcpu.h:224 #1 0x8036fc9a in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:306 #2 0x80370668 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:609 #3 0x80507850 in uma_zalloc_arg (zone=0xff00071c6e00, udata=0xff00071c8380, flags=2) at /usr/src/sys/vm/uma_core.c:2132 #4 0x80dac385 in kmem_cache_alloc (cache=Variable cache is not available. ) at /usr/src/sys/modules/opensolaris/../../cddl/compat/opensolaris/kern/opensolaris_kmem.c:196 #5 0x80c016e4 in arc_buf_alloc (spa=0xff00071e5000, size=131072, tag=Variable tag is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1344 #6 0x80c0389d in arc_read_nolock (pio=0x0, spa=0xff00071e5000, bp=0xff8002c71e80, done=0, private=0x0, priority=6, zio_flags=3, arc_flags=0xff812673b2bc, zb=0xff812673b280) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2931 #7 0x80c03dff in arc_read (pio=0x0, spa=0xff00071e5000, bp=0xff8002c71e80, pbuf=0xff00abaa31b0, done=0, private=0x0, priority=6, zio_flags=3, arc_flags=0xff812673b2bc, zb=0xff812673b280) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:2832 #8 0x80c0826a in dbuf_prefetch (dn=0xff00b440f000, blkid=221) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1641 #9 0x80c21444 in dmu_zfetch_dofetch (zf=0xff00b440f2b8, zs=0xff0126bb6480) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_zfetch.c:308 #10 0x80c21c89 in dmu_zfetch (zf=0xff00b440f2b8, offset=Variable offset is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_zfetch.c:526 #11 0x80c06c04 in dbuf_read (db=0xff0031970b60, zio=0xff0078bb2328, flags=54) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:568 #12 0x80c0a58d in dmu_buf_hold_array_by_dnode (dn=0xff00b440f000, offset=Variable offset is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:235 #13 0x80c0a80f in dmu_read (os=Variable os is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:572 #14 0x80c6c9b5 in zfs_freebsd_getpages (ap=Variable ap is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:4348 #15 0x805a6618 in VOP_GETPAGES_APV (vop=0x80cd8680, a=0xff812673b740) at vnode_if.c:2666 #16 0x80523c09 in vnode_pager_getpages (object=Variable object is not available. ) at vnode_if.h:1154 #17 0x8050a67a in vm_fault (map=0xff00ab3d5c40, vaddr=35585523712, fault_type=1 '\001', fault_flags=Variable fault_flags is not available. ) at vm_pager.h:130 #18 0x80545d6f in trap_pfault (frame=0xff812673bc40, usermode=1) at /usr/src/sys/amd64/amd64/trap.c:729 #19
[head tinderbox] failure on mips/mips
TB --- 2010-11-10 07:31:37 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 07:31:37 - starting HEAD tinderbox run for mips/mips TB --- 2010-11-10 07:31:37 - cleaning the object tree TB --- 2010-11-10 07:31:46 - cvsupping the source tree TB --- 2010-11-10 07:31:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-11-10 07:32:02 - building world TB --- 2010-11-10 07:32:02 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 07:32:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 07:32:02 - TARGET=mips TB --- 2010-11-10 07:32:02 - TARGET_ARCH=mips TB --- 2010-11-10 07:32:02 - TZ=UTC TB --- 2010-11-10 07:32:02 - __MAKE_CONF=/dev/null TB --- 2010-11-10 07:32:02 - cd /src TB --- 2010-11-10 07:32:02 - /usr/bin/make -B buildworld /src/Makefile.inc1, line 138: Unknown target mips:mips. *** Error code 1 Stop in /src. TB --- 2010-11-10 07:32:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 07:32:03 - ERROR: failed to build world TB --- 2010-11-10 07:32:03 - 2.52 user 10.20 system 25.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-11-10 07:52:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-10 07:52:29 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-11-10 07:52:29 - cleaning the object tree TB --- 2010-11-10 07:52:59 - cvsupping the source tree TB --- 2010-11-10 07:52:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-11-10 07:53:18 - building world TB --- 2010-11-10 07:53:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-10 07:53:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-10 07:53:18 - TARGET=powerpc TB --- 2010-11-10 07:53:18 - TARGET_ARCH=powerpc64 TB --- 2010-11-10 07:53:18 - TZ=UTC TB --- 2010-11-10 07:53:18 - __MAKE_CONF=/dev/null TB --- 2010-11-10 07:53:18 - cd /src TB --- 2010-11-10 07:53:18 - /usr/bin/make -B buildworld World build started on Wed Nov 10 07:53:19 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools [...] cc -o rtermcap /src/usr.sbin/sysinstall/rtermcap.c -ltermcap === gnu/usr.bin/cc/cc_tools (obj,depend,all) LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-gather.awk /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/c.opt /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/common.opt /src/gnu/usr.bin/cc/cc_tools/freebsd.opt optionlist LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opth-gen.awk optionlist options.h LC_ALL=C awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/opt-functions.awk -f /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/optc-gen.awk -v header_name=config.h system.h coretypes.h tm.h optionlist options.c TARGET_CPU_DEFAULT=\powerpc64\ HEADERS=auto-host.h ansidecl.h DEFINES= /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh bconfig.h TARGET_CPU_DEFAULT=\powerpc64\ HEADERS=options.h rs600064/rs600064.h dbxelf.h elfos-undef.h elfos.h freebsd-native.h freebsd-spec.h freebsd.h rs600064/biarch64.h rs600064/default64.h rs600064/freebsd.h defaults.h DEFINES= /bin/sh /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/mkconfig.sh tm.h make: don't know how to make /src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/rs600064/rs600064.c. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-11-10 07:58:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-11-10 07:58:19 - ERROR: failed to build world TB --- 2010-11-10 07:58:19 - 206.66 user 69.12 system 350.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
