Re: Hang when using loop device

[J Sloan]

[EMAIL PROTECTED] wrote:

> > Hello all,
> >
> >   Recently my ext2 partition out of space so I have made a regular file
> > in the FAT32 partition and format it  as ext2 partiton and mount it as
> > loop device.However,occasionaly when I extract a large tar to the loop device..
> > The computer will hang while extracting. I wonder if deadlock occur.
> > I'm using kernel 2.4.1 now and there is no problem when I am using
> > kernel 2.2.x kernel
>
> There are known problems with some of the 2.4 series kernels and loopback
> device support. Look through the kernel archives for Jens Axboe's patches,
> or grab one of the latest ac (Alan Cox) kernels.

The fix is also in the 2.4.3-pre series -

cu

Jup

-
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: st corruption with 2.4.3-pre4

[Geert Uytterhoeven]

On Tue, 20 Mar 2001, Gérard Roudier wrote:
> On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > > On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > > > Is the corruption reproducible?  If so, does the corruption go away if
> > > 
> > > Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB each to
> > > tape (I used a new one).
> > >   - test 1: 4 files with failed md5sum (no further investigation on type of
> > >   corruption)
> > >   - test 2: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were
> > >   corrupted, all starting at an offset of the form 32*x+1.
> > >   - test 3: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were
> > >   corrupted, all starting at an offset of the form 32*x+1.
> > > 
> > > The files seem to be corrupted during writing only, as reading always gives the
> > > exact same (corrupted) data back.
> > > 
> > > Copying files from the disk on the MESH to a disk on the Sym53c875 (which also
> > > has the tape drive) shows no corruption.
> > 
> > I did some more tests:
> >   - The problem also occurs when tarring up files from a disk on the Sym53c875.
> >   - The corrupted data always occurs at offset 32*x (the `+1' above was caused
> > by hexdump, starting counting at 1).
> >   - The 32 bytes of corrupted data at offset 32*x are always a copy of the data
> > at offset 32*x-10240.
> >   - Since 10240 is the default blocksize of tar (bug in tar?), I made a tarball
> > on disk instead of on tape, but no corruption.
> >   - 32 is the size of a cacheline on PPC. Is there a missing cacheflush
> > somewhere in the Sym53c875 driver? But then it should happen on disk as
> > well?
> 
> The only PCI transaction that requires the cache line size to be correctly
> configured is PCI WRITE and INVALIDATE. This transaction may be used by
> the 875 only for data read from a SCSI device and DMAed to memory.

So if this would be the problem, I should see the corruption when reading files
from disks too? But my tests indicate it happens when writing to tape only, not
when reading from tape, nor when copying between disks.

> Note that the controller may use optimized PCI transactions only if the 
> cache line size is configured in its PCI device configuration space.
> Otherwise only normal PCI memory read and PCI memory write transactions 
> will be used.
> 
> Could you check if the cache line size is configured for your 875?
> 
> Let me imagine it is so. Btw, I may be wasting my time if it is not ...
> Then the 875 may also use PCI read multiple transactions and/or PCI read
> line transactions when reading data from memory. If the corruption is due
> to the use of these transactions, the the PCI-HOST bridges may well be the
> culprit, in my opinion.
> 
> Anyway, since the sym53c8xx driver does not try to change the configured
> cache line size on PPC, I would suggest to try again the same tests with
> the cache line size set to zero for the 875. You may hack the driver code
> or the PPC pci code if needed, for example, for value zero to be written
> in the proper place in the PCI configuration space of the 875.

I'll try that.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-
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/

spinlock usage - ext2_get_block, lru_list_lock

[Anton Blanchard]

Hi,

I ported lockmeter to PPC and ran a few dbench runs on a quad CPU F50 here.
These runs were made to never hit the disk. The full results can be found
here:

http://samba.org/~anton/ppc/lockmeter/2.4.3-pre3_hacked/

It was not surprising the BKL was one of the main offenders. Looking at the
stats ext2_get_block was the bad guy (UTIL is % of time lock was busy for,
WAIT is time spent waiting for lock):

SPINLOCKS HOLD   WAIT
  UTIL  CONMEAN(  MAX )  MEAN(  MAX )( %CPU)   TOTAL NAME
 38.8% 41.0%  7.6us(  31ms)  15us(  18ms)( 7.7%) 1683368 kernel_flag
 0.87%  9.1%   13ms(  31ms) 129us( 231us)(0.00%)  22  do_exit+0x120
  2.6% 21.6%   45us(2103us)  79us(  18ms)(0.25%)   19240  ext2_delete_inode+0x34
 0.32% 24.8%  1.2us(  46us)  14us( 992us)(0.25%)   92415  ext2_discard_prealloc+0x34

 29.2% 50.9%   10us( 400us)  15us( 892us)( 5.4%)  957740  ext2_get_block+0x64

 0.40% 32.8%   18us( 208us)  31us(  11ms)(0.06%)7435  lookup_hash+0xb0
 0.09% 17.3%   11us( 139us)  17us( 237us)(0.01%)2560  notify_change+0x8c
 0.01% 17.3%   34us( 138us) 912us(  11ms)(0.01%)  81  real_lookup+0x94
 0.02% 39.5%   34us( 344us)  47us( 331us)(0.00%) 172  schedule+0x4fc
 0.00% 15.4%   11us(  37us)  14us(  22us)(0.00%)  26  sys_ioctl+0x50
  1.1% 28.7%  0.7us( 131us)  12us( 910us)( 1.5%)  559700  sys_lseek+0x90
 0.56% 25.8%   48us( 245us)  12us( 162us)(0.01%)3900  sys_rename+0x1fc
 0.03% 25.0%   24us(  43us)  64us(1004us)(0.00%) 400  tty_read+0xd4
 0.07% 24.1%   31us(  64us)  17us( 293us)(0.00%) 776  tty_write+0x234
  2.0% 32.5%   35us( 267us)  13us( 504us)(0.06%)   19220  vfs_create+0xd0
 0.29% 76.5%  437us( 533us)  25us( 456us)(0.00%) 221  vfs_mkdir+0xd0
 0.05% 19.2%   65us( 285us) 460us(9017us)(0.02%) 240  vfs_rmdir+0x208
  1.1% 23.2%   19us( 236us)  17us( 819us)(0.06%)   19220  vfs_unlink+0x188

It can be also seen that do_exit grabbed the BKL for way too long. Another
large waster of cpu time was the lru_list_lock:

SPINLOCKS HOLD   WAIT
  UTIL  CONMEAN(  MAX )  MEAN(  MAX )( %CPU)   TOTAL NAME
 25.8% 27.0%  1.6us( 169us) 8.9us( 446us)( 9.5%) 5281025 lru_list_lock
 0.07% 33.0%  2.9us(  34us)  11us( 293us)(0.02%)8051  __bforget+0x20
  1.7% 14.6%  0.3us(  44us) 5.2us( 265us)( 1.1%) 1870792  
buffer_insert_inode_queue+0x24
  7.3% 13.6%  1.9us( 169us) 5.5us( 278us)(0.70%) 1239163  getblk+0x28
 0.00% 58.8%  1.0us( 4.5us)  13us( 142us)(0.00%) 221  invalidate_inode_buffers+0x20
 10.0% 45.5%  1.7us( 134us)  10us( 446us)( 6.6%) 1920438  refile_buffer+0x20
  6.7% 45.2%  9.2us( 149us)  14us( 330us)( 1.2%)  242360  try_to_free_buffers+0x44

I began smashing up lru_list_lock but found a few problems. With a name
like lru_list_lock, you would expect it to only synchronise operations to
lru_list[]. However I find things like:

int inode_has_buffers(struct inode *inode)
{
int ret;

spin_lock(_list_lock);
ret = !list_empty(>i_dirty_buffers);
spin_unlock(_list_lock);

return ret;
}

It also looks to be protecting some of the items in the buffer_head struct.
Is the lru_list_lock spinlock usage documented anywhere?

Cheers,
Anton
-
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: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[Mike Galbraith]

On 20 Mar 2001, Kevin Buhr wrote:

> Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
> > Cool. Somebody actually found a real case.
> >
> > I'll fix the mmap case asap. Its' not hard, I just waited to see if it
> > ever actually triggers. Something like g++ certainly counts as major.
>
> I frequently build Mozilla from scratch on my (aging) dual Celeron
> machine.  That's about 65 megs of actual C++ source, and it takes
> about an hour of real time to compile.  I see times for the whole
> build like this:
>
> real60m4.574s
> user101m18.260s  <-- impossible no?
> sys 3m23.520s

Why do numbers like this show up?  I noticed some of this after having
enabled SMP on my UP box.

-Mike

-
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: esound (esd), 2.4.[12] chopped up sound -- solved

[Doug Ledford]

David Ford wrote:
> 
> a) not all drivers are created equal
> b) esd should check the return value anyway

In as much as several people did point out that a write is not guaranteed to
be complete and may be short, even when in blocking mode, you are perfectly
correct.  In as much as this usually is a result of an error condition or
inability of the write to be completed, and not a result of a driver refusing
to block and complete the write as the caller has requested (which would be
the case in a sound driver since the output should be draining, the only
exception being if the program had call the SETTRIGGER ioctl to disable the
output starting with the first write of a complete oss frag, which esd doesn't
do so it isn't a plausible condition) I think drivers that do this are
"inferior" (since I can't call them buggy any longer).  Amongst other things,
it increases the number of traversals through the syscall heirarchy
needlessly, wastes both kernel and user space CPU cycles, and negates the
whole purpose of having the file opened in blocking mode anyway.  So, yes esd
should check these conditions to be complete and compliant with specs.  Given
a decent sound driver though, it shouldn't have to.

> -d
> 
> Doug Ledford wrote:
> 
> > David Ford wrote:
> > >
> > > Actually you probably upgraded to a non-broken version of esd.  Stock esd -still-
> > > writes to the socket without regard to return value.  If the write only accepted
> > > 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet 
>at
> > > 4097, not 2099.  esd is incredibly bad about err checking as is old e stuff.
> > >
> > > I posted my last patch for esd here and to other places in June of 2000.  All it
> > > does is check for return value and adjust the writes accordingly.  For reference,
> > > the patch is at http://stuph.org/esound-audio.c.patch.
> >
> > Why would esd get a short write() unless it is opening the file in non
> > blocking mode (which I didn't see when I was working on the i810 sound
> > driver)?  If esd is writing to a file in blocking mode and that write is
> > returning short, then that sounds like a driver bug to me.


-- 

 Doug Ledford <[EMAIL PROTECTED]>  http://people.redhat.com/dledford
  Please check my web site for aic7xxx updates/answers before
  e-mailing me about problems
-
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: Hang when using loop device

[Ville Herva]

On Wed, Mar 21, 2001 at 12:16:05PM +0800, you [[EMAIL PROTECTED]] claimed:
> Hello all,
> 
>   Recently my ext2 partition out of space so I have made a regular file
> in the FAT32 partition and format it  as ext2 partiton and mount it as 
> loop device.However,occasionaly when I extract a large tar to the loop device..
> The computer will hang while extracting. I wonder if deadlock occur.
> I'm using kernel 2.4.1 now and there is no problem when I am using
> kernel 2.2.x kernel

Jens Axboe fixed this. The fix is merged in 2.4.2ac20 and 2.4.3pre6. The fix
will be in 2.4.3. Please search the mailing list archive before asking...


-- v --

[EMAIL PROTECTED]
-
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: Hang when using loop device

[agrawal]

> Hello all,
> 
>   Recently my ext2 partition out of space so I have made a regular file
> in the FAT32 partition and format it  as ext2 partiton and mount it as 
> loop device.However,occasionaly when I extract a large tar to the loop device..
> The computer will hang while extracting. I wonder if deadlock occur.
> I'm using kernel 2.4.1 now and there is no problem when I am using
> kernel 2.2.x kernel

There are known problems with some of the 2.4 series kernels and loopback
device support. Look through the kernel archives for Jens Axboe's patches,
or grab one of the latest ac (Alan Cox) kernels.


-
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: Matrox framebuffer dualhead and utilities

[Petr Vandrovec]

German Gomez Garcia wrote:

> I'm trying to set the Matrox framebuffer to dualhead or TV output,
> but the utilities mentioned in the docs seem to be outdated (ioctl failed
> with incorrect command). Any idea about where to get up to date tools?
> I'm using kernel 2.4.2-ac20 (quite stable 5 days uptime with heavy DRI
> testing and heavy disk working).

matroxset-0.3 is latest one. You are probably doing something wrong:
(1) With fbset you are trying to use 8bpp or 24bpp color depth.
Secondary
head supports only 16/32bpp.
(2) You did not insmod all needed modules if you compiled matroxfb as
modular (you should compile everything into the kernel...)
(3) You are trying to do some illegal thing, like connecting both
/dev/fb0 and /dev/fb1 into same output...
Petr Vandrovec
[EMAIL PROTECTED]
-
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: VIA audio and parport in 2.4.2

[Jeff Garzik]

Tim Waugh wrote:
> 
> On Mon, Mar 19, 2001 at 12:16:26AM +, Will Newton wrote:
> 
> > In /etc/modules.conf I have:
> >
> > options parport_pc irq=none
> >
> > but dmesg says:
> >
> > parport0: PC-style at 0x378 (0x778), irq 7, dma 3
> > [PCSPP,TRISTATE,COMPAT,ECP,DMA]
> 
> Jeff, this is a bug with the Via code in parport_pc.c.  Basically, the
> problem is that the code that detects the Via doesn't know what
> parameters you passed.  I know about the problem, but I don't know the
> fix yet.

Will,
What are your parallel port settings in BIOS?
Do you have Plug-n-Play OS enabled in BIOS?

The current Via-specific parport_pc.c code forces on the best possible
parallel port modes the chip can handle.  In retrospect, what it should
be doing is reading the configuration BIOS has set up, and not touching
it.

I am not sure that I agree, however, that an "irq=none" on the kernel
cmd line should affect the operation of the Via code.  I would much
rather fix the Via code as I suggest above.

Time to look for and drag out the old Via laptop...  Oh well, I needed
to debug the Via audio code some more anyway. :)

Jeff


-- 
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.
-
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/

Hang when using loop device

[hingwah]

Hello all,

Recently my ext2 partition out of space so I have made a regular file
in the FAT32 partition and format it  as ext2 partiton and mount it as 
loop device.However,occasionaly when I extract a large tar to the loop device..
The computer will hang while extracting. I wonder if deadlock occur.
I'm using kernel 2.4.1 now and there is no problem when I am using
kernel 2.2.x kernel


-
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/

Only 10 MB/sec with via 82c686b chipset?

[SodaPop]

Only 10 MB/sec with via 82c686b chipset?

I have an IWill KK-266R motherboard with an athlon-c 1200
processor in it, and for the life of me I can't get more than
10 MB/sec through the on-board ide controller.  Yes, all the
appropriate support is turned on in the kernel to enable dma
and specific chipset support, and yes, I think I have all
relevant patches and a reasonable kernel.

I started out with stock kernel 2.4.2.  I later added Hedrick's
ide.2.4.3-p4.all.03132001.patch, which did not change the
behaviour other than to include messages in the dmesg output. I
have even tried removing the via-specific chipset support from
the kernel, only to find that enabling dma with generic support
leaves me at the same 10 MB/sec as the specific support does.

I noted a number of other interesting things;  one, that -X33,
-X34, and -X64 through -X69 all have the same 10 MB/sec transfer
rate, and two, that the 10 MB/sec transfer rate can be linearly
increased to 12 MB/sec by raising the system bus from 100 mhz to
120 mhz (all components are safely rated at 133, no overclocking
involved.)

It is also quite strange that I have been able to run 'hdparm
-t /dev/hda' and 'hdparm -t /dev/hdb' concurrently and can still
get the full 10 MB/sec on both, for a sum total of 20 MB/sec. I
would have expected that the drives would clobber each other
given that they are on the same ide bus.

>From the /proc data and other information below, it seems to me
that this is some kind of screwball tuning issue between linux and
the chipset, not the chipset and the drives.  As near as I can
tell, the chipset is talking to the drives at a much higher data
rate than 10 MB/sec, but for some reason linux isn't able to
process the data any faster than that.  Running hdparm -t in
parallel and observing a speed increase from raising the cpu
clock leads me in that direction.  (Also note that hdparm -t only
uses a few percent of cpu.  It's not like the machine doesn't
have enough processing power.)

I'm really baffled at this point.  I can't rule out that I have
done something dumb, but for the life of me I can't think of
anything else.  I've been to a number of web pages, but the
general consensus seems to be that this chipset should just work,
and work beautifully without any trouble.  There aren't any
fixes because I seem to be the only one having this problem.

Does anyone have any other ideas?

-dennis T





Misc hardware information:

The board has raid hardware on it, but its currently disabled with
jumpers.  Cables are high quality 80 wire/40 pin cables.  Both
drives are the same, but currently hdb has the 32 gig clip jumper
attached.  Putting the drives on separate ide busses does not
change the 10 MB/sec throughput.  Removing hdb from the chain
does not raise the throughput of hda.  Both drives are rated at
37 MB/sec continuous DTR.  Hdd is a cheap 8x cdrom.

Hdb, when installed in a nearby machine, has a 17 MB/sec data
rate.  The machine is an AMD K6-II 500, 100 MHz bus, with via
82c586 chipset, running kernel 2.4.1 (via chipset support
enabled.)




Various miscellaneous data, and dmesg output:


root@gurney:~# cat /proc/ide/via
--VIA BusMastering IDE Configuration
Driver Version: 3.20
South Bridge:   VIA vt82c686b
Revision:   ISA 0x40 IDE 0x6
BM-DMA base:0xd000
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 40w
---drive0drive1drive2drive3-
Transfer Mode:   UDMA  UDMA   PIO   PIO
Address Setup:   30ns  30ns 120ns  60ns
Cmd Active:  90ns  90ns  90ns  90ns
Cmd Recovery:30ns  30ns  90ns  90ns
Data Active: 90ns  90ns 330ns 240ns
Data Recovery:   30ns  30ns 270ns 240ns
Cycle Time:  20ns  20ns  50ns  90ns
Transfer Rate:  100.0MB/s 100.0MB/s  40.0MB/s  22.2MB/s


root@gurney:~# hdparm /dev/hda

/dev/hda:
 multcount=  0 (off)
 I/O support  =  1 (32-bit)
 unmaskirq=  1 (on)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 5606/255/63, sectors 

Re: [PATCH for 2.5] preemptible kernel

[Nigel Gamble]

On Wed, 21 Mar 2001, Keith Owens wrote:
> I misread the code, but the idea is still correct.  Add a preemption
> depth counter to each cpu, when you schedule and the depth is zero then
> you know that the cpu is no longer holding any references to quiesced
> structures.

A task that has been preempted is on the run queue and can be
rescheduled on a different CPU, so I can't see how a per-CPU counter
would work.  It seems to me that you would need a per run queue
counter, like the example I gave in a previous posting.

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [EMAIL PROTECTED]

-
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: esound (esd), 2.4.[12] chopped up sound -- solved

[David Ford]

a) not all drivers are created equal
b) esd should check the return value anyway

-d

Doug Ledford wrote:

> David Ford wrote:
> >
> > Actually you probably upgraded to a non-broken version of esd.  Stock esd -still-
> > writes to the socket without regard to return value.  If the write only accepted
> > 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at
> > 4097, not 2099.  esd is incredibly bad about err checking as is old e stuff.
> >
> > I posted my last patch for esd here and to other places in June of 2000.  All it
> > does is check for return value and adjust the writes accordingly.  For reference,
> > the patch is at http://stuph.org/esound-audio.c.patch.
>
> Why would esd get a short write() unless it is opening the file in non
> blocking mode (which I didn't see when I was working on the i810 sound
> driver)?  If esd is writing to a file in blocking mode and that write is
> returning short, then that sounds like a driver bug to me.

--
  There is a natural aristocracy among men. The grounds of this are virtue and 
talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. 
Tanenbaum



-
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: Drvie Corruption CONSTANTLY with Linux and KT7-RAID

[Peter DeVries]

I have noiw tried the following
   Diffrent Ram
   No PNP/ Manual set IRQ's
   All bios settings are manual. CPU speed etc
   -X 34
   Diffrent Controlllers ide0,ide1,ide2
   
Still getting drive corruption as soon as I turn on DMA mode..  I even 
tested 2 HD's and only activating DMA on 1.  (seperate controllers) and 
the both got corrupted. 

any ideas? 






Mark Hahn wrote:

>> least 30 times now.  I have a ABIT KT7-RAID and no
> 
> 
> have you installed the latest bios, and/or turned off the 
> bugusly agressive pci-bridge settings?  they are responsible 
> for all verified kt133/ide problems reported so far.
> 
> 
> 


-
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: NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel2.4.2-ac11 and earlier.

[Jeff Lightfoot]

On Tuesday 20 March 2001 14:58, Jeff Garzik wrote:
> > With all the above kernel revisions/drivers, my network card
> > hangs at random (sometimes within minutes, other times it takes
> > days). To restart it I need to do an ifdown/ifup cycle and it
> > will work fine until the next hang. I upgraded to 2.4.2-ac11
> > because of the documented tulip fixes, but after a few days got
> > this again. The error log shows:
>
> In Alan Cox terms, that's a long time ago :)
>
> Can you please try 2.4.2-ac20?  It includes fixes specifically for
> this problem.

I started having the same problem with my LNE100TX and switched it 
out with another LNE100TX and had the same problem.  Figured it was 
my BP6 SMP motherboard and ordered a new computer. Doh. :-)

Using 2.4.2-ac20.
Current LNE100TX having problems (other is different Rev):
  Lite-On Communications Inc LNE100TX (rev 20)

The first card would get "unexpected IRQ trap at vector d0" before 
dying whereas the second one didn't give that indication.  It would 
just freeze and the traditional "NETDEV WATCHDOG: eth0: transmit 
timed out" message.
-
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/

socket close problems

[Lee Chin]

Hi,
On linux I have the following problem:
I accept connections from client sockets, read the request and send data
back and close the socket.

After a while, I run out of file descriptors... and when I run netstat, all
my connections to the clients are in state CLOSING...  and I know the client
has received all the data and disconnected too.

What could I be doing wrong?  The socket is set obtained via the accept
system call.  I set the socket to non blocking via fcntl and use
SO_REUSEADDR via setsockopt... and after using the socket for read and
write, I simply call shutdown followed by a close

Thanks
Lee


__
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup
-
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: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[Dieter Nützel]

Linus Torvalds <[EMAIL PROTECTED]> writes:
> 
> Cool. Somebody actually found a real case.
> 
> I'll fix the mmap case asap. Its' not hard, I just waited to see if it
> ever actually triggers. Something like g++ certainly counts as major.

I do daily builds of the VTK CVS tree (The Visualization Toolkit, 
www.kitware.com/vtk.html, a huge 3D app).

~33 MB C++ source

It took ~1 hour on my K7 550, 256 MB, IBM DTL-307030, glibc-2.2 and 
gcc-2.95.2 ( 19991024 (release)) under most of the 2.4-test kernels (all with 
ReiserFS) for a whole rebuild.
Now it take nearly 1 and a half hour with 2.4.2-ac20.
BTW My mouse (PS2) is very sluggished during C++ compilations, now.

I am open for all of your patches. Or should I better say most :-)))

Cheers,
Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany

email: [EMAIL PROTECTED]
@home: [EMAIL PROTECTED]
-
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: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[David S. Miller]

Kevin Buhr writes:
 > If I recall correctly, RedHat's 2.96 was a modified development
 > snapshot of GCC 3.0, not an official GCC release.  If this is just a
 > quirk in 2.96 that can be fixed before the official release of 3.0 by
 > a trivial patch to libiberty, maybe your original hunch was right and
 > the kernel should be left as-is.

It is the garbage collector scheme used for memory allocation in gcc
>=2.96 that triggers the bad cases seen by Serge.

Later,
David S. Miller
[EMAIL PROTECTED]
-
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: [PATCH for 2.5] preemptible kernel

[Keith Owens]

On Tue, 20 Mar 2001 16:48:01 -0800 (PST), 
Nigel Gamble <[EMAIL PROTECTED]> wrote:
>On Tue, 20 Mar 2001, Keith Owens wrote:
>> The preemption patch only allows preemption from interrupt and only for
>> a single level of preemption.  That coexists quite happily with
>> synchronize_kernel() which runs in user context.  Just count user
>> context schedules (preempt_count == 0), not preemptive schedules.
>
>If you're looking at preempt_schedule(), note the call to ctx_sw_off()
>only increments current->preempt_count for the preempted task - the
>higher priority preempting task that is about to be scheduled will have
>a preempt_count of 0.

I misread the code, but the idea is still correct.  Add a preemption
depth counter to each cpu, when you schedule and the depth is zero then
you know that the cpu is no longer holding any references to quiesced
structures.

>So, to make sure I understand this, the code to free a node would look
>like:
>
>   prev->next = node->next; /* assumed to be atomic */
>   synchronize_kernel();
>   free(node);
>
>So that any other CPU concurrently traversing the list would see a
>consistent state, either including or not including "node" before the
>call to synchronize_kernel(); but after synchronize_kernel() all other
>CPUs are guaranteed to see a list that no longer includes "node", so it
>is now safe to free it.
>
>It looks like there are also implicit assumptions to this approach, like
>no other CPU is trying to use the same approach simultaneously to free
>"prev".

Not quite.  The idea is that readers can traverse lists without locks,
code that changes the list needs to take a semaphore first.

Read
node = node->next;

Update
down(_sem);
prev->next = node->next;
synchronize_kernel();
free(node);
up(_sem);

Because the readers have no locks, other cpus can have references to
the node being freed.  The updating code needs to wait until all other
cpus have gone through at least one schedule to ensure that all
dangling references have been flushed.  Adding preemption complicates
this slightly, we have to distinguish between the bottom level schedule
and higher level schedules for preemptive code.  Only when all
preemptive code on a cpu has ended is it safe to say that there are no
dangling references left on that cpu.

This method is a win for high read, low update lists.  Instead of
penalizing the read code every time on the off chance that somebody
will update the data, speed up the common code and penalize the update
code.  The classic example is module code, it is rarely unloaded but
right now everything that *might* be entering a module has to grab the
module spin lock and update the module use count.  So main line code is
being slowed down all the time.

-
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: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[Kevin Buhr]

Linus Torvalds <[EMAIL PROTECTED]> writes:
> 
> Cool. Somebody actually found a real case.
> 
> I'll fix the mmap case asap. Its' not hard, I just waited to see if it
> ever actually triggers. Something like g++ certainly counts as major.

I frequently build Mozilla from scratch on my (aging) dual Celeron
machine.  That's about 65 megs of actual C++ source, and it takes
about an hour of real time to compile.  I see times for the whole
build like this:

real60m4.574s
user101m18.260s
sys 3m23.520s

with gcc 2.95.2 2220 (Debian GNU/Linux) under Linux 2.4.2.

The sys-to-user ratio seems much closer to Serge's 2.2.13 numbers than
his 2.4.2 numbers, and I'm wondering why.

If I recall correctly, RedHat's 2.96 was a modified development
snapshot of GCC 3.0, not an official GCC release.  If this is just a
quirk in 2.96 that can be fixed before the official release of 3.0 by
a trivial patch to libiberty, maybe your original hunch was right and
the kernel should be left as-is.

> Are you willing to test out patches?

I'm willing to help test out the patch; I'd be curious to see what
effect it has on the performance of 2.95.2.

Kevin <[EMAIL PROTECTED]>
-
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/

linux cluster

[Tomasiewicz, William R]

I once saw an articles on how to install Linux on four separate 456's to
form a cluster server. I since then have not seen any other info on the
subject.
I have multiple Gateway 166's that I would like to try and experiment with
Linux in a clustered environment. Any Advise?

Bill Tomasiewicz
Computer Specialist
-
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: CDROM and harddisk fighting over DMA

[Shawn Starr]

Some CDROMS can do this, My old Acer 12x cdrom was fighting with DMA with
my new Fujitsu drive, I disabled the cd-rom and no more DMA errors ;-)

You might also be able to fix this by rearranging the CD-ROM and drives:
move the CD-ROM off the HD's IDE chain and put it separate (if its not
already).

Shawn.

On Tue, 20 Mar 2001, Wouter Verhelst wrote:

> (I'm not subscribed to linux-kernel, so please CC any answers. TIA)
>
> Hello
>
> Since I bought my new harddisk (a Maxtor 40GB of about a half year old
> now), I've had errors over my console like this:
>
> hda: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
>
> hda is my harddisk. The CDROM was first connected to hdb, but I changed
> that to hdc, trying to get rid of these errors. This did not resolve the
> issue.
> After playing around a bit, I found out that these errors occur when both
> the CDROM and the harddisk are being accessed at the same time (well,
> almost; it's not an SMP system ;-). I managed to fix it by disabling DMA
> on the harddisk, using hdparm. Disabling DMA on the CDROM, by contrast,
> did not resolve the issue.
>
> However, as this slows down my data throughput speed quite drastically,
> I'd like to do this differently.
>
> I first posted this to comp.os.linux.setup, but did not get any useful
> information. I believe it's not some misconfiguration from my side, so I
> sent this here since this mailinglist is listed as relevant mailinglist
> for the IDE subsystem; however, if this is the wrong place to ask, please
> redirect.
>
> --
> wouter dot verhelst at advalvas in belgium
>
> Real men don't take backups.
> They put their source on a public FTP-server and let the world mirror it.
>   -- Linus Torvalds
>
> -
> 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/
>
>

-
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: [PATCH for 2.5] preemptible kernel

[Nigel Gamble]

On Tue, 20 Mar 2001, Keith Owens wrote:
> The preemption patch only allows preemption from interrupt and only for
> a single level of preemption.  That coexists quite happily with
> synchronize_kernel() which runs in user context.  Just count user
> context schedules (preempt_count == 0), not preemptive schedules.

I'm not sure what you mean by "only for a single level of preemption."
It's possible for a preempting process to be preempted itself by a
higher priority process, and for that process to be preempted by an even
higher priority one, limited only by the number of processes waiting for
interrupt handlers to make them runnable.  This isn't very likely in
practice (kernel preemptions tend to be rare compared to normal calls to
schedule()), but it could happen in theory.

If you're looking at preempt_schedule(), note the call to ctx_sw_off()
only increments current->preempt_count for the preempted task - the
higher priority preempting task that is about to be scheduled will have
a preempt_count of 0.

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [EMAIL PROTECTED]

-
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: [PATCH for 2.5] preemptible kernel

[Nigel Gamble]

On Tue, 20 Mar 2001, Rusty Russell wrote:
>   I can see three problems with this approach, only one of which
> is serious.
> 
> The first is code which is already SMP unsafe is now a problem for
> everyone, not just the 0.1% of SMP machines.  I consider this a good
> thing for 2.5 though.

So do I.

> The second is that there are "manual" locking schemes which are used
> in several places in the kernel which rely on non-preemptability;
> de-facto spinlocks if you will.  I consider all these uses flawed: (1)
> they are often subtly broken anyway, (2) they make reading those parts
> of the code much harder, and (3) they break when things like this are
> done.

Likewise.

> The third is that preemtivity conflicts with the naive
> quiescent-period approach proposed for module unloading in 2.5, and
> useful for several other things (eg. hotplugging CPUs).  This method
> relies on knowing that when a schedule() has occurred on every CPU, we
> know noone is holding certain references.  The simplest example is a
> single linked list: you can traverse without a lock as long as you
> don't sleep, and then someone can unlink a node, and wait for a
> schedule on every other CPU before freeing it.  The non-SMP case is a
> noop.  See synchonize_kernel() below.

So, to make sure I understand this, the code to free a node would look
like:

prev->next = node->next; /* assumed to be atomic */
synchronize_kernel();
free(node);

So that any other CPU concurrently traversing the list would see a
consistent state, either including or not including "node" before the
call to synchronize_kernel(); but after synchronize_kernel() all other
CPUs are guaranteed to see a list that no longer includes "node", so it
is now safe to free it.

It looks like there are also implicit assumptions to this approach, like
no other CPU is trying to use the same approach simultaneously to free
"prev".  So my initial reaction is that this approach is, like the
manual locking schemes you commented on above, open to being subtly
broken when people don't understand all the implicit assumptions and
subsequently invalidate them.

> This, too, is soluble, but it means that synchronize_kernel() must
> guarantee that each task which was running or preempted in kernel
> space when it was called, has been non-preemtively scheduled before
> synchronize_kernel() can exit.  Icky.

Yes, you're right.

> Thoughts?

Perhaps synchronize_kernel() could take the run_queue lock, mark all the
tasks on it and count them.  Any task marked when it calls schedule()
voluntarily (but not if it is preempted) is unmarked and the count
decremented.  synchronize_kernel() continues until the count is zero.
As you said, "Icky."

> /* We could keep a schedule count for each CPU and make idle tasks
>schedule (some don't unless need_resched), but this scales quite
>well (eg. 64 processors, average time to wait for first schedule =
>jiffie/64.  Total time for all processors = jiffie/63 + jiffie/62...
> 
>At 1024 cpus, this is about 7.5 jiffies.  And that assumes noone
>schedules early. --RR */
> void synchronize_kernel(void)
> {
>   unsigned long cpus_allowed, policy, rt_priority;
> 
>   /* Save current state */
>   cpus_allowed = current->cpus_allowed;
>   policy = current->policy;
>   rt_priority = current->rt_priority;
> 
>   /* Create an unreal time task. */
>   current->policy = SCHED_FIFO;
>   current->rt_priority = 1001 + sys_sched_get_priority_max(SCHED_FIFO);
> 
>   /* Make us schedulable on all CPUs. */
>   current->cpus_allowed = (1UL<   
>   /* Eliminate current cpu, reschedule */
>   while ((current->cpus_allowed &= ~(1 << smp_processor_id())) != 0)
>   schedule();
> 
>   /* Back to normal. */
>   current->cpus_allowed = cpus_allowed;
>   current->policy = policy;
>   current->rt_priority = rt_priority;
> }
> 

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [EMAIL PROTECTED]

-
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: NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel2.4.2-ac11 and earlier.

[Manuel A. McLure]

I'd looked for changes in tulip between 2.4.2-ac11 and 2.4.2-ac20 and hadn't
seen any - that's why I hadn't updated. I gather that the change in question
is at a higher level?

Anyway, I've upgraded to 2.4.2-ac20 and now I still get the error messages:

Mar 20 14:35:52 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 20 14:35:52 ulthar kernel: eth0: Transmit timed out, status fc664010,
CSR12
, resetting...

but instead of hanging completely the connection just gets extremely slow
and "bursty" as shown by the following fragment of ping output:

64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=8 ttl=255
time=130 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=9 ttl=255
time=358 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=10 ttl=255
time=6.000 sec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=4 ttl=255
time=12.001 sec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=12 ttl=255
time=1.000 sec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=13 ttl=255
time=368 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=14 ttl=255
time=361 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=15 ttl=255
time=395 usec

So the behavior is quite a bit better (at least I can telnet in to
ifdown/ifup) but still not OK. Once again, ifdown/ifup makes things work OK.

Thanks!
--
Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]>
Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What
about-?" M: "It's fixed." SG: "Eh, good. Good."




"Jeff Garzik" wrote:
> "Manuel A. McLure" wrote:
> > 
> > System:
> > AMD Athlon Thunderbird 900MHz
> > MSI K7T Pro (VIA KT133 chipset)
> > Network card: Linksys LNE100TX Rev. 4.0 (tulip)
> > Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, 
> 2.4.2, 2.4.2-ac11
> > 
> > With all the above kernel revisions/drivers, my network 
> card hangs at random
> > (sometimes within minutes, other times it takes days). To 
> restart it I need
> > to do an ifdown/ifup cycle and it will work fine until the 
> next hang. I
> > upgraded to 2.4.2-ac11 because of the documented tulip 
> fixes, but after a
> > few days got this again. The error log shows:
> 
> In Alan Cox terms, that's a long time ago :)
> 
> Can you please try 2.4.2-ac20?  It includes fixes 
> specifically for this
> problem.

I'd looked for changes in tulip between 2.4.2-ac11 and 2.4.2-ac20 and hadn't
seen any - that's why I hadn't updated. I gather that the change in question
is at a higher level?

Anyway, I've upgraded to 2.4.2-ac20 and now I still get the error messages:

Mar 20 14:35:52 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 20 14:35:52 ulthar kernel: eth0: Transmit timed out, status fc664010,
CSR12
, resetting...

but instead of hanging completely the connection just gets extremely slow
and "bursty" as shown by the following fragment of ping output:

64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=8 ttl=255
time=130 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=9 ttl=255
time=358 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=10 ttl=255
time=6.000 sec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=4 ttl=255
time=12.001 sec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=12 ttl=255
time=1.000 sec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=13 ttl=255
time=368 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=14 ttl=255
time=361 usec
64 bytes from leng.internal.mclure.org (10.1.1.1): icmp_seq=15 ttl=255
time=395 usec

So the behavior is quite a bit better (at least I can telnet in to
ifdown/ifup) but still not OK. Once again, ifdown/ifup makes things work
fine until the problem starts again.

Thanks!
--
Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]>
Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What
about-?" M: "It's fixed." SG: "Eh, good. Good."
-
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/

[PATCH] ieee1394 pcilynx.c SMP fix

[Andreas Bombe]

Due to a brain malfunction spinlocks were used in pcilynx.c before they
were initialized, causing SMP systems to deadlock.  The patch fixes this
and removes one second/redundant initialization of another lock.


diff -ruN linux-2.4.linus/drivers/ieee1394/pcilynx.c 
linux-2.4/drivers/ieee1394/pcilynx.c
--- linux-2.4.linus/drivers/ieee1394/pcilynx.c  Mon Feb 26 01:39:30 2001
+++ linux-2.4/drivers/ieee1394/pcilynx.cWed Mar 14 01:00:13 2001
@@ -470,8 +470,6 @@
 lynx->phy_reg0 = -1;
 
 lynx->async.queue = NULL;
-spin_lock_init(>async.queue_lock);
-spin_lock_init(>phy_reg_lock);
 
 pcl.next = pcl_bus(lynx, lynx->rcv_pcl);
 put_pcl(lynx, lynx->rcv_pcl_start, );
@@ -1357,6 +1355,9 @@
 lynx->id = num_of_cards-1;
 lynx->dev = dev;
 
+lynx->lock = SPIN_LOCK_UNLOCKED;
+lynx->phy_reg_lock = SPIN_LOCK_UNLOCKED;
+
 if (!pci_dma_supported(dev, 0x)) {
 FAIL("DMA address limits not supported for PCILynx hardware %d",
  lynx->id);
@@ -1456,8 +1457,6 @@
 lynx->iso_rcv.pcl_start = alloc_pcl(lynx);
 
 /* all allocations successful - simple init stuff follows */
-
-lynx->lock = SPIN_LOCK_UNLOCKED;
 
 reg_write(lynx, PCI_INT_ENABLE, PCI_INT_DMA_ALL);
 


-- 
 Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/http://linux1394.sourceforge.net/
-
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: esound (esd), 2.4.[12] chopped up sound -- solved

[Ion Badulescu]

On Tue, 20 Mar 2001 15:19:37 -0500, Doug Ledford <[EMAIL PROTECTED]> wrote:

> Why would esd get a short write() unless it is opening the file in non
> blocking mode (which I didn't see when I was working on the i810 sound
> driver)?  If esd is writing to a file in blocking mode and that write is
> returning short, then that sounds like a driver bug to me.

No, it's not a bug. It would be a bug if esd was writing to a *real* file
or if the write() returned -1 and an errno of EAGAIN. But incomplete writes
are very much ok.

Just try opening /dev/tty and see how it won't take writes of more than
2k (iirc). And that's not just on Linux, I've tested on Solaris and BSD
as well -- though it was a while ago.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
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: Question about memory usage in 2.4 vs 2.2

[Juha Saarinen]

:: > And can this behavior be tuned so that it uses less of the overall
:: > memory?
::
:: This isn't currently possible. Also, I suspect what we really want
:: for most situations is a way to better balance between the different
:: uses of memory.  Again, patches are welcome (I haven't figured out a
:: way to take care of this balancing yet ... maybe we DO want some way
:: of limiting memory usage of each subsystem??).

man ulimit? ;-)

On a more serious note, is there a way to find out what has been paged out
to disk, and also limit what can be paged out?

I could be wrong, but for instance I leave X running for a while (not sure
about the timing here but let's say several hours), and come back and log in
again, it is very slow to "come alive". The screen redraws slowly, and
there's quite a bit of disk access. This only happens if the system is left
alone for a long period of time (no, I don't have APM running on it).

Squid behaves the same -- the first access after a long period of inactivity
causes a lot of disk grinding, but successive accesses are fine.

Don't see this behaviour with the 2.2.x kernels.


-- Juha

-
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: esound (esd), 2.4.[12] chopped up sound -- solved

[David Woodhouse]

On Tue, 20 Mar 2001, Doug Ledford wrote:

> Why would esd get a short write() unless it is opening the file in non
> blocking mode (which I didn't see when I was working on the i810 sound
> driver)?  If esd is writing to a file in blocking mode and that write is
> returning short, then that sounds like a driver bug to me.

Please quote chapter and verse.

I'm looking at http://www.opengroup.org/onlinepubs/7908799/xsh/write.html 
and cannot see anything which states that write may not return having 
written fewer data than it was asked to.

The only vaguely relevant text I see is...

Write requests to a pipe or FIFO will be handled the same as a
regular file with the following exceptions:

<...>

* If the O_NONBLOCK flag is clear, a write request may cause the 
  thread to block, but on normal completion it will return
  nbyte.

This being an _exception_ clearly implies that for file descriptors other 
than pipes and fifos, it is _not_ necessary to return nbyte on normal 
completion.

Applications (and also I believe glibc) which assume otherwise are, 
technically, broken. Despite being numerous.

-- 
dwmw2


-
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: [PATCH for 2.5] preemptible kernel

[george anzinger]

Nigel Gamble wrote:
> 
> On Tue, 20 Mar 2001, Roger Larsson wrote:
> > One little readability thing I found.
> > The prev->state TASK_ value is mostly used as a plain value
> > but the new TASK_PREEMPTED is or:ed together with whatever was there.
> > Later when we switch to check the state it is checked against TASK_PREEMPTED
> > only. Since TASK_RUNNING is 0 it works OK but...
> 
> Yes, you're right.  I had forgotten that TASK_RUNNING is 0 and I think I
> was assuming that there could be (rare) cases where a task was preempted
> while prev->state was in transition such that no other flags were set.
> This is, of course, impossible given that TASK_RUNNING is 0.  So your
> change makes the common case more obvious (to me, at least!)
> 
> > --- sched.c.nigel   Tue Mar 20 18:52:43 2001
> > +++ sched.c.roger   Tue Mar 20 19:03:28 2001
> > @@ -553,7 +553,7 @@
> >  #endif
> > del_from_runqueue(prev);
> >  #ifdef CONFIG_PREEMPT
> > -   case TASK_PREEMPTED:
> > +   case TASK_RUNNING | TASK_PREEMPTED:
> >  #endif
> > case TASK_RUNNING:
> > }
> >
> >
> > We could add all/(other common) combinations as cases
> >
> >   switch (prev->state) {
> >   case TASK_INTERRUPTIBLE:
> >   if (signal_pending(prev)) {
> >   prev->state = TASK_RUNNING;
> >   break;
> >   }
> >   default:
> > #ifdef CONFIG_PREEMPT
> >   if (prev->state & TASK_PREEMPTED)
> >   break;
> > #endif
> >   del_from_runqueue(prev);
> > #ifdef CONFIG_PREEMPT
> >   case TASK_RUNNING   | TASK_PREEMPTED:
> >   case TASK_INTERRUPTIBLE | TASK_PREEMPTED:
> >   case TASK_UNINTERRUPTIBLE   | TASK_PREEMPTED:
> > #endif
> >   case TASK_RUNNING:
> >   }
> >
> >
> > Then the break in default case could almost be replaced with a BUG()...
> > (I have not checked the generated code)
> 
> The other cases are not very common, as they only happen if a task is
> preempted during the short time that it is running while in the process
> of changing state while going to sleep or waking up, so the default case
> is probably OK for them; and I'd be happier to leave the default case
> for reliability reasons anyway.

Especially since he forgot:

TASK_ZOMBIE
TASK_STOPPED
TASK_SWAPPING

I don't know about the last two but TASK_ZOMBIE must be handled
correctly or the task will never clear.

In general, a task must run till it gets to schedule() before the actual
state is "real" so the need for the TASK_PREEMPT.  

The actual code generated with what you propose should be the same (even
if TASK_RUNNING != 0, except for the constant).

George
-
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: AMI MegaRAID support in 2.4.3-pre4

[Dan Merillat]

> (please cc: me any response, I only keep up with linux-kernel via the archives)

Dan Merillat writes:

> Apparently the chip is too new for driver version 1.07b, (not recognized
> at all by the kernel) and 1.14g has the problems I'm going over here.

An update... driver version 1e08 (stupid version number... 1.08e?) works,
but only on a 2.2.x kernel (2.2.18)  1e08 dosn't play nicely with 2.4.x
PCI scanning... compiles but never gets run.

I believe this is the version sent to RedHat.  Anyway, I can live with this,
since this particular box is single-CPU.  I'll have a SMP configuration on
another machine soon, though.

This box is available for another day or so for experimentation, before I wipe
the drive and do a final install.  If anyone has any ideas let me know now.

I can even give root level access to it for the moment. (again, it's getting
wiped in 48 hours)

--Dan

-
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: Memory leak in 2.4.2 (+loop-6-patch)???

[Rik van Riel]

On Tue, 20 Mar 2001, Matthias Schniedermeyer wrote:

> After some days of uptime, i just stopped (nearly) all programs,
> unmounted all unnecessary devices.
> 
> But top & free say that 1/3 of my RAM is still "used"

grep cache < /proc/slabinfo
grep buffer < /proc/slabinfo

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
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: Question about memory usage in 2.4 vs 2.2

[Rik van Riel]

On Tue, 20 Mar 2001, Josh Grebe wrote:

> slabinfo reports:
> 
> inode_cache   189974 243512480 30439 304391 :  124   62
> dentry_cache  201179 341940128 11398 113981 :  252  126
  ^
  |   
  

> However, I am hard pressed to find documentation on how to actually
> read this data, especially on a SMP box. Could someone give me a brief
> runwdown?

See above. The columns further to the right are debugging info.

> Also, if this memory is cached, wouldn't it make sense if it were
> reported as part of the total cached memory in /proc/meminfo?

I'd definately like to see this. It would be great if somebody
would sit down and implement this.

> And can this behavior be tuned so that it uses less of the overall
> memory?

This isn't currently possible. Also, I suspect what we really want
for most situations is a way to better balance between the different
uses of memory.  Again, patches are welcome (I haven't figured out a
way to take care of this balancing yet ... maybe we DO want some way
of limiting memory usage of each subsystem??).

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
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: esound (esd), 2.4.[12] chopped up sound -- solved

[Tim Wright]

Not necessarily. For a write to a disk file, it would be an error to return a
short write except in an error situation. For devices, the rules are looser.
Quoting Stevens APUE p.406, "Some devices, notably terminals, networks, and any
SVR4 streams devices have the following two properties.
...
2 A write operation can also return less that we specified. This may be caused
by flow control constraints by downstream modules, for example. Again it's not
an error, and we should continue writing the remainder of the data. (Normally
this short return from a write only occurs with a nonblocking descriptor or if
a signal is caught."

So, whilst I personally find drivers that return a short write without
O_NONBLOCK set to be rather obnoxious, it's not illegal, and you have to code
accordingly :-)

Tim

On Tue, Mar 20, 2001 at 03:19:37PM -0500, Doug Ledford wrote:
> David Ford wrote:
> > 
> > Actually you probably upgraded to a non-broken version of esd.  Stock esd -still-
> > writes to the socket without regard to return value.  If the write only accepted
> > 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at
> > 4097, not 2099.  esd is incredibly bad about err checking as is old e stuff.
> > 
> > I posted my last patch for esd here and to other places in June of 2000.  All it
> > does is check for return value and adjust the writes accordingly.  For reference,
> > the patch is at http://stuph.org/esound-audio.c.patch.
> 
> Why would esd get a short write() unless it is opening the file in non
> blocking mode (which I didn't see when I was working on the i810 sound
> driver)?  If esd is writing to a file in blocking mode and that write is
> returning short, then that sounds like a driver bug to me.
> 
> -- 
> 
>  Doug Ledford <[EMAIL PROTECTED]>  http://people.redhat.com/dledford
>   Please check my web site for aic7xxx updates/answers before
>   e-mailing me about problems
> -
> 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/

-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
Interested in Linux scalability ? Look at http://lse.sourceforge.net/
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
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: [PATCH for 2.5] preemptible kernel

[Nigel Gamble]

On Tue, 20 Mar 2001, Roger Larsson wrote:
> One little readability thing I found.
> The prev->state TASK_ value is mostly used as a plain value
> but the new TASK_PREEMPTED is or:ed together with whatever was there.
> Later when we switch to check the state it is checked against TASK_PREEMPTED
> only. Since TASK_RUNNING is 0 it works OK but...

Yes, you're right.  I had forgotten that TASK_RUNNING is 0 and I think I
was assuming that there could be (rare) cases where a task was preempted
while prev->state was in transition such that no other flags were set.
This is, of course, impossible given that TASK_RUNNING is 0.  So your
change makes the common case more obvious (to me, at least!)

> --- sched.c.nigel   Tue Mar 20 18:52:43 2001
> +++ sched.c.roger   Tue Mar 20 19:03:28 2001
> @@ -553,7 +553,7 @@
>  #endif
> del_from_runqueue(prev);
>  #ifdef CONFIG_PREEMPT
> -   case TASK_PREEMPTED:
> +   case TASK_RUNNING | TASK_PREEMPTED:
>  #endif
> case TASK_RUNNING:
> }
> 
> 
> We could add all/(other common) combinations as cases 
> 
>   switch (prev->state) {
>   case TASK_INTERRUPTIBLE:
>   if (signal_pending(prev)) {
>   prev->state = TASK_RUNNING;
>   break;
>   }
>   default:
> #ifdef CONFIG_PREEMPT
>   if (prev->state & TASK_PREEMPTED)
>   break;
> #endif
>   del_from_runqueue(prev);
> #ifdef CONFIG_PREEMPT
>   case TASK_RUNNING   | TASK_PREEMPTED:
>   case TASK_INTERRUPTIBLE | TASK_PREEMPTED:
>   case TASK_UNINTERRUPTIBLE   | TASK_PREEMPTED:
> #endif
>   case TASK_RUNNING:
>   }
> 
> 
> Then the break in default case could almost be replaced with a BUG()...
> (I have not checked the generated code)

The other cases are not very common, as they only happen if a task is
preempted during the short time that it is running while in the process
of changing state while going to sleep or waking up, so the default case
is probably OK for them; and I'd be happier to leave the default case
for reliability reasons anyway.

Nigel Gamble[EMAIL PROTECTED]
Mountain View, CA, USA. http://www.nrg.org/

MontaVista Software [EMAIL PROTECTED]

-
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/

[2.4.2] APM unwanted wakeup from standby (kreiserfsd?)

[Eugene Crosser]

Gentlemen,

this might be somewhat offtopic but I could not find answers on the Net
and "official" APM page seems dramatically out of date...

I recently bought Casio Fiva mini notebook that has APM BIOS 1.2,
Linux APM support partly works.  "Hibernate" does not work at all,
but let it be.  "Standby" ("apm -S") puts the box in standby mode
but after 10..30 seconds it inevitably awakes with a message like
"Normal resume from standby".  This happens even if there are no
processes that would initiate disk/screen/whatever activity (single
user mode).

My suspect is kreiserfsd.  If I am right, could it be modified to
honor standby mode and stop disk access?  If I am wrong, does
anyone have suggestions/advice/ideas how to make standby mode work?
(advice on making hibernate work is also welcome)

Eugene
-
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/

2.4.2 freezes with bad ISOs in IDE cdroms

[Olaf Hering]

Hi,

this is a bogus bugreport.

The 2.4.2 kernel freezes on some machines here when I try to access (or
mount) a bad self burned ISO image, in this case the boot CD with the
install system.

There are different case:

I have an iBook and a blue G3. The G3 has a cmd646 controller. It
freezes when it tries to access the CD. No output.
"ide0=nodma ide2=nodma" doesnt lead to a freeze, but endless error messages.
The installer starts after a while, so it can mount the inst-sys, but it
doest get very far (no output).

Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
CMD646: IDE controller on PCI bus 01 dev 08
CMD646: chipset revision 7
CMD646: chipset revision 0x07, UltraDMA Capable
CMD646: 100% native mode on irq 26
ide0: BM-DMA at 0x1800-0x1807, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x1808-0x180f, BIOS settings: hdc:pio, hdd:pio
pmac_ide: enabling IDE bus ID 0
hda: Maxtor 90648D3, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
hde: MATSHITADVD-ROM SR-8583, ATAPI CD/DVD-ROM drive
ide0 at 0x1840-0x1847,0x1832 on irq 26
ide2 at 0xc8544000-0xc8544007,0xc8544160 on irq 13
hda: 12656448 sectors (6480 MB) w/512KiB Cache, CHS=12556/16/63,
UDMA(33)
hde: Enabling MultiWord DMA 2
hde: ATAPI 32X DVD-ROM drive, 512kB Cache, DMA
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: [mac] hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8 hda9 hda10


Today I got another report on a G4/500. It just freezes when it access a
package on a bad block. Skipping the rpm package were it freezes solves that.

I tried the same ISOs on a SCSI cdrom to verify the MD5SUMS, no crash,
just read errors in dmesg. The controller is a "Symbios Logic Inc.
(formerly NCR) 53c875 (rev 04)".

However, my machine at home locks the SCSI bus in sometimes. It has a
mesh SCSI controller, The last message in the syslog is that:
Device not ready.  Make sure there is a disc in the drive
I still can switch consoles, but the hard drive is not accessible
anymore. 
(this part of the bugreport is maybe not related to the lockups).



Any ideas where to start here?


Gruss Olaf

-- 
 $ man clone

BUGS
   Main feature not yet implemented...
-
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: st corruption with 2.4.3-pre4

[Gérard Roudier]

On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:

> On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> > On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > > Is the corruption reproducible?  If so, does the corruption go away if
> > 
> > Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB each to
> > tape (I used a new one).
> >   - test 1: 4 files with failed md5sum (no further investigation on type of
> > corruption)
> >   - test 2: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were
> > corrupted, all starting at an offset of the form 32*x+1.
> >   - test 3: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were
> > corrupted, all starting at an offset of the form 32*x+1.
> > 
> > The files seem to be corrupted during writing only, as reading always gives the
> > exact same (corrupted) data back.
> > 
> > Copying files from the disk on the MESH to a disk on the Sym53c875 (which also
> > has the tape drive) shows no corruption.
> 
> I did some more tests:
>   - The problem also occurs when tarring up files from a disk on the Sym53c875.
>   - The corrupted data always occurs at offset 32*x (the `+1' above was caused
> by hexdump, starting counting at 1).
>   - The 32 bytes of corrupted data at offset 32*x are always a copy of the data
> at offset 32*x-10240.
>   - Since 10240 is the default blocksize of tar (bug in tar?), I made a tarball
> on disk instead of on tape, but no corruption.
>   - 32 is the size of a cacheline on PPC. Is there a missing cacheflush
> somewhere in the Sym53c875 driver? But then it should happen on disk as
> well?

The only PCI transaction that requires the cache line size to be correctly
configured is PCI WRITE and INVALIDATE. This transaction may be used by
the 875 only for data read from a SCSI device and DMAed to memory.

Note that the controller may use optimized PCI transactions only if the 
cache line size is configured in its PCI device configuration space.
Otherwise only normal PCI memory read and PCI memory write transactions 
will be used.

Could you check if the cache line size is configured for your 875?

Let me imagine it is so. Btw, I may be wasting my time if it is not ...
Then the 875 may also use PCI read multiple transactions and/or PCI read
line transactions when reading data from memory. If the corruption is due
to the use of these transactions, the the PCI-HOST bridges may well be the
culprit, in my opinion.

Anyway, since the sym53c8xx driver does not try to change the configured
cache line size on PPC, I would suggest to try again the same tests with
the cache line size set to zero for the 875. You may hack the driver code
or the PPC pci code if needed, for example, for value zero to be written
in the proper place in the PCI configuration space of the 875.

  Gérard.

-
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: Linux should better cope with power failure

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Otto Wyss <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> It was just a simple test machine where it didn't matter what was lost.
> Still that doesn't justify this behaviour.
> 

Then use a journalling filesystem.  If not, give it a few minutes of
idle time; fsck will complain on boot but it should be able to clean
up the mess.

-hpa
-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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/

OPPS 2.2.18

[James Stevenson]

ksymoops 2.3.4 on i686 2.2.18.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.2.18/ (default)
 -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
Unable to handle kernel paging request at virtual address 72043a2e
current->tss.cr3 = 04074000, %cr3 = 04074000
*pde = 000
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax:    ebx: c7be1000   ecx:    edx: 0078
esi: 0ab936c1   edi: c01818f0   ebp: c3de3c78   esp: c5525cac
ds: 0018   es: 0018   ss: 0018
Process diff (pid: 1805, process nr: 49, stackpage=c5525000)
Stack:  c02106d4 c01ef30d c018195a c7be1000 c5524000 c5525d84 c0162ac0 
   c3de3c78 c5525d84 0078 c5525cf8 c5524000 c3de3c78 c3e34000 0078 
   c5525cf8 c01818f0 c5525cf8 070d 01f4 0190   
Call Trace: [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] [] 
   [] [] [] [] [] [] 
[] 
Code: 00 90 2e 3a 04 72 0c 2e 3a 44 01 77 06 2e 84 54 02 75 09 83 

>>EIP; c00f36a1 Before first symbol   <=
Trace; c01ef30d 
Trace; c018195a 
Trace; c0162ac0 
Trace; c01818f0 
Trace; c019e687 
Trace; c019f9a0 
Trace; c019f92a 
Trace; c019de78 
Trace; c01a1873 <__rpc_execute+9f/2ac>
Trace; c01a1acb 
Trace; c01534e4 
Trace; c015356e 
Trace; c0153688 
Trace; c0153213 
Trace; c01538c1 
Trace; c011cb68 
Trace; c012b8df 
Trace; c011ccd7 
Trace; c011cc24 
Trace; c0152bae 
Trace; c0124a56 
Trace; c0109374 
Code;  c00f36a1 Before first symbol
 <_EIP>:
Code;  c00f36a1 Before first symbol   <=
   0:   00 90 2e 3a 04 72 add%dl,0x72043a2e(%eax)   <=
Code;  c00f36a7 Before first symbol
   6:   0c 2e or $0x2e,%al
Code;  c00f36a9 Before first symbol
   8:   3a 44 01 77   cmp0x77(%ecx,%eax,1),%al
Code;  c00f36ad Before first symbol
   c:   06push   %es
Code;  c00f36ae Before first symbol
   d:   2e 84 54 02 75test   %dl,%cs:0x75(%edx,%eax,1)
Code;  c00f36b3 Before first symbol
  12:   09 83 00 00 00 00 or %eax,0x0(%ebx)


2 warnings issued.  Results may not be reliable.
-
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: UDMA 100 / PIIX4 question

[Mark Hahn]

>Device BootStart   EndBlocks   Id  System
> /dev/hda1   * 1   932   7486258+   b  Win95 FAT32
> /dev/hda2   933  3737  22531162+   5  Extended
> /dev/hda5   933   935 24066   83  Linux
> /dev/hda6   936   952136521   82  Linux swap
> /dev/hda7   953  3737  22370481   83  Linux
> 
> 
> I also ran hdparm -tT /dev/hda1:
>  
> Timing buffer-cache reads:   128 MB in  1.28 seconds =100.00 MB/sec
>  Timing buffered disk reads:  64 MB in  4.35 seconds = 14.71 MB/sec
> 
> Which obviously gives much the same result as my usual hdparm -tT /dev/hda
> 
> I then tried hdparm -tT /dev/hda7:
> 
>  Timing buffer-cache reads:   128 MB in  1.28 seconds =100.00 MB/sec
>  Timing buffered disk reads:  64 MB in  2.12 seconds = 30.19 MB/sec
> 
> As you would expect, I get almost identical results with several repetitions.
> 
> Does this solve the mystery ?

no, it's quite odd.  hdparm -t cannot be effected by the filesystem
that lives in the partition, since hdparm is doing reads that don't
go through the filesystem.  hmm, I wonder if that's it: if you mount
the FS that's in hda1, it might change the block driver configuration
(changing the blocksize, for instance).  that would effect hdparm,
even though its reads don't go through the FS.

prediction: if you comment out the hda1 line in fstab, and reboot,
so that vfat never gets mounted on that partition, I predict that 
hdparm will show >30.19 MB/s on it.

-
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: NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel2.4.2-ac11 and earlier.

[Jeff Garzik]

"Manuel A. McLure" wrote:
> 
> System:
> AMD Athlon Thunderbird 900MHz
> MSI K7T Pro (VIA KT133 chipset)
> Network card: Linksys LNE100TX Rev. 4.0 (tulip)
> Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, 2.4.2, 2.4.2-ac11
> 
> With all the above kernel revisions/drivers, my network card hangs at random
> (sometimes within minutes, other times it takes days). To restart it I need
> to do an ifdown/ifup cycle and it will work fine until the next hang. I
> upgraded to 2.4.2-ac11 because of the documented tulip fixes, but after a
> few days got this again. The error log shows:

In Alan Cox terms, that's a long time ago :)

Can you please try 2.4.2-ac20?  It includes fixes specifically for this
problem.

-- 
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.
-
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/

NETDEV WATCHDOG: eth0: transmit timed out on LNE100TX 4.0, kernel 2.4.2-ac11 and earlier.

[Manuel A. McLure]

System:
AMD Athlon Thunderbird 900MHz
MSI K7T Pro (VIA KT133 chipset)
Network card: Linksys LNE100TX Rev. 4.0 (tulip)
Kernel: 2.2.18 (with 0.92 Scyld drivers), 2.4.0, 2.4.1, 2.4.2, 2.4.2-ac11

With all the above kernel revisions/drivers, my network card hangs at random
(sometimes within minutes, other times it takes days). To restart it I need
to do an ifdown/ifup cycle and it will work fine until the next hang. I
upgraded to 2.4.2-ac11 because of the documented tulip fixes, but after a
few days got this again. The error log shows:

Mar 16 18:37:00 ulthar kernel: NETDEV WATCHDOG: eth0: transmit timed out
Mar 16 18:37:00 ulthar kernel: eth0: Transmit timed out, status fc664010,
CSR12
, resetting...

ad infinitum until I do ifdown/ifup. The status & CSR12 values are always
the same. My card is detected as follows by the kernel:

Mar 12 21:38:49 ulthar kernel: Linux Tulip driver version 0.9.14c (March 3,
2001
)
Mar 12 21:38:49 ulthar kernel: PCI: Found IRQ 11 for device 00:0a.0
Mar 12 21:38:49 ulthar kernel: IRQ routing conflict in pirq table for device
00:
07.2
Mar 12 21:38:49 ulthar kernel: IRQ routing conflict in pirq table for device
00:
07.3
Mar 12 21:38:49 ulthar kernel: PCI: The same IRQ used for device 00:0e.0
Mar 12 21:38:49 ulthar kernel: eth0: ADMtek Comet rev 17 at 0xdc00,
00:20:78:0D:
D2:E1, IRQ 11.

Any ideas on why this might be happening? 

--
Manuel A. McLure - Unify Corp. Technical Support <[EMAIL PROTECTED]>
Space Ghost: "Hey, what happened to the-?" Moltar: "It's out." SG: "What
about-?" M: "It's fixed." SG: "Eh, good. Good."



-
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/

Memory leak in 2.4.2 (+loop-6-patch)???

[Matthias Schniedermeyer]

#Include 


After some days of uptime, i just stopped (nearly) all programs, unmounted
all unnecessary devices.

But top & free say that 1/3 of my RAM is still "used"


Here is what top means:

(Swap is 0K because i don't use Swap at all. Should i use swap?)

  9:54pm  up 11 days, 23 min,  4 users,  load average: 0.00, 0.22, 0.52
30 processes: 29 sleeping, 1 running, 0 zombie, 0 stopped
CPU0 states:  0.1% user,  0.0% system,  0.0% nice, 99.4% idle
CPU1 states:  0.0% user,  0.2% system,  0.0% nice, 99.3% idle
Mem:  1028648K av,  334624K used,  694024K free,   0K shrd,3556K buff
Swap:   0K av,   0K used,   0K free   55136K cached

  PID USER PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
1 root   4   0   100  10060 S 0.0  0.0   0:17 init
2 root   9   0 00 0 SW0.0  0.0   0:00 keventd
3 root   9   0 00 0 SW0.0  0.0   0:53 kswapd
4 root   9   0 00 0 SW0.0  0.0   0:00 kreclaimd
5 root   9   0 00 0 SW0.0  0.0   6:21 bdflush
6 root   9   0 00 0 SW0.0  0.0   0:34 kupdate
7 root   9   0 00 0 SW0.0  0.0   0:00 khubd
  294 root   8   0   164  16472 S 0.0  0.0   0:01 cron
  373 root   9   0   508  508   144 S 0.0  0.0   0:00 login
  374 root   9   0   508  508   144 S 0.0  0.0   0:00 login
  375 root   9   0   508  508   144 S 0.0  0.0   0:00 login
  380 root   9   084   84 0 S 0.0  0.0   0:00 mingetty
  385 root   9   0   508  508   144 S 0.0  0.0   0:00 login
  386 root   9   084   84 0 S 0.0  0.0   0:00 mingetty
  389 ms 8   0  1072 1072   736 S 0.0  0.1   0:00 bash
  396 root   0   0  1264 1264   896 S 0.0  0.1   0:01 bash
  404 root  11   0  1132 1132   732 S 0.0  0.1   0:01 bash
  463 citd   8   0  1192 1192   852 S 0.0  0.1   0:00 bash
 6520 root   9   0   612  612   524 S 0.0  0.0   0:00 mingetty
 6521 root   9   0   612  612   524 S 0.0  0.0   0:00 mingetty
 6522 root   9   0   612  612   524 S 0.0  0.0   0:00 mingetty
 6523 root   9   0   612  612   524 S 0.0  0.0   0:00 mingetty
 6524 root   9   0   612  612   524 S 0.0  0.0   0:00 mingetty
 6525 root   9   0   612  612   524 S 0.0  0.0   0:00 mingetty
 6526 root   9   0   612  612   524 S 0.0  0.0   0:00 mingetty
 6527 root   9   0   612  612   524 S 0.0  0.0   0:00 mingetty
 6528 root   9   0   612  612   524 S 0.0  0.0   0:00 mingetty
 6529 root   9   0   612  612   524 S 0.0  0.0   0:00 mingetty
 6652 root  12   0  1008 1008   804 R 0.0  0.0   0:00 top
 6663 root  17   0   544  544   468 S 0.0  0.0   0:00 gpm

uname -a
Linux leeloo 2.4.2 #18 SMP Fri Feb 23 19:31:03 CET 2001 i686 unknown

gcc --version
2.95.2






Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.


-
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: Question about memory usage in 2.4 vs 2.2

[Josh Grebe]

As far as performance goes, I can only say that my max load is slightly
lower on the 2.4 box then on the 2.2 boxes. Our average load for yesterday
on 2.4 was .23, with a max of 1.11. In comparison, my averages for the
other machines are .27, .27, .23, and .23. The maxes are 1.85, 1.33, 2.06,
1.47.

As far as speed goes, I am not able to measure any real difference (only
testing pop3) between 2.2 and 2.4. I would blame this on the NAS device, a
NetApp Filer F760 being only able to push about 110mbit sustained on the
gig-e network.

Thanks,

Josh
---
Josh Grebe
Senior Unix Systems Administrator
Primary Network, an MPower Company
http://www.primary.net

On Tue, 20 Mar 2001, [iso-8859-1] Jakob Østergaard wrote:

> On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> > Greetings,
> ...
> > Doing the math, the 2.4 machine is using 44% of available memory, while
> > the 2.2 is using only about 14%.
> 
> How is the performance difference ?
> 
> ...
> > These machines are dual P2-400's, with 512M ECC ram, adaptec 2940, and
> > dual intel etherexpress pro 100 cards.
> > 
> > I also tried 2.4.2-ac20 with similar results.
> > 
> > Am I missing something here? I'd really like to move the farm back up to
> > 2.4 series.
> 
> Free memory is wasted memory.   It seemed like 2.4 wasted a lot less memory
> than 2.2 on your workload.
> 
> Could you do some performance measurements (eg. average latency on IMAP
> connection or something like that)   ?It would be great to know wheter
> 2.4 is better or worse than 2.2  (it's most likely better, since it probably
> uses the memory better, but it would be nice to know)
> 
> -- 
> 
> :   [EMAIL PROTECTED]   : And I see the elder races, :
> :.: putrid forms of man:
> :   Jakob Østergaard  : See him rise and claim the earth,  :
> :OZ9ABN   : his downfall is at hand.   :
> :.:{Konkhra}...:
> 



-
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/

linux-2.4.x on asus CUW4X-DLS

[Alexander Lyamin]

Got 2.4.2 + ac-last patches applied.

boot impossible since it floods screen with emssages
about bugged clock (and blaming on possible VIA694 chipset).


any suggestions on patches i should apply?

P.S. initially tought its  becouse of scsi host drivers,
but at vendor ftp latest patches against 2.3.9-pre ( i assume they are mainline now ).

-- 
silence is science
Lex Lyamin, 'FLX' == 'Functional Lifelike Xenomorph'
-
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: Question about memory usage in 2.4 vs 2.2

[Josh Grebe]

slabinfo reports:

inode_cache   189974 243512480 30439 304391 :  124   62
dentry_cache  201179 341940128 11398 113981 :  252  126

However, I am hard pressed to find documentation on how to actually read
this data, especially on a SMP box. Could someone give me a brief
runwdown? 

Also, if this memory is cached, wouldn't it make sense if it were reported
as part of the total cached memory in /proc/meminfo?  And can this
behavior be tuned so that it uses less of the overall memory?

Thanks,

Josh

---
Josh Grebe
Senior Unix Systems Administrator
Primary Network, an MPower Company
http://www.primary.net

On Tue, 20 Mar 2001, Jan Harkes wrote:

> On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> > Greetings,
> > 
> > I have a server farm made of identical hardware running pop3 and imap mail
> > functions. recently, we upgraded all the machines to kernel 2.4.2, but we
> > noticed that according to free, our memory utilization went way up. Here
> > is the output of free on the 2.4.2 machine:
> >  total   used   free sharedbuffers cached
> > Mem:513192 492772  20420  0   1684 263188
> > -/+ buffers/cache: 227900 285292
> > Swap:   819304540 818764
> > 
> > 
> > On the 2.2..18 machine:
> >  total   used   free sharedbuffers cached
> > Mem:517256 351280 165976  19920  82820 186836
> > -/+ buffers/cache:  81624 435632
> > Swap:   819304  0 819304
> > 
> > 
> > Doing the math, the 2.4 machine is using 44% of available memory, while
> > the 2.2 is using only about 14%.
> 
> What does /proc/slabinfo report for the number of pages locked down in
> the inode and dentry caches? My machine has pretty much every inode in
> memory and is using close to 50% of my memory for these (214MB/512MB).
> 
> These caches do not seem to be counted towards 'reclaimable' memory by
> the new VM and are only pruned when _all_ other attempts to free up
> memory have failed.
> 
> This becomes very noticeable on a not very fast, small memory machine
> (i.e. 48MB sparc-IPC), where 2.2 stays relatively snappy, but 2.4
> becomes unusable after an updatedb run.
> 
> Jan
> 



-
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/

Problems with SCSI controller !!!

[Mircea Ciocan]

Hello everybody,

This is a message on behalf of a friend that is not subscribed to list:

It's about an ASUS board that has this ncr53-1010 dual 160 SCSI
controller (sym53c1010).
On both latest kernels (2.2.18ac19 AND 2.4.2ac18) the log and console
is filled with that:

sym53c1010-33-0: unable to abort current chip operation.
sym53c1010-33-0: Downloading SCSI SCRIPTS.
sym53c8xx_reset: pid=0 reset_flags=2 ...

and the controller suddenly blocks and the system have be restarted.

Do someone know the meaning of this messages and what's matter, do you
want more details and what else ???

Regards,

Mircea C.
-
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: esound (esd), 2.4.[12] chopped up sound -- solved

[Doug Ledford]

David Ford wrote:
> 
> Actually you probably upgraded to a non-broken version of esd.  Stock esd -still-
> writes to the socket without regard to return value.  If the write only accepted
> 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at
> 4097, not 2099.  esd is incredibly bad about err checking as is old e stuff.
> 
> I posted my last patch for esd here and to other places in June of 2000.  All it
> does is check for return value and adjust the writes accordingly.  For reference,
> the patch is at http://stuph.org/esound-audio.c.patch.

Why would esd get a short write() unless it is opening the file in non
blocking mode (which I didn't see when I was working on the i810 sound
driver)?  If esd is writing to a file in blocking mode and that write is
returning short, then that sounds like a driver bug to me.

-- 

 Doug Ledford <[EMAIL PROTECTED]>  http://people.redhat.com/dledford
  Please check my web site for aic7xxx updates/answers before
  e-mailing me about problems
-
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: esound (esd), 2.4.[12] chopped up sound -- solved

[David Ford]

Actually you probably upgraded to a non-broken version of esd.  Stock esd -still-
writes to the socket without regard to return value.  If the write only accepted
2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at
4097, not 2099.  esd is incredibly bad about err checking as is old e stuff.

I posted my last patch for esd here and to other places in June of 2000.  All it
does is check for return value and adjust the writes accordingly.  For reference,
the patch is at http://stuph.org/esound-audio.c.patch.

-d

Peter Lund wrote:

> Pozsar Balazs wrote:
>
> > Are you sure that the problem isn't at the mp3->raw conversino point? In
> > mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2,
> > but awfully on 2.4.
>
> Positive.  Anyway, the problem is solved now...I just want to investigate it a
> little bit further because I think there is something I can learn from it.
>
> In my original mail I wrote:
>
> > I've tested it on a freshly booted machine without X and gnome, only the bare
> > essentials for the machine + esd + esdcat (I converted one of my mp3's into raw
> > audio for the test).
>
> 1) mpg123 and XMMS sounded fine under 2.2.18 (which I hope was clear from what I
> wrote).
> 2) I played the raw sound directly to /dev/dsp -- worked great
> 3) I played it through esd on 2.2.18 -- worked great
>  (the latter two points should have been made explicitly but weren't - sorry)
>
> so the conclusion is that there is some bad interaction between 2.4.x, the esd
> version I was using, and the esdcat version I was using.   esdcat seemed pretty
> simple, it just
> wrote 4K at a time to a Unix socket, blocking as necessary, so I figured the
> culprit was elsewhere.
>
> The problem went away when I upgraded to the esd in Debian unstable (in the
> esound package).  I was either using an esd binary from Debian stable or one
> from one of the Ximian packages.  I'm still not sure whether they supply an esd
> themselves or just rely on the standard Debian one.
>
> I took a look at the diff between the stable/testing and unstable versions of
> the Debian esound package and there was a change in two or three places that
> seems to give a plausible explanation.  A simple write() was changed into a loop
> that retried the write() in case it was partial with an error code of EAGAIN
> (after sleeping 100 microseconds and with an upper bound on the number of
> retries).
>
> My theory now is that the sound driver changed in some way from 2.2.x to 2.4.x
> so some writes would only move a limited amount of bytes to the driver.  Maybe
> the driver only accepts about 4K in each version and the kernel performs the
> retries, sleeping in between?  Just a theory until I know more.
>
> Anyway, it works now with 2.4.x, even without the lowlatency patch from Andrew
> Morton.
>
> -Peter
> -
> 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/

--
  There is a natural aristocracy among men. The grounds of this are virtue and 
talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. 
Tanenbaum



-
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/

Rebooting a system with a bad filesystem (2.4.2 + ReiserFS)

[Jasmeet Sidhu]

Hi guys,

I have a system here with the following setup:

Filesystem   1k-blocks  Used Available Use% Mounted on
/dev/hda3 19072868   6260156  11843848  35% /
/dev/hda1   198313 18161169898  10% /boot
/dev/md0 525461076  89626136 435834940  18% /raid

/raid is the reiserfs volume.  / is ext2.

  The only thing on /raid is some pcbackup stuff. The system entirely runs 
from the root drive (ext2 filesystem).

Lately, reiserfs has been giving me problems. If I try to do anything on 
/raid - like vi a text file, the kernel will oops.  But the system will 
stay up.  All the services are there, and I can login.

However, I cannot unmount the partition, or do anythinh else.  Even if I 
call sync, it never returns.  I can't even reboot the system, or shutdown 
my nfs services.  Since all of the stuff is on the root drive, shouldn't 
linux be able to cope with such a situation?  I know that filesystems do 
get corrupted every now and then, especially if they are in the beta 
stage.  But such a malfunction should not keep the whole system from being 
shutdown.

The only way now is to hit the magic reset button.  With this, I loose a 
lot of data.  I dont know when sync was called last, but when I tried to 
call it manually, it never returned.

All the processes that are dealing with the /raid partition, are in STATE 
D,  uninterruptible sleep, and cannot be killed.

root   828 46.7 11.0 29628 28172 ?   D02:00 258:15 
/opt/legato/usr/sbin/save -s lester.arraycomm.com -g Linux Servers -LL -f - 
-m bertha.arraycomm.com -l full -q -W 78 -N /raid /raid
root  1599  0.0  0.2  1452  548 pts/4D10:40   0:00 umount /dev/md0
root  1634  0.0  0.2  1452  548 pts/6D10:45   0:00 umount /dev/md0

I'd appreciate any help.  Thank you.

Jasmeet.

-
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: st corruption with 2.4.3-pre4

[Geert Uytterhoeven]

On Tue, 20 Mar 2001, Geert Uytterhoeven wrote:
> On Mon, 19 Mar 2001, Jeff Garzik wrote:
> > Is the corruption reproducible?  If so, does the corruption go away if
> 
> Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB each to
> tape (I used a new one).
>   - test 1: 4 files with failed md5sum (no further investigation on type of
>   corruption)
>   - test 2: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were
>   corrupted, all starting at an offset of the form 32*x+1.
>   - test 3: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were
>   corrupted, all starting at an offset of the form 32*x+1.
> 
> The files seem to be corrupted during writing only, as reading always gives the
> exact same (corrupted) data back.
> 
> Copying files from the disk on the MESH to a disk on the Sym53c875 (which also
> has the tape drive) shows no corruption.

I did some more tests:
  - The problem also occurs when tarring up files from a disk on the Sym53c875.
  - The corrupted data always occurs at offset 32*x (the `+1' above was caused
by hexdump, starting counting at 1).
  - The 32 bytes of corrupted data at offset 32*x are always a copy of the data
at offset 32*x-10240.
  - Since 10240 is the default blocksize of tar (bug in tar?), I made a tarball
on disk instead of on tape, but no corruption.
  - 32 is the size of a cacheline on PPC. Is there a missing cacheflush
somewhere in the Sym53c875 driver? But then it should happen on disk as
well?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-
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: [CHECKER] blocking w/ spinlock or interrupt's disabled

[george anzinger]

Dawson Engler wrote:
> 
> > Is it difficult to split it into "interrupts disabled" and "spin lock
> > held"?
> 
Is it difficult to test for matching spinlock pairs such as
spin_lock_irq/spin_unlock_irq.  Sometimes a spin_lock_irq is followed by
a spin_unlock and a separate interrupt re-enable.  This sort of usage,
while not strictly wrong, does make it hard to use the spin_lock/unlock
macros to do preemption.  This said, pairing information would be very
helpful.  Note, there are several flavors here, not just the one I
cited.

George
-
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/

Matrox framebuffer dualhead and utilities

[German Gomez Garcia]

Hello,

I'm trying to set the Matrox framebuffer to dualhead or TV output,
but the utilities mentioned in the docs seem to be outdated (ioctl failed
with incorrect command). Any idea about where to get up to date tools?
I'm using kernel 2.4.2-ac20 (quite stable 5 days uptime with heavy DRI
testing and heavy disk working).

Thanks

- german


PS: Please CC to me as I'm not subscribed to the list.
-
German Gomez Garcia | "This isn't right.  This isn't even wrong."
<[EMAIL PROTECTED]> | -- Wolfgang Pauli


-
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: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[Jakob Østergaard]

On Tue, Mar 20, 2001 at 10:43:33AM -0800, Linus Torvalds wrote:
> 
> 
> On Tue, 20 Mar 2001, Serge Orlov wrote:
> >
> > I upgraded one of our computer happily running 2.2.13 kernel
> > to 2.4.2. Everything was OK, but compilation time of our C++
> > project greatly increased (1.4 times slower). I investigated the
> > issue and found that g++ spends 7 times more time in kernel.
> > The reason for this is big vm map:
> 
> Cool. Somebody actually found a real case.
> 
> I'll fix the mmap case asap. Its' not hard, I just waited to see if it
> ever actually triggers. Something like g++ certainly counts as major.

Uber-cool !  :)

> 
> Are you willing to test out patches?

Definitely.

-- 

:   [EMAIL PROTECTED]   : And I see the elder races, :
:.: putrid forms of man:
:   Jakob Østergaard  : See him rise and claim the earth,  :
:OZ9ABN   : his downfall is at hand.   :
:.:{Konkhra}...:
-
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: Question about memory usage in 2.4 vs 2.2

[Jan Harkes]

On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> Greetings,
> 
> I have a server farm made of identical hardware running pop3 and imap mail
> functions. recently, we upgraded all the machines to kernel 2.4.2, but we
> noticed that according to free, our memory utilization went way up. Here
> is the output of free on the 2.4.2 machine:
>  total   used   free sharedbuffers cached
> Mem:513192 492772  20420  0   1684 263188
> -/+ buffers/cache: 227900 285292
> Swap:   819304540 818764
> 
> 
> On the 2.2..18 machine:
>  total   used   free sharedbuffers cached
> Mem:517256 351280 165976  19920  82820 186836
> -/+ buffers/cache:  81624 435632
> Swap:   819304  0 819304
> 
> 
> Doing the math, the 2.4 machine is using 44% of available memory, while
> the 2.2 is using only about 14%.

What does /proc/slabinfo report for the number of pages locked down in
the inode and dentry caches? My machine has pretty much every inode in
memory and is using close to 50% of my memory for these (214MB/512MB).

These caches do not seem to be counted towards 'reclaimable' memory by
the new VM and are only pruned when _all_ other attempts to free up
memory have failed.

This becomes very noticeable on a not very fast, small memory machine
(i.e. 48MB sparc-IPC), where 2.2 stays relatively snappy, but 2.4
becomes unusable after an updatedb run.

Jan

-
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: VIA686B + 2.2.18 (was: VIA686A chipset crash under 2.4.2-ac20)

[Andre Hedrick]

On Fri, 16 Mar 2001, William Park wrote:

> I'm running 2.2.18 on VIA686B (ABit VP6).  Some time ago, you mentioned
> that you got ~80Mb/s from 'hdparm -t /dev/hda'.  Please tell us how?
> Which hdparm/kernel options did you enable?

Nope not w/ 'hdparm' with DiskPerf and correcting for CR3's on memcpy's.

[root@via DiskPerf-1.0.3]# ./DiskPerf /dev/hda
Device: IBM-DTLA-307030 Serial Number: YKDYKM37674
LBA 0 DMA Read Test  = 56.62 MB/Sec (4.42 Seconds)
Outer Diameter Sequential DMA Read Test  = 35.46 MB/Sec (7.05 Seconds)
Inner Diameter Sequential DMA Read Test  = 17.72 MB/Sec (14.10 Seconds)

When you adjust for memory delays (of 35-40%) then you get those number.
and those numbers are valid inside for kernel-kernel access, not
kernel-user-space.

Cheers,

Andre Hedrick
Linux ATA Development


-
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: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[Linus Torvalds]

On Tue, 20 Mar 2001, Serge Orlov wrote:
>
> I upgraded one of our computer happily running 2.2.13 kernel
> to 2.4.2. Everything was OK, but compilation time of our C++
> project greatly increased (1.4 times slower). I investigated the
> issue and found that g++ spends 7 times more time in kernel.
> The reason for this is big vm map:

Cool. Somebody actually found a real case.

I'll fix the mmap case asap. Its' not hard, I just waited to see if it
ever actually triggers. Something like g++ certainly counts as major.

Are you willing to test out patches?

Linus

-
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: Linux 2.4.2 fails to merge mmap areas, 700% slowdown.

[Jakob Østergaard]

On Tue, Mar 20, 2001 at 09:28:57PM +0300, Serge Orlov wrote:
>  Hi,
> I upgraded one of our computer happily running 2.2.13 kernel
> to 2.4.2. Everything was OK, but compilation time of our C++
> project greatly increased (1.4 times slower). I investigated the
> issue and found that g++ spends 7 times more time in kernel.

I see the *exact* same problem. Large C++ codes, and gcc spending most of the
CPU time in kernel.

> The reason for this is big vm map:
> 
> cat /proc/15677/maps |wc -l
>2238

Exactly what I see too.   200 MB of memory allocated in 4K maps...

There is an easy fix:  In libiberty in GCC we could change xmalloc()
to do real malloc instead of calloc().   I think that would fix it.

Or glibc could be fixed to make calloc() behave more reasonably
when it's called with tons and tons of 4K allocations.

Or the kernel could be fixed to merge maps.

...
> .
> 15677 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40019000

hear hear !   

...
> 
> OK, the numbers are here. g++ is 2.96 from RedHat 7.0.
> Please, CC me, as I'm not on the list.

gcc 2.96 here too.

Should we take this up with the glibc or gcc folks, or should
someone fix the kernel ?

This *is* a very significant performance problem for a standard tool.

-- 

:   [EMAIL PROTECTED]   : And I see the elder races, :
:.: putrid forms of man:
:   Jakob Østergaard  : See him rise and claim the earth,  :
:OZ9ABN   : his downfall is at hand.   :
:.:{Konkhra}...:
-
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: esound (esd), 2.4.[12] chopped up sound -- solved

[Peter Lund]

Pozsar Balazs wrote:

> Are you sure that the problem isn't at the mp3->raw conversino point? In
> mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2,
> but awfully on 2.4.

Positive.  Anyway, the problem is solved now...I just want to investigate it a
little bit further because I think there is something I can learn from it.


In my original mail I wrote:

> I've tested it on a freshly booted machine without X and gnome, only the bare
> essentials for the machine + esd + esdcat (I converted one of my mp3's into raw
> audio for the test).

1) mpg123 and XMMS sounded fine under 2.2.18 (which I hope was clear from what I
wrote).
2) I played the raw sound directly to /dev/dsp -- worked great
3) I played it through esd on 2.2.18 -- worked great
 (the latter two points should have been made explicitly but weren't - sorry)

so the conclusion is that there is some bad interaction between 2.4.x, the esd
version I was using, and the esdcat version I was using.   esdcat seemed pretty
simple, it just
wrote 4K at a time to a Unix socket, blocking as necessary, so I figured the
culprit was elsewhere.

The problem went away when I upgraded to the esd in Debian unstable (in the
esound package).  I was either using an esd binary from Debian stable or one
from one of the Ximian packages.  I'm still not sure whether they supply an esd
themselves or just rely on the standard Debian one.

I took a look at the diff between the stable/testing and unstable versions of
the Debian esound package and there was a change in two or three places that
seems to give a plausible explanation.  A simple write() was changed into a loop
that retried the write() in case it was partial with an error code of EAGAIN
(after sleeping 100 microseconds and with an upper bound on the number of
retries).

My theory now is that the sound driver changed in some way from 2.2.x to 2.4.x
so some writes would only move a limited amount of bytes to the driver.  Maybe
the driver only accepts about 4K in each version and the kernel performs the
retries, sleeping in between?  Just a theory until I know more.

Anyway, it works now with 2.4.x, even without the lowlatency patch from Andrew
Morton.

-Peter
-
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/

kernel 2.4.2 OOPS (in add_entropy_words ?)

[Wayne Whitney]

Hi,

I got the following OOPS yesterday while simultaneously doing a big 'rpm
-U' and a big computation (magma.exe) on an SMP i686 machine.  I copied
the OOPS down by hand from the console, but it should be accurate.  When
running ksymooops, I don't know that I reconstructed the module stack
completely, but I don't believe any modules are implicated in the trace.

Any suggestions would be welcome.  Of particular interest is how to tell
whether this is an 'off by one bit' error implicating the memory.  More
information about the machine is obviously available, I just thought this
is the relevant part.

Cheers,
Wayne

ksymoops 2.4.1 on i686 2.4.2.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.2/ (default)
 -m /boot/System.map (specified)

Warning (compare_maps): ksyms_base symbol pcmcia_lookup_bus_R__ver_pcmcia_lookup_bus 
not found in System.map.  Ignoring ksyms_base entry
Unable to handle kernel NULL pointer dereference at virtual address 0100
c0193d4b
Oops: 
CPU: 1
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 0040 ebx: c77c ecx: 0040 edx: 
esi: 007f edi: c322fc20 ebp:  esp: d1f15f10
ds: 0018 es: 0018 ss: 0018
Process magma.exe (pid: 5487, stackpage=d1f15000)
Stack: c322fe20 1000 0009 c02f8ea0 c0193f5c c322fe20 c3268948 0002
   d1f15f44 d1f15f44 0020 c0119f9d c322fe20 c02f22ec c02f22ec 0001
    c011c889 c028d2c0 0086 c010de9f d1f15fc4 d1f14000 c0119e8c
Call Trace: [] [] [] [] [] 
[] []
[] [] []
Code: 33 1c 82 89 c8 03 47 18 21 f0 33 1c 82 89 c8 03 47 1c 21 f0

>>EIP; c0193d4b<=
Trace; c0193f5c 
Trace; c0119f9d <__run_task_queue+5d/70>
Trace; c011c889 
Trace; c010de9f 
Trace; c0119e8c 
Trace; c0119d43 
Trace; c0119bcb 
Trace; c010aca5 
Trace; c01091a8 
Trace; c010002b 
Code;  c0193d4b 
 <_EIP>:
Code;  c0193d4b<=
   0:   33 1c 82  xor(%edx,%eax,4),%ebx   <=
Code;  c0193d4e 
   3:   89 c8 mov%ecx,%eax
Code;  c0193d50 
   5:   03 47 18  add0x18(%edi),%eax
Code;  c0193d53 
   8:   21 f0 and%esi,%eax
Code;  c0193d55 
   a:   33 1c 82  xor(%edx,%eax,4),%ebx
Code;  c0193d58 
   d:   89 c8 mov%ecx,%eax
Code;  c0193d5a 
   f:   03 47 1c  add0x1c(%edi),%eax
Code;  c0193d5d 
  12:   21 f0 and%esi,%eax

Kernel panic: Aiee, killing interrupt handler!

1 warning issued.  Results may not be reliable.

-
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: [PATCH for 2.5] preemptible kernel

[Roger Larsson]

Hi,

One little readability thing I found.
The prev->state TASK_ value is mostly used as a plain value
but the new TASK_PREEMPTED is or:ed together with whatever was there.
Later when we switch to check the state it is checked against TASK_PREEMPTED
only. Since TASK_RUNNING is 0 it works OK but...

--- sched.c.nigel   Tue Mar 20 18:52:43 2001
+++ sched.c.roger   Tue Mar 20 19:03:28 2001
@@ -553,7 +553,7 @@
 #endif
del_from_runqueue(prev);
 #ifdef CONFIG_PREEMPT
-   case TASK_PREEMPTED:
+   case TASK_RUNNING | TASK_PREEMPTED:
 #endif
case TASK_RUNNING:
}


We could add all/(other common) combinations as cases 

switch (prev->state) {
case TASK_INTERRUPTIBLE:
if (signal_pending(prev)) {
prev->state = TASK_RUNNING;
break;
}
default:
#ifdef CONFIG_PREEMPT
if (prev->state & TASK_PREEMPTED)
break;
#endif
del_from_runqueue(prev);
#ifdef CONFIG_PREEMPT
case TASK_RUNNING   | TASK_PREEMPTED:
case TASK_INTERRUPTIBLE | TASK_PREEMPTED:
case TASK_UNINTERRUPTIBLE   | TASK_PREEMPTED:
#endif
case TASK_RUNNING:
}


Then the break in default case could almost be replaced with a BUG()...
(I have not checked the generated code)

/RogerL
-
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: [PATCH] Re: PCMCIA serial CardBus support vanished in2.4.3-pre3 and later

[Miles Lane]

On 20 Mar 2001 10:37:40 -0500, Jeff Garzik wrote:
> On closer inspection, that patch I linked to appears to be incomplete.
> 
> Can you try the attached patch, to see if it fixes the
> absence-of-serial_cb problem?
> 
> Thanks,
> 
>   Jeff
> 
> 
> P.S. I'm surprised serial_cb in 2.4 worked at all, for anybody.  I guess
> they must be using pcmcia_cs's serial_cb, not the kernel's serial_cb...


Yes.  Well, this just strengthens the case for getting PCMCIA support
migrated fully into the kernel tree so that we can pry people's finger
loose from pcmcia_cs.  David Woodhouse is planning to take up this
project early in the 2.5 development cycle.

It's kind of a shame that more testing of the 2.4.x Cardbus/PCMCIA 
drivers isn't happening, because a lot of the Cardbus/PCMCIA support
in the kernel tree is really just fine.  We should all be using it and
testing it and reporting bugs.

One of the work items will be getting the in-kernel PCMCIA support
to work with the new hotplug stuff.


Miles

-
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/

BH implementation question

[Anders Peter Fugmann]

Hi I have a couple of questions to the kernel code.

I have been trying to fully inderstand (and doccument) the changes in 
2.4 wrt. Tasklets and softirq's, BH's and task queues.

In my try to understand how it all works, I came across the code:

(linux/kernel/softirq.c: 246)

static void bh_action(unsigned long nr)
{
int cpu = smp_processor_id();

if (!spin_trylock(_bh_lock))
goto resched;

if (!hardirq_trylock(cpu))
goto resched_unlock;

if (bh_base[nr])
bh_base[nr]();

hardirq_endlock(cpu);
spin_unlock(_bh_lock);
return;

resched_unlock:
spin_unlock(_bh_lock);
resched:
mark_bh(nr);
}

Now all of this but the hardirq_trylock(cpu) and hardirq_endlock(cpu) 
makes perfectly sence.

Anyone care to explain the what theese lines do.

Secondly.

Is there a reason why to implement a queue (TASKLET_HI) for the old 
BH's, instead of just using a single tasklet for all BH administraton. 
Would'ent this guarentee that no BH is executed at the same time, and at 
the same time reduce code complexity, and remove the global_bh_lock?


TIA
Anders Fugmann



-- 
Hi. I'm a .signature virus.
Please copy me into your .signature file and help me spread.

-
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: esound (esd), 2.4.[12] chopped up sound

[Pozsar Balazs]

> On my home machine playing sound through esd has worked beautifully on various
> kernels from 2.2.5 and up to 2.2.18.
> On 2.4.1 and 2.4.2 it stinks.
>
> It sounds like there are small pauses or repetitions in the sound, as if esd
> doesn't get
> the data quickly enough from the client or something.  Music and voices
> (realaudio radio) still easy to understand but it does get on my nerves after a
> few minutes :(

Are you sure that the problem isn't at the mp3->raw conversino point? In
mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2,
but awfully on 2.4.
I suggest you trying another (meybe self-compiled) version of mpg123.

bye,
Balazs Pozsar.

-
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: Question about memory usage in 2.4 vs 2.2

[Jakob Østergaard]

On Tue, Mar 20, 2001 at 11:01:52AM -0600, Josh Grebe wrote:
> Greetings,
...
> Doing the math, the 2.4 machine is using 44% of available memory, while
> the 2.2 is using only about 14%.

How is the performance difference ?

...
> These machines are dual P2-400's, with 512M ECC ram, adaptec 2940, and
> dual intel etherexpress pro 100 cards.
> 
> I also tried 2.4.2-ac20 with similar results.
> 
> Am I missing something here? I'd really like to move the farm back up to
> 2.4 series.

Free memory is wasted memory.   It seemed like 2.4 wasted a lot less memory
than 2.2 on your workload.

Could you do some performance measurements (eg. average latency on IMAP
connection or something like that)   ?It would be great to know wheter
2.4 is better or worse than 2.2  (it's most likely better, since it probably
uses the memory better, but it would be nice to know)

-- 

:   [EMAIL PROTECTED]   : And I see the elder races, :
:.: putrid forms of man:
:   Jakob Østergaard  : See him rise and claim the earth,  :
:OZ9ABN   : his downfall is at hand.   :
:.:{Konkhra}...:
-
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: UDMA 100 / PIIX4 question

[Jeremy Jackson]

Holger Lubitz wrote:

> [EMAIL PROTECTED] wrote:
> >
> > On Mon, 19 Mar 2001 12:17:38 -0800
> > Tim Moore <[EMAIL PROTECTED]> wrote:
> >
> > > Apologies for the too brief answer.  Sustained real world transfer rates
> > > for the PIIX4 under ideal
> > > setup conditions and a quiet bus are 14-18MB/s.
>
> I dare to disagree. These numbers are from an Asus P2L97-DS (Dual P2,
> Intel 440LX chipset with PIIX4) with an IBM DTLA 307045:

Yes this is why I originally replied to the post... but he's not using a PIIXx at
all,
but the IDE chip on an Intel 815 motherboard.  I'm not sure if they use the same
driver
, but I don't think so.

>
>
> /dev/hda5:
>  Timing buffer-cache reads:   128 MB in  1.21 seconds =105.79 MB/sec
>  Timing buffered disk reads:  64 MB in  2.30 seconds = 27.83 MB/sec
>
> /dev/hda5 is the outermost linux partition, starting at cyl 256.
>
> (if you don't count hdparm measurements as real world transfer rates -
> linear read as measured by bonnie is 26.3 MB/s).
>
> > There is a Win partition - so I do not think I am at the start of the drive.
> >
> > Then  hdparm -tT /dev/hda
> >
> > /dev/hda:
> >  Timing buffer-cache reads:   128 MB in  1.04 seconds =123.08 MB/sec
> >  Timing buffered disk reads:  64 MB in  4.08 seconds = 15.69 MB/sec
>
> Would your windows partition by any chance be at the beginning of the
> disk?
> hdparm speed measurements differ by filesystem (i have no idea why,

this is false.  They may differ by partition, since different parts (zones) of a
modern disk have different recording densities and therefore transfer rates.
IBM's spec sheet says rates vary from 15MB/sec to 31MB/sec... it he's seeing
15MB/sec, maybe he should try the other end of the disk.  can you verify this?
try hdparm -t /dev/hda1 instead of hda5 (if those are on opposite ends of the
disk)

include output of fdisk so we can see partition layout, and results of hdparm on
different areas.

>
> since they don't go through it - maybe some interaction with the
> buffering code).
>
> if you are testing a windows partition, you can expect to see
> significantly lower values for hdparm:
>
> /dev/hda1:
>  Timing buffer-cache reads:   128 MB in  1.65 seconds = 77.58 MB/sec
>  Timing buffered disk reads:  64 MB in  3.48 seconds = 18.39 MB/sec

please show us your partition table.

>
>
> Remarkably /dev/hda benches slightly better, even though the 64 MB read
> are nearly the same as for hda1:
>
> /dev/hda:
>  Timing buffer-cache reads:   128 MB in  1.40 seconds = 91.43 MB/sec
>  Timing buffered disk reads:  64 MB in  3.06 seconds = 20.92 MB/sec
>
> I also noticed that operations on a lot of files (like scanning for all
> files in a filesystem as done by updatedb) got really slow with the 2.4
> vfat fs, with a very high percentage (in the 90s) of CPU time attributed
> to "system". Has anybody else noticed this?

-
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: LDT allocated for cloned task!

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Pau  <[EMAIL PROTECTED]> wrote:
>
>I've been running 2.4.3-pre4 for a few days now and today I've got this
>message in the logs a couple of times. Is it harmless?

It's harmless.

It's really a warning that says: the mm that you allocated a new LDT for
may have multiple users, and while the LDT is added to all of them, we
don't guarantee _when_ the other users will actually see the LDT.

It so happens that the other users are probably just something like
"top" or similar, that increment the MM count to make sure that the MM
doesn't go away while they get information about the process. And those
users don't care about the LDT in the least.

Linus
-
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/

Question about memory usage in 2.4 vs 2.2

[Josh Grebe]

Greetings,

I have a server farm made of identical hardware running pop3 and imap mail
functions. recently, we upgraded all the machines to kernel 2.4.2, but we
noticed that according to free, our memory utilization went way up. Here
is the output of free on the 2.4.2 machine:
 total   used   free sharedbuffers cached
Mem:513192 492772  20420  0   1684 263188
-/+ buffers/cache: 227900 285292
Swap:   819304540 818764


On the 2.2..18 machine:
 total   used   free sharedbuffers cached
Mem:517256 351280 165976  19920  82820 186836
-/+ buffers/cache:  81624 435632
Swap:   819304  0 819304


Doing the math, the 2.4 machine is using 44% of available memory, while
the 2.2 is using only about 14%.

Here are the contents of /proc/meminfo on 2.4:
total:used:free:  shared: buffers:  cached:
Mem:  525508608 517480448  80281600  1138688 282091520
Swap: 838967296   552960 838414336
MemTotal:   513192 kB
MemFree:  7840 kB
MemShared:   0 kB
Buffers:  1112 kB
Cached: 275480 kB
Active: 254876 kB
Inact_dirty: 18880 kB
Inact_clean:  2836 kB
Inact_target:   48 kB
HighTotal:   0 kB
HighFree:0 kB
LowTotal:   513192 kB
LowFree:  7840 kB
SwapTotal:  819304 kB
SwapFree:   818764 kB

on 2.2:
total:used:free:  shared: buffers:  cached:
Mem:  529670144 366837760 162832384 22945792 84807680 194367488
Swap: 8389672960 838967296
MemTotal:517256 kB
MemFree: 159016 kB
MemShared:22408 kB
Buffers:  82820 kB
Cached:  189812 kB
SwapTotal:   819304 kB
SwapFree:819304 kB

These machines are dual P2-400's, with 512M ECC ram, adaptec 2940, and
dual intel etherexpress pro 100 cards.

I also tried 2.4.2-ac20 with similar results.

Am I missing something here? I'd really like to move the farm back up to
2.4 series.

Thanks,

Josh

---
Josh Grebe
Senior Unix Systems Administrator
Primary Network, an MPower Company
http://www.primary.net


-
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: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later

[Alessandro Suardi]

Pau wrote:
> 
> On Tue, 20 Mar 2001, Linus Torvalds wrote:
> 
> >
> >
> > On Tue, 20 Mar 2001, Alessandro Suardi wrote:
> > >
> > >  2.4.3-pre3 and synced-up versions of the -ac series remove support for
> > >  PCMCIA serial CardBus. In drivers/char/pcmcia the Makefile and Config.in
> > >  files are modified to exclude serial_cb and the serial_cb.c file itself
> > >  is removed by the patch. As a net result, my Xircom modem port becomes
> > >  invisible to the kernel and I can't dial out through it.
> >
> > The regular serial.c should handle it natively. Just make sure you have
> > CONFIG_SERIAL enabled, along with hotplugging support etc.
> 
> In fact it does. I discovered it last weekend when my modem -them same one
> than Alessandro's- stopped working.
> 
> Removing "alias char-major-4 serial_cb" from modules.conf did the trick
> and the serial driver worked flawlessly. Modules serial got loaded
> instead.

Cool... but I have used for a while serial_cb in kernel, not as a module
 so there is nothing to remove here :) as for Jeff's surprise I have had
 basically no problem in using kernel PCMCIA stuff in 2.4 series, apart
 from the usual Tx hang bug of the Xircom.

Built with Jeff's latest patch, rebooting

--alessandro  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Linux:  kernel 2.2.19p17/2.4.3p4 glibc-2.2 gcc-2.96-69 binutils-2.11.90.0.1
Oracle: Oracle8i 8.1.7.0.1 Enterprise Edition for Linux
motto:  Tell the truth, there's less to remember.
-
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: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later

[Pau]

On Tue, 20 Mar 2001, Alessandro Suardi wrote:

> > Removing "alias char-major-4 serial_cb" from modules.conf did the trick
> > and the serial driver worked flawlessly. Modules serial got loaded
> > instead.
>
> Cool... but I have used for a while serial_cb in kernel, not as a module
>  so there is nothing to remove here :) as for Jeff's surprise I have had
>  basically no problem in using kernel PCMCIA stuff in 2.4 series, apart
>  from the usual Tx hang bug of the Xircom.

I've been using it since first 2.3 series :)
I still have the Tx hang basically with NFS, but also when moving high
amount of Mb in the LAN.
I've moved from pcmcia-cs to hotplug and it works too :)

Pau

-
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: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later

[Pau]

On Tue, 20 Mar 2001, Linus Torvalds wrote:

>
>
> On Tue, 20 Mar 2001, Alessandro Suardi wrote:
> >
> >  2.4.3-pre3 and synced-up versions of the -ac series remove support for
> >  PCMCIA serial CardBus. In drivers/char/pcmcia the Makefile and Config.in
> >  files are modified to exclude serial_cb and the serial_cb.c file itself
> >  is removed by the patch. As a net result, my Xircom modem port becomes
> >  invisible to the kernel and I can't dial out through it.
>
> The regular serial.c should handle it natively. Just make sure you have
> CONFIG_SERIAL enabled, along with hotplugging support etc.

In fact it does. I discovered it last weekend when my modem -them same one
than Alessandro's- stopped working.

Removing "alias char-major-4 serial_cb" from modules.conf did the trick
and the serial driver worked flawlessly. Modules serial got loaded
instead.

Pau

-
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/

LDT allocated for cloned task!

[Pau]

I've been running 2.4.3-pre4 for a few days now and today I've got this
message in the logs a couple of times. Is it harmless?

Pau

-
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/

[Fwd: [reiserfs-dev] [Fwd: [reiserfs-list] 2.4.3-pre1 oops w/ rsync & ReiserFS]]

[Hans Reiser]

David, did you determine if it was a memory bug?


Just to note: stack trace doesn't involve reiserfs at all. Other people
suggested that it may me memory bug.

Nikita.

Hans Reiser writes:
 > Who is taking this one?
 > 
 > HansReturn-Path: <[EMAIL PROTECTED]>
 > Delivered-To: [EMAIL PROTECTED]
 > Received: (qmail 30581 invoked by uid 501); 19 Mar 2001 23:27:52 -
 > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 > Precedence: bulk
 > list-help: 
 > list-unsubscribe: 
 > list-post: 
 > Delivered-To: mailing list [EMAIL PROTECTED]
 > Received: (qmail 30574 invoked from network); 19 Mar 2001 23:27:52 -
 > Date: Mon, 19 Mar 2001 15:28:42 -0800
 > From: David Raufeisen <[EMAIL PROTECTED]>
 > To: [EMAIL PROTECTED]
 > Cc: [EMAIL PROTECTED]
 > Message-ID: <[EMAIL PROTECTED]>
 > Reply-To: David Raufeisen <[EMAIL PROTECTED]>
 > Mime-Version: 1.0
 > Content-Type: text/plain; charset=us-ascii
 > Content-Disposition: inline
 > User-Agent: Mutt/1.3.12i
 > X-Operating-System: Linux 2.2.17 i686
 > Subject: [reiserfs-list] 2.4.3-pre1 oops w/ rsync & ReiserFS
 > X-Mozilla-Status2: 
 > 
 > Getting oops every time I run rsync today.. happens after it receives file list and 
 >is starting to stat all the files.. filesystem is reiser.
 > 
 > Linux prototype 2.4.3-pre1 #2 Thu Mar 15 00:24:43 PST 2001 i686 unknown
 > 
 > 15:25:28 up 1 day, 20:05,  4 users,  load average: 0.00, 0.03, 0.00
 > 
 > Linux prototype 2.4.3-pre1 #2 Thu Mar 15 00:24:43 PST 2001 i686 unknown
 >  
 > Gnu C  2.95.3
 > Gnu make   3.79.1
 > binutils   2.11.90.0.1
 > util-linux 2.11a
 > modutils   2.4.2
 > e2fsprogs  1.19
 > reiserfsprogs  3.x.0b
 > Linux C Library2.2.2
 > Dynamic linker (ldd)   2.2.2
 > Procps 2.0.7
 > Net-tools  1.59
 > Kbdcommand
 > Sh-utils   2.0.11
 > Modules Loaded NVdriver
 > 
 > prototype:~# ksymoops oops.txt
 > ksymoops 2.3.7 on i686 2.4.3-pre1.  Options used
 >  -V (default)
 >  -k /proc/ksyms (default)
 >  -l /proc/modules (default)
 >  -o /lib/modules/2.4.3-pre1/ (default)
 >  -m /System.map (default)
 > 
 > Warning: You did not tell me where to find symbol information.  I will
 > assume that the log matches the kernel and modules that are running
 > right now and I'll use the default options above for symbol resolution.
 > If the current kernel and/or modules do not match the log, you can get
 > more accurate output by telling me the kernel version and where to find
 > map, modules, ksyms etc.  ksymoops -h explains the options.
 > 
 > Unable to handle kernel paging request at virtual address 4280d8c4
 > c01410c0
 > *pde = 
 > Oops: 
 > CPU:0
 > EIP:0010:[]
 > Using defaults from ksymoops -t elf32-i386 -a i386
 > EFLAGS: 00210207
 > eax: c7fdc5e0   ebx: 4280d8ac   ecx: 000e   edx: 21cd5a87
 > esi:    edi: c71424c0   ebp: 4280d8c4   esp: c37b1f04
 > ds: 0018   es: 0018   ss: 0018
 > Process rsync (pid: 16269, stackpage=c37b1000)
 > Stack: c37b1f68  c71424c0 c37b1fa4 c7fdc5e0 c5919022 21cd5a87 000a 
 >c01392d0 c71424c0 c37b1f68 c37b1f68 c0139a92 c71424c0 c37b1f68  
 >c5919000  c37b1fa4  c5919000  c01390da 0008 
 > Call Trace: [] [] [] [] [] 
 >[] [] 
 > Code: 8b 6d 00 8b 54 24 18 39 53 48 75 7c 8b 44 24 24 39 43 0c 75 
 > 
 > >>EIP; c01410c0<=
 > Trace; c01392d0 
 > Trace; c0139a92 
 > Trace; c01390da 
 > Trace; c013a0dc <__user_walk+3c/60>
 > Trace; c0137116 
 > Trace; c012f453 
 > Trace; c0108e8b 
 > Code;  c01410c0 
 >  <_EIP>:
 > Code;  c01410c0<=
 >0:   8b 6d 00  mov0x0(%ebp),%ebp   <=
 > Code;  c01410c3 
 >3:   8b 54 24 18   mov0x18(%esp,1),%edx
 > Code;  c01410c7 
 >7:   39 53 48  cmp%edx,0x48(%ebx)
 > Code;  c01410ca 
 >a:   75 7c jne88 <_EIP+0x88> c0141148 
 > Code;  c01410cc 
 >c:   8b 44 24 24   mov0x24(%esp,1),%eax
 > Code;  c01410d0 
 >   10:   39 43 0c  cmp%eax,0xc(%ebx)
 > Code;  c01410d3 
 >   13:   75 00 jne15 <_EIP+0x15> c01410d5 
 > 
 > 
 > 1 warning issued.  Results may not be reliable.
 > 
 > 
 > 
 > -- 
 > David Raufeisen <[EMAIL PROTECTED]>
 > Cell: (604) 818-3596
 > 

Re: IBM ServeRAID 4L firmware 4.40.03

[Pim Zandbergen]

On Wed, 14 Mar 2001 23:19:05 GMT, Robert Miciovici wrote:

>look what I get on one of the installation log screens:
>
>* Cannot find /tmp/drivers/rhdd-6.1; bad driver disk
>* Cannot find /tmp/drivers/modinfo; bad driver disk
>* Cannot find /tmp/drivers/modules.dep; bad driver disk
>* Cannot find /tmp/drivers/pcitable; bad driver disk

[ ... ]

>What do you say, how should I approach this one?

Are you using the right version of the driver disk and
firmware? It should be 4.50.

You best download the latest ServeRAID Support CD image:
ftp://ftp.pc.ibm.com/pub/pccbbs/pc_servers/25p2529.iso

You can upgrade your ServeRAID firmware & BIOS by booting
from this CD, and it contains a driver disk floppy image
that supports installing RedHat 7.0. It worked for me.

Supposedly there's a version 4.70 coming soon that will
suppport kernel 2.4. The current 4.50 driver is unstable
on kernel 2.4.
-
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/

Developing Linux-compatible Ethernet hardware

[J.D. Bakker]

Hi all,

I need a Fast Ethernet chip for an Open Hardware PCI board I'm 
working on. Of course said chip has to be available in small 
quantities (and not just attached to a NIC), and well supported by 
Linux. Other 'nice but not crucial' properties would be:

- Gigabit Ethernet support
- Integrated PHY
- 66MHz PCI compliant
- Multiple ports

As it stands I'm thinking about using the Intel 82559ER (which lacks 
Gig Enet and 66MHz PCI), but I'm *very* open to other suggestions.

Thanks,

JD 'linux-hardware-dev@vger anyone ?' B.
[oh, and the board will have 4-way SMP with G4 PowerPCs]
-- 
LART. 250 MIPS under one Watt. Free hardware design files.
http://www.lart.tudelft.nl/
-
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: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later

[Linus Torvalds]

On Tue, 20 Mar 2001, Alessandro Suardi wrote:
>
>  2.4.3-pre3 and synced-up versions of the -ac series remove support for
>  PCMCIA serial CardBus. In drivers/char/pcmcia the Makefile and Config.in
>  files are modified to exclude serial_cb and the serial_cb.c file itself
>  is removed by the patch. As a net result, my Xircom modem port becomes
>  invisible to the kernel and I can't dial out through it.

The regular serial.c should handle it natively. Just make sure you have
CONFIG_SERIAL enabled, along with hotplugging support etc.

Linus

-
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: UDMA 100 / PIIX4 question

[Holger Lubitz]

[EMAIL PROTECTED] wrote:
> 
> On Mon, 19 Mar 2001 12:17:38 -0800
> Tim Moore <[EMAIL PROTECTED]> wrote:
> 
> > Apologies for the too brief answer.  Sustained real world transfer rates
> > for the PIIX4 under ideal
> > setup conditions and a quiet bus are 14-18MB/s.

I dare to disagree. These numbers are from an Asus P2L97-DS (Dual P2,
Intel 440LX chipset with PIIX4) with an IBM DTLA 307045:

/dev/hda5:
 Timing buffer-cache reads:   128 MB in  1.21 seconds =105.79 MB/sec
 Timing buffered disk reads:  64 MB in  2.30 seconds = 27.83 MB/sec

/dev/hda5 is the outermost linux partition, starting at cyl 256.

(if you don't count hdparm measurements as real world transfer rates -
linear read as measured by bonnie is 26.3 MB/s).

> There is a Win partition - so I do not think I am at the start of the drive.
> 
> Then  hdparm -tT /dev/hda
> 
> /dev/hda:
>  Timing buffer-cache reads:   128 MB in  1.04 seconds =123.08 MB/sec
>  Timing buffered disk reads:  64 MB in  4.08 seconds = 15.69 MB/sec

Would your windows partition by any chance be at the beginning of the
disk?
hdparm speed measurements differ by filesystem (i have no idea why,
since they don't go through it - maybe some interaction with the
buffering code).

if you are testing a windows partition, you can expect to see
significantly lower values for hdparm:

/dev/hda1:
 Timing buffer-cache reads:   128 MB in  1.65 seconds = 77.58 MB/sec
 Timing buffered disk reads:  64 MB in  3.48 seconds = 18.39 MB/sec

Remarkably /dev/hda benches slightly better, even though the 64 MB read
are nearly the same as for hda1:

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.40 seconds = 91.43 MB/sec
 Timing buffered disk reads:  64 MB in  3.06 seconds = 20.92 MB/sec

I also noticed that operations on a lot of files (like scanning for all
files in a filesystem as done by updatedb) got really slow with the 2.4
vfat fs, with a very high percentage (in the 90s) of CPU time attributed
to "system". Has anybody else noticed this?

Holger
-
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: user space web server accelerator support

[Zach Brown]

> Fantastic!
> 
> I was not aware of it, sorry... where can I find some doc?

There are some patches in the apache source rpms in
http://www.zabbo.net/phhttpd/ that shows how apache can connect to
another daemon and get its incoming connections sockets from it.

phhttpd itself is pretty hairy code (don't ask :)), but the apache
changes are pretty straight forward.

-- 
 zach
-
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/

[CRASH] 2.4.2-ac20: kernel: memory.c:83: bad pmd 4f433232.

[Alexander Riesen]

Hi, all

Simply crashed. No oops-screens. And fast rebooted :)
Under middle load. Nothing serious.
Workstation, running XFree86 4.0.2,
simple programs eating megabytes.

Alex Riesen
Traian AG

P.S.:

>From syslog:
Mar 20 15:41:48 ws018 -- MARK --
Mar 20 15:49:00 ws018 kernel: emory.c:83: bad pmd 5f454341.
Mar 20 15:49:00 ws018 kernel: memory.c:83: bad pmd 68736148.
... a while
Mar 20 15:49:01 ws018 kernel: memory.c:83: bad pmd 4f433232.
Mar 20 15:49:01 ws018 kernel: memory.c:83: bad pmd 5f414252.
... some normal activity

Mar 20 16:10:19 ws018 syslogd 1.3-3#33: restart (remote reception).

ver_linux:
Linux ws018 2.4.2-ac20 #1 Wed Mar 14 12:19:28 CET 2001 i686 unknown
 
Gnu C  2.95.2
Gnu make   3.78.1
binutils   2.9.5.0.37
util-linux 2.10r
modutils   2.4.2
e2fsprogs  1.19
reiserfsprogs  3.x.0b
Linux C Library2.1.3
ldd: version 1.9.11
Procps 2.0.6
Net-tools  1.54
Console-tools  0.2.3
Sh-utils   2.0
Modules Loaded snd-seq-midi snd-seq-midi-event snd-seq snd-card-als4000 
snd-pcm snd-mpu401-uart snd-rawmidi snd-opl3 snd-hwdep snd-seq-device snd-timer 
snd-sb-common snd soundcore reiserfs serial 3c59x nls_koi8-r ntfs smbfs vfat fat 
nls_iso8859-2 nls_iso8859-1 nls_cp866 binfmt_misc autofs nfs lockd sunrpc nbd



There are .{modules,ksyms} in var/log/ksymoops,
timestamp corresponds to the time before restart. I provide
here only .modules, but have a copy of .ksyms kept.

20010320161019.modules (i have rmmod in crontab):
snd-seq-midi3472   0 (unused)
snd-seq-midi-event  2912   0 [snd-seq-midi]
snd-seq35712   0 [snd-seq-midi snd-seq-midi-event]
snd-card-als40004560   0 (unused)
snd-pcm46400   0 [snd-card-als4000]
snd-mpu401-uart 2720   0 [snd-card-als4000]
snd-rawmidi11008   0 [snd-seq-midi snd-mpu401-uart]
snd-opl35280   0 [snd-card-als4000]
snd-hwdep   3600   0 [snd-opl3]
snd-seq-device  4160   0 [snd-seq-midi snd-seq snd-rawmidi snd-opl3]
snd-timer   9152   0 [snd-seq snd-pcm snd-opl3]
snd-sb-common   6176   0 [snd-card-als4000]
snd22816   1 [snd-seq-midi snd-seq-midi-event snd-seq 
snd-card-als4000 snd-pcm snd-mpu401-uart snd-rawmidi snd-opl3 snd-hwdep snd-seq-device 
snd-timer snd-sb-common]
soundcore   3472   3 [snd]
reiserfs  146480   1 (autoclean)
serial 41104   0 (autoclean)
3c59x  23520   1
nls_koi8-r  3856   0 (unused)
ntfs   34480   0 (unused)
smbfs  30448   0 (unused)
vfat8432   0 (unused)
fat28896   0 [vfat]
nls_iso8859-2   3360   0 (unused)
nls_iso8859-1   2848   0 (unused)
nls_cp866   3840   0 (unused)
binfmt_misc 5536   0
autofs  8896   0 (unused)
nfs68224   3
lockd  47088   1 [nfs]
sunrpc 56064   1 [nfs lockd]
nbd14576   0 (unused)


Hardware:
/proc/pci:
PCI devices found:
  Bus  0, device   0, function  0:
Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 3).
  Master Capable.  Latency=64.  
  Prefetchable 32 bit memory at 0xe700 [0xe7ff].
  Bus  0, device   1, function  0:
PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 3).
  Master Capable.  Latency=64.  Min Gnt=136.
  Bus  0, device   4, function  0:
ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).
  Bus  0, device   4, function  1:
IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1).
  Master Capable.  Latency=32.  
  I/O at 0xb800 [0xb80f].
  Bus  0, device   4, function  2:
USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).
  IRQ 5.
  Master Capable.  Latency=32.  
  I/O at 0xb400 [0xb41f].
  Bus  0, device   4, function  3:
Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2).
  IRQ 9.
  Bus  0, device  11, function  0:
Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 116).
  IRQ 10.
  Master Capable.  Latency=32.  Min Gnt=10.Max Lat=10.
  I/O at 0xb000 [0xb07f].
  Non-prefetchable 32 bit memory at 0xe480 [0xe480007f].
  Bus  0, device  13, function  0:
Multimedia audio controller: Avance Logic Inc. ALS4000 Audio Chipset (rev 0).
  IRQ 5.
  Master Capable.  Latency=32.  
  I/O at 0xa800 [0xa87f].
  Bus  1, device   0, function  0:
VGA compatible controller: ATI Technologies Inc 3D Rage IIC AGP (rev 58).
  IRQ 11.
  Master Capable.  Latency=64.  Min Gnt=8.
  Prefetchable 32 bit memory at 0xe600 [0xe6ff].
  I/O at 0xd800 [0xd8ff].
  Non-prefetchable 32 bit memory at 0xe500 [0xe5000fff].


/proc/cpuinfo:

processor   : 0
vendor_id   : GenuineIntel

Re: modules_install does not install acpi with linux-2.4.2

[Jeff Garzik]

"Juergen Rose,K17,0331-9772437,030-2425483" wrote:
> if I try 'make modules_install' with linux-2.4.2 I get:
> ...
> mkdir -p /lib/modules/2.4.2/kernel/drivers/acpi/
> cp common.o dispatcher.o events.o hardware.o interpreter.o namespace.o
> parser.o resources.o tables.o os.o acpi_ksyms.o driver.o cmbatt.o cpu.o
> ec.o acpi_ksyms.o sys.o table.o power.o
> /lib/modules/2.4.2/kernel/drivers/acpi/
> cp: common.o: No such file or directory
...
> cp: tables.o: No such file or directory
> make[2]: *** [_modinst__] Error 1
> make[2]: Leaving directory `/usr/src_laptop450/linux-2.4.2/drivers/acpi'

> In .config I find with respect to ACPI only
> CONFIG_ACPI=m
> 
> Who can help me?

Doctor says:  don't do that.  :)  I don't know how you managed
CONFIG_ACPI=m, because the configuration system doesn't allow it. 
"dep_bool" means only Y or N, and we see the CONFIG_ACPI entry in
arch/i386/config.in is correct:

[jgarzik@rum linux_2_4]$ egrep -rw 'CONFIG_PM|CONFIG_ACPI' arch
[...edited output...]
arch/arm/config.in:   bool 'Power Management support' CONFIG_PM
arch/i386/config.in:bool 'Power Management support' CONFIG_PM
arch/i386/config.in:   dep_bool '  ACPI support' CONFIG_ACPI $CONFIG_PM
arch/i386/defconfig:CONFIG_PM=y
arch/ia64/config.in:  define_bool CONFIG_PM y
arch/ia64/config.in:  define_bool CONFIG_ACPI y

So the solution is not build ACPI as a module, because it shouldn't have
allowed you to do so in the first place :)

-- 
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.
-
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/

[PATCH] Re: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later

[Jeff Garzik]

On closer inspection, that patch I linked to appears to be incomplete.

Can you try the attached patch, to see if it fixes the
absence-of-serial_cb problem?

Thanks,

Jeff


P.S. I'm surprised serial_cb in 2.4 worked at all, for anybody.  I guess
they must be using pcmcia_cs's serial_cb, not the kernel's serial_cb...

-- 
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.

Index: drivers/char/serial.c
===
RCS file: /cvsroot/gkernel/linux_2_4/drivers/char/serial.c,v
retrieving revision 1.1.1.33
diff -u -r1.1.1.33 serial.c
--- drivers/char/serial.c   2001/03/20 12:59:44 1.1.1.33
+++ drivers/char/serial.c   2001/03/20 15:35:47
@@ -59,8 +59,8 @@
  *
  */
 
-static char *serial_version = "5.05";
-static char *serial_revdate = "2000-12-13";
+static char *serial_version = "5.05a";
+static char *serial_revdate = "2001-03-20";
 
 /*
  * Serial driver configuration section.  Here are the various options:
@@ -4610,7 +4610,8 @@
 * (Should we try to make guesses for multiport serial devices
 * later?) 
 */
-   if ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_SERIAL ||
+   if dev->class >> 8) != PCI_CLASS_COMMUNICATION_SERIAL) &&
+   ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_MODEM)) ||
(dev->class & 0xff) > 6)
return 1;
 
@@ -4708,6 +4709,8 @@
 static struct pci_device_id serial_pci_tbl[] __devinitdata = {
{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
 PCI_CLASS_COMMUNICATION_SERIAL << 8, 0x00, },
+   { PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
+PCI_CLASS_COMMUNICATION_MODEM << 8, 0x00, },
{ 0, }
 };
 

Re: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later

[Alessandro Suardi]

Jeff Garzik wrote:
> 
> On Tue, 20 Mar 2001, Alessandro Suardi wrote:
> > Jeff Garzik wrote:
> > > Neither.  serial.c does serial_cb's job now.  It looks like serial.c
> > > needs to scan for modems as well as serial ports, and tytso agrees with
> > > me on that.  We just need to check and see if winmodems reports
> > > themselves as real modems before fixing this.
> 
> > OK, thanks. I assume you mean "serial.c should do serial_cb's job now",
> >  since it doesn't :) If you want me to test patches etc. just let me know.
> 
> Re-CC'd to linux-kernel, hope you don't mind.

No problem for me, of course.

> Anyone interested in testing patches, this simple change is what needs
> testing on various PCI and CardBus modems:
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg34097.html
> (since it's a web archive, you may have to hack the patch in manually...)

I performed this hand-diff...

[asuardi@princess char]$ diff serial.c serial.c-2.4.3p4 
4613,4614c4613
<   if (!((dev->class >> 8) == PCI_CLASS_COMMUNICATION_SERIAL ||
<   (dev->class >> 8) == PCI_CLASS_COMMUNICATION_MODEM) ||
---
>   if ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_SERIAL ||

...and still my Xircom modem tty isn't detected :(

> It seems straightforward enough, and both tytso and I think the change
> is ok, but (at tytso's suggestion) I'm going to test some various
> winmodem and other use cases because assuring ourselves that it is good
> enough for a general rule...

Available for further testing (or fixing my diff if I patched it badly).


Thanks & ciao,

--alessandro  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Linux:  kernel 2.2.19p17/2.4.3p4 glibc-2.2 gcc-2.96-69 binutils-2.11.90.0.1
Oracle: Oracle8i 8.1.7.0.1 Enterprise Edition for Linux
motto:  Tell the truth, there's less to remember.

-
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: gettimeofday question

[Eli Carter]

Russell King wrote:
> This problem has a non-trivial solution, and I think whoever originally
> wrote the x86 do_gettimeofday code decided that it wasn't worth finding
> a solution to it.

So are you going to use the x86 solution and not worry about the >10ms
problem for now?  The x86 is an improvement over the current situation
(at least on ebsa285).  Or do you have something else in mind?

Eli
---.   Rule of Accuracy: When working toward
Eli Carter |the solution of a problem, it always 
eli.carter(at)inet.com `-- helps if you know the answer.
-
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/

modules_install does not install acpi with linux-2.4.2

[Juergen Rose,K17,0331-9772437,030-2425483]

Hello,

if I try 'make modules_install' with linux-2.4.2 I get:

...
make[1]: Entering directory `/usr/src_laptop450/linux-2.4.2/drivers'
make -C acpi modules_install
make[2]: Entering directory `/usr/src_laptop450/linux-2.4.2/drivers/acpi'
mkdir -p /lib/modules/2.4.2/kernel/drivers/acpi/
cp common.o dispatcher.o events.o hardware.o interpreter.o namespace.o 
parser.o resources.o tables.o os.o acpi_ksyms.o driver.o cmbatt.o cpu.o 
ec.o acpi_ksyms.o sys.o table.o power.o 
/lib/modules/2.4.2/kernel/drivers/acpi/
cp: common.o: No such file or directory
cp: dispatcher.o: No such file or directory
cp: events.o: No such file or directory
cp: hardware.o: No such file or directory
cp: interpreter.o: No such file or directory
cp: namespace.o: No such file or directory
cp: parser.o: No such file or directory
cp: resources.o: No such file or directory
cp: tables.o: No such file or directory
make[2]: *** [_modinst__] Error 1
make[2]: Leaving directory `/usr/src_laptop450/linux-2.4.2/drivers/acpi'

Indeed I don't have such files in the drivers/acpi-Directory.
laptop450:/usr/src/linux(114)#ls drivers/acpi/
Makefile  acpi_ksyms.o  cmbatt.o  cpu.c  dispatcher/  driver.h  
ec.c  ec.o hardware/  interpreter/  os.c  parser/  power.o 
sys.c  table.c  tables/
acpi_ksyms.c  cmbatt.c  common/   cpu.o  driver.c driver.o  
ec.h  events/  include/   namespace/os.o  power.c  resources/  
sys.o  table.o

My tools should be new enough to work correctly:
laptop450:/usr/src/linux(133)#sh 
/data_tiger/SRC/linux-2.4.1/scripts/ver_linux
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux laptop450 2.4.0-test7 #1 Fri Aug 18 23:29:02 CEST 2000 i686 unknown
Kernel modules 2.4.3
Gnu C  2.95.2
Gnu Make   3.79
Binutils   2.10.0.33
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.2
Mount  2.10k
Net-tools  1.52
Kbd0.99
Sh-utils   1.16
Modules Loaded autofs serial_cb tulip_cb cb_enabler ds i82365 
pcmcia_core maestro soundcore apm ppp_generic slip input usb-uhci 
usbcore nls_cp437 vfat nls_iso8859-1 ntfs

In .config I find with respect to ACPI only
CONFIG_ACPI=m

Who can help me?

With best regards
   Juergen

-
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/

OOPS

[Mircea Damian]

Hello,

[1.] One line summary of the problem:
Kernel OOPS. Machine hanged under heavy load.

[2.] Full description of the problem/report:
The computer that is handling our e-mail hanged with an OOPS from which I
recovered only the EIP.

[3.] Keywords (i.e., modules, networking, kernel):
networking, kernel

[4.] Kernel version (from /proc/version):
Linux version 2.4.3-pre4 (root@k) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #1 SMP Tue Mar 13 11:00:08 EET 2001

[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)
This is all that I could save:

Unable to handle kernel paging request 86c90cc0
OOPS:000  CPU1:  EIP=0010:[]

I could not get the stack trace. Next-time I'll log the message on a serial
console.

If I read from System.map the address is between: 

c01f7b98 T tcp_v4_rcv
c01f81b0 t __tcp_v4_rehash

[6.] A small shell script or example program which triggers the
 problem (if possible)
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Linux k 2.4.3-pre4 #1 SMP Tue Mar 13 11:00:08 EET 2001 i686 unknown
 
 Gnu C  egcs-2.91.66
 Gnu make   3.79
 binutils   2.10.1.0.2
 util-linux 2.10o
 modutils   2.4.2
 e2fsprogs  1.19
 PPP2.3.11
 Linux C Library2.2.1
 ldd: version 1.9.9
 Procps 2.0.7
 Net-tools  1.57
 Kbd0.99
 Sh-utils   2.0
 Modules Loaded 

[7.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 3
cpu MHz : 736.019
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips: 1468.00

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 8
model name  : Pentium III (Coppermine)
stepping: 3
cpu MHz : 736.019
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse
bogomips: 1471.28

[7.3.] Module information (from /proc/modules):
none
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
5000-500f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
6000-607f : VIA Technologies, Inc. VT82C686 [Apollo Super ACPI]
9000-9fff : PCI Bus #01
  9000-907f : Silicon Integrated Systems [SiS] 86C326
a000-a00f : VIA Technologies, Inc. Bus Master IDE
  a000-a007 : ide0
  a008-a00f : ide1
ac00-ac07 : Triones Technologies, Inc. HPT366
b000-b003 : Triones Technologies, Inc. HPT366
b400-b407 : Triones Technologies, Inc. HPT366
b800-b803 : Triones Technologies, Inc. HPT366
bc00-bcff : Triones Technologies, Inc. HPT366
  bc00-bc07 : ide2
  bc08-bc0f : ide3
  bc10-bcff : HPT370
c000-c0ff : Realtek Semiconductor Co., Ltd. RTL-8139
  c000-c0ff : eth0

-0009fbff : System RAM
0009fc00-0009 : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-1fff : System RAM
  0010-00220086 : Kernel code
  00220087-00286b7f : Kernel data
d000-d3ff : VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x]
d400-d5ff : PCI Bus #01
  d500-d500 : Silicon Integrated Systems [SiS] 86C326
d700-d77f : PCI Bus #01
  d700-d77f : Silicon Integrated Systems [SiS] 86C326
d780-d78000ff : Realtek Semiconductor Co., Ltd. RTL-8139
  d780-d78000ff : eth0
fec0-fec00fff : reserved
fee0-fee00fff : reserved
- : reserved

[7.5.] PCI information ('lspci -vvv' as root)

00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc. 

Re: IDE DMA resets with ALI15X3 on Aladdin V

[Jeremy Jackson]

Jules Bean wrote:

> Hi,
>
> I have an intermittent problem with my IDE setup:
>
> pear# dmesg | grep -i ide
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> ALI15X3: IDE controller on PCI bus 00 dev 78
> ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> scsi0 : SCSI host adapter emulation for IDE ATAPI devices
> {snip}
>
> It works absolutely fine under normal load; I see the very occasional
>
> Mar 18 12:23:01 pear kernel: hda: dma_intr: status=0x51 { DriveReady
> SeekComplete Error }
> Mar 18 12:23:01 pear kernel: hda: dma_intr: error=0x84 {
> DriveStatusError BadCRC }
>

This is clue #1 - BadCRC

>
> but they don't seem to affect performance.
>
> However, very occasionally, normally when the HD is under very heavy
> load, I get messages like this:
>
> Mar 20 10:24:05 pear kernel: hda: timeout waiting for DMA
> Mar 20 10:24:05 pear kernel: ide_dmaproc: chipset supported
> ide_dma_timeout func only: 14
> Mar 20 10:24:05 pear kernel: hda: irq timeout: status=0x58 {
> DriveReady SeekComplete DataRequest }
> Mar 20 10:24:05 pear kernel: hda: status timeout: status=0xd0 { Busy }
> Mar 20 10:24:05 pear kernel: hda: drive not ready for command
> Mar 20 10:24:05 pear kernel: ide0: reset: success
>
> This is accompanied by a freeze of the machine, which in this
> particular instance sorted itself out.  Sometimes, the machine goes
> down hard, causing some disk corruption (always minor, thankfully, so
> far).
>
> This all sounds very like that described in the thread which starts at
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0006.1/0924.html
> although he didn't seem to get an actually crashes from it.
>
> Sometimes I also hear alarming clicking sounds from the disk; on those

This is clue #2.

>
> occasions, the crash is hard, and the machine has to be reset.
>
> Is this a hardware fault?  I would think so, except for the
> intermittent dma_intr errors suggesting there could be a motherboard
> problem too?
>
> The disk is as follows:
>
> pear# cat /proc/ide/hda/model
> Maxtor 91080D5

If memory serves me correctly, this disk is the same model as
one I send back for RMA... I think your disk is toast.
you could try using badblocks to scan it, prefferably in read-write
mode (you'll have to move your data to another disk first, of course,
since this erases data)  You could try just a read scan first.
The clicking is likely the drive trying to re-read the bad sectors.
You should try to exchange it under warranty, before your data
disappears.

You could try using an Ultra-DMA 66 cable to improve signal quality,
even though this chipset (I think) only supports UDMA33.  Also,
try it with the drive by itsself (not sharing cable with a cdrom or
another disk) on an interface.

Cheers,

Jeremy

>
>
> (It does normally seem to be that disk, but the other disk is much
> smaller anyhow).
>
> I do also sometime see problems with hdd, which is an ATAPI
> cd-rom. This normally happens after there's been some problem with
> hda, and I get:

{snip}

-
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/

2.4.2-ac20 USB suspend oops message

[Mark Swanson]

Hello,

Reproducable 100% of the time. I have 1 mouse plugged into my uhci port.
When I suspend I get:

Mar 20 09:09:33 laptop kernel: Unable to handle kernel paging request at

virtual address 6273754b
Mar 20 09:09:33 laptop kernel:  printing eip:
Mar 20 09:09:33 laptop kernel: cc86d58b
Mar 20 09:09:33 laptop kernel: pgd entry c74b6624: 
Mar 20 09:09:33 laptop kernel: pmd entry c74b6624: 
Mar 20 09:09:33 laptop kernel: ... pmd not present!
Mar 20 09:09:33 laptop kernel: Oops: 
Mar 20 09:09:33 laptop kernel: CPU:0
Mar 20 09:09:33 laptop kernel: EIP:0010:[]
Mar 20 09:09:33 laptop kernel: EFLAGS: 00010093
Mar 20 09:09:33 laptop kernel: eax: 4f525000   ebx: c84747e0   ecx:
c765c120
edx: 0001
Mar 20 09:09:33 laptop kernel: esi: 6273752f   edi: c765c158   ebp:
c7489f2c
esp: c7489f0c

ksymoops:
Warning (compare_maps): ksyms_base symbol
__VERSIONED_SYMBOL(shmem_file_setup) not found in System.map.  Ignoring
ksyms_base entry
Mar 20 09:09:33 laptop kernel: Unable to handle kernel paging request at

Mar 20 09:09:33 laptop kernel: cc86d58b
Mar 20 09:09:33 laptop kernel: Oops: 
Mar 20 09:09:33 laptop kernel: CPU:0
Mar 20 09:09:33 laptop kernel: EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
Mar 20 09:09:33 laptop kernel: EFLAGS: 00010093
Mar 20 09:09:33 laptop kernel: eax: 4f525000   ebx: c84747e0   ecx:
c765c120
Mar 20 09:09:33 laptop kernel: esi: 6273752f   edi: c765c158   ebp:
c7489f2c
Warning (Oops_read): Code line not seen, dumping what data is available

>>EIP; cc86d58b <[uhci]uhci_call_completion+8b/164>   <=


2 warnings issued.  Results may not be reliable.


-
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: Anybody C440GX+ aic7xxx SMP ?

[J . A . Magallon]

On 03.20 Igor Mozetic wrote:
> We plan to buy a second Xeon 550Mhz for the C440GX+ board.
> Before we invest 1300$ I would like to hear if anybody is
> running 2.4.x on this hardware without problems. 
> On a UP box with 2GB RAM, I run 2.4.3-pre3 + Gibbs' aic7xxx-6.1.7
> + stock eepro100. Anybody with SMP ?
> 

If it is usefull for you, I'm running a SuperMicro P6DGU (400GX):

00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge
00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:0e.0 SCSI storage controller: Adaptec AHA-2940U2/W / 7890 (rev 01)

with 2xPII@400, 256Mb RAM. Bios version 3.1.

With 2.4.2-ac20+aic6.1.7. Just took away the scsi/aic7xxx from ac20 and
put instead the Gibbs version.

No problem.

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.2-ac20 #2 SMP Tue Mar 13 15:49:10 CET 2001 i686

-
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: [sligthly OT] serial console on palm

[Rafael E. Herrera]

It was posted by Christian Ehrhardt.

[EMAIL PROTECTED] wrote:
> 
> On Mon, Feb 12, 2001 at 05:32:39PM +0100, I wrote:
> > I wrote a little palm app some time ago that can capture serial
> > console output. If anyone is interested I'll build a tar ball with
> > sources and binary.
> 
> It is now availiable at http://www.mathematik.uni-ulm.de/~ehrhardt/serial/
> 
> Sorry for the slightly off topic post but I think enough people
> showed interest to justify this.
> 
>  regardsChristian Ehrhardt


I made a couple of changes to it. Mainly:

 Made a Makefile
 increased the speed to 19200
 added a scrollbar
 a filter to get rid of some ansi characters.

If someone could add the code to use higher speeds and being able to
recall previous logs would make it more usefull.

The changed version can be obtained in:

http://www.neuronet.pitt.edu/~raffo/SerialRecord/

Bugs: If your machine crashes while booting it will loose the tail of
the output, maybe because is not fast enough. 

-- 
 Rafael
-
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: [CHECKER] 16 potential locking bugs in 2.4.1

[Rik van Riel]

On Tue, 20 Mar 2001, Neil Brown wrote:
> On Friday March 16, [EMAIL PROTECTED] wrote:

> > | fs/nfsd/vfs.c   | nfsd_link  |
> > | fs/nfsd/vfs.c   | nfsd_symlink   |
> 
> These are not actually bugs.  The usage of fh_lock is fairly obscure.
> The unlock gets done by an fh_put which the caller does after calling
> nfsd_link or nfs_symlink.

Sounds like a "bug waiting to be implemented"   ;)

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/

-
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: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later

[Jeff Garzik]

On Tue, 20 Mar 2001, Alessandro Suardi wrote:
> Jeff Garzik wrote:
> > Neither.  serial.c does serial_cb's job now.  It looks like serial.c
> > needs to scan for modems as well as serial ports, and tytso agrees with
> > me on that.  We just need to check and see if winmodems reports
> > themselves as real modems before fixing this.

> OK, thanks. I assume you mean "serial.c should do serial_cb's job now",
>  since it doesn't :) If you want me to test patches etc. just let me know.

Re-CC'd to linux-kernel, hope you don't mind.

Anyone interested in testing patches, this simple change is what needs
testing on various PCI and CardBus modems:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg34097.html
(since it's a web archive, you may have to hack the patch in manually...)

It seems straightforward enough, and both tytso and I think the change
is ok, but (at tytso's suggestion) I'm going to test some various
winmodem and other use cases because assuring ourselves that it is good
enough for a general rule...

Regards,

Jeff



-
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/

Anybody C440GX+ aic7xxx SMP ?

[Igor Mozetic]

We plan to buy a second Xeon 550Mhz for the C440GX+ board.
Before we invest 1300$ I would like to hear if anybody is
running 2.4.x on this hardware without problems. 
On a UP box with 2GB RAM, I run 2.4.3-pre3 + Gibbs' aic7xxx-6.1.7
+ stock eepro100. Anybody with SMP ?

-Igor Mozetic
-
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: PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later

[Jeff Garzik]

Alessandro Suardi wrote:
> 
> Sorry to repost the issue but I got no reply...
> 
>  2.4.3-pre3 and synced-up versions of the -ac series remove support for
>  PCMCIA serial CardBus. In drivers/char/pcmcia the Makefile and Config.in
>  files are modified to exclude serial_cb and the serial_cb.c file itself
>  is removed by the patch. As a net result, my Xircom modem port becomes
>  invisible to the kernel and I can't dial out through it.
> 
> As a temporary measure I backed out the changes in drivers/char/pcmcia
>  and my 2.4.3-pre4 kernel seems happy (in fact I am dialing out through
>  said Xircom modem).
> 
> Did I miss some announcement for replacement features for serial_cb or
>  did a bad patch slip in ?

Neither.  serial.c does serial_cb's job now.  It looks like serial.c
needs to scan for modems as well as serial ports, and tytso agrees with
me on that.  We just need to check and see if winmodems reports
themselves as real modems before fixing this.

-- 
Jeff Garzik   | May you have warm words on a cold evening,
Building 1024 | a full mooon on a dark night,
MandrakeSoft  | and a smooth road all the way to your door.
-
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: switch_to()/doesnt %esp get replaced with %ebp on ret

[Jamie Lokier]

Parity Error wrote:
> I dont know if you understood my doubt, but your pointer
> to bp accidentally or otherwise solved the mystery. 

We agree, and I like your explanation.

> Still, could some one enlighten me on why esi and edi are
> also similarly saved and restored ?

The compiler _may_ cache other values in those registers across the call
to switch_to.  Although this doesn't happen in your kernel, it does
sometimes happen and switch_to must be coded to assume that it does.

You can safely remove the esi & edi pushes and pops, if you put those
registers in the "clobber" list of the asm.  In theory that's best,
because then the compiler will save the register values itself only if
it needs to.

In practice, putting them in the clobber list sometimes results in worse
code, at least when I tried this in the 2.2 series.

You can't put ebp in the clobber list for some reason: GCC silently
ignores it.  (Maybe that's fixed now too, I don't know).

-- Jamie
-
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/

IDE DMA resets with ALI15X3 on Aladdin V

[Jules Bean]

Hi,

I have an intermittent problem with my IDE setup:

pear# dmesg | grep -i ide
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
ALI15X3: IDE controller on PCI bus 00 dev 78
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
scsi0 : SCSI host adapter emulation for IDE ATAPI devices

pear# lspci   
00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04)
00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04)
00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev
03)
00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA
Bridge [Aladdin IV] (rev c3)
00:08.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 
08)
00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c2)
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3
(rev 01)


It works absolutely fine under normal load; I see the very occasional 

Mar 18 12:23:01 pear kernel: hda: dma_intr: status=0x51 { DriveReady
SeekComplete Error }
Mar 18 12:23:01 pear kernel: hda: dma_intr: error=0x84 {
DriveStatusError BadCRC }

but they don't seem to affect performance.

However, very occasionally, normally when the HD is under very heavy
load, I get messages like this:

Mar 20 10:24:05 pear kernel: hda: timeout waiting for DMA
Mar 20 10:24:05 pear kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Mar 20 10:24:05 pear kernel: hda: irq timeout: status=0x58 {
DriveReady SeekComplete DataRequest }
Mar 20 10:24:05 pear kernel: hda: status timeout: status=0xd0 { Busy }
Mar 20 10:24:05 pear kernel: hda: drive not ready for command
Mar 20 10:24:05 pear kernel: ide0: reset: success

This is accompanied by a freeze of the machine, which in this
particular instance sorted itself out.  Sometimes, the machine goes
down hard, causing some disk corruption (always minor, thankfully, so
far).

This all sounds very like that described in the thread which starts at 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0006.1/0924.html
although he didn't seem to get an actually crashes from it.

Sometimes I also hear alarming clicking sounds from the disk; on those 
occasions, the crash is hard, and the machine has to be reset.

Is this a hardware fault?  I would think so, except for the
intermittent dma_intr errors suggesting there could be a motherboard
problem too?

The disk is as follows:

pear# cat /proc/ide/hda/model 
Maxtor 91080D5

(It does normally seem to be that disk, but the other disk is much
smaller anyhow).

I do also sometime see problems with hdd, which is an ATAPI
cd-rom. This normally happens after there's been some problem with
hda, and I get:

Mar 20 09:56:04 pear kernel: scsi0 : SCSI host adapter emulation for
IDE ATAPI devices
Mar 20 09:56:04 pear kernel: scsi : aborting command due to timeout :
pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 
Mar 20 09:56:04 pear kernel: scsi : aborting command due to timeout :
pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 
Mar 20 09:56:04 pear kernel: SCSI host 0 abort (pid 0) timed out -
resetting
Mar 20 09:56:04 pear kernel: SCSI bus is being reset for host 0
channel 0.
Mar 20 09:56:04 pear kernel: scsi : aborting command due to timeout :
pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 
[repeated many times, before finally:]
Mar 20 09:56:04 pear kernel: SCSI host 0 abort (pid 0) timed out -
resetting
Mar 20 09:56:04 pear kernel: SCSI bus is being reset for host 0
channel 0.
Mar 20 09:56:04 pear kernel: hdc: timeout waiting for DMA
Mar 20 09:56:04 pear kernel: ide_dmaproc: chipset supported
ide_dma_timeout func only: 14
Mar 20 09:56:04 pear kernel: hdc: irq timeout: status=0x50 {
DriveReady SeekComplete }
Mar 20 09:56:04 pear kernel: scsi : aborting command due to timeout :
pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 
Mar 20 09:56:04 pear kernel: SCSI host 0 abort (pid 0) timed out -
resetting
Mar 20 09:56:04 pear kernel: SCSI bus is being reset for host 0
channel 0.
Mar 20 09:56:04 pear kernel: hdd: irq timeout: status=0xd0 { Busy }
Mar 20 09:56:04 pear kernel: hdd: DMA disabled
Mar 20 09:56:04 pear kernel: hdd: ATAPI reset complete
Mar 20 09:56:04 pear kernel: hdd: status error: status=0x08 {
DataRequest }
Mar 20 09:56:04 pear kernel: hdd: drive not ready for command
Mar 20 09:56:04 pear kernel: hdd: status timeout: status=0x80 { Busy }
Mar 20 09:56:04 pear kernel: hdd: drive not ready for command
Mar 20 09:56:04 pear kernel: scsi : aborting command due to timeout :
pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 
Mar 20 09:56:04 pear kernel: SCSI host 0 abort (pid 0) timed out -
resetting
Mar 20 09:56:04 pear kernel: SCSI bus is being reset for host 0
channel 0.
Mar 20 09:56:04 pear kernel: hdd: ATAPI reset complete
Mar 20 09:56:04 

PCMCIA serial CardBus support vanished in 2.4.3-pre3 and later

[Alessandro Suardi]

Sorry to repost the issue but I got no reply...

 2.4.3-pre3 and synced-up versions of the -ac series remove support for
 PCMCIA serial CardBus. In drivers/char/pcmcia the Makefile and Config.in
 files are modified to exclude serial_cb and the serial_cb.c file itself
 is removed by the patch. As a net result, my Xircom modem port becomes
 invisible to the kernel and I can't dial out through it.

As a temporary measure I backed out the changes in drivers/char/pcmcia
 and my 2.4.3-pre4 kernel seems happy (in fact I am dialing out through
 said Xircom modem).

Did I miss some announcement for replacement features for serial_cb or
 did a bad patch slip in ?


Thanks & ciao,

--alessandro  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Linux:  kernel 2.2.19p17/2.4.3p4 glibc-2.2 gcc-2.96-69 binutils-2.11.90.0.1
Oracle: Oracle8i 8.1.7.0.1 Enterprise Edition for Linux
motto:  Tell the truth, there's less to remember.
-
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[2]: switch_to()/doesnt %esp get replaced with %ebp on ret

[Parity Error]

I dont know if you understood my doubt, but your pointer
to bp accidentally or otherwise solved the mystery. 

The problem was although switch_to changes esp to the
next processes stack, code emitted by the compiler, has
"cached" the 'prev' processes's esp via ebp, and uses this
at return to restore... So in effect, esp would again
get changed to prev's esp.

switch_to is a MACRO and saves ebp on stack and restores
it. The above ensures that the cached ebp is also changed
to the next's cached ebp, in some sense. I removed the
push %ebp , and pop %ebp from switch_to and ran and it
promptly crashed. But with -fomit-frame-pointer, all this
does not take place.

Still, could some one enlighten me on why esi and edi are
also similarly saved and restored ?

-Original Message-
From: Jamie Lokier <[EMAIL PROTECTED]>
To: Parity Error <[EMAIL PROTECTED]>
Date: Mon, 19 Mar 2001 15:04:25 +0100
Subject: Re: switch_to()/doesnt %esp get replaced with %ebp on ret

=
=That's not nice code from the compiler (suboptimal), but it'll work.
=leal -24(%ebp),%esp is perfectly ok in the epilogue of a function.
=You're right that %esp is lost -- in this case, %ebp has effectively the
=same information.
=
=Think like this: a perfectly normal function (without switch_to) can
=have this:
=
=f: pushl %ebp
=   movl %esp,%ebp
=   pushl %ebx
=   ... do stuff, decrement %esp a lot to call functions etc. etc. ...
=   movl -4(%ebp),%esp
=   popl %ebx
=   popl %ebp
=   ret
=
=Parity Error wrote:
=> in schedule(), switch_to() macro changes esp to
=> the new process's stack. But, on exit frm schedule,
=> how come it does not get overwritten with  ebp-24,
=> as the dissasembled code shows. The code was compiled
=> without the -fomit-frame-pointer.
=> 
=> pushl 508(%ecx)
=> jmp __switch_to
=> 1:  popl %ebp
=> popl %edi
=> popl %esi
=> 
=> jmp .L1180
=> 
=> .L1180: 
=>  leal -24(%ebp),%esp
=> popl %ebx
=> popl %esi
=> popl %edi
=> movl %ebp,%esp
=> popl %ebp
=> ret
=
-
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/

2.4.2-acXX hangs on boot if IrDA is in kernel

[Alessandro Suardi]

Hi Alan,

  tried as you suggested to config out IrDA and indeed the kernel boots.

 Even in -ac20 my Dell Latitude laptop hangs in the RH7.0 init sequence
  after printing the IRCOMM line. C-A-D doesn't do anything but I can use
  Magic Sysrq to reboot.

 I am available for further diagnostic investigation. Just in case, this
  is my IrDA h/w (booted into 2.4.3-pre4).

[root@princess /root]# findchip -v
Found SMC FDC37N958FR Controller at 0x3f0, DevID=0x01, Rev. 1
SIR Base 0x3e8, FIR Base 0x290
IRQ = 4, DMA = 3
Enabled: yes, Suspended: no
UART compatible: yes
Half duplex delay = 3 us


 Thanks & ciao,

--alessandro  <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Linux:  kernel 2.2.19p17/2.4.3p4 glibc-2.2 gcc-2.96-69 binutils-2.11.90.0.1
Oracle: Oracle8i 8.1.7.0.1 Enterprise Edition for Linux
motto:  Tell the truth, there's less to remember.
-
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: How to mount /proc/sys/fs/binfmt_misc ?

[Richard Guenther]

On Mon, 19 Mar 2001, Colin Watson wrote:

> Alexander Viro <[EMAIL PROTECTED]> wrote:
> >Seriously, binfmt_misc.c was written in rather, erm, interesting C.
> >Read it and you'll see. Just one (but rather impressive) example:
> >
> >if ((count == 1) && !(buffer[0] & ~('0' | '1'))) {
> >
> >It was meant to be
> >
> >if (count == 1 && (buffer[0] == '0' || buffer[0] == '1')) {
> >
> >and anyone who can't find the difference really should learn C. And
> >that's not the only bogosity of such level. Besides, the thing is
> >trivially oopsable - write() to any file in binfmt_misc with buffer
> >pointing to unmapped kernel address and you are screwed,
>
> Or you can register binfmt names that are registered already and
> silently shadow old ones, or register names like 'register', 'status',
> '.', and '..'. It's hideous to manage reliably from userspace.

I know you have sent me patches to prevent multiple entries of the
same name some time ago and I can see we argued about it. The main
point I have with such checks is, that we dont prevent root from
doing rm -Rf / either. There is no reason to clobber the kernel with
endless checks of such cornercases (which even dont make the system
unusable, but only one (unimportant) part of it). There is even one
truely nasty "exploit" of binfmt_misc, if you register an entry
that catches standard elf programs and do module insertion of the
elf and misc handler in the right order... how would you catch this!?

Richard.

--
Richard Guenther <[EMAIL PROTECTED]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/

-
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/