I have a few systems that use the SIS630 host bridge, the 5513 IDE bridge,
etc, etc, etc, and they are slooooooowwww under 2.4.x, whereas 2.2.19
performance seems to be fairly decent.
It does appear that support for the SiS5513 was added sometime recently,
or I've just gone blind ... But trying (2 hr make dep on 2.4.14) to get a
kernel with SiS5513 support started.
Anyway, various configs, system information, dmesg, and so forth can be
found at http://www.realityfailure.org/~jjasen/SiS630, as I'm gonna be
here for a while. :(
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
On Sat, 17 Nov 2001, John Jasen wrote:
> Anyway, various configs, system information, dmesg, and so forth can be
> found at http://www.realityfailure.org/~jjasen/SiS630, as I'm gonna be
> here for a while. :(
errr ... braindump. The url should work now.
Guess I fell asleep waiting for the kernel to compile. :/
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
On 11/17/2001 11:22 PM, John Jasen wrote:
>
> Anyway, various configs, system information, dmesg, and so forth can be
> found at http://www.realityfailure.org/~jjasen/SiS630, as I'm gonna be
> here for a while. :(
>
dmesg for the "failing" 2.4.X kernel would be nice.
(the ones on the site is from version 2.2.19)
Also output from 'hdparm /dev/hda' is needed in order to sort out the
problem.
Regards
Anders Fugmann
On Sun, 18 Nov 2001, Anders Peter Fugmann wrote:
> dmesg for the "failing" 2.4.X kernel would be nice.
> (the ones on the site is from version 2.2.19)
> Also output from 'hdparm /dev/hda' is needed in order to sort out the
> problem.
dmesg, /proc/interrupts, /proc/pci added to
http://www.realityfailure.org/~jjasen/SiS630/2.4.12/
There is also a hdparm.info, from hdparm -I /dev/hda; and hdparm.stat from
hdparm -t -T /dev/hda (3 runs).
I've also added, in http://www.realityfailure.org/~jjasen/SiS630/,
hdparm.info and hdparm.stat from the RH 2.2.19 kernel.
What seems really interesting is that while the buffered disk reads from
2.2.19 are 4.5x slower, 2.2.19 is able to get work done (ie compiling)
_much_ faster. (subjectively, a 2.4.x kernel compile (make clean && make
dep && make && make modules) might take 20 minutes or so on 2.2.19,
whereas it takes 4-5 hours on a 2.4.x kernel.
--
-- John E. Jasen ([email protected])
-- If things worked according to specs, there'd be a lot less work.
Hi again.
One thing i cannot see is "unmaskirq" setting.
So I would really like to see the output of a plain
hdparm /dev/hda.
As far as I can see the 2.4.X kernel gives much better throughput,
but 4-5 hours for compiling the kernel is way too long on a 700Mhz
celeron. Please try to do a
$ make dep clean && time make bzImage -j 3
on both 2.2.19 and 2.4.X kernel and send the time information.
The line
"PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try
using pci=biosirq." in the dmesg output is strange. Have you tried to do
what is says?
I've only seen it on my server, where I have disabled my onboard
controller, which means that the BIOS does not allocate an interrupt pin
for it. Have you looked in the BIOS, to see if the controller is enabled
correctly?
Regards
Anders Fugmann
On Sun, 18 Nov 2001, Anders Peter Fugmann wrote:
> Hi again.
>
> One thing i cannot see is "unmaskirq" setting.
> So I would really like to see the output of a plain
> hdparm /dev/hda.
[root@labrat5 /root]# /sbin/hdparm /dev/hda // 2.4.12
/dev/hda:
multcount = 16 (on)
I/O support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 2491/255/63, sectors = 40021632, start = 0
tried it with and without 32bit I/O support, and with/without unmaskirq.
[root@labrat6 linux]# /sbin/hdparm /dev/hda // RH 2.2.19-6.2.1
/dev/hda:
multcount = 0 (off)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 2491/255/63, sectors = 40021632, start = 0
> As far as I can see the 2.4.X kernel gives much better throughput,
> but 4-5 hours for compiling the kernel is way too long on a 700Mhz
> celeron. Please try to do a
> $ make dep clean && time make bzImage -j 3
> on both 2.2.19 and 2.4.X kernel and send the time information.
>
> The line
> "PCI: No IRQ known for interrupt pin A of device 00:00.1. Please try
> using pci=biosirq." in the dmesg output is strange. Have you tried to do
> what is says?
yep. No effect on performance or error message.
Can't check the BIOS immediately, as the nearest offending beast is 20km
away.
I should have the results of make dep clean && time make bzImage -j 3 in
... a few hours. :(
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
On Sun, 18 Nov 2001, John Jasen wrote:
> > As far as I can see the 2.4.X kernel gives much better throughput,
> > but 4-5 hours for compiling the kernel is way too long on a 700Mhz
> > celeron. Please try to do a
> > $ make dep clean && time make bzImage -j 3
> > on both 2.2.19 and 2.4.X kernel and send the time information.
// RH 2.2.19-6.2.1
439.35user 54.86system 8:19.45elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (357039major+484758minor)pagefaults 0swaps
// 2.4.12
(still in make dep) ...
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
On 11/18/2001 09:11 PM, John Jasen wrote:
> On Sun, 18 Nov 2001, Anders Peter Fugmann wrote:
>>
>>Another thing... Is it the same machine?
>>
>
> I have three machines with SiS630 boards at the moment.
>
> Two are identical, except for current kernel. (labrat5 and labrat6)
Hmm. It seems that these machines are in fact not identical.
I would strongly suggest that you try to boot either one with another
kernel, and see how it reacts.
(if labrat6 is still fast using a 2.4 kernel, or if labrat5 is still
slow with a 2.2 kernel, you have successfully shown a hardware/BIOS
differnce between the two machines.)
Another idea could be not to compile in SIS support.
It might be that the driver is broken. The 2.2 kernel does not have
support for the chipset, and uses general drivers instead. That should
explain why throughput is higher in 2.4 kernel.
Thats the best I can do for now. Sorry.
> configs and lspci output added to
> http://www.realityfailure.org/~jjasen/SiS630
I really cannot understand why they differ, since Revision numbers are
identical, but alot of IO-ports are not. Maybe you have two different
revisions of the same motherboard.
Anyone else care to try and explain?
Regards
Anders Fugmann
On Sun, 18 Nov 2001, Anders Peter Fugmann wrote:
> Hmm. It seems that these machines are in fact not identical.
> I would strongly suggest that you try to boot either one with another
> kernel, and see how it reacts.
>
> (if labrat6 is still fast using a 2.4 kernel, or if labrat5 is still
> slow with a 2.2 kernel, you have successfully shown a hardware/BIOS
> differnce between the two machines.)
labrat5+linux2.2.19 = decent response times
labrat6+linux2.2.19 = decent response times
firewall system + linux2.2.19 = decent response time
labrat5+linux2.4.x, where X=4,7,12 = painfully slow
labrat6+linux2.4.x, where X=4,7,12 = painfully slow
firewall system + linux2.4.x, where X=7 = painfully slow
> Another idea could be not to compile in SIS support.
> It might be that the driver is broken. The 2.2 kernel does not have
> support for the chipset, and uses general drivers instead. That should
> explain why throughput is higher in 2.4 kernel.
I'll try it. I just may reboot into 2.2.19, so that the compiles won't
take until kernel 2.6.2 is out. :/
I'm also thinking of calling up the hardware vendor and suggesting that
these boards be used for target practise, as the Intel 810 boards that
they were _supposed_ to replace appear to be superior.
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
At 04:55 PM 18/11/01 -0500, John Jasen wrote:
>labrat5+linux2.2.19 = decent response times
>labrat6+linux2.2.19 = decent response times
>firewall system + linux2.2.19 = decent response time
>
>labrat5+linux2.4.x, where X=4,7,12 = painfully slow
>labrat6+linux2.4.x, where X=4,7,12 = painfully slow
>firewall system + linux2.4.x, where X=7 = painfully slow
Have you tried going through with hdparm enabling/disabling the options in
turn? eg: DMA, Unmasq IRQ, Multi-Count, etc.
I would not be surprised if what was happening was related to DMA causing
huge locks of the IDE subsystem, and dragging out the disk times, therefore
throwing the system out the window. Out of your previous posts, I saw you
mention you fiddled with Unmasq IRQ and 32 bit, but not DMA.
Also are these systems per chance running the same brand/model of h/drive?
While I doubt it, could this be a problem with these drives and these
boards only in certain modes?
Good luck!
AMC Enterprises P/L - Stuart Young
First Floor - Network and Systems Admin
3 Chesterville Rd - [email protected]
Cheltenham Vic 3192 - Ph: (03) 9584-2700
http://www.amc.com.au/ - Fax: (03) 9584-2755
On Sun, 18 Nov 2001, John Jasen wrote:
> // RH 2.2.19-6.2.1
> 439.35user 54.86system 8:19.45elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (357039major+484758minor)pagefaults 0swaps
>
> // 2.4.12
5230.73user 52.88system 1:28:09elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (346527major+482788minor)pagefaults 0swaps
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
On Mon, 19 Nov 2001, Stuart Young wrote:
> Have you tried going through with hdparm enabling/disabling the options in
> turn? eg: DMA, Unmasq IRQ, Multi-Count, etc.
What makes no sense is that hdparm -t -T indicates that 2.4.12 is faster.
> I would not be surprised if what was happening was related to DMA causing
> huge locks of the IDE subsystem, and dragging out the disk times, therefore
> throwing the system out the window. Out of your previous posts, I saw you
> mention you fiddled with Unmasq IRQ and 32 bit, but not DMA.
toggled off DMA, to no effect. Interrupts, between the two systems,
actually looked like the 2.4.12 machine was lower over time.
(up 1/6 of the time, had 1/10 of the interrupts)
> Also are these systems per chance running the same brand/model of h/drive?
> While I doubt it, could this be a problem with these drives and these
> boards only in certain modes?
The three systems in question are all running Maxtor hard drives, but two
are 32049H2 20GB, and one is 91024U3, a 10GB.
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
On 11/19/2001 02:07 AM, John Jasen wrote:
> On Sun, 18 Nov 2001, John Jasen wrote:
>
>
>>// RH 2.2.19-6.2.1
>>439.35user 54.86system 8:19.45elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
>>0inputs+0outputs (357039major+484758minor)pagefaults 0swaps
>>
>>// 2.4.12
>>
>
> 5230.73user 52.88system 1:28:09elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (346527major+482788minor)pagefaults 0swaps
Funny how the system time is almost identical, while 10 times as much
time is spend in userspace.
What does top say while compiling a kernel? (On a 2.4.12 system)
I just had this strange thought that the problem might not be with the
disc, but a whole other place - like some process hogging the CPU, and
not allowing gcc to do its job.
How does 'grep -r "somestring"' on 2.4.12 compre to 2.2.19?
Regards
Anders Fugmann
On Mon, 19 Nov 2001, Anders Peter Fugmann wrote:
> Funny how the system time is almost identical, while 10 times as much
> time is spend in userspace.
> What does top say while compiling a kernel? (On a 2.4.12 system)
right now, top is consuming 7.7% of CPU on the 2.4.12 system, and 0.7% on
the 2.2.19 system. Nothing else is running.
Hmmmm... However, I just noticed that there is a different in memory
reported:
2.2.19: 259680k
2.4.12: 254236k
but less used on the 2.4.12 machine, with right now 90000k being free
there, versus 3000k on the 2.2.19 system (running grep -r)
> I just had this strange thought that the problem might not be with the
> disc, but a whole other place - like some process hogging the CPU, and
> not allowing gcc to do its job.
>
> How does 'grep -r "somestring"' on 2.4.12 compre to 2.2.19?
grep comsumes about 25% of CPU on 2.2.19, with the following times:
1.50user 2.79system 0:12.61elapsed 34%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (178major+79minor)pagefaults 0swaps
on 2.4.12, it consumes between 60 and 80% of cpu, and I'm still waiting
for times ...
101.48user 4.11system 3:22.85elapsed 52%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (130major+138minor)pagefaults 0swaps
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
This isn't a universal problem with the chipset. I have a laptop with
the SiS630 chipset and performance is fine. I have
CONFIG_BLK_DEV_SIS5513 enabled.
Further details available on request.
--
Nate Eldredge
[email protected]
Nate Eldredge writes:
> This isn't a universal problem with the chipset. I have a laptop with
> the SiS630 chipset and performance is fine. I have
> CONFIG_BLK_DEV_SIS5513 enabled.
>
> Further details available on request.
I should mention that I'm currently using kernel 2.4.13-ac7.
--
Nate Eldredge
[email protected]
Some people have asked about lspci -v giving differing output between
2.2.19 and 2.4.12, and I've just confirmed that /sbin/lspci -v is
identical when the systems are running the same kernel revision.
[I have three systems running the same board, two are identical, and I've
been using one as a 2.2.19 RH baseline against the 2.4.x lame duck for
analysis]
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
kernel 2.4.14, based off the same .config as 2.4.12 also exhibits the same
problem.
Making a more stripped 2.4.14 now, and will post results and .config in
the same directory as everything else.
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
On Mon, 19 Nov 2001, John Jasen wrote:
> Making a more stripped 2.4.14 now, and will post results and .config in
> the same directory as everything else.
ehhh ... same results.
Interestingly enough, a few people posted and emailed that they hade no
problems with their SiS630E chipsets, and offering various theories
therein.
My vendor had a SiS630E board that was going to be RMA'd (broken ps/2 port
for mouse of all damned things), so he quickly built a system around it, I
ssh'ed in, copied over 2.4.14, and make dep took a whopping 37 seconds or
so, with make (on a .config with everything either added in or as a
module) about 6.5 minutes.
So, no, whatever magic molassas infects my SiS630 boards does not seem to
extend to the SiS630E.
--
-- John E. Jasen ([email protected])
-- In theory, theory and practise are the same. In practise, they aren't.
| From: John Jasen <[email protected]>
| grep comsumes about 25% of CPU on 2.2.19, with the following times:
| 1.50user 2.79system 0:12.61elapsed 34%CPU (0avgtext+0avgdata 0maxresident)k
| 0inputs+0outputs (178major+79minor)pagefaults 0swaps
|
| on 2.4.12, it consumes between 60 and 80% of cpu, and I'm still waiting
| for times ...
|
| 101.48user 4.11system 3:22.85elapsed 52%CPU (0avgtext+0avgdata 0maxresident)k
| 0inputs+0outputs (130major+138minor)pagefaults 0swaps
That sounds like something "invisible" is eating your CPU. Perhaps
some interrupt handling.
Do a "cat /proc/interrupts", wait a few seconds and do it again. See
if any count jumped by a lot. I assume, but don't actually know, that
interrupts that are not handled are still counted.
Hugh Redelmeier
[email protected] voice: +1 416 482-8253
On my machine, when not doing anything, I get a lot of timer
interrupts.
RFC $ cat /proc/interrupts ; sleep 10 ; cat /proc/interrupts
CPU0 CPU1
0: 13363128 13480402 IO-APIC-edge timer
1: 78903 77330 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 1 0 IO-APIC-edge rtc
12: 376841 390230 IO-APIC-edge PS/2 Mouse
14: 183020 166039 IO-APIC-edge ide0
15: 236 450 IO-APIC-edge ide1
16: 2321 2395 IO-APIC-level bttv
17: 2166 2170 IO-APIC-level es1371
18: 7 7 IO-APIC-level aic7xxx
19: 619226 619253 IO-APIC-level usb-uhci, eth0
NMI: 0 0
LOC: 26844734 26844733
ERR: 43
MIS: 0
CPU0 CPU1
0: 13363381 13481153 IO-APIC-edge timer
1: 78903 77331 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 1 0 IO-APIC-edge rtc
12: 376841 390230 IO-APIC-edge PS/2 Mouse
14: 183026 166062 IO-APIC-edge ide0
15: 236 450 IO-APIC-edge ide1
16: 2321 2395 IO-APIC-level bttv
17: 2166 2170 IO-APIC-level es1371
18: 7 7 IO-APIC-level aic7xxx
19: 619226 619253 IO-APIC-level usb-uhci, eth0
NMI: 0 0
LOC: 26845738 26845737
ERR: 43
MIS: 0