freebsd-stable Digest, Vol 351, Issue 9
freebsd-sta...@freebsd.org
freebsd...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
or, via email, send a message with subject or body 'help' to
freebsd-sta...@freebsd.org
You can reach the person managing the list at
freebsd-st...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-stable digest..."
Today's Topics:
1. Re: em driver regression (Mike Tancsa)
2. Re: CPU problems after 8.0-STABLE update (Attilio Rao)
3. Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
(Peter C. Lai)
4. Re: em driver regression (Pyun YongHyeon)
5. Re: em driver regression (Jack Vogel)
6. Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
(Pyun YongHyeon)
7. Re: binding on 127.0.0.1 not working after upgrade to 7.3
(Mykola Dzham)
8. Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
(Michael Beckmann)
9. Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
(Pyun YongHyeon)
10. LSI MegaRAID SAS 9211-8i on FreeBSD 8/9? (O. Hartmann)
11. Re: CPU problems after 8.0-STABLE update (Akephalos)
----------------------------------------------------------------------
Message: 1
Date: Fri, 09 Apr 2010 09:17:07 -0400
From: Mike Tancsa <mi...@sentex.net>
Subject: Re: em driver regression
To: pyu...@gmail.com, Jack Vogel <jfv...@gmail.com>
Cc: freebsd...@freebsd.org
Message-ID: <201004091317....@lava.sentex.ca>
Content-Type: text/plain; charset="us-ascii"; format=flowed
At 07:07 PM 4/8/2010, Pyun YongHyeon wrote:
>On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
> > Only one device support by em does multiqueue right now, and that is
> > Hartwell, 82574.
> >
>
>Thanks for the info.
>
>Mike, here is updated patch. Now UDP bulk TX transfer performance
>recovered a lot(about 890Mbps) but it still shows bad numbers
>compared to other controllers. For example, bce(4) shows about
>958Mbps for the same load.
>During the testing I found a strong indication of packet reordering
>issue of drbr interface. If I forcibly change to use single TX
>queue, em(4) got 950Mbps as it used to be.
>
>Jack, as we talked about possible drbr issue with igb(4), UDP
>transfer seems to suffer from packet reordering issue here. Can we
>make em(4)/igb(4) use single TX queue until we solve drbr interface
>issue? Given that only one em(4) controller supports multiqueue,
>dropping multiqueue support for em(4) does not look bad to me.
No watchdog errors over night. I wonder if the issue was due to
100Mb, or the patch from current fixed it. I will try today with the
new patch below! I am guessing the rejection was due to the RX/TX fix ?
---Mike
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: sys/dev/e1000/if_em.c
|===================================================================
|--- sys/dev/e1000/if_em.c (revision 206403)
|+++ sys/dev/e1000/if_em.c (working copy)
--------------------------
Patching file if_em.c using Plan A...
Hunk #1 succeeded at 812 with fuzz 2.
Hunk #2 succeeded at 834 (offset -4 lines).
Hunk #3 succeeded at 869 (offset -4 lines).
Hunk #4 succeeded at 913 (offset -4 lines).
Hunk #5 succeeded at 941 (offset -4 lines).
Hunk #6 succeeded at 1439 (offset -4 lines).
Hunk #7 succeeded at 1452 (offset -4 lines).
Hunk #8 succeeded at 1472 (offset -4 lines).
Hunk #9 succeeded at 1532 (offset -4 lines).
Hunk #10 succeeded at 1549 (offset -4 lines).
Hunk #11 failed at 1909.
Hunk #12 succeeded at 3617 (offset 2 lines).
Hunk #13 succeeded at 4069 (offset -6 lines).
Hunk #14 succeeded at 4087 (offset 2 lines).
Hunk #15 succeeded at 4187 (offset -6 lines).
1 out of 15 hunks failed--saving rejects to if_em.c.rej
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: sys/dev/e1000/if_em.h
|===================================================================
|--- sys/dev/e1000/if_em.h (revision 206403)
|+++ sys/dev/e1000/if_em.h (working copy)
--------------------------
Patching file if_em.h using Plan A...
Hunk #1 succeeded at 223.
done
1(ich10)# less if_em.c.rej
***************
*** 1908,1919 ****
bus_dmamap_sync(txr->txdma.dma_tag, txr->txdma.dma_map,
BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE);
E1000_WRITE_REG(&adapter->hw, E1000_TDT(txr->me), i);
- txr->watchdog_time = ticks;
- /* Call cleanup if number of TX descriptors low */
- if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD)
- em_txeof(txr);
-
return (0);
}
--- 1909,1915 ----
bus_dmamap_sync(txr->txdma.dma_tag, txr->txdma.dma_map,
BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE);
E1000_WRITE_REG(&adapter->hw, E1000_TDT(txr->me), i);
return (0);
}
0(ich10)#
> > Jack
> >
> >
> > On Thu, Apr 8, 2010 at 2:05 PM, Mike Tancsa <mi...@sentex.net> wrote:
> >
> > > At 04:56 PM 4/8/2010, Pyun YongHyeon wrote:
> > >
> > >> On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
> > >> > At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
> > >> >
> > >> > >Try this patch. It should fix the issue. It seems Jack forgot to
> > >> > >strip CRC bytes as old em(4) didn't strip it, probably to
> > >> > >workaround silicon bug of old em(4) controllers.
> > >> >
> > >> > Thanks! The attached patch does indeed fix the dhclient issue.
> > >> >
> > >> >
> > >> > >It seems there are also TX issues here. The system load is too high
> > >> > >and sometimes system is not responsive while TX is in progress.
> > >> > >Because I initiated TCP bulk transfers, TSO should reduce CPU load
> > >> > >a lot but it didn't so I guess it could also be related watchdog
> > >> > >timeouts you've seen. I'll see what can be done.
> > >> >
> > >> > Thanks for looking into that as well!!
> > >> >
> > >> > ---Mike
> > >> >
> > >>
> > >> Mike,
> > >>
> > >> Here is patch I'm working on. This patch fixes high system load and
> > >> system is very responsive as before. But it seems there is still
> > >> some TX issue here. Bulk UDP performance is very poor(< 700Mbps)
> > >> and I have no idea what caused this at this moment.
> > >>
> > >> BTW, I have trouble to reproduce watchdog timeouts. I'm not sure
> > >> whether latest fix from Jack cured it. By chance does your
> > >> controller support multi TX/RX queues? You can check whether em(4)
> > >> uses multi-queues with "vmstat -i". If em(4) use multi-queue you
> > >> may have multiple irq output for em0.
> > >>
> > >
> > > Hi,
> > > I will give it a try later tonight! This one does not seem to.
> > >
> > > 0(ich10)# vmstat -i
> > > interrupt total rate
> > > irq16: uhci0+ 30 0
> > > irq18: ehci0 uhci5 158419 17
> > > irq19: fwohci0++ 86 0
> > > irq21: uhci1 17 0
> > > irq23: uhci3 ehci1 2 0
> > > cpu0: timer 18570305 1994
> > > irq256: igb0 80 0
> > > irq257: igb0 255 0
> > > irq258: igb0 66 0
> > > irq259: igb0 32 0
> > > irq260: igb0 2 0
> > > irq261: igb1 2679 0
> > > irq262: igb1 998 0
> > > irq263: igb1 2468 0
> > > irq264: igb1 6361 0
> > > irq265: igb1 2 0
> > > irq266: em0 33910 3
> > > irq267: ahci1 15317 1
> > > cpu1: timer 18557074 1993
> > > cpu3: timer 18557168 1993
> > > cpu2: timer 18557108 1993
> > > Total 74462379 7998
> > > 0(ich10)#
> > >
>
--------------------------------------------------------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mi...@sentex.net
Providing Internet since 1994 www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
------------------------------
Message: 2
Date: Fri, 9 Apr 2010 16:28:03 +0200
From: Attilio Rao <att...@freebsd.org>
Subject: Re: CPU problems after 8.0-STABLE update
To: Jakub Lach <jakub...@mailplus.pl>
Cc: freebsd...@freebsd.org
Message-ID:
<w2i3bbf2fe11004090728r7...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2010/4/9 Jakub Lach <jakub...@mailplus.pl>:
>
>
>
> Andriy Gapon wrote:
>>
>>
>> Really shooting in the dark here: are there any BIOS options about HPET
>> and RTC on
>> this system? Can you try playing with them?
>>
>>
>
> Hello. I have similar problem. Once in few boots performance would be
> sluggish and
> top would be at 0%. It started on 4th April I think. After today's update,
> problem is persistent.
> Currently, as I type letters are appearing with considerable delay.
>
> I'm using HPET, 8-STABLE amd64 r206412
Ok, r206421 switches the default tunable for machdep.lapic_allclock in
order to enable atrtc usage only if it is properly turned off.
I will MFC in a week.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
------------------------------
Message: 3
Date: Fri, 9 Apr 2010 10:52:53 -0400
From: "Peter C. Lai" <pe...@simons-rock.edu>
Subject: Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
To: Michael Beckmann <mic...@apfel.de>
Cc: 'Adam Vande More' <amvan...@gmail.com>, sta...@freebsd.org
Message-ID: <20100409145...@cesium.hyperfine.info>
Content-Type: text/plain; charset=us-ascii
On 2010-04-09 12:10:16PM +0200, Michael Beckmann wrote:
>
> re0@pci0:4:0:0: class=0x020000 card=0x84321043 chip=0x816810ec rev=0x06
> hdr=0x00
> vendor = 'Realtek Semiconductor'
> device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)'
> class = network
> subclass = ethernet
>
> So I have rev=0x06 and you have rev=0x03. The dmesg output says I have an
> unknown H/W revision.
>
> The mainboard is fairly new. So I guess I have to report a bug and wait for
> a driver update?
>
> Thanks,
>
> Michael
>
Well you could patch the source yourself and see if it works. It's been
a while but you need to find the actual revision not the one that pciconf
prints out (I think if you select the verbose boot option it might
print it in dmesg), then add that "real" revision code to
/usr/src/sys/pci/if_rlreg.h, rebuild the kernel and go from there...
(Or file a PR and wait for Pyun to get back to you :)
--
===========================================================
Peter C. Lai | Bard College at Simon's Rock
Systems Administrator | 84 Alford Rd.
Information Technology Svcs. | Gt. Barrington, MA 01230 USA
peter AT simons-rock.edu | (413) 528-7428
===========================================================
------------------------------
Message: 4
Date: Fri, 9 Apr 2010 09:41:15 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: em driver regression
To: Mike Tancsa <mi...@sentex.net>
Cc: freebsd...@freebsd.org, Jack Vogel <jfv...@gmail.com>
Message-ID: <2010040916...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Fri, Apr 09, 2010 at 09:17:07AM -0400, Mike Tancsa wrote:
> At 07:07 PM 4/8/2010, Pyun YongHyeon wrote:
> >On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
> >> Only one device support by em does multiqueue right now, and that is
> >> Hartwell, 82574.
> >>
> >
> >Thanks for the info.
> >
> >Mike, here is updated patch. Now UDP bulk TX transfer performance
> >recovered a lot(about 890Mbps) but it still shows bad numbers
> >compared to other controllers. For example, bce(4) shows about
> >958Mbps for the same load.
> >During the testing I found a strong indication of packet reordering
> >issue of drbr interface. If I forcibly change to use single TX
> >queue, em(4) got 950Mbps as it used to be.
> >
> >Jack, as we talked about possible drbr issue with igb(4), UDP
> >transfer seems to suffer from packet reordering issue here. Can we
> >make em(4)/igb(4) use single TX queue until we solve drbr interface
> >issue? Given that only one em(4) controller supports multiqueue,
> >dropping multiqueue support for em(4) does not look bad to me.
>
> No watchdog errors over night. I wonder if the issue was due to
> 100Mb, or the patch from current fixed it. I will try today with the
> new patch below! I am guessing the rejection was due to the RX/TX fix ?
>
The patch was generated against latest HEAD. This includes Jack's
latest fix too so it may not be applied cleanly on stable/8.
I think you can use em(4) in HEAD.
------------------------------
Message: 5
Date: Fri, 9 Apr 2010 09:45:03 -0700
From: Jack Vogel <jfv...@gmail.com>
Subject: Re: em driver regression
To: pyu...@gmail.com
Cc: freebsd...@freebsd.org
Message-ID:
<g2u2a41acea1004090945p6...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Apr 9, 2010 at 9:41 AM, Pyun YongHyeon <pyu...@gmail.com> wrote:
> On Fri, Apr 09, 2010 at 09:17:07AM -0400, Mike Tancsa wrote:
> > At 07:07 PM 4/8/2010, Pyun YongHyeon wrote:
> > >On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
> > >> Only one device support by em does multiqueue right now, and that is
> > >> Hartwell, 82574.
> > >>
> > >
> > >Thanks for the info.
> > >
> > >Mike, here is updated patch. Now UDP bulk TX transfer performance
> > >recovered a lot(about 890Mbps) but it still shows bad numbers
> > >compared to other controllers. For example, bce(4) shows about
> > >958Mbps for the same load.
> > >During the testing I found a strong indication of packet reordering
> > >issue of drbr interface. If I forcibly change to use single TX
> > >queue, em(4) got 950Mbps as it used to be.
> > >
> > >Jack, as we talked about possible drbr issue with igb(4), UDP
> > >transfer seems to suffer from packet reordering issue here. Can we
> > >make em(4)/igb(4) use single TX queue until we solve drbr interface
> > >issue? Given that only one em(4) controller supports multiqueue,
> > >dropping multiqueue support for em(4) does not look bad to me.
> >
> > No watchdog errors over night. I wonder if the issue was due to
> > 100Mb, or the patch from current fixed it. I will try today with the
> > new patch below! I am guessing the rejection was due to the RX/TX fix ?
> >
>
> The patch was generated against latest HEAD. This includes Jack's
> latest fix too so it may not be applied cleanly on stable/8.
> I think you can use em(4) in HEAD.
>
Yes, you can. And I think its the code change not the
speed Mike.
Jack
------------------------------
Message: 6
Date: Fri, 9 Apr 2010 10:32:28 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
To: Michael Beckmann <mic...@apfel.de>
Cc: sta...@freebsd.org
Message-ID: <2010040917...@michelle.cdnetworks.com>
Content-Type: text/plain; charset="us-ascii"
On Fri, Apr 09, 2010 at 01:50:02AM +0200, Michael Beckmann wrote:
> Greetings,
>
>
>
> the onboard Realtek Ethernet on my Asus M4A89GTD PRO is not functioning.
>
>
>
> I use FreeBSD 8.0-STABLE with a generic kernel (amd64). Everything was
> updated March 27, 2010.
>
>
>
> Is it a bug?
>
>
>
> Thanks,
>
>
>
> Michael
>
>
>
>
>
> pcib4: <ACPI PCI-PCI bridge> at device 21.0 on pci0
>
> pci4: <ACPI PCI bus> on pcib4
>
> re0: <RealTek 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP
> PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem
> 0xfdfff000-0xfdffffff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4
>
> re0: Using 1 MSI messages
>
> re0: Chip rev. 0x2c000000
>
> re0: MAC rev. 0x00000000
>
> re0: Unknown H/W revision: 0x2c000000
>
> device_attach: re0 attach returned 6
>
Try attached patch and let me know how it goes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: re.8168E.diff
Type: text/x-diff
Size: 2953 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100409/82fe6d0a/re.8168E-0001.bin
------------------------------
Message: 7
Date: Fri, 9 Apr 2010 23:48:55 +0300
From: Mykola Dzham <i...@levsha.me>
Subject: Re: binding on 127.0.0.1 not working after upgrade to 7.3
To: "Mikhail T." <mi+...@aldan.algebra.com>
Cc: sta...@FreeBSD.org
Message-ID: <2010040920...@laptop.levsha.me>
Content-Type: text/plain; charset="koi8-r"
Mikhail T. wrote:
> Jeremy Chadwick �������(��):
> > Check ifconfig -a and make sure lo0 appears / has a correct IP address,
> > and the interface is up.
> >
> You are right, it is not up:
>
> lo0: flags=8008<LOOPBACK,MULTICAST> metric 0 mtu 16384
>
> Manually running `ifconfig lo0 127.0.0.1' fixed the problem for the time
> being...
>
> But why? What changed so significantly in the last few month, that lo0
> broke, of all things? :-)
Have you network_interfaces variable in /etc/rc.conf with manually
enumerated interfaces list (and without lo0 in this list)? Don't do
that, just remove this line.
--
LEFT-(UANIC|RIPE)
JID: lev...@jabber.net.ua
PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100409/4a3899cd/attachment-0001.pgp
------------------------------
Message: 8
Date: Sat, 10 Apr 2010 00:12:47 +0200
From: Michael Beckmann <mic...@apfel.de>
Subject: Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
To: pyu...@gmail.com
Cc: sta...@freebsd.org
Message-ID: <C5FB6BEDCE679BF318BDDAFA@[10.0.0.102]>
Content-Type: text/plain; charset=us-ascii; format=flowed
--On Freitag, 9. April 2010 10:32 -0700 Pyun YongHyeon <pyu...@gmail.com>
wrote:
> On Fri, Apr 09, 2010 at 01:50:02AM +0200, Michael Beckmann wrote:
>> Greetings,
>>
>> the onboard Realtek Ethernet on my Asus M4A89GTD PRO is not functioning.
>>
>> I use FreeBSD 8.0-STABLE with a generic kernel (amd64). Everything was
>> updated March 27, 2010.
>>
>> Is it a bug?
>>
>> Thanks,
>>
>> Michael
>>
>>
>> pcib4: <ACPI PCI-PCI bridge> at device 21.0 on pci0
>> pci4: <ACPI PCI bus> on pcib4
>> re0: <RealTek
>> 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP PCIe
>> Gigabit Ethernet> port 0xe800-0xe8ff mem
>> 0xfdfff000-0xfdffffff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4
>> re0: Using 1 MSI messages
>> re0: Chip rev. 0x2c000000
>> re0: MAC rev. 0x00000000
>> re0: Unknown H/W revision: 0x2c000000
>> device_attach: re0 attach returned 6
>
> Try attached patch and let me know how it goes.
The patch solved the problem. I can now use the Ethernet interface. I will
report if I find any problems in the long run.
Many thanks!
Michael
------------------------------
Message: 9
Date: Fri, 9 Apr 2010 15:51:15 -0700
From: Pyun YongHyeon <pyu...@gmail.com>
Subject: Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
To: Michael Beckmann <mic...@apfel.de>
Cc: sta...@freebsd.org
Message-ID: <2010040922...@michelle.cdnetworks.com>
Content-Type: text/plain; charset=us-ascii
On Sat, Apr 10, 2010 at 12:12:47AM +0200, Michael Beckmann wrote:
> --On Freitag, 9. April 2010 10:32 -0700 Pyun YongHyeon <pyu...@gmail.com>
> wrote:
>
> >On Fri, Apr 09, 2010 at 01:50:02AM +0200, Michael Beckmann wrote:
> >>Greetings,
> >>
> >>the onboard Realtek Ethernet on my Asus M4A89GTD PRO is not functioning.
> >>
> >>I use FreeBSD 8.0-STABLE with a generic kernel (amd64). Everything was
> >>updated March 27, 2010.
> >>
> >>Is it a bug?
> >>
> >>Thanks,
> >>
> >>Michael
> >>
> >>
> >>pcib4: <ACPI PCI-PCI bridge> at device 21.0 on pci0
> >>pci4: <ACPI PCI bus> on pcib4
> >>re0: <RealTek
> >>8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP PCIe
> >>Gigabit Ethernet> port 0xe800-0xe8ff mem
> >>0xfdfff000-0xfdffffff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4
> >>re0: Using 1 MSI messages
> >>re0: Chip rev. 0x2c000000
> >>re0: MAC rev. 0x00000000
> >>re0: Unknown H/W revision: 0x2c000000
> >>device_attach: re0 attach returned 6
> >
> >Try attached patch and let me know how it goes.
>
> The patch solved the problem. I can now use the Ethernet interface. I will
> report if I find any problems in the long run.
>
Patch committed to HEAD(r206433).
Thanks for reporting!
------------------------------
Message: 10
Date: Sat, 10 Apr 2010 02:40:34 +0200
From: "O. Hartmann" <ohar...@mail.zedat.fu-berlin.de>
Subject: LSI MegaRAID SAS 9211-8i on FreeBSD 8/9?
To: freebsd-...@freebsd.org, freebsd...@FreeBSD.org
Message-ID: <4BBFC902...@mail.zedat.fu-berlin.de>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
I'd like to build a new Workstation based on Intels 'Gulftown' for some
numerical modelling purposes. Since I realised that on our Dell
Poweredge Server with built-in Fusion MPT RAID/JBOD controller even
attached SATA 3 GB hard disks seem to be 'faster' than on most Intel
ICH9/ICH10 machines we also utilise with FreeBSD 8/amd64, I'd like to
have a replacement SAS 2.0 controller like the LSI MegaRAID SAS 9211-8.
I do not know much about this controller. I don't want to wait for
native SATA 6Gb on Intel chipsets since this is announce for next year
and I feel better being 'back to the roots' with SCSI/SAS 2 on FreeBSD.
Are there any contraints on this above mentioned LSI SAS 2.0 controller
execpt lacking RAID 5/6 level (it should be an replacement for the ICH10
so far for 7 or 8 hard disks/SSDs)?
Any comment would be appreciated (please set CC to my email since I do
not subscribe the questions-list).
Thanks in advance,
O. Hartmann
------------------------------
Message: 11
Date: Sat, 10 Apr 2010 07:21:03 +0300
From: Akephalos <akephalos...@gmail.com>
Subject: Re: CPU problems after 8.0-STABLE update
To: Andriy Gapon <a...@icyb.net.ua>
Cc: Attilio Rao <att...@freebsd.org>, freebsd...@freebsd.org
Message-ID: <20100410072103.7a2162...@gmail.com>
Content-Type: text/plain; charset=US-ASCII
On Thu, 08 Apr 2010 18:03:08 +0300
Andriy Gapon <a...@icyb.net.ua> wrote:
>
> Really shooting in the dark here: are there any BIOS options about HPET and RTC on
> this system? Can you try playing with them?
>
> --
> Andriy Gapon
I'm sorry for this late reply.
I can't see any option like that in bios, unfortunately, there are few options that can be changed. In case it was forgotten, on the firs install (8.0 release version) it was all fine, I think diffing or tracing the changes from there might point to a solution?
Thanks,
Mihai
------------------------------
End of freebsd-stable Digest, Vol 351, Issue 9
**********************************************