Re: CPU problems after 8.0-STABLE update
On Thu, 08 Apr 2010 18:03:08 +0300 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? > > -- > 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
LSI MegaRAID SAS 9211-8i on FreeBSD 8/9?
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
On Sat, Apr 10, 2010 at 12:12:47AM +0200, Michael Beckmann wrote: > --On Freitag, 9. April 2010 10:32 -0700 Pyun YongHyeon > 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: at device 21.0 on pci0 > >>pci4: on pcib4 > >>re0: >>8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP PCIe > >>Gigabit Ethernet> port 0xe800-0xe8ff mem > >>0xfdfff000-0xfdff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4 > >>re0: Using 1 MSI messages > >>re0: Chip rev. 0x2c00 > >>re0: MAC rev. 0x > >>re0: Unknown H/W revision: 0x2c00 > >>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! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
--On Freitag, 9. April 2010 10:32 -0700 Pyun YongHyeon 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: at device 21.0 on pci0 pci4: on pcib4 re0: port 0xe800-0xe8ff mem 0xfdfff000-0xfdff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4 re0: Using 1 MSI messages re0: Chip rev. 0x2c00 re0: MAC rev. 0x re0: Unknown H/W revision: 0x2c00 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: binding on 127.0.0.1 not working after upgrade to 7.3
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 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 pgp5TbzGBUjrg.pgp Description: PGP signature
Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
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: at device 21.0 on pci0
>
> pci4: on pcib4
>
> re0: PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem
> 0xfdfff000-0xfdff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4
>
> re0: Using 1 MSI messages
>
> re0: Chip rev. 0x2c00
>
> re0: MAC rev. 0x
>
> re0: Unknown H/W revision: 0x2c00
>
> device_attach: re0 attach returned 6
>
Try attached patch and let me know how it goes.
Index: sys/dev/re/if_re.c
===
--- sys/dev/re/if_re.c (revision 206426)
+++ sys/dev/re/if_re.c (working copy)
@@ -174,8 +174,7 @@
{ RT_VENDORID, RT_DEVICEID_8101E, 0,
"RealTek 8101E/8102E/8102EL/8103E PCIe 10/100baseTX" },
{ RT_VENDORID, RT_DEVICEID_8168, 0,
- "RealTek 8168/8168B/8168C/8168CP/8168D/8168DP/"
- "8111B/8111C/8111CP/8111DP PCIe Gigabit Ethernet" },
+ "RealTek 8168/8111 B/C/CP/D/DP/E PCIe Gigabit Ethernet" },
{ RT_VENDORID, RT_DEVICEID_8169, 0,
"RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet" },
{ RT_VENDORID, RT_DEVICEID_8169SC, 0,
@@ -220,6 +219,7 @@
{ RL_HWREV_8168CP, RL_8169, "8168CP/8111CP"},
{ RL_HWREV_8168D, RL_8169, "8168D/8111D"},
{ RL_HWREV_8168DP, RL_8169, "8168DP/8111DP"},
+ { RL_HWREV_8168E, RL_8169, "8168E/8111E"},
{ 0, 0, NULL }
};
@@ -1310,6 +1310,11 @@
*/
sc->rl_flags |= RL_FLAG_NOJUMBO;
break;
+ case RL_HWREV_8168E:
+ sc->rl_flags |= RL_FLAG_PHYWAKE | RL_FLAG_PHYWAKE_PM |
+ RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT |
+ RL_FLAG_CMDSTOP | RL_FLAG_AUTOPAD | RL_FLAG_NOJUMBO;
+ break;
case RL_HWREV_8169_8110SB:
case RL_HWREV_8169_8110SBL:
case RL_HWREV_8169_8110SC:
@@ -1393,6 +1398,8 @@
}
/* Take PHY out of power down mode. */
+ if ((sc->rl_flags & RL_FLAG_PHYWAKE_PM) != 0)
+ CSR_WRITE_1(sc, RL_PMCH, CSR_READ_1(sc, RL_PMCH) | 0x80);
if ((sc->rl_flags & RL_FLAG_PHYWAKE) != 0) {
re_gmii_writereg(dev, 1, 0x1f, 0);
re_gmii_writereg(dev, 1, 0x0e, 0);
@@ -3135,6 +3142,9 @@
v |= RL_CFG5_WOL_LANWAKE;
CSR_WRITE_1(sc, RL_CFG5, v);
+ if ((ifp->if_capenable & IFCAP_WOL) != 0 &&
+ (sc->rl_flags & RL_FLAG_PHYWAKE_PM) != 0)
+ CSR_WRITE_1(sc, RL_PMCH, CSR_READ_1(sc, RL_PMCH) & ~0x80);
/*
* It seems that hardware resets its link speed to 100Mbps in
* power down mode so switching to 100Mbps in driver is not
Index: sys/pci/if_rlreg.h
===
--- sys/pci/if_rlreg.h (revision 206426)
+++ sys/pci/if_rlreg.h (working copy)
@@ -133,6 +133,7 @@
#define RL_GMEDIASTAT 0x006C /* 8 bits */
#define RL_MACDBG 0x006D /* 8 bits, 8168C SPIN2 only */
#define RL_GPIO 0x006E /* 8 bits, 8168C SPIN2 only */
+#define RL_PMCH 0x006F /* 8 bits */
#define RL_MAXRXPKTLEN 0x00DA /* 16 bits, chip multiplies by 8 */
#define RL_GTXSTART 0x0038 /* 8 bits */
@@ -162,6 +163,7 @@
#define RL_HWREV_8102EL_SPIN1 0x24c0
#define RL_HWREV_8168D 0x2800
#define RL_HWREV_8168DP 0x2880
+#define RL_HWREV_8168E 0x2C00
#define RL_HWREV_8168_SPIN1 0x3000
#define RL_HWREV_8100E 0x3080
#define RL_HWREV_8101E 0x3400
@@ -884,6 +886,7 @@
uint32_t rl_flags;
#define RL_FLAG_MSI 0x0001
#define RL_FLAG_AUTOPAD 0x0002
+#define RL_FLAG_PHYWAKE_PM 0x0004
#define RL_FLAG_PHYWAKE 0x0008
#define RL_FLAG_NOJUMBO 0x0010
#define RL_FLAG_PAR 0x0020
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em driver regression
On Fri, Apr 9, 2010 at 9:41 AM, Pyun YongHyeon 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em driver regression
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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Realtek Ethernet not functioning on Asus M4A89GTD PRO
On 2010-04-09 12:10:16PM +0200, Michael Beckmann wrote: > > r...@pci0:4:0:0: class=0x02 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 === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CPU problems after 8.0-STABLE update
2010/4/9 Jakub Lach : > > > > 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em driver regression
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 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
RE: Realtek Ethernet not functioning on Asus M4A89GTD PRO
>On Thu, Apr 8, 2010 at 6:50 PM, Michael Beckmann wrote: > >> re0: > 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP >> PCIe Gigabit Ethernet> port 0xe800-0xe8ff mem >> 0xfdfff000-0xfdff,0xfdff8000-0xfdffbfff irq 16 at device 0.0 on pci4 >> >> re0: Using 1 MSI messages >> re0: Chip rev. 0x2c00 >> re0: MAC rev. 0x >> re0: Unknown H/W revision: 0x2c00 >> device_attach: re0 attach returned 6 >> > > >What's pciconf -lv say about it? > >Mine is > >r...@pci0:3:0:0: class=0x02 card=0x75811462 chip=0x816810ec rev=0x03 >hdr=0x00 >vendor = 'Realtek Semiconductor' >device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111)' >class = network >subclass = ethernet > >FreeBSD 8.0-STABLE #0: Sun Apr 4 01:28:48 CDT 2010 >r...@galacticdominator.com:/usr/obj/usr/src/sys/GENERIC > >Cards work fine here. Here is the output of pciconf -lv : r...@pci0:4:0:0: class=0x02 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CPU problems after 8.0-STABLE update
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 (Thinkpad T400) best regards, -Jakub Lach -- View this message in context: http://old.nabble.com/CPU-problems-after-8.0-STABLE-update-tp28131503p28189840.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
