Date: Thu, 25 Aug 2005 15:25:48 -0500 From: Mark Kane <mark@mkproductions.org> To: Roland Smith <rsmith@xs4all.nl> Cc: freebsd-questions@freebsd.org Subject: Re: Performance Issues with AMD64 3000+, 1.5GB RAM, FreeBSD 5.4-RELEASE Message-ID: <430E294C.2080207@mkproductions.org> In-Reply-To: <20050825200838.GA18166@slackbox.xs4all.nl> References: <430D3823.9070301@mkproductions.org> <20050825160909.GB10134@slackbox.xs4all.nl> <430DF015.5000203@mkproductions.org> <20050825173758.GA10790@slackbox.xs4all.nl> <430E0461.3030101@mkproductions.org> <20050825181931.GE10790@slackbox.xs4all.nl> <430E105D.3080509@mkproductions.org> <20050825200838.GA18166@slackbox.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Roland Smith wrote:
> On Thu, Aug 25, 2005 at 01:39:25PM -0500, Mark Kane wrote:
>
>
>>Wow, that would be really nice. I notice whenever I compress something
>>like a backup of my Thunderbird Inbox files (several hundred megs) in
>>bzip2 format it goes nowhere near 100% or even 90% CPU usage. The
>>problems I am talking about occur even when CPU usage is real low as
>>well. :-\
>
>
> Hmm, if bzip2 can't saturate the CPU, I would say it's probably waiting
> for disk reads/writes.
The drives I was trying to compress from/to are both brand new 200GB
Maxtor 7200RPM ATA133 drives. Maybe that has something to do with the
bad controller on this series of boards.
> <snip>
>
>> 29 ?? WL 1:35.00 [irq19: skc0 atapci2]
>
>
> It looks like one of your disk controllers is sharing an interrupt with
> another device (network card? can't find a skc device, only sk). That
> might have something to do with your problem. Try disabling that device,
> and see if your troubles disappear. If so, you could try to add
> a device hint to have the skc device use another free interrupt
> line. See device.hints(5).
Looks like it is the network card. Would disabling that in the BIOS mess
anything up in FreeBSD? With it disabled I couldn't test the streaming,
but could try playing files.
[mixx941@amd64:~]% dmesg | grep sk
skc0: <Marvell Gigabit Ethernet> port 0x9c00-0x9cff mem
0xfb008000-0xfb00bfff irq 19 at device 11.0 on pci2
skc0: Marvell Yukon Lite Gigabit Ethernet rev. A3(0x7)
sk0: <Marvell Semiconductor, Inc. Yukon> on skc0
sk0: Ethernet address: 00:0f:ea:4f:83:8b
I'm also compiling STABLE on that other 5.4-RELEASE i386 machine that
had the same problems while I was using it for that month. I'm going to
see if that helps that machine out any. Here is the IRQ output from that
machine:
12 ?? WL 0:00.00 [irq1: atkbd0]
13 ?? WL 0:00.00 [irq3: sio1]
14 ?? WL 0:00.00 [irq4: sio0]
15 ?? WL 0:00.00 [irq5:]
16 ?? WL 0:00.00 [irq6: fdc0]
17 ?? WL 0:00.00 [irq7: ppc0]
18 ?? WL 0:00.00 [irq8: rtc]
19 ?? WL 0:00.00 [irq9: acpi0]
20 ?? WL 0:00.00 [irq10:]
21 ?? WL 0:00.00 [irq11:]
22 ?? WL 0:00.00 [irq12: psm0]
23 ?? WL 0:00.00 [irq13:]
24 ?? WL 0:01.94 [irq14: ata0]
25 ?? WL 0:00.00 [irq15: ata1]
26 ?? WL 0:00.00 [irq16:]
27 ?? WL 0:00.00 [irq17:]
28 ?? WL 0:19.72 [irq18: rl0]
29 ?? WL 0:00.00 [irq19:]
30 ?? WL 0:00.00 [irq20:]
31 ?? WL 0:00.00 [irq21: uhci0 uhci1+]
32 ?? WL 0:00.00 [irq22: pcm0]
33 ?? WL 0:00.00 [irq23:]
34 ?? WL 0:00.00 [irq0: clk]
-Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?430E294C.2080207>