Re: [QUESTION] 2.4.x nice level

[Quim K Holland]

> "BS" == BERECZ Szabolcs <[EMAIL PROTECTED]> writes:

BS> ... a setiathome running at nice level 19, and a bladeenc at
BS> nice level 0. setiathome uses 14 percent, and bladeenc uses
BS> 84 percent of the processor. I think, setiathome should use
BS> max 2-3 percent.  the 14 percent is way too much for me.
BS> ...
BS> with kernel 2.2.16 it worked for me.
BS> now I use 2.4.2-ac20

Would it the case that bladeenc running on 2.4.2 spends more
time doing I/O?  I am not saying that the userland makes more I/O
requests, but if the same set of I/O requests are taking longer
to complete on 2.4.2, then while bladeenc is waiting for their
completion, it is not so surprising that the other process uses
the otherwise-idle CPU cycles.




--== Sent via Deja.com ==--
http://www.deja.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: About DC-315U scsi driver

[Quim K Holland]

> "AC" == Alan Cox <[EMAIL PROTECTED]> writes:

>> Indeed; people report more problems on 2.4 kernels than on
>> 2.2 kernels. I currently have no clue why.

AC> 2.4 causes longer continuous I/O requests to be sent to the
AC> drive for one

Sorry but I am having a hard time understanding this comment.
Are you saying 2.4 causes applications to send I/O requests
longer than the hardware accepts, and if applications are
properly written they should be able to limit the continuous
requests from the userland (which means it is an application
bug)?  Or are you saying 2.4 kernel should not ``cause longer
continuous I/O requests to be sent'' but it ends up doing
so (which means its a kernel bug)?



--== Sent via Deja.com ==--
http://www.deja.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

CD-RW ide-scsi lost interrupts on 2.4.2 w/ VIA vt82c686b

[Quim K Holland]

I have a Plextor CD-RW connected as slave at ide1 and have
append="hdd=ide-scsi" in lilo.conf.  Motherboard is AOpen
AK73-PRO which has VIA vt82c686b onboard.

On recent kernels, cdrecord (1.9) started to barf when trying to
write (both with and without --dummy).  The system reports irq
timeouts for /dev/hdd.  Reading data from /dev/scd0 (11,0) works
as expected.  I would appreciate it if somebody can fix this.

The kernel is compiled with the following enabled.

CONFIG_BLK_DEV_IDESCSI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_SR_EXTRA_DEVS=1
CONFIG_CHR_DEV_SG=y

Here are the lines from syslog when this problem occured.

Feb 24 13:20:31 linux kernel: scsi : aborting command due to timeout : pid 0, 
scsi0, channel 0, id 0, lun 0 0x00 00 00 00 00 00 
Feb 24 13:20:31 linux kernel: hdd: lost interrupt
Feb 24 13:20:52 linux kernel: scsi : aborting command due to timeout : pid 0, 
scsi0, channel 0, id 0, lun 0 0x01 00 00 00 00 00 
Feb 24 13:20:52 linux kernel: hdd: irq timeout: status=0xd0 { Busy }
Feb 24 13:20:52 linux kernel: hdd: ATAPI reset complete
Feb 24 13:20:52 linux kernel: hdd: irq timeout: status=0x80 { Busy }
Feb 24 13:20:52 linux kernel: hdd: ATAPI reset complete
Feb 24 13:20:53 linux kernel: hdd: irq timeout: status=0x80 { Busy }
Feb 24 13:20:53 linux kernel: hdc: status timeout: status=0x80 { Busy }
Feb 24 13:20:53 linux kernel: hdc: drive not ready for command
Feb 24 13:20:53 linux kernel: ide1: reset: success
Feb 24 13:21:13 linux kernel: scsi : aborting command due to timeout : pid 0, 
scsi0, channel 0, id 0, lun 0 0x00 00 00 00 00 00 
Feb 24 13:21:13 linux kernel: hdd: lost interrupt

Here is what hdparm -i /dev/hdd reports:

/dev/hdd:

 Model=PLEXTOR CD-R PX-W8432T, FwRev=1.05, SerialNo=
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:180,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2 

And the following is from /proc/ide/via (before lost-interrupts
disables DMA for /dev/hdd).  For /dev/hda and /dev/hdc (they are
hard disks), hdparm -d0 is run at the system startup time to
disable UDMA (I have 80-wire UDMA-100 cable on these channels,
but previously lost a lot of data without CRC errors, so am
being paranoid to do this for now).

--VIA BusMastering IDE Configuration
Driver Version: 3.20
South Bridge:   VIA vt82c686b
Revision:   ISA 0x40 IDE 0x6
BM-DMA base:0xc000
PCI clock:  33MHz
Master Read  Cycle IRDY:0ws
Master Write Cycle IRDY:0ws
BM IDE Status Register Read Retry:  yes
Max DRDY Pulse Width:   No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush:  yes yes
End Sector FIFO flush: no  no
Prefetch Buffer:  yes yes
Post Write Buffer:yes  no
Enabled:  yes yes
Simplex only:  no  no
Cable Type:   80w 80w
---drive0drive1drive2drive3-
Transfer Mode:PIO   PIO   PIO  UDMA
Address Setup:   30ns 120ns  30ns  30ns
Cmd Active:  90ns  90ns  90ns  90ns
Cmd Recovery:30ns  30ns  30ns  30ns
Data Active: 90ns 330ns  90ns  90ns
Data Recovery:   30ns 270ns  30ns  30ns
Cycle Time:  60ns  50ns  60ns  90ns
Transfer Rate:   33.3MB/s  40.0MB/s  33.3MB/s  22.2MB/s



--== Sent via Deja.com ==--
http://www.deja.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cpu_has_fxsr or cpu_has_xmm?

[Quim K Holland]

> "DL" == Doug Ledford <[EMAIL PROTECTED]> writes:
>> > --- linux.vanilla/arch/i386/kernel/i387.c   Thu Feb 22 09:05:35 2001
>> > +++ linux.ac/arch/i386/kernel/i387.cSun Feb  4 10:58:36 2001
>> > @@ -179,7 +179,7 @@
>> >
>> >  unsigned short get_fpu_mxcsr( struct task_struct *tsk )
>> >  {
>> > -   if ( cpu_has_fxsr ) {
>> > +   if ( cpu_has_xmm ) {
>> > return tsk->thread.i387.fxsave.mxcsr;
>> > } else {
>> > return 0x1f80;
>> >

DL> As to the correctness, the mxcsr register really only exists
DL> if you have xmm, so the xmm is the correct test. However,...

DL> ...  User space programmers should be checking for xmm
DL> capability themselves before ever paying attention to mxcsr
DL> anyway, so it's not an end of the world error.

If that is the case, wouldn't it be simpler to always return
tsk->thread.i387.fxsave.mxcsr from this function, and initialize
that field to 0x1f80 (whatever that magic number means) when
the structure is built?



--== Sent via Deja.com ==--
http://www.deja.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

cpu_has_fxsr or cpu_has_xmm?

[Quim K Holland]

I've been looking at various -ac patches for the last couple of 
weeks and have been wondering why only this piece of difference
still remains between Linus' 2.4.2 and Alan's -ac2.  All the other
diffs in i387.c from 2.4.1-ac2 seem to have been merged into Linus
tree at around 2.4.2-pre1.  Could anybody explain it for me please?

--- linux.vanilla/arch/i386/kernel/i387.c   Thu Feb 22 09:05:35 2001
+++ linux.ac/arch/i386/kernel/i387.cSun Feb  4 10:58:36 2001
@@ -179,7 +179,7 @@
 
 unsigned short get_fpu_mxcsr( struct task_struct *tsk )
 {
-   if ( cpu_has_fxsr ) {
+   if ( cpu_has_xmm ) {
return tsk->thread.i387.fxsave.mxcsr;
} else {
return 0x1f80;



--== Sent via Deja.com ==--
http://www.deja.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: need to suggest a good FS:

[Quim K Holland]

> "DW" == David Weinehall <[EMAIL PROTECTED]> writes:

DW> On Thu, Feb 22, 2001 at 07:57:07PM -0500, Wakko Warner wrote:
>> > anyone can suggest some good FS that can install linux?
>> > exclude reiserfs, ext2, ext3, DOS FAT..etc
>> > just need non-normal or non-popular FS, any suggestion?
>> 
>> How about minixfs?  >=)

DW> ADFS, AFFS, BFS or HPFS are all uncommon
DW> and unpopular (especially in the case of AFFS, if I understood Alexander
DW> Viro's woes correctly), QNX4 might do too, then there's always NTFS;
DW> guaranteed to make your day...

DW> SysV5, UFS and UDF are probably too easy to get going, or?!

tmpfs, swapfs, shmfs :-).



--== Sent via Deja.com ==--
http://www.deja.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RAID1/RAID5 hot-add/hot-remove patch?

[Quim K Holland]

Thanks for your reply.

On the same topic; I am also wondering if there is a reason
why your RAID1/RAID5 hot-add/hot-remove patch (originally against
2.4.0-ac9, Message-ID: )
does not go into Linus tree.  

I saw Neil Brown commenting on the patch in linux-raid list in

(he was suggesting to revert it for somebody who had raid related
crashes), but do not know what happened after that discussion.
Alan Cox still seems to have the hot-add/hot-remove patch in his
tree as of 2.4.0-ac12.



--== Sent via Deja.com ==--
http://www.deja.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.X inode cache bug

[Quim K Holland]

In <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
writes:

> Excuse me for the lack of patch in this mail,...
> In 2.4.x, linux/fs/inode.c has a hash() function with a small
> slip-up.  The inode hash-value is initialized with "unsigned
> long tmp = i_ino | ((unsigned long) sb / L1_CACHE_BYTES);".
> ... I believe this is a
> slip-up, because you should NEVER use bitwise-or in a hash
> formula. This creates a slanted distribution, and depending on
> the address of the superblock block, can cause severe
> inefficiency in the code.
> Just replacing the | with ^ imroves hash-table efficiency
> noticeably,...

Then maybe the attached patch is what you want?  This also replaces
`+' on the next line with `^' to avoid slanted distribution.



--== Sent via Deja.com ==--
http://www.deja.com/



 jukka.patch

Desk check of raid5.c patch from mtew@cds.duke.edu?

[Quim K Holland]

I've been following the recent 2.4.1-pre series and am wondering why the following 
one-liner
(obviously correct) patch has not been applied.  Maybe the original request from Neil 
to Linus
did not get through?



--- drivers/md/raid5.c  2001/01/13 04:31:15 1.1
+++ drivers/md/raid5.c  2001/01/13 04:31:30
@@ -1071,7 +1071,7 @@
bh->b_end_io(bh, 1);
}
while ((bh=return_fail)) {
-   return_ok = bh->b_reqnext;
+   return_fail = bh->b_reqnext;
bh->b_reqnext = NULL;
bh->b_end_io(bh, 0);
}



--== Sent via Deja.com ==--
http://www.deja.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: More on the VIA KT133 chipset misbehaving in Linux

[Quim K Holland]

> "DG" == Dylan Griffiths <[EMAIL PROTECTED]> writes:

DG> The VIA KT133 chipset exhibits the following bugs under Linux
DG> 2.2.17 and 2.4.0:
DG> 1) PS/2 mouse cursor randomly jumps to upper right hand corner
DG> of screen and locks for a bit
DG> 2) Detects a maximum of 64mb of ram, unless worked around by the
DG> "mem=" switch
DG> 3) The clock drifts slowly (more so under heavy load than light
DG> load), leaking time.

I am not a guru, but AOpen AK73PRO which uses VIA KT133 does not
show any of these symptoms that you describe (I cannot be sure
about #3 since I run ntp).  You may want to make your hardware
description a bit more specific to help gurus to help you...



--== Sent via Deja.com ==--
http://www.deja.com/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/