Re: fifo_listen: fchmod public/pickup: Invalid argument with postfix on today's current
On Sat, Feb 25, 2012 at 8:15 AM, Doug Barton do...@freebsd.org wrote: On 02/24/2012 21:00, Doug Barton wrote: I'm on today's -current (r232126) and I'm getting the error in the subject when trying to start postfix. I recompiled 2.9, and then tried 2.8 both give the same error. Backing out r232055 fixed this. Hi Doug, sorry for the breakage. It should be related to a behavior change in handling fo_chmod/fo_chown for named pipes due to r232055. Could you try the patch at http://www.trematerra.net/patches/fifo_chmod.patch to see if it fixes your issue with postfix? Thank you -- Gianni ___ 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: /sys/amd64/conf/DEFAULTS
On Tue, Nov 8, 2011 at 3:52 PM, O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Am 11/08/11 14:31, schrieb Chuck Burns: And for FBSD 10.0/amd64, it has been started to use a VFS-option for loading thread safe filesystems. That will be removed. see http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS -- Gianni ___ 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: sched_priority: invalid priority 2906: nice 0, ticks 122865664 ftick 516947 ltick 517947 tick pri 2726
On Mon, Nov 29, 2010 at 9:56 PM, Attilio Rao atti...@freebsd.org wrote: 2010/11/29 Alexander Motin m...@freebsd.org: On 29.11.2010 17:07, John Baldwin wrote: On Friday, November 26, 2010 4:38:49 pm David Rhodus wrote: I hit this panic on my NFS server. -DR coke.fun dumped core - see /var/crash/vmcore.2 Fri Nov 26 14:50:48 UTC 2010 FreeBSD coke.fun 9.0-CURRENT FreeBSD 9.0-CURRENT #14 r215800: Wed Nov 24 12:35:30 UTC 2010 r...@coke.fun:/usr/obj/usr/src/sys/GENERIC i386 panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664 ftick 516947 ltick 517947 tick pri 2726 I ran the numbers and assuming a hz of 1000, this requires you to have a very large value for ts_ticks (about (2726 * 24) 10). I suspect this is due to sched_tick() being invoked for a long idle sleep combined with the eventtimer changes. Can you go to frame 10 and 'p td-td_sched-ts_ticks'? As I can see, this is VirtualBox virtual machine. So it is still a question what side makes so large hole in sched_tick() on some CPUs. It could be interesting to get ktr(4) dump with KTR_SPARE2 mask: options KTR options ALQ options KTR_ALQ options KTR_ENTRIES=131072 options KTR_COMPILE=(KTR_SPARE2) options KTR_MASK=(KTR_SPARE2) I'm sure gianni (CC'ed) got this bug and got some conclusions on it before (maybe he also has a patch). I got it on QEMU and assumed that QEMU was not doing a proper job of distributing run-time amongst cores (so VirtualBox???). I figured out that sched_tick is being passed a huge number of ticks elapsed for the cpu at startup, in my case, by hardclock_anycpu (kern_clock.c). I haven't a patch only a dirty hack just to make sure we won't be running for more than 5s solid, if we have a huge number of ticks in input to sched_tick, which is something that ULE can still handle. Hope this helps. diff -r d16464301129 sys/kern/kern_clock.c --- a/sys/kern/kern_clock.c Thu Sep 23 11:56:35 2010 -0400 +++ b/sys/kern/kern_clock.c Sun Oct 03 17:53:39 2010 -0400 @@ -525,7 +525,7 @@ hardclock_anycpu(int cnt, int usermode) PROC_SUNLOCK(p); } thread_lock(td); - sched_tick(cnt); + sched_tick((cnt (hz*10)/2) ? cnt : (hz*10)/2); td-td_flags |= flags; thread_unlock(td); -- Giovanni Trematerra ___ 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 in uma_startup for many-core amd64 system
On Tue, Nov 2, 2010 at 2:11 PM, Andriy Gapon a...@freebsd.org wrote: on 01/11/2010 19:09 Giovanni Trematerra said the following: Here the patch that was in my mind. The patch doesn't implement dynamic slab size just allow to have a multipage slab to back uma_zone objects. I'm going to work more on the topic dynamic slab size soon. I tested the patch on qemu with -smp 32. I'm looking for real hw to test the patch on. Having only skimmed the patch I have a question - is this only used for internal zones? Application zones with large items still use off-page slabs? Yes, it is used only for internal zones. Other zones will go off-page as usual. -- Giovanni Trematerra ___ 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 in uma_startup for many-core amd64 system
On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon a...@freebsd.org wrote:
on 19/10/2010 00:01 Giovanni Trematerra said the following:
Your patch seems just a work around about initial slab size where the
keg is backed.
Well, setting aside my confusion with the terminology - yes, the patch is just
that, and precisely because I only tried to solve that particular problem.
Having dynamic slab sizes would allow to have the keg backed on a larger slab
without going OFFPAGE.
I agree in principle.
But without seeing code that implements that I can't guess if it would really
be
more efficient or more maintainable, i.e. more useful in general.
Still a very good idea.
Here the patch that was in my mind.
The patch doesn't implement dynamic slab size just allow
to have a multipage slab to back uma_zone objects.
I'm going to work more on the topic dynamic slab size soon.
I tested the patch on qemu with -smp 32.
I'm looking for real hw to test the patch on.
here some interesting output:
qemulab# vmstat -z | more
ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP
UMA Kegs: 208, 0, 149, 4, 149, 0, 0
UMA Zones: 4480, 0, 149, 0, 149, 0, 0
UMA Slabs: 568, 0, 836, 4,1187, 0, 0
UMA RCntSlabs: 568, 0, 202, 1, 202, 0, 0
UMA Hash: 256, 0, 2, 13, 3, 0, 0
qemulab# sysctl kern | grep cpu
kern.ccpu: 0
cpu count=32 mask=0x0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
28, 29, 30, 31/cpu
kern.smp.cpus: 32
kern.smp.maxcpus: 32
Any feedback will be appreciate.
--
Giovanni Trematerra
==
diff -r 36572cbc6817 sys/vm/uma_core.c
--- a/sys/vm/uma_core.c Tue Oct 05 04:49:04 2010 -0400
+++ b/sys/vm/uma_core.c Mon Nov 01 11:54:38 2010 -0400
@@ -930,27 +930,36 @@ startup_alloc(uma_zone_t zone, int bytes
{
uma_keg_t keg;
uma_slab_t tmps;
-
- keg = zone_first_keg(zone);
+ u_int16_t pages;
+
+ keg = zone_first_keg(zone);
+ pages = bytes / PAGE_SIZE;
+
+ /* Account for remainder */
+ if ((pages * PAGE_SIZE) bytes)
+ pages++;
+ KASSERT(pages 0, (startup_alloc can't reserve 0 pages\n));
/*
* Check our small startup cache to see if it has pages remaining.
*/
mtx_lock(uma_boot_pages_mtx);
- if ((tmps = LIST_FIRST(uma_boot_pages)) != NULL) {
- LIST_REMOVE(tmps, us_link);
+ do {
+ if ((tmps = LIST_FIRST(uma_boot_pages)) != NULL)
+ LIST_REMOVE(tmps, us_link);
+ } while (--pages tmps != NULL);
+ if (tmps != NULL) {
mtx_unlock(uma_boot_pages_mtx);
*pflag = tmps-us_flags;
return (tmps-us_data);
- }
+ } else if (booted == 0)
+ panic(UMA: Increase vm.boot_pages);
mtx_unlock(uma_boot_pages_mtx);
- if (booted == 0)
- panic(UMA: Increase vm.boot_pages);
/*
* Now that we've booted reset these users to their real allocator.
*/
#ifdef UMA_MD_SMALL_ALLOC
- keg-uk_allocf = uma_small_alloc;
+ keg-uk_allocf = (keg-uk_ppera 1) ? page_alloc : uma_small_alloc;
#else
keg-uk_allocf = page_alloc;
#endif
@@ -1163,7 +1172,7 @@ keg_small_init(uma_keg_t keg)
static void
keg_large_init(uma_keg_t keg)
{
- int pages;
+ u_int16_t pages;
KASSERT(keg != NULL, (Keg is null in keg_large_init));
KASSERT((keg-uk_flags UMA_ZFLAG_CACHEONLY) == 0,
@@ -1177,12 +1186,15 @@ keg_large_init(uma_keg_t keg)
keg-uk_ppera = pages;
keg-uk_ipers = 1;
+ keg-uk_rsize = keg-uk_size;
+
+ /* We can't do OFFPAGE if we're internal, bail out here. */
+ if (keg-uk_flags UMA_ZFLAG_INTERNAL)
+ return;
keg-uk_flags |= UMA_ZONE_OFFPAGE;
if ((keg-uk_flags UMA_ZONE_VTOSLAB) == 0)
keg-uk_flags |= UMA_ZONE_HASH;
-
- keg-uk_rsize = keg-uk_size;
}
static void
@@ -1301,7 +1313,8 @@ keg_ctor(void *mem, int size, void *udat
#endif
if (booted == 0)
keg-uk_allocf = startup_alloc;
- }
+ } else if (booted == 0 (keg-uk_flags UMA_ZFLAG_INTERNAL))
+ keg-uk_allocf = startup_alloc;
/*
* Initialize keg's lock (shared among zones).
@@ -1330,7 +1343,7 @@ keg_ctor(void *mem, int size, void *udat
if (totsize UMA_ALIGN_PTR)
totsize = (totsize ~UMA_ALIGN_PTR) +
(UMA_ALIGN_PTR + 1);
- keg-uk_pgoff = UMA_SLAB_SIZE - totsize;
+ keg-uk_pgoff = (UMA_SLAB_SIZE * keg-uk_ppera) - totsize;
if (keg-uk_flags UMA_ZONE_REFCNT)
totsize
Re: panic in uma_startup for many-core amd64 system
On Mon, Nov 1, 2010 at 8:14 PM, John Baldwin j...@freebsd.org wrote:
On Monday, November 01, 2010 1:09:22 pm Giovanni Trematerra wrote:
On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon a...@freebsd.org wrote:
on 19/10/2010 00:01 Giovanni Trematerra said the following:
Your patch seems just a work around about initial slab size where the
keg is backed.
Well, setting aside my confusion with the terminology - yes, the patch is
just
that, and precisely because I only tried to solve that particular problem.
Having dynamic slab sizes would allow to have the keg backed on a larger
slab
without going OFFPAGE.
I agree in principle.
But without seeing code that implements that I can't guess if it would
really be
more efficient or more maintainable, i.e. more useful in general.
Still a very good idea.
Here the patch that was in my mind.
The patch doesn't implement dynamic slab size just allow
to have a multipage slab to back uma_zone objects.
I'm going to work more on the topic dynamic slab size soon.
I tested the patch on qemu with -smp 32.
I'm looking for real hw to test the patch on.
here some interesting output:
qemulab# vmstat -z | more
ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP
UMA Kegs: 208, 0, 149, 4, 149, 0, 0
UMA Zones: 4480, 0, 149, 0, 149, 0, 0
UMA Slabs: 568, 0, 836, 4, 1187, 0, 0
UMA RCntSlabs: 568, 0, 202, 1, 202, 0, 0
UMA Hash: 256, 0, 2, 13, 3, 0, 0
qemulab# sysctl kern | grep cpu
kern.ccpu: 0
cpu count=32 mask=0x0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27,
28, 29, 30, 31/cpu
kern.smp.cpus: 32
kern.smp.maxcpus: 32
Any feedback will be appreciate.
--
Giovanni Trematerra
==
diff -r 36572cbc6817 sys/vm/uma_core.c
--- a/sys/vm/uma_core.c Tue Oct 05 04:49:04 2010 -0400
+++ b/sys/vm/uma_core.c Mon Nov 01 11:54:38 2010 -0400
@@ -930,27 +930,36 @@ startup_alloc(uma_zone_t zone, int bytes
{
uma_keg_t keg;
uma_slab_t tmps;
-
- keg = zone_first_keg(zone);
+ u_int16_t pages;
+
+ keg = zone_first_keg(zone);
+ pages = bytes / PAGE_SIZE;
+
+ /* Account for remainder */
+ if ((pages * PAGE_SIZE) bytes)
+ pages++;
+ KASSERT(pages 0, (startup_alloc can't reserve 0 pages\n));
You can use 'pages = howmany(bytes, PAGE_SIZE)' here.
Thanks for the hint.
Also, why did you make
pages a uint16_t instead of an int? An int is generally more convenient
unless you really need a uint16_t (and C99 spells it without an _ after the
leading 'u'.. FYI).
Uhm just to be coherent with field uk_ppera of struct keg, but I think
I can just use an int.
BTW is new code supposed to use C99 form even if the rest of the file
use u_int* form?
/*
* Check our small startup cache to see if it has pages remaining.
*/
mtx_lock(uma_boot_pages_mtx);
- if ((tmps = LIST_FIRST(uma_boot_pages)) != NULL) {
- LIST_REMOVE(tmps, us_link);
+ do {
+ if ((tmps = LIST_FIRST(uma_boot_pages)) != NULL)
+ LIST_REMOVE(tmps, us_link);
+ } while (--pages tmps != NULL);
+ if (tmps != NULL) {
mtx_unlock(uma_boot_pages_mtx);
*pflag = tmps-us_flags;
return (tmps-us_data);
- }
+ } else if (booted == 0)
+ panic(UMA: Increase vm.boot_pages);
mtx_unlock(uma_boot_pages_mtx);
- if (booted == 0)
- panic(UMA: Increase vm.boot_pages);
Probably best to make the pages test here explicit. Also, is there any reason
you can't do this as:
while (--pages 0) {
tmps = LIST_FIRST(uma_boot_pages);
if (tmps != NULL)
LIST_REMOVE(tmps, us_link);
else if (booted == 0)
panic(...);
}
Well, no, even if I'll need to initialize tmps to NULL otherwise the
compiler will
raise a warning.
do {} while(); might be still better than a while(){}. bytes parameter
will never be
zero so pages will always be at least one and KASSERT will catch some
wired behavior.
Anyway that looks to me more readable, thanks. I could add an else
break; just in
the few cases that pages is still 0 and tmps == NULL, that could
be useless though.
One question btw, how does this work since if you need to allocate more than 1
page it seems that the 'tmps' values for all but the last are simply ignored
and leaked?
When you extract one item from the list you have tmps-us_data
pointing to start address of the memory page. The pages are contiguous
in decrescent
order of address (see below) so when you extract 2 items the last one
Re: panic in uma_startup for many-core amd64 system
On Tue, Oct 19, 2010 at 8:55 AM, Andriy Gapon a...@freebsd.org wrote: Having dynamic slab sizes would allow to have the keg backed on a larger slab without going OFFPAGE. I agree in principle. But without seeing code that implements that I can't guess if it would really be more efficient or more maintainable, i.e. more useful in general. Still a very good idea. I'm going to work on that. Unfortunately I think that could take a long time to me. I hope someone will have some insight to share. -- Giovanni Trematerra ___ 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 in uma_startup for many-core amd64 system
On Mon, Oct 18, 2010 at 8:40 AM, Andriy Gapon a...@freebsd.org wrote: on 23/09/2010 21:25 Andriy Gapon said the following: Jeff, just for the kicks I tried to emulate a machine with 64 logical CPUs using qemu-devel port: qemu-system-x86_64 -smp sockets=4,cores=8,threads=2 ... It seems that FreeBSD agreed to recognize only first 32 CPUs, but it paniced anyway. Here's a backtrace: #34 0x804fe7f5 in zone_alloc_item (zone=0x80be1554, udata=0x80be1550, flags=1924) at /usr/src/sys/vm/uma_core.c:2506 #35 0x804ff35d in hash_alloc (hash=0xff001ffdb030) at /usr/src/sys/vm/uma_core.c:483 #36 0x804ff642 in keg_ctor (mem=Variable mem is not available. ) at /usr/src/sys/vm/uma_core.c:1396 #37 0x804fe91b in zone_alloc_item (zone=0x80a1f300, udata=0x80be1b60, flags=2) at /usr/src/sys/vm/uma_core.c:2544 #38 0x804ff92e in zone_ctor (mem=Variable mem is not available. ) at /usr/src/sys/vm/uma_core.c:1832 #39 0x804ffca4 in uma_startup (bootmem=0xff001ffac000, boot_pages=48) at /usr/src/sys/vm/uma_core.c:1741 #40 0x80514822 in vm_page_startup (vaddr=18446744071576817664) at /usr/src/sys/vm/vm_page.c:360 #41 0x805060c5 in vm_mem_init (dummy=Variable dummy is not available. ) at /usr/src/sys/vm/vm_init.c:118 #42 0x803258b9 in mi_startup () at /usr/src/sys/kern/init_main.c:253 #43 0x8017177c in btext () at /usr/src/sys/amd64/amd64/locore.S:81 [[[ Note: 1. Frame numbers are high because the backtrace is obtained via gdb remotely connected to qemu and also there is bunch of extra frames from DDB, etc. 2. Line numbers in uma_core. won't match those in FreeBSD tree, because I've doing some unrelated hacking in the file. ]]] The problem seems to be with creation of UMA Zones zone and keg. Because of the large number of processors, size argument in the following snippet is set to a value of 4480: args.name = UMA Zones; args.size = sizeof(struct uma_zone) + (sizeof(struct uma_cache) * (mp_maxid + 1)); Because of this, keg_ctor() calls keg_large_init(): else if ((keg-uk_size+UMA_FRITM_SZ) (UMA_SLAB_SIZE - sizeof(struct uma_slab))) keg_large_init(keg); else keg_small_init(keg); keg_large_init sets UMA_ZONE_OFFPAGE and UMA_ZONE_HASH flags for this keg. This leads to hash_alloc() being invoked from keg_ctor(): if (keg-uk_flags UMA_ZONE_HASH) hash_alloc(keg-uk_hash); But the problem is that UMA Hash zone is not created yet and thus the call leads to the panic. UMA Hash zone is the last of system zones created. Not sure what the proper fix here could/should be. Would it work to simply not set UMA_ZONE_HASH flag when UMA_ZFLAG_INTERNAL is set? And some final calculations. On the test system sizeof(struct uma_cache) is 128 bytes and (mp_maxid + 1) is 32, so it's already UMA_SLAB_SIZE = PAGE_SIZE = 4096. Here is a simple solution that seems to work: http://people.freebsd.org/~avg/uma-many-cpus.diff Not sure if it's the best we can do. I don't know if it makes sense I only want to raise a flag. Is it safe to call kmem_malloc() before bucket_init() during uma_startup() to reserve room for CPU caches? Reading the top uma_int.h comment, it seems that the best way to handle this issue would be to implement and allow for dynamic slab sizes. I'm also afraid that memory footprint will be larger than now. -- Trematerra Giovanni ___ 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 in uma_startup for many-core amd64 system
On Mon, Oct 18, 2010 at 4:18 PM, Andriy Gapon a...@freebsd.org wrote: on 18/10/2010 16:40 Giovanni Trematerra said the following: On Mon, Oct 18, 2010 at 8:40 AM, Andriy Gapon a...@freebsd.org wrote: on 23/09/2010 21:25 Andriy Gapon said the following: Jeff, just for the kicks I tried to emulate a machine with 64 logical CPUs using qemu-devel port: qemu-system-x86_64 -smp sockets=4,cores=8,threads=2 ... It seems that FreeBSD agreed to recognize only first 32 CPUs, but it paniced anyway. Here's a backtrace: #34 0x804fe7f5 in zone_alloc_item (zone=0x80be1554, udata=0x80be1550, flags=1924) at /usr/src/sys/vm/uma_core.c:2506 #35 0x804ff35d in hash_alloc (hash=0xff001ffdb030) at /usr/src/sys/vm/uma_core.c:483 #36 0x804ff642 in keg_ctor (mem=Variable mem is not available. ) at /usr/src/sys/vm/uma_core.c:1396 #37 0x804fe91b in zone_alloc_item (zone=0x80a1f300, udata=0x80be1b60, flags=2) at /usr/src/sys/vm/uma_core.c:2544 #38 0x804ff92e in zone_ctor (mem=Variable mem is not available. ) at /usr/src/sys/vm/uma_core.c:1832 #39 0x804ffca4 in uma_startup (bootmem=0xff001ffac000, boot_pages=48) at /usr/src/sys/vm/uma_core.c:1741 #40 0x80514822 in vm_page_startup (vaddr=18446744071576817664) at /usr/src/sys/vm/vm_page.c:360 #41 0x805060c5 in vm_mem_init (dummy=Variable dummy is not available. ) at /usr/src/sys/vm/vm_init.c:118 #42 0x803258b9 in mi_startup () at /usr/src/sys/kern/init_main.c:253 #43 0x8017177c in btext () at /usr/src/sys/amd64/amd64/locore.S:81 [[[ Note: 1. Frame numbers are high because the backtrace is obtained via gdb remotely connected to qemu and also there is bunch of extra frames from DDB, etc. 2. Line numbers in uma_core. won't match those in FreeBSD tree, because I've doing some unrelated hacking in the file. ]]] The problem seems to be with creation of UMA Zones zone and keg. Because of the large number of processors, size argument in the following snippet is set to a value of 4480: args.name = UMA Zones; args.size = sizeof(struct uma_zone) + (sizeof(struct uma_cache) * (mp_maxid + 1)); Because of this, keg_ctor() calls keg_large_init(): else if ((keg-uk_size+UMA_FRITM_SZ) (UMA_SLAB_SIZE - sizeof(struct uma_slab))) keg_large_init(keg); else keg_small_init(keg); keg_large_init sets UMA_ZONE_OFFPAGE and UMA_ZONE_HASH flags for this keg. This leads to hash_alloc() being invoked from keg_ctor(): if (keg-uk_flags UMA_ZONE_HASH) hash_alloc(keg-uk_hash); But the problem is that UMA Hash zone is not created yet and thus the call leads to the panic. UMA Hash zone is the last of system zones created. Not sure what the proper fix here could/should be. Would it work to simply not set UMA_ZONE_HASH flag when UMA_ZFLAG_INTERNAL is set? And some final calculations. On the test system sizeof(struct uma_cache) is 128 bytes and (mp_maxid + 1) is 32, so it's already UMA_SLAB_SIZE = PAGE_SIZE = 4096. Here is a simple solution that seems to work: http://people.freebsd.org/~avg/uma-many-cpus.diff Not sure if it's the best we can do. I don't know if it makes sense I only want to raise a flag. Is it safe to call kmem_malloc() before bucket_init() during uma_startup() to reserve room for CPU caches? Hmm, not sure what exactly you mean. Sorry, nevermind Reading the top uma_int.h comment, it seems that the best way to handle this issue would be to implement and allow for dynamic slab sizes. Again, not sure if I follow you, I don't see relation between per-cpu caches and dynamic slab size. Your patch seems just a work around about initial slab size where the keg is backed. Having dynamic slab sizes would allow to have the keg backed on a larger slab without going OFFPAGE. -- Giovanni Trematerra ___ 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
[PATCH] panic on boot with QEMU a multiple cpu emulated
Qemu 0.11.1 installed from port with -CURRENT as host, emulating 8 CPU on a 8-way box makes my FreeBSD -CURRENT guest kernel, panic with this bt at boot: panic: sched_priority: invalid priority 230: nice 0, ticks 2289712 ftick 353 ltick 1363 tick pri 50 cpuid = 7 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x182 sched_priority() at sched_priority+0x1f8 sched_clock() at sched_clock+0x136 statclock() at statclock+0xc6 handleevents() at handleevents+0xda timercb() at timercb+0x1cb lapic_handle_timer() at lapic_handle_timer+0xb2 Xtimerint() at Xtimerint+0x8d The panic is due a KASSERT in sched_priority (sched_ule.c) KASSERT(pri = PRI_MIN_TIMESHARE pri = PRI_MAX_TIMESHARE, (sched_priority: invalid priority %d: nice %d, ticks %d ftick %d ltick %d tick pri %d, pri, td-td_proc-p_nice, td-td_sched-ts_ticks, td-td_sched-ts_ftick, td-td_sched-ts_ltick, SCHED_PRI_TICKS(td-td_sched))); ts-ts_ticks is higher than what you could expect. I figured out that sched_tick is being passed a huge number of ticks elapsed for the cpu at startup by hardclock_anycpu (kern_clock.c). I assume that QEMU is not doing a proper job of distributing run-time amongst cores. My hack, below, will assure that we won't be running for more than 5s solid, if we have a huge number of ticks in input to sched_tick, which is something that ULE can still handle. I don't think it's worth to have the hack into the tree for now. I'm just posting it FYI. -- Gianni diff -r d16464301129 sys/kern/kern_clock.c --- a/sys/kern/kern_clock.c Thu Sep 23 11:56:35 2010 -0400 +++ b/sys/kern/kern_clock.c Sun Oct 03 17:53:39 2010 -0400 @@ -525,7 +525,7 @@ hardclock_anycpu(int cnt, int usermode) PROC_SUNLOCK(p); } thread_lock(td); - sched_tick(cnt); + sched_tick((cnt (hz*10)/2) ? cnt : (hz*10)/2); td-td_flags |= flags; thread_unlock(td); ___ 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
kernel micro-benchmarking framework
Hi all,
based on a work of rwatson@ about micro-benchmarking,
I managed to have a kernel module that exposes some sysctls.
Reading sysctl associated to test start the benchmark and print the results.
The code is split up in this way:
test.h, test.c
where the infrastructure work lives.
test_sync_timing.c
test_mem_timing.c
where the actual micro-benchmarks live:
I wrote some macros to simplify adding more benchmarks. (test.h)
The idea is to have a struct for every benchmark/test
struct timing_proc {
void (*setup)(void *); /* called before
starting timing */
void (*test)(void *); /* what we want
microbenchmark */
void (*tear_down)(void *); /* called after the end of timing */
void *args; /* pointer passed to
the above funcs */
};
and let an agnostic code deals with it.
Every test can specify a setup and tear_down function for
allocate/deallocate resources and a test function to benchmark things.
The great difference with Robert's code is that the test function cannot be
inline as it's a pointer to function. I don't know if that could
influence the results.
The test function is called with interrupt disabled.
We could further extent this framework to add regression test support.
You could get the code here:
http://www.trematerra.net/patches/timing.tbz
Feedback and reviews are welcome.
Thanks
--
Gianni
___
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: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
Sorry for top posting. I report just for the record the test that Garrett kindly did. On Wed, Mar 24, 2010 at 8:45 PM, Garrett Cooper yanef...@gmail.com wrote: The patch looks good for commit. No performance regression at boot, no functional regression when the keyboard's detached, and if I'm not mistaken it appears that performance actually improves at reboot (seems like the window between the final fs sync and the reboot is more along the lines of what's expected for a system that doesn't have the RAID card). Thanks! -Garrett On Sun, Mar 14, 2010 at 12:56 AM, Giovanni Trematerra giovanni.tremate...@gmail.com wrote: On Sat, Mar 13, 2010 at 4:33 AM, Garrett Cooper yanef...@gmail.com wrote: On Wed, Mar 10, 2010 at 9:58 PM, Garrett Cooper yanef...@gmail.c if you don't mind could you try this patch? Less dirty but always quick :) Thank you for your time. -- Gianni diff -r 69c84861a227 sys/dev/twa/tw_cl.h --- a/sys/dev/twa/tw_cl.h Thu Mar 11 16:18:11 2010 -0500 +++ b/sys/dev/twa/tw_cl.h Sat Mar 13 18:50:16 2010 -0500 @@ -66,6 +66,8 @@ #define TW_CLI_CTLR_STATE_RESET_PHASE1_IN_PROGRESS (15) /* G66 register write access bug needs to be worked around. */ #define TW_CLI_CTLR_STATE_G66_WORKAROUND_NEEDED (16) +/* Controller is shutting down. */ +#define TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS (17) /* Possible values of ctlr-ioctl_lock.lock. */ #define TW_CLI_LOCK_FREE 0x0 /* lock is free */ diff -r 69c84861a227 sys/dev/twa/tw_cl_init.c --- a/sys/dev/twa/tw_cl_init.c Thu Mar 11 16:18:11 2010 -0500 +++ b/sys/dev/twa/tw_cl_init.c Sat Mar 13 18:50:16 2010 -0500 @@ -598,6 +598,7 @@ tw_cl_shutdown_ctlr(struct tw_cl_ctlr_ha * and notify the controller that we are going down. */ ctlr-state = ~TW_CLI_CTLR_STATE_ACTIVE; + ctlr-state |= TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS; tw_cli_disable_interrupts(ctlr); diff -r 69c84861a227 sys/dev/twa/tw_cl_intr.c --- a/sys/dev/twa/tw_cl_intr.c Thu Mar 11 16:18:11 2010 -0500 +++ b/sys/dev/twa/tw_cl_intr.c Sat Mar 13 18:50:16 2010 -0500 @@ -75,9 +75,12 @@ tw_cl_interrupt(struct tw_cl_ctlr_handle if (ctlr == NULL) goto out; - /* If we get an interrupt while resetting, it is a shared - one for another device, so just bail */ - if (ctlr-state TW_CLI_CTLR_STATE_RESET_IN_PROGRESS) + /* + * If we get an interrupt while resetting or shutting down, + * it is a shared one for another device, so just bail + */ + if (ctlr-state TW_CLI_CTLR_STATE_RESET_IN_PROGRESS || + ctlr-state TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS) goto out; /* ___ 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: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
On Sat, Mar 13, 2010 at 4:33 AM, Garrett Cooper yanef...@gmail.com wrote: On Wed, Mar 10, 2010 at 9:58 PM, Garrett Cooper yanef...@gmail.c Apart from the typo above (s/ctrl/ctlr/), things work appropriately Oopss I'm sorry. now at reboot. The only problem is that bootup is really wonky now, because the RAID had a LOT of issues attaching to cam(4) (failed in 2/3 cold boot attempts); an additional branch condition may need to be added to the above if-statement if this change didn't take that into account. However, if the old behavior was incorrect and the new behavior is correct, s.t. the RAID controller demonstrating bus detection timeout issue that is occurring with a lot of USB devices and some RAID controllers today, this could be extremely problematic. if you don't mind could you try this patch? Less dirty but always quick :) Thank you for your time. -- Gianni diff -r 69c84861a227 sys/dev/twa/tw_cl.h --- a/sys/dev/twa/tw_cl.h Thu Mar 11 16:18:11 2010 -0500 +++ b/sys/dev/twa/tw_cl.h Sat Mar 13 18:50:16 2010 -0500 @@ -66,6 +66,8 @@ #define TW_CLI_CTLR_STATE_RESET_PHASE1_IN_PROGRESS (15) /* G66 register write access bug needs to be worked around. */ #define TW_CLI_CTLR_STATE_G66_WORKAROUND_NEEDED(16) +/* Controller is shutting down. */ +#define TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS (17) /* Possible values of ctlr-ioctl_lock.lock. */ #define TW_CLI_LOCK_FREE 0x0 /* lock is free */ diff -r 69c84861a227 sys/dev/twa/tw_cl_init.c --- a/sys/dev/twa/tw_cl_init.c Thu Mar 11 16:18:11 2010 -0500 +++ b/sys/dev/twa/tw_cl_init.c Sat Mar 13 18:50:16 2010 -0500 @@ -598,6 +598,7 @@ tw_cl_shutdown_ctlr(struct tw_cl_ctlr_ha * and notify the controller that we are going down. */ ctlr-state = ~TW_CLI_CTLR_STATE_ACTIVE; + ctlr-state |= TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS; tw_cli_disable_interrupts(ctlr); diff -r 69c84861a227 sys/dev/twa/tw_cl_intr.c --- a/sys/dev/twa/tw_cl_intr.c Thu Mar 11 16:18:11 2010 -0500 +++ b/sys/dev/twa/tw_cl_intr.c Sat Mar 13 18:50:16 2010 -0500 @@ -75,9 +75,12 @@ tw_cl_interrupt(struct tw_cl_ctlr_handle if (ctlr == NULL) goto out; - /* If we get an interrupt while resetting, it is a shared - one for another device, so just bail */ - if (ctlr-state TW_CLI_CTLR_STATE_RESET_IN_PROGRESS) + /* +* If we get an interrupt while resetting or shutting down, +* it is a shared one for another device, so just bail +*/ + if (ctlr-state TW_CLI_CTLR_STATE_RESET_IN_PROGRESS || + ctlr-state TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS) goto out; /* ___ 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: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
On Wed, Mar 10, 2010 at 11:07 PM, Tom Couch tom.couch.stor...@gmail.com wrote: Hi FreeBSD-current, I am available to maintain the twa driver, now that I am on this list. Let me know how I can help, Hi Tom, That's a good news to hear! You could take a look at GNATS database where problems are reported by the users and find out if there are any PRs open for twa driver. http://www.freebsd.org/cgi/query-pr-summary.cgi?query Many users post problem report to the list too, so stay tuned! Nonetheless you can post patches if you discover some bugs or if you'd like to improve the driver code. -- Gianni ___ 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: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
On Sun, Mar 7, 2010 at 11:24 AM, Garrett Cooper yanef...@gmail.com wrote: On Sun, Mar 7, 2010 at 2:07 AM, Garrett Cooper yanef...@gmail.com wrote: Hi Alexander and Hans, I recently did the following which generated a panic on a 9-CURRENT kernel compiled on the 26th: 1. Executed reboot 2. Removed keyboard. 3. Some time after `All buffers synced\nUptime: ...' was displayed, the keyboard was registered disconnected. 4. The interrupt was delivered to my twa(4) enabled card and the kernel panicked, like so: ugen2.2: Mitsumi Electric at usbus2 (disconnected) uhub8: at uhub2, port 1, addr 2 (disconnected) ugen2.3: Mitsumi Electric at usbus2 (disconnected) ukbd0: at uhub8, port 3, addr 3 (disconnected) uhid0: at uhub8, port 3, addr 3 (disconnected) panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/dev/twa/tw_cl_intr.c:88 cpuid = 1 KDB: enter: panic [thread pid 12 tid 100025 ] Stopped at kdb_enter+0x3d: movq $0,0x40289c(%rip) db I wish I could provide you with more details, but unfortunately I the USB bus isn't registering the fact that I'm reattaching the keyboard right now and the box won't reboot automatically :( (didn't set the right sysctl beforehand to panic automatically). I'll try and reproduce the issue again, but I was just wondering whether or not you guys had seen this problem before. Phew... it's reproducible with that kernel. Here's what I did exactly (because my original directions were incorrect): 1. Hit power button (for S5). 2. Disconnect keyboard RIGHT as `Uptime: ...' is displayed. Kernel panicked on my system again. Now to figure out if it still exists with a kernel compiled today, and also how to debug it if it still does exist :/... Thanks, -Garrett Hi Garrett, Could you please try the patch below and report back? Thank you diff -r cab6489de66d sys/dev/twa/tw_cl_intr.c --- a/sys/dev/twa/tw_cl_intr.cWed Mar 03 04:51:13 2010 -0500 +++ b/sys/dev/twa/tw_cl_intr.cWed Mar 10 06:29:05 2010 -0500 @@ -75,9 +75,12 @@ tw_cl_interrupt(struct tw_cl_ctlr_handle if (ctlr == NULL) goto out; - /* If we get an interrupt while resetting, it is a shared -one for another device, so just bail */ - if (ctlr-state TW_CLI_CTLR_STATE_RESET_IN_PROGRESS) + /* + * If we get an interrupt while resetting or shutting down, + * it is a shared one for another device, so just bail + */ + if (ctlr-state TW_CLI_CTLR_STATE_RESET_IN_PROGRESS || + (ctrl-state TW_CLI_CTLR_STATE_ACTIVE) == 0) goto out; /* ___ 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: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
On Sun, Mar 7, 2010 at 11:24 AM, Garrett Cooper yanef...@gmail.com wrote: On Sun, Mar 7, 2010 at 2:07 AM, Garrett Cooper yanef...@gmail.com wrote: Hi Alexander and Hans, I recently did the following which generated a panic on a 9-CURRENT kernel compiled on the 26th: 1. Executed reboot 2. Removed keyboard. 3. Some time after `All buffers synced\nUptime: ...' was displayed, the keyboard was registered disconnected. 4. The interrupt was delivered to my twa(4) enabled card and the kernel panicked, like so: ugen2.2: Mitsumi Electric at usbus2 (disconnected) uhub8: at uhub2, port 1, addr 2 (disconnected) ugen2.3: Mitsumi Electric at usbus2 (disconnected) ukbd0: at uhub8, port 3, addr 3 (disconnected) uhid0: at uhub8, port 3, addr 3 (disconnected) panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/dev/twa/tw_cl_intr.c:88 cpuid = 1 KDB: enter: panic [thread pid 12 tid 100025 ] Stopped at kdb_enter+0x3d: movq $0,0x40289c(%rip) db I wish I could provide you with more details, but unfortunately I the USB bus isn't registering the fact that I'm reattaching the keyboard right now and the box won't reboot automatically :( (didn't set the right sysctl beforehand to panic automatically). I'll try and reproduce the issue again, but I was just wondering whether or not you guys had seen this problem before. Phew... it's reproducible with that kernel. Here's what I did exactly (because my original directions were incorrect): 1. Hit power button (for S5). 2. Disconnect keyboard RIGHT as `Uptime: ...' is displayed. Kernel panicked on my system again. Now to figure out if it still exists with a kernel compiled today, and also how to debug it if it still does exist :/... I thinks that's a race in twa driver. You could unplug another USB device different from your keyboard and you should still got the panic. If you get the panic again try to show at least the following information: bt; show pcpu; show alllocks; show locks; ps Thank you -- Gianni ___ 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: [FAQ] FBSD on a USB stick
Instead of this patch people can use kern.cam.boot_delay
Just set a delay in ms.
That works on 8-STABLE too.
--
Gianni
On Mon, Mar 1, 2010 at 5:31 PM, Hans Petter Selasky hsela...@c2i.net wrote:
Hi,
Sometimes the USB sticks won't get detected in time. You can fix this by using
the following simple quick and dirty patch.
--HPS
==
--- sys/kern/vfs_mount.c (revision 204512)
+++ sys/kern/vfs_mount.c (local)
@@ -1656,6 +1656,8 @@
UMA_ALIGN_PTR, UMA_ZONE_NOFREE);
devfs_first();
+repeat:
+
/*
* We are booted with instructions to prompt for the root filesystem.
*/
@@ -1725,9 +1727,10 @@
* Everything so far has failed, prompt on the console if we haven't
* already tried that.
*/
- if (!asked)
- if (!vfs_mountroot_ask())
- goto mounted;
+ if (!asked) {
+ pause(WDISK, 1*hz);
+ goto repeat;
+ }
panic(Root mount failed, startup aborted.);
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic ia64 r204293
On Thu, Feb 25, 2010 at 2:14 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: I'm upgrading from 8.0-stable to 9.0-current. Got this panic. Any advice? Do you have options SMP in your custom kernel? Try to boot with GENERIC kernel. many thanks anton ## Loading.: FreeBSD Starting: FreeBSD Consoles: EFI console FreeBSD/ia64 EFI boot, Revision 2.1 (me...@mech-as28.men.bris.ac.uk, Thu Feb 25 10:06:10 GMT 2010) Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0xa5209d+0x1c6933 syms=[0x8+0x80400+0x8+0x751a2] \ Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Entering /boot/kernel/kernel at 0xe4078000... GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0 r204293: Thu Feb 25 12:38:11 GMT 2010 me...@mech-as28.men.bris.ac.uk:/usr/obj/usr/src/sys/ZEEV ia64 WARNING: WITNESS option enabled, expect reduced performance. CPU: Madison II (1600 Mhz Itanium 2) Origin = GenuineIntel Revision = 2 Features = 0x1LB real memory = 12849717248 (12254 MB) avail memory = 12585984000 (12002 MB) FPSWA Revision = 0x10012, Entry = 0xe040ffcc4050 ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 (20100121/tbfadt-625) ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 (20100121/tbfadt-625) acpi0: HP on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz iomem 0xff5c1004-0xff5c1007 on acpi0 cpu0: ACPI CPU on acpi0 acpi_tz0: Thermal Zone on acpi0 pcib0: ACPI Host-PCI bridge on acpi0 pci0: ACPI PCI bus on pcib0 ohci0: NEC uPD 9210 USB controller mem 0x80002000-0x80002fff irq 16 at device 1.0 on pci0 ohci0: [ITHREAD] usbus0: NEC uPD 9210 USB controller on ohci0 ohci1: NEC uPD 9210 USB controller mem 0x80001000-0x80001fff irq 17 at device 1.1 on pci0 ohci1: [ITHREAD] usbus1: NEC uPD 9210 USB controller on ohci1 ehci0: NEC uPD 720100 USB 2.0 controller mem 0x8000-0x80ff irq 18 at device 1.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 0.95 usbus2: NEC uPD 720100 USB 2.0 controller on ehci0 pci0: mass storage, ATA at device 2.0 (no driver attached) pcib1: ACPI Host-PCI bridge on acpi0 pci32: ACPI PCI bus on pcib1 mpt0: LSILogic 1030 Ultra4 Adapter port 0x2100-0x21ff mem 0x903a-0x903b,0x9038-0x9039 irq 27 at device 1.0 on pci32 mpt0: [ITHREAD] mpt0: MPI Version=1.2.12.0 mpt1: LSILogic 1030 Ultra4 Adapter port 0x2000-0x20ff mem 0x9036-0x9037,0x9034-0x9035 irq 28 at device 1.1 on pci32 mpt1: [ITHREAD] mpt1: MPI Version=1.2.12.0 em0: Intel(R) PRO/1000 Network Connection 6.9.25 port 0x2240-0x227f mem 0x9032-0x9033,0x9028-0x902f irq 29 at device 2.0 on pci32 em0: [FILTER] em0: Ethernet address: 00:13:21:5b:05:1c em1: Intel(R) PRO/1000 Network Connection 6.9.25 port 0x2200-0x223f mem 0x9030-0x9031 irq 30 at device 2.1 on pci32 em1: [FILTER] em1: Ethernet address: 00:13:21:5b:05:1d pcib2: ACPI Host-PCI bridge on acpi0 pci64: ACPI PCI bus on pcib2 pcib3: ACPI Host-PCI bridge on acpi0 pci96: ACPI PCI bus on pcib3 pcib4: ACPI Host-PCI bridge on acpi0 pci128: ACPI PCI bus on pcib4 pcib5: ACPI Host-PCI bridge on acpi0 pci192: ACPI PCI bus on pcib5 isp0: Qlogic ISP 2422 PCI FC-AL Adapter port 0xc000-0xc0ff mem 0xe004-0xe0040fff irq 71 at device 1.0 on pci192 isp0: [ITHREAD] pcib6: ACPI Host-PCI bridge on acpi0 pci224: ACPI PCI bus on pcib6 uart0: 16550 or compatible mem 0xf8051000-0xf805100f irq 82 at device 1.0 on pci224 uart0: [FILTER] puc0: HP Diva Serial [GSP] uart1: Non-standard ns8250 class UART with FIFOs on puc0 uart1: [FILTER] uart1: console (9600,n,8,1) uart2: Non-standard ns8250 class UART with FIFOs on puc0 uart2: [FILTER] uart3: Non-standard ns8250 class UART with FIFOs on puc0 uart3: [FILTER] vgapci0: VGA-compatible display port 0xe000-0xe0ff mem 0xf000-0xf7ff,0xf804-0xf804 at device 2.0 on pci224 uart4: 16550 or compatible iomem 0xff5e-0xff5e0007 irq 34 on acpi0 uart4: [FILTER] uart5: 16550 or compatible iomem 0xff5e2000-0xff5e2007 irq 35 on acpi0 uart5: [FILTER] uart5: debug port (9600,n,8,1) Timecounter ITC frequency 16 Hz quality 0 Timecounters tick every 1.000 msec IP Filter: v4.1.28 initialized. Default = block all, Logging = enabled usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 (xpt0:isp0:0:-1:-1): rescan already queued ugen0.1: NEC at usbus0 uhub0: NEC OHCI root
Re: panic ia64 r204293
forwarding to the list just for record. -- Gianni -- Forwarded message -- From: Anton Shterenlikht me...@bristol.ac.uk Date: Thu, Feb 25, 2010 at 3:14 PM Subject: Re: (no subject) To: Marc Lörner loer...@gmx.de Cc: giovanni.tremate...@gmail.com, freebsd-i...@freebsd.org, mar...@freebsd.org On Thu, Feb 25, 2010 at 03:02:41PM +0100, Marc Lörner wrote: On Thu, Feb 25, 2010 at 2:14 PM, Anton Shterenlikht me...@bristol.ac.uk wrote: I'm upgrading from 8.0-stable to 9.0-current. Got this panic. Any advice? Do you have options SMP in your custom kernel? Try to boot with GENERIC kernel. I think this is no problem because SMP is already turned on in GENERIC kernel. yes, my fault, I copied the kernel config file from my other UP box. All is well now. many thanks for your help anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: Virtualbox
On Tue, Feb 23, 2010 at 5:20 PM, Ian FREISLICH i...@clue.co.za wrote: Hi Has anyone managed to make Virtualbox work on 9-Current? Since installing 3.1.2-OSE VMs, all brand new, abort on startup. The last part of the log seems pertinent: 00:00:15.481 !!Assertion Failed!! 00:00:15.481 Expression: paPages[i].Phys != 0 paPages[i].Phys != NIL_RTHCPHYS !(paPages[i].Phys PAGE_OFFSET_MASK) 00:00:15.481 Location : /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox/VMM/MMHyper.cpp(610) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const char*, RTGCPTR64*) 00:00:15.482 i=0x0 Phys= Heap Does anyone have any ideas? Hi Ian, Are your arch i386? There should be a bug in virtualbox-ose-kmod driver (vboxdrv to be precise). vboxdrv passes to vtophys kernel macro, user virtual addresses instead of kernel ones. Without debug compilation you should experience freeze or reboot of the host machine. -- Gianni ___ 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: Virtualbox
On Wed, Feb 24, 2010 at 12:16 PM, Jacques Fourie jacques.fou...@gmail.com wrote: As a test you can apply the following mod to sys/i386/include/pmap.h and re-compile vboxdrv.ko. It fixed the problem for me but I'm by no means an expert on the i386 pmap stuff so use at your own risk. Also revert the change to pmap.h after re-compiling vboxdrv just so that you don't inadvertently break something else. Index: pmap.h === --- pmap.h (revision 204194) +++ pmap.h (working copy) @@ -296,7 +296,10 @@ * however, safe to use the old PDE because the page table * page is preserved by the promotion. */ - pa = KPTmap[i386_btop(va)]; + if (va = KERNBASE) + pa = KPTmap[i386_btop(va)]; + else + pa = *vtopte(va); pa = (pa PG_FRAME) | (va PAGE_MASK); } return (pa); pmap_kextract is intend to be used with kernel virtual addresses and not user virtual addresses. The problem lies in the driver not in the kernel. The vboxdrv call vtophys macro passing user virtual addresses through rtR0MemObjNativeGetPagePhysAddr and this is wrong. If you want a way to get virtualbox works try to revert this commit (r202894): http://www.mail-archive.com/svn-src-...@freebsd.org/msg19081.html If you don't use ZFS with superpages enable you have a good chance to get a work system until a patch to vboxdrv will be around. -- Gianni ___ 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: Virtualbox
2010/2/24 Bernhard Fröhlich de...@bluelife.at: Hi Has anyone managed to make Virtualbox work on 9-Current? Since installing 3.1.2-OSE VMs, all brand new, abort on startup. The last part of the log seems pertinent: 00:00:15.481 !!Assertion Failed!! 00:00:15.481 Expression: paPages[i].Phys != 0 paPages[i].Phys != NIL_RTHCPHYS !(paPages[i].Phys PAGE_OFFSET_MASK) 00:00:15.481 Location : /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox /VMM/MMHyper.cpp(610) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const char*, RTGCPTR64*) 00:00:15.482 i=0x0 Phys= Heap Does anyone have any ideas? Thanks for the report. I've talked to Alexander Eichner and he gave me a patch that could fix that problem. Could you please try to build the virtualbox-ose-kmod port with that patch? If it works we will include it in the port update coming quite soon. http://pastebin.ca/1808090 If that does not help please create a backtrace from the vbox coredump and send the vbox.log. There are other point in src/VBox/Runtime/r0drv/freebsd/memobj-r0drv-freebsd.c where vtophys is misused as in rtR0MemObjNativeGetPagePhysAddr. Using pmap_extract might be insufficient, what if the page will be swapped out? Thanks! -- Bernhard Fröhlich http://www.bluelife.at/ -- View this message in context: http://old.nabble.com/Virtualbox-tp27705983p27714203.html Sent from the freebsd-current mailing list archive at Nabble.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 ___ 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
