Re: SUJ update
On Thu, Apr 29, 2010 at 06:37:00PM -1000, Jeff Roberson wrote: > Hello, > > I fixed a few SUJ bugs. If those of you who reported one of the > following bugs could re-test I would greatly appreciate it. > I've noticed that when trying to enable a feature on a mounted filesystem tunefs gives a bogus warning about fsck not having been run because the fs_clean flag is 0. Could we fix the warning so it mentions not being able to run it on a mounted filesystem too? -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: if_re regression on RELENG_8
On Sat, May 08, 2010 at 01:53:34AM +0300, McLone wrote: > On Fri, May 7, 2010 at 11:53 PM, Pyun YongHyeon wrote: > >> So the thing is, re0 stops working after sending any packet > >> longer than 536 bytes. I tested via ping, -S (536-8) works, > >> but (537-8) leads to watchdog timeout. The host cannot be > >> software rebooted in ~80% cases after it happened. > > Would you try attached patch? > Indeed it helped. > Thank you Pyun! You are fast as always! > That's what i call "support" :-) Fixed at r207763. Thanks for testing! ___ 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: if_re regression on RELENG_8
On Fri, May 7, 2010 at 11:53 PM, Pyun YongHyeon wrote: >> So the thing is, re0 stops working after sending any packet >> longer than 536 bytes. I tested via ping, -S (536-8) works, >> but (537-8) leads to watchdog timeout. The host cannot be >> software rebooted in ~80% cases after it happened. > Would you try attached patch? Indeed it helped. Thank you Pyun! You are fast as always! That's what i call "support" :-) -- wbr,|\ _,,,---,,_ dog bless ya! ` Zzz /,`.-'`'-. ;-;;,_ McLone at GMail dot com|,4- ) )-,_. ,\ ( `'-' net- and *BSD admin '---''(_/--' `-'\_) ...translit rawx! ___ 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"
PT_ATTACH resumes suspended process
If a debugger attaches to a suspended process, the process will be
resumed, and backgrounded. This seems like the incorrect behavior to me
based what I read in the man page. "The tracing process will see the
newly-traced process stop and may then control it as if it had been
traced all along."
The behavior exhibited in FreeBSD is that the process is resumed, and we
will not reach ptracestop() until the next debugger command comes in.
The exact code in question I believe is a combination of kern_ptrace()
and issignal(). When a PT_ATTACH comes in, ptrace code will unsuspend the
process and set xsig=SIGSTOP of the thread picked to communicate with the
debugger (which by the way should be the same as the thread chosen to
deliver the SIGSTOP earlier, and I see no guarantee of this either but I
may be missing something). The thread will resume in issignal, and may
not have any signals pending, so issignal will return 0. The result here is
every thread gets unsuspended until the debugger explicitly suspends.
There is even a comment in kern_ptrace() for which I see no action:
/* deliver or queue signal */
I've created a quick hack to enable debugging to work how I think it
should. Essentially the change is as follows, there are a couple
other bits as well; line 2524 kern_sig.c, in issignal():
if (traced && !sig) {
/*
* see if we were given a signal by sendsig in kern_ptrace()
*/
sig = td->td_xsig;
}
You can reproduce this with a simple app that spins forever doing
something. In one shell, run the app and from another shell send a
SIGSTOP and attach with gdb. I've only tried this on FreeBSD 8.0-RELEASE,
but judging by the code it seems like it would still happen in HEAD.
:::SHELL1:::
[bwida...@bwfbsd ~/workspace/C/debugg]$ ./a.out
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[1]+ Stopped ./a.out
[bwida...@bwfbsd ~/workspace/C/debugg]$ 21
22
:::SHELL2:::
[bwida...@bwfbsd ~/workspace/C/debugg]$ kill -SIGSTOP 4134
[bwida...@bwfbsd ~/workspace/C/debugg]$ gdb a.out 4134
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Attaching to program: /usr/home/bwidawsk/workspace/C/debugg/a.out, process 4134
___
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: if_re regression on RELENG_8
On Fri, May 07, 2010 at 05:55:02PM +0300, McLone wrote:
> Hell Low.
>
> When Vista finally died on my girl's notebook,
> she asked me to install FreeBSD on it, so no more viruses.
> I installed RELENG_8_0/i386, to compile fresh RELENG_8/amd64
> in hopes SUJ will be availible (2gb RAM is kinda too small for ZFS).
>
> I've built custom kernel (GENERIC with unneeded things nodevice'd)
> and rebooted it, kldload if_re, ifcionfig, so ping started to work.
> I then attempted to mount_nfs, but it hung.
> "re0: watchdog timeout" appeared on console.
>
> So the thing is, re0 stops working after sending any packet
> longer than 536 bytes. I tested via ping, -S (536-8) works,
> but (537-8) leads to watchdog timeout. The host cannot be
> software rebooted in ~80% cases after it happened.
>
> Machine in question is Fujitsu-Siemens Amilo Pi 2540.
> The lines from RELENG_8 dmesg are:
>
> re0: port
> 0x3000-0x30ff mem 0xf030-0xf0300fff irq 19 at device 0.0 on pci5
> re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xf030
> re0: MSI count : 2
> re0: attempting to allocate 1 MSI vectors (2 supported)
> re0: using IRQ 256 for MSI
> re0: Using 1 MSI messages
> re0: Chip rev. 0x3400
> re0: MAC rev. 0x
> miibus0: on re0
> re0: bpf attached
> re0: Ethernet address: 00:03:0d:a1:a8:19
> re0: [MPSAFE]
> re0: [FILTER]
>
> Those lines in RELENG_8_0 are the same except IRQ 259
> (i kldload if_re after boot).
> RELENG_8 is from 2010.05.04 i believe;
> had tried with sources as of 2 or 3 weeks earlier - same bug.
> No CFLAGS except -mtune=native (i doubt it does the weather).
> It doesn't matter if i kldload or just use GENERIC.
>
> How can i test further, except building fresh RELENG_8/i386?
> How to use a magic "DDB key" and what to input in there?
>
Would you try attached patch?
Index: sys/dev/re/if_re.c
===
--- sys/dev/re/if_re.c (revision 207747)
+++ sys/dev/re/if_re.c (working copy)
@@ -1162,9 +1162,11 @@
msic = 0;
if (pci_find_extcap(dev, PCIY_EXPRESS, ®) == 0) {
sc->rl_flags |= RL_FLAG_PCIE;
- /* Set PCIe maximum read request size to 2048. */
- if (pci_get_max_read_req(dev) < 2048)
- pci_set_max_read_req(dev, 2048);
+ if (devid != RT_DEVICEID_8101E) {
+ /* Set PCIe maximum read request size to 2048. */
+ if (pci_get_max_read_req(dev) < 2048)
+pci_set_max_read_req(dev, 2048);
+ }
msic = pci_msi_count(dev);
if (bootverbose)
device_printf(dev, "MSI count : %d\n", msic);
___
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: ZFS Stability & MySQL (Comments Requested)
Hi, just chirping in; we've upgraded a bunch of old 6.x servers to 8.0 with ZFS. This is a pair of HP DL385 G1s (dual opteron, old stuff) with SmartArray controllers, which had absolutely horrible performance in both 6.0 and 8.0. The drive array gave us ~25 mbyte/s sustained, which is obviously abysmal for U320/15k SCSI drives backed by hardware RAID and cache. We ended up splitting the hardware RAID into single drives, and using ZFS/RaidZ. We suddenly got around 45 mbye/s (still bad) per channel, adding up nicely when benchmarking the RaidZ volume. MySQL now performs much better than before, and we've enabled compression (gzip-2) and fixed block sizes. Compression ratio is about 1.7:1, transaction latency on the database (as seen from application) has gone down by about 65% on average. We see anything between 300 and 2000 queries/second throughout the day, and our active dataset is about 500GB. The servers have 8GB of memory. /Eirik On Apr 29, 2010, at 4:31 PM, Jason J. W. Williams wrote: > Hi Y'all, > > I've written before that we're considering moving to FreeBSD 8 from > OpenSolaris and are heavily reliant on ZFS. Has anyone used FreeBSDs > ZFS implementation for a high reliability environment like a database? > If so, what are your experiences? > > Basically, I'm curious how stable the implementation is and whether > it's ready for a critical production environment. Also, any gotchas > particularly with running it with MySQL or anything else that utilizes > a lot of memory. On Solaris, we cap the max ARC size to keep it from > grabbing all the system RAM and competing with MySQL. > > Any thoughts or comments are greatly appreciated. > > -J > ___ > 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: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
> > Hello Gustau, I'm so sorry for belated response that I had no time to > read and work email and wireless stuffs. > > Could you please test this symptom with attached patch? It looks in > CURRENT it missed to initialize a ratectl when it associates with AP. > The patch made the machine to panic. I think it happened when launching the supplicant. In fact, right now it works by putting the RF switch to OFF. As soon as I change it to ON the machine panics. It get a trap 12, with two reasons : page fault and "bufwrite, buffer is not busy?" I'm running 9.0/AMD64 from 1 of May (don't know exact svn revision). Do you want me to test anything else ? Regards, Gustau > regards, > Weongyo Jeong > > ___ > 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"
if_re regression on RELENG_8
Hell Low. When Vista finally died on my girl's notebook, she asked me to install FreeBSD on it, so no more viruses. I installed RELENG_8_0/i386, to compile fresh RELENG_8/amd64 in hopes SUJ will be availible (2gb RAM is kinda too small for ZFS). I've built custom kernel (GENERIC with unneeded things nodevice'd) and rebooted it, kldload if_re, ifcionfig, so ping started to work. I then attempted to mount_nfs, but it hung. "re0: watchdog timeout" appeared on console. So the thing is, re0 stops working after sending any packet longer than 536 bytes. I tested via ping, -S (536-8) works, but (537-8) leads to watchdog timeout. The host cannot be software rebooted in ~80% cases after it happened. Machine in question is Fujitsu-Siemens Amilo Pi 2540. The lines from RELENG_8 dmesg are: re0: port 0x3000-0x30ff mem 0xf030-0xf0300fff irq 19 at device 0.0 on pci5 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xf030 re0: MSI count : 2 re0: attempting to allocate 1 MSI vectors (2 supported) re0: using IRQ 256 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x3400 re0: MAC rev. 0x miibus0: on re0 re0: bpf attached re0: Ethernet address: 00:03:0d:a1:a8:19 re0: [MPSAFE] re0: [FILTER] Those lines in RELENG_8_0 are the same except IRQ 259 (i kldload if_re after boot). RELENG_8 is from 2010.05.04 i believe; had tried with sources as of 2 or 3 weeks earlier - same bug. No CFLAGS except -mtune=native (i doubt it does the weather). It doesn't matter if i kldload or just use GENERIC. How can i test further, except building fresh RELENG_8/i386? How to use a magic "DDB key" and what to input in there? p.s. I subscribed only to current@ so cc me if needed. -- wbr,|\ _,,,---,,_ dog bless ya! ` Zzz /,`.-'`'-. ;-;;,_ McLone at GMail dot com|,4- ) )-,_. ,\ ( `'-' net- and *BSD admin '---''(_/--' `-'\_) ...translit rawx! ___ 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: Revision 205728: broken bluetooth mouse support
Hi Kal, Thanks a lot for your patch! I`m apply this patch and my bt mouse work fine again! For Hans: > Which daemon is driving the BT mouse? bthidd patch for bthidd(8) works fine only WITH your patches for: lib/libusbhid/data.c sys/dev/usb/usb_hid.c sys/dev/usb/usbhid.h Thanks a lot! 2010/5/7 Kai Wang : > On Fri, May 07, 2010 at 01:58:13AM +0400, Alex Deiter wrote: >> Hi, >> >> Bluetooth mouse support is broken after Revision 205728: >> >> http://svn.freebsd.org/viewvc/base?view=revision&revision=205728 >> >> When I move the mouse - cursor stays in same place but moves the >> current position of the console. >> >> Proposed patch as an attachment. Could you please revew this ? > > Hi Alex, > > If we adopt your patch, usbhidctl(1) and usbhidaction(1) will be > broken again on device with multiple report IDs. > > Could you please try if the attached patch for the bthidd(8) > daemon works as well? > > Thanks, > Kai > -- -- Alex Deiter ___ 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: Revision 205728: broken bluetooth mouse support
On Fri, May 07, 2010 at 01:58:13AM +0400, Alex Deiter wrote:
> Hi,
>
> Bluetooth mouse support is broken after Revision 205728:
>
> http://svn.freebsd.org/viewvc/base?view=revision&revision=205728
>
> When I move the mouse - cursor stays in same place but moves the
> current position of the console.
>
> Proposed patch as an attachment. Could you please revew this ?
Hi Alex,
If we adopt your patch, usbhidctl(1) and usbhidaction(1) will be
broken again on device with multiple report IDs.
Could you please try if the attached patch for the bthidd(8)
daemon works as well?
Thanks,
Kai
Index: usr.sbin/bluetooth/bthidd/hid.c
===
--- usr.sbin/bluetooth/bthidd/hid.c (revision 207113)
+++ usr.sbin/bluetooth/bthidd/hid.c (working copy)
@@ -130,7 +130,7 @@ hid_interrupt(bthid_session_p s, uint8_t *data, in
hid_item_t h;
int32_t report_id, usage, page, val,
mouse_x, mouse_y, mouse_z, mouse_butt,
- mevents, kevents;
+ mevents, kevents, i;
assert(s != NULL);
assert(s->srv != NULL);
@@ -150,8 +150,8 @@ hid_interrupt(bthid_session_p s, uint8_t *data, in
}
report_id = data[1];
- data += 2;
- len -= 2;
+ data ++;
+ len --;
hid_device = get_hid_device(&s->bdaddr);
assert(hid_device != NULL);
@@ -202,17 +202,11 @@ hid_interrupt(bthid_session_p s, uint8_t *data, in
if (val && val < kbd_maxkey())
bit_set(s->keys1, val);
- data ++;
- len --;
-
- len = min(len, h.report_size);
- while (len > 0) {
+ for (i = 1; i < h.report_count; i++) {
+ h.pos += h.report_size;
val = hid_get_data(data, &h);
if (val && val < kbd_maxkey())
bit_set(s->keys1, val);
-
- data ++;
- len --;
}
}
break;
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: 64-bit quotas going in to head today
On 05/07/10 02:36, Kirk McKusick wrote: Dag-Erling Smørgrav and I have been working on updating the FFS quota system to support both traditional 32-bit and new 64-bit quotas (for those of you who want to put 2+Tb quotas on your users). By default quotas are not compiled into the kernel. To include them in your kernel configuration you need to specify: options QUOTA # Enable FFS quotas Just wondering - does the quota code have that much impact on the file system that it's still today left out of the GENERIC kernel? ___ 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: SUJ deadlock
On Fri, 7 May 2010, Fabien Thomas wrote: fixed/works a lot better for me. Thanks Fabien, I just committed this. Thanks everyone for the assistance finding bugs so far. Please let me know if you run into anything else. For now I don't know of any other than some feature/change requests for tunefs. Thanks, Jeff Applied and restarted portupgrade. Will tell you tomorrow. Fabien Le 6 mai 2010 ? 00:54, Jeff Roberson a ?crit : On Mon, 3 May 2010, Fabien Thomas wrote: Hi Jeff, I'm with r207548 now and since some days i've system deadlock. It seems related to SUJ with process waiting on suspfs or ppwait. I've also seen it stalled in suspfs, but this information is way better than what I was able to garner. I was only able to tell via ctrl-t on a stalled 'ls' process in a terminal before hard booting. Right now it occurs everytime I attempt to do the portmaster -a upgrade of X/KDE on this system. I've spotted this during multiple portupgrade -aR :) Can anyone who has experienced this hang test this patch: Thanks, Jeff Index: ffs_softdep.c === --- ffs_softdep.c (revision 207480) +++ ffs_softdep.c (working copy) @@ -9301,7 +9301,7 @@ hadchanges = 1; } /* Leave this inodeblock dirty until it's in the list. */ - if ((inodedep->id_state & (UNLINKED | DEPCOMPLETE)) == UNLINKED) + if ((inodedep->id_state & (UNLINKED | UNLINKONLIST)) == UNLINKED) hadchanges = 1; /* * If we had to rollback the inode allocation because of Fabien ___ 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" ___ 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: SUJ update - new panic - "ffs_copyonwrite: recursive call"
On Sun, 2 May 2010, Vladimir Grebenschikov wrote: Hi While 'make buildworld' kgdb /boot/kernel/kernel /var/crash/vmcore.13 GNU gdb 6.1.1 [FreeBSD] Hi Vladimir, I checked in a fix for this at revision 207742. If you can verify that it works for you it would be appreciated. Thanks! Jeff ... #0 0xc056b93c in doadump () (kgdb) bt #0 0xc056b93c in doadump () #1 0xc0489019 in db_fncall () #2 0xc0489411 in db_command () #3 0xc048956a in db_command_loop () #4 0xc048b3ed in db_trap () #5 0xc05985a4 in kdb_trap () #6 0xc06f8b5e in trap () #7 0xc06dd6eb in calltrap () #8 0xc059870a in kdb_enter () #9 0xc056c1d1 in panic () #10 0xc066d602 in ffs_copyonwrite () #11 0xc068742a in ffs_geom_strategy () #12 0xc05d8955 in bufwrite () #13 0xc0686e64 in ffs_bufwrite () #14 0xc067a8a2 in softdep_sync_metadata () #15 0xc068c568 in ffs_syncvnode () #16 0xc0681425 in softdep_prealloc () #17 0xc066592a in ffs_balloc_ufs2 () #18 0xc066a252 in ffs_snapblkfree () #19 0xc065eb9a in ffs_blkfree () #20 0xc0673de0 in freework_freeblock () #21 0xc06797c7 in handle_workitem_freeblocks () #22 0xc0679aaf in process_worklist_item () #23 0xc06821f4 in softdep_process_worklist () #24 0xc0682940 in softdep_flush () #25 0xc0542a00 in fork_exit () #26 0xc06dd760 in fork_trampoline () (kgdb) x/s panicstr 0xc07c2b80: "ffs_copyonwrite: recursive call" (kgdb) -- Vladimir B. Grebenschikov v...@fbsd.ru ___ 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: Problem with reboot
On Fri, May 7, 2010 at 12:33 AM, Garrett Cooper wrote: > On Thu, May 6, 2010 at 8:53 PM, Cy Schubert wrote: >> In message , >> Dmit >> ry Krivenok writes: >>> Hello! >>> >>> I have a trouble with my FreeBSD-CURRENT virtual machine running on VmWare >>> ESX server. >>> >>> uname -a prints: >>> FreeBSD host 9.0-CURRENT FreeBSD 9.0-CURRENT #16 r207299: Wed Apr 28 >>> 04:15:07 UTC 2010 r...@host:/usr/obj/usr/src/sys/GENERIC amd64 >>> >>> The problem lies in that FreeBSD hangs after "reboot" command. >>> I see the following on console: >>> http://www.freeimagehosting.net/image.php?8885b3c6ea.png >>> >>> Is it a known problem? >>> Are there any solutions? >>> >>> Thanks in advance! >> >> I'm experiencing the same on real hardware with AMD Sempron on an MCI >> board. On my system this occurs in i386 mode. As it's my testbed I have no >> such problems under 7.X or 8.X. I also have the same problem on my Acer >> 3623NWXMi laptop (with 1.6 GHz Pentium M CPU, 1.5 GB memory, and 120 GB >> hard disk upgrades, and the latest Acer 1.6 BIOS upgrade for this computer). > > Same here on a Dell 2950 server with 2 x X5670's, 8GB RAM, etc. I looked at the LOR a bit more closely, and I also saw this at boot, not just reboot. 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: Problem with reboot
On Thu, May 6, 2010 at 8:53 PM, Cy Schubert wrote: > In message , > Dmit > ry Krivenok writes: >> Hello! >> >> I have a trouble with my FreeBSD-CURRENT virtual machine running on VmWare >> ESX server. >> >> uname -a prints: >> FreeBSD host 9.0-CURRENT FreeBSD 9.0-CURRENT #16 r207299: Wed Apr 28 >> 04:15:07 UTC 2010 r...@host:/usr/obj/usr/src/sys/GENERIC amd64 >> >> The problem lies in that FreeBSD hangs after "reboot" command. >> I see the following on console: >> http://www.freeimagehosting.net/image.php?8885b3c6ea.png >> >> Is it a known problem? >> Are there any solutions? >> >> Thanks in advance! > > I'm experiencing the same on real hardware with AMD Sempron on an MCI > board. On my system this occurs in i386 mode. As it's my testbed I have no > such problems under 7.X or 8.X. I also have the same problem on my Acer > 3623NWXMi laptop (with 1.6 GHz Pentium M CPU, 1.5 GB memory, and 120 GB > hard disk upgrades, and the latest Acer 1.6 BIOS upgrade for this computer). Same here on a Dell 2950 server with 2 x X5670's, 8GB RAM, etc. 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"
