2.4.0-test12: SiS pirq handling..

2.4.0-test12: SiS pirq handling..

[Linus Torvalds]

Could people that had problems with SiS interrupt handling before please
give 2.4.0-test12 a final whirl before I release it as 2.4.1? We got a lot
of pirq tables from people, and Martin Diehl put them together with the
hardware specs to come up with what looks to be the "final and correct"
SiS pirq routing, but as always it would be good to have this verified by
as many people as possible.

The other changes in pre12 aren't likely to be all that noticeable, unless
you happen to be hit by just that detail.. As always, fedback is
appreciated.

		Linus


----
pre12:
 - Get non-cpuid Cyrix probing right (it's not a NexGen)
 - Jens Axboe: cdrom tray status and queing cleanups
 - AGP GART: don't disable VIA, and allow i815 with external AGP
 - Coda: use iget4() in order to have big inode numbers without clashes.
 - Fix UDF writepage() page locking
 - NIIBE Yutaka: SuperH update
 - Martin Diehl and others: SiS pirq routing fixes
 - Andy Grover: ACPI update
 - Andrea Arkangeli: LVM update
 - Ingo Molnar: RAID cleanups
 - David Miller: sparc and networking updates
 - Make NFS really be able to handle large files

pre11:
 - Trond Myklebust: NFS/RPC client SMP fixes
 - rth: alpha pyxis and cabriolet fixes
 - remove broken sys_wait4() declarations
 - disable radeon debugging code
 - VIA IDE driver should not enable autodma unless asked for
 - Andrey Savochkin: eepro100 update. Should fix the resource timing problems.
 - Jeff Garzik: via82cxxx_audio update
 - YMF7xx PCI audio update: get rid of old broken driver, make new
   driver handle legacy control too. 
 - fix missed wakeup on block device request list
 - hpt366 controller doesn't play nice with some IBM harddisks
 - remove inode pages from the page cache only after having removed them
   from the page tables.
 - shared memory out-of-swap writepage() fixup (no more magic return)

pre10:
 - got a few too-new R128 #defines in the Radeon merge. Fix.
 - tulip driver update from Jeff Garzik
 - more cpq and DAC elevator fixes from Jens. Looks good.
 - Petr Vandrovec: nicer ncpfs behaviour
 - Andy Grover: APCI update
 - Cort Dougan: PPC update
 - David Miller: sparc updates
 - David Miller: networking updates
 - Neil Brown: RAID5 fixes

pre9:
 - cpq array driver elevator fixes 
 - merge radeon driver from X CVS tree
 - ispnp cleanups
 - emu10k unlock on error fixes
 - hpfs doesn't allow truncate to larger

pre8:
 - Don't drop a megabyte off the old-style memory size detection
 - remember to UnlockPage() in ramfs_writepage()
 - 3c59x driver update from Andrew Morton
 - egcs-1.1.2 miscompiles depca: workaround by Andrew Morton
 - dmfe.c module init fix: Andrew Morton
 - dynamic XMM support. Andrea Arkangeli.
 - ReiserFS merge
 - USB hotplug updates/fixes
 - boots on real i386 machines
 - blk-14 from Jens Axboe
 - fix DRM R128/AGP dependency
 - fix n_tty "canon" mode SMP race
 - ISDN fixes
 - ppp UP deadlock attack fix
 - FAT fat_cache SMP race fix
 - VM balancing tuning
 - Locked SHM segment deadlock fix
 - fork() page table copy race fix

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

Re: 2.4.0-test12: SiS pirq handling..

[Sven Koch]

On Mon, 29 Jan 2001, Linus Torvalds wrote:

> give 2.4.0-test12 a final whirl before I release it as 2.4.1? We got a lot
[...]
> The other changes in pre12 aren't likely to be all that noticeable, unless
[...]
> 		Linus

Seems that even you are still confused with -testXX and -preXX ;)

*SCNR*
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

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

Recommended swap for 2.4.x.

[Alan Olsen]

What is the recommended amount of swap with the 2.4.x kernels?

The standard rule is usually memory x 2.  (But that is more a Solaris
superstition than anything else.)

Is it the same or "as much as I can get away with" or something else?

I am asking because I have just ordered a new drive for my Vaio (8.1 gig
in a 8.45mm drive!) and I want to install 2.4.x on it.  (I like getting
the swap partition done right the first time. Repartitions are a pain.
Especially if you screw up.)

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.
    "In the future, everything will have its 15 minutes of blame."

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

Re: Recommended swap for 2.4.x.

[Linus Torvalds]

In article <Pine.LNX.4.10.10101291452120.31258-100000@clueserver.org>,
Alan Olsen  <alan@clueserver.org> wrote:
>
>What is the recommended amount of swap with the 2.4.x kernels?
>
>The standard rule is usually memory x 2.  (But that is more a Solaris
>superstition than anything else.)

"memory x 2" is probably a good rule. With normal usage patterns, at the
point you fully use up your swap, you _want_ the system to start killing
things off due to out-of-memory errors.

But there really is no "fixed" rule: it can depend a lot on your usage
patterns. Some people have a lot of big background processes that don't
have a big active footprint but that have a lot of "idle" pages that can
successfully be swapped out - using up tons of swap-space without
actually causing any bad behaviour.

And you might end up adding more memory.. 

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[alex]

On Mon, Jan 29, 2001 at 02:57:44PM -0800, Alan Olsen wrote:
> 
> What is the recommended amount of swap with the 2.4.x kernels?

AFAIK, swap requirements for applications running under a 2.4 kernel have not 
changed significantly from 2.2 kernels (please anyone correct me if I'm wrong),
so the basic answer is:  About as much as you needed with for a 2.2 kernel.

> The standard rule is usually memory x 2.  (But that is more a Solaris
> superstition than anything else.)

This always struck me as the most stupid rule of thumb I'd ever heard of.  
With this metric, systems which precisely need swap the most (low-RAM systems) 
get the least of it, and those that need it the least (those with gigs of RAM) 
get tons of swap they don't need.  I don't know how this keeps perpetuating, 
as it should be plainly brain damaged to anybody who thinks about it for a 
couple of seconds, but somehow it does.

My general recommendation is:
1) Take the best guess you can at how much total memory you're ever going to 
   need at one time.  This can vary with the type of tasks you're doing 
   (server/desktop/image-editing/etc), the software programs you're using, and 
   so on.  There is no easy way to figure this out, but I would recommend that 
   if you come up with anything less than 128MB, you're probably being too 
   optimistic.
2) Subtract the amount of RAM you have (believe it or not, the more RAM you 
   have, the less swap you need.  Imagine that).
3) Round up to a nice breaking point (multiples of 64MB are nice and are easy 
   to remember), just for convenience.
4) Add a little bit of extra just in case (it's better to have too much than 
   too little, particularly since disk is cheap).  I usually add somewhere 
   around 64MB.

For most people, for most systems, this comes out somewhere between 128MB and 
256MB of swap needed (in some cases you may need 512MB or more, but if you've 
got those sorts of memory demands you may want to carefully consider whether 
more RAM wouldn't be a good investment).  If in doubt, go for the larger 
number.  After all, with an 8.1GB drive, how much are you going to miss a puny 
0.25GB (256MB) chunk of it?

-alex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[Mike Castle]

On Mon, Jan 29, 2001 at 03:23:35PM -0800, alex@foogod.com wrote:
> On Mon, Jan 29, 2001 at 02:57:44PM -0800, Alan Olsen wrote:
> > The standard rule is usually memory x 2.  (But that is more a Solaris
> > superstition than anything else.)
> 
> This always struck me as the most stupid rule of thumb I'd ever heard of.  
> With this metric, systems which precisely need swap the most (low-RAM systems) 
> get the least of it, and those that need it the least (those with gigs of RAM) 
> get tons of swap they don't need.  I don't know how this keeps perpetuating, 
> as it should be plainly brain damaged to anybody who thinks about it for a 
> couple of seconds, but somehow it does.

Because it used to be necessary.

Early VM systems *required* at least one page of swap for every page of
physical ram.  In theory, the entire contents of physical ram would be
copied at any time onto swap, and whenever it was necessary to free up a
page to bring in a new one, it would already be on backing store and could
easily be freed up.

This was prior to things like being able to page in binaries from file
systems on demand, so your programs had to be swapped back out as well.

So, basically, your totally usable paging area was the sum of swap space.
Not the sum of swap space + physical memory.

Now, granted, this is no longer the case for most (all?) VM based systems,
the rule of thumb has such strong momentum behind it that it's difficult to
stop.
 
 
Now, personally, I tend to throw on a few meg of swap onto each disk and
stripe swap across them for performance.  If I find I ever run out of
memory under normal use, I'll up it.  But I've never had that happen.  Swap
space depends on how you use it.  Set up some stuff, and monitor with free
every once in a while.  If you never hit swap, then reduce it or eliminate
it.  If you are constantly running over 1/3 of it or so, might consider
upping it a little bit.

mrc
-- 
       Mike Castle       Life is like a clock:  You can work constantly
  dalgoda@ix.netcom.com  and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[William T Wilson]

On Mon, 29 Jan 2001 alex@foogod.com wrote:

> This always struck me as the most stupid rule of thumb I'd ever heard
> of.  With this metric, systems which precisely need swap the most

It used to be basically meaningful, for systems that had to swap, instead
of page.  In those cases, in order to be assured of getting any use out of
the system, it had to be at least twice the amount of RAM needed.  Of
course, you could have twice as much swap as RAM, four times, eight
times... but twice was the usual amount.

It's pretty well useless now though, even on Solaris :}

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

RE: Recommended swap for 2.4.x.

[Kevin Krieser]

You mean my current 1.9 gig of swap is overkill? :)

I have 256MB of RAM, and am currently not using any of the swap.

So, I probably have too much swap allocated.  But I wanted to find an use
for a gig SCSI drive I have, and it was just easiest to add it as swap.


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

Re: Recommended swap for 2.4.x.

[Jeff Chua]

better off configure squid and use that as web cache.

Thanks,
Jeff
[ jchua@fedex.com ]
----- Original Message ----- 
From: "Kevin Krieser" <kkrieser_list@footballmail.com>
To: "Linux Kernel" <linux-kernel@vger.kernel.org>
Sent: Tuesday, January 30, 2001 8:24 AM
Subject: RE: Recommended swap for 2.4.x.


You mean my current 1.9 gig of swap is overkill? :)

I have 256MB of RAM, and am currently not using any of the swap.

So, I probably have too much swap allocated.  But I wanted to find an use
for a gig SCSI drive I have, and it was just easiest to add it as swap.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[James H. Cloos Jr.]

>>>>> "Kevin" == Kevin Krieser <kkrieser_list@footballmail.com> writes:

Kevin> You mean my current 1.9 gig of swap is overkill? :) I have
Kevin> 256MB of RAM, and am currently not using any of the swap.

Looks like you are a perfect candidate for testing shmfs[1] as /tmp, eh?

[1] or vmfs or tmpfs or whatever it ends up being called when it get's
    into the mainline kernel....

-JimC
-- 
James H. Cloos, Jr.  <http://jhcloos.com/public_key>     1024D/ED7DAEA6 
<cloos@jhcloos.com>  E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6

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

Re: Recommended swap for 2.4.x.

[idalton]

On Mon, Jan 29, 2001 at 03:23:35PM -0800, alex@foogod.com wrote:
> On Mon, Jan 29, 2001 at 02:57:44PM -0800, Alan Olsen wrote:
> > 
> > What is the recommended amount of swap with the 2.4.x kernels?
> 
> AFAIK, swap requirements for applications running under a 2.4 kernel have not 
> changed significantly from 2.2 kernels (please anyone correct me if I'm wrong),
> so the basic answer is:  About as much as you needed with for a 2.2 kernel.
> 
> > The standard rule is usually memory x 2.  (But that is more a Solaris
> > superstition than anything else.)
> 
> This always struck me as the most stupid rule of thumb I'd ever heard of.  
> With this metric, systems which precisely need swap the most (low-RAM systems) 
> get the least of it, and those that need it the least (those with gigs of RAM) 
> get tons of swap they don't need.  I don't know how this keeps perpetuating, 
> as it should be plainly brain damaged to anybody who thinks about it for a 
> couple of seconds, but somehow it does.

I think this has more to do with the Olden Days when kernel panics would
be written out to swap. Or something. You wanted more swap than ram so
the dump wouldn't overwrite your fs.

> My general recommendation is:
> 1) Take the best guess you can at how much total memory you're ever going to 
>    need at one time.  This can vary with the type of tasks you're doing 
>    (server/desktop/image-editing/etc), the software programs you're using, and 
>    so on.  There is no easy way to figure this out, but I would recommend that 
>    if you come up with anything less than 128MB, you're probably being too 
>    optimistic.
> 2) Subtract the amount of RAM you have (believe it or not, the more RAM you 
>    have, the less swap you need.  Imagine that).
> 3) Round up to a nice breaking point (multiples of 64MB are nice and are easy 
>    to remember), just for convenience.
> 4) Add a little bit of extra just in case (it's better to have too much than 
>    too little, particularly since disk is cheap).  I usually add somewhere 
>    around 64MB.
> 
> For most people, for most systems, this comes out somewhere between 128MB and 
> 256MB of swap needed (in some cases you may need 512MB or more, but if you've 
> got those sorts of memory demands you may want to carefully consider whether 
> more RAM wouldn't be a good investment).  If in doubt, go for the larger 
> number.  After all, with an 8.1GB drive, how much are you going to miss a puny 
> 0.25GB (256MB) chunk of it?

This is pretty close to the rules-of-thumb I use. Some round numbers
that work for me:

XFree86: 48MB
Window Manager: ? (fvwm I give about 16MB; E I hear might want 48MB)
Netscape/Mozilla: 64MB
Base system: 32MB
Basic audio: 16MB (mostly buffer space)
Other applications: ?

Minimum swap: 16MB (I allocate in 16MB chunks)
Maximum swap: 1.5x - 2x physical memory.

-- Ferret
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[Rik van Riel]

On Mon, 29 Jan 2001 alex@foogod.com wrote:
> On Mon, Jan 29, 2001 at 02:57:44PM -0800, Alan Olsen wrote:
> > 
> > What is the recommended amount of swap with the 2.4.x kernels?
> 
> AFAIK, swap requirements for applications running under a 2.4
> kernel have not changed significantly from 2.2 kernels

It has. We now leave dirty pages swapcached, which means that
for certain workloads Linux 2.4 eats up much more swap space
than Linux 2.2.

On the other hand, if you almost never used swap under Linux
2.2, you probably won't be using it under 2.4 either.

> 2) Subtract the amount of RAM you have (believe it or not, the more RAM you 
>    have, the less swap you need.  Imagine that).

For Linux 2.4, it may be better to substract a bit less,
because of the issue above.

If you have a very swap-intensive workload, you may end
up with 90% of your memory being "duplicated" in swap, in
which case this rule doesn't work.

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[alex]

On Tue, Jan 30, 2001 at 09:48:33AM -0200, Rik van Riel wrote:
> It has. We now leave dirty pages swapcached, which means that
> for certain workloads Linux 2.4 eats up much more swap space
> than Linux 2.2.

Ah.. thanks for the clarification.  Is this duplication "hard" or "soft"?  
i.e. under low-memory conditions, do these duplicated pages actually reduce 
the hard limit of VM available, or just imply that using that last bit of 
memory will entail greater paging overhead (because it has to do more cleanup)?

Does this mean that having a swap partition less than or equal to RAM is now 
effectively pointless?

-alex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[Rik van Riel]

On Tue, 30 Jan 2001 alex@foogod.com wrote:
> On Tue, Jan 30, 2001 at 09:48:33AM -0200, Rik van Riel wrote:
> > It has. We now leave dirty pages swapcached, which means that
> > for certain workloads Linux 2.4 eats up much more swap space
> > than Linux 2.2.
> 
> Ah.. thanks for the clarification.  Is this duplication "hard"
> or "soft"?  i.e. under low-memory conditions, do these
> duplicated pages actually reduce the hard limit of VM available,
> or just imply that using that last bit of memory will entail
> greater paging overhead (because it has to do more cleanup)?

At the moment there is no way to reclaim the swap space if
the page is shared, and for non-shared pages we haven't
implemented a way to reclaim swap space.

While reclaiming swap space when you run out is pretty
trivial to do, Linus doesn't seem to like the idea all
that much and Disk Space Is Cheap(tm) so it's not very
high on my list of things to do.

> Does this mean that having a swap partition less than or equal
> to RAM is now effectively pointless?

If you're swapping heavily, yes. If most of your programs
fit in memory and you're hardly using swap, nothing changes.

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[Matthew Kirkwood]

On Tue, 30 Jan 2001, Rik van Riel wrote:

> While reclaiming swap space when you run out is pretty
> trivial to do, Linus doesn't seem to like the idea all
> that much and Disk Space Is Cheap(tm) so it's not very
> high on my list of things to do.

'anybody who says "disk is cheap" deserves to be shot.'
- Linus Torvalds

Matthew.

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

Re: Recommended swap for 2.4.x.

[Rik van Riel]

On Tue, 30 Jan 2001, Matthew Kirkwood wrote:
> On Tue, 30 Jan 2001, Rik van Riel wrote:
> 
> > While reclaiming swap space when you run out is pretty
> > trivial to do, Linus doesn't seem to like the idea all
> > that much and Disk Space Is Cheap(tm) so it's not very
> > high on my list of things to do.
> 
> 'anybody who says "disk is cheap" deserves to be shot.'
> - Linus Torvalds

I wonder if Linus will shoot himself or if he'll just
segfault ;)

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[Russell King]

Rik van Riel writes:
> On Tue, 30 Jan 2001, Matthew Kirkwood wrote:
> > On Tue, 30 Jan 2001, Rik van Riel wrote:
> > > While reclaiming swap space when you run out is pretty
> > > trivial to do, Linus doesn't seem to like the idea all
> > > that much and Disk Space Is Cheap(tm) so it's not very
> > > high on my list of things to do.
> > 
> > 'anybody who says "disk is cheap" deserves to be shot.'
> > - Linus Torvalds
> 
> I wonder if Linus will shoot himself or if he'll just
> segfault ;)

Depends whether someone compiled oom_kill.c into his brain!

--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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

Re: Recommended swap for 2.4.x.

[alex]

On Tue, Jan 30, 2001 at 04:22:20PM -0200, Rik van Riel wrote:
> At the moment there is no way to reclaim the swap space if
> the page is shared, and for non-shared pages we haven't
> implemented a way to reclaim swap space.
> 
> While reclaiming swap space when you run out is pretty
> trivial to do, Linus doesn't seem to like the idea all
> that much and Disk Space Is Cheap(tm) so it's not very
> high on my list of things to do.

In general, I agree that Disk Space Is Cheap(tm) (though, of course, there are 
always unusual cases where it may not be), but my primary concern is for 
migration of existing configurations.  It sounds like what you're saying is 
that if I have a machine with 1GB RAM and 1GB swap that I upgrade from 2.2 to 
2.4, all of a sudden this machine has effectively half the VM it used to.  
That could cause some rather unexpected behavior, so it's good to know ahead 
of time..

I guess it's a good thing this question was brought up.

> > Does this mean that having a swap partition less than or equal
> > to RAM is now effectively pointless?
> 
> If you're swapping heavily, yes. If most of your programs
> fit in memory and you're hardly using swap, nothing changes.

I think I'm confused.. are you saying that it's useful to have swap which you 
can't use?  (What I'm hearing is "if you try to use it it won't work, but if 
you don't use it it works fine."  I get the feeling I'm missing something 
subtle.)

-alex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[Rik van Riel]

On Tue, 30 Jan 2001 alex@foogod.com wrote:
> On Tue, Jan 30, 2001 at 04:22:20PM -0200, Rik van Riel wrote:
> > At the moment there is no way to reclaim the swap space if
> > the page is shared, and for non-shared pages we haven't
> > implemented a way to reclaim swap space.
> > 
> > While reclaiming swap space when you run out is pretty
> > trivial to do, Linus doesn't seem to like the idea all
> > that much and Disk Space Is Cheap(tm) so it's not very
> > high on my list of things to do.
> 
> In general, I agree that Disk Space Is Cheap(tm)

I don't, in this case. I have proposed a scheme to reclaim
swap space and disk space is cheap was one of Linus' arguments
for rejecting the extra complexity of swap space reclaiming(IIRC).

That said, reclaiming swap space isn't very high on my priority
list since most people do have enough memory/swap anyway and
there are a few VM things to sort out that affect everybody, and
not just those unfortunate people who are short on memory and
swap.

Once I get some more time, however, I will make a patch to
reclaim swap space ... at least for non-shared pages.

> my primary concern is for migration of existing configurations.

This isn't a very big concern for me, though I must admit
that's mostly because I've never seen a production machine
use more than half of its swap space.  ;)

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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[Pavel Machek]

Hi!

> I am asking because I have just ordered a new drive for my Vaio (8.1 gig
> in a 8.45mm drive!) and I want to install 2.4.x on it.  (I like getting

8.1GB in under centimeter? That's 8.1GB in compactflash slot?
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Recommended swap for 2.4.x.

[Alan Olsen]

On Fri, 2 Feb 2001, Pavel Machek wrote:

> Hi!
> 
> > I am asking because I have just ordered a new drive for my Vaio (8.1 gig
> > in a 8.45mm drive!) and I want to install 2.4.x on it.  (I like getting
> 
> 8.1GB in under centimeter? That's 8.1GB in compactflash slot?

Standard laptop drive size except 8.45mm thick as opposed to 9.5mm thick.
(Kind of bites too.  If it would take a 9.5mm drive I could put in 30 gigs
instead of 8.1gigs.)

alan@ctrl-alt-del.com | Note to AOL users: for a quick shortcut to reply
Alan Olsen            | to my mail, just hit the ctrl, alt and del keys.
    "In the future, everything will have its 15 minutes of blame."

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

Re: Recommended swap for 2.4.x.

[Jonathan Morton]

At 1:51 pm +0000 2/2/2001, Pavel Machek wrote:
>Hi!
>
>> I am asking because I have just ordered a new drive for my Vaio (8.1 gig
>> in a 8.45mm drive!) and I want to install 2.4.x on it.  (I like getting
>
>8.1GB in under centimeter? That's 8.1GB in compactflash slot?

In general, i think the normal reccommendation is to put around double your
physical RAM size as a swapfile.  In practice, I use 256Mb swap on most
(almost all) my machines, which have physical RAM from 28Mb up to 320Mb.
Only the 28Mb machine ever makes substantial use of that space.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi@cyberspace.org  (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk

The key to knowledge is not to rely on people to teach you it.

Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/

-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+
-----END GEEK CODE BLOCK-----


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

Re: 2.4.0-test12: SiS pirq handling..

[Aaron Tiensivu]

| Could people that had problems with SiS interrupt handling before please
| give 2.4.0-test12 a final whirl before I release it as 2.4.1? We got a lot
| of pirq tables from people, and Martin Diehl put them together with the
| hardware specs to come up with what looks to be the "final and correct"
| SiS pirq routing, but as always it would be good to have this verified by
| as many people as possible.

Linux version 2.4.1-pre12 (root@usr1-ip023-cs.wmis.net) (gcc version 2.95.3
20010125 (prerelease)) #2 Mon Jan 29 17:53:38 EST 2001
BIOS-provided physical RAM map:
 BIOS-e820: 00000000000a0000 @ 0000000000000000 (usable)
 BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
 BIOS-e820: 0000000003efd000 @ 0000000000100000 (usable)
 BIOS-e820: 0000000000002000 @ 0000000003ffd000 (ACPI data)
 BIOS-e820: 0000000000001000 @ 0000000003fff000 (ACPI NVS)
 BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved)
On node 0 totalpages: 16381
zone(0): 4096 pages.
zone(1): 12285 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=lnew ro root=341
BOOT_FILE=/home/kernel/kernel/linux/arch/i386/boot/bzImage
Initializing CPU#0
Detected 374.229 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 747.11 BogoMIPS
Memory: 62404k/65524k available (928k kernel code, 2736k reserved, 312k
data, 180k init, 0k highmem)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
CPU: Before vendor init, caps: 008021bf 808029bf 00000000, vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: After vendor init, caps: 008021bf 808029bf 00000000 00000002
CPU: After generic, caps: 008021bf 808029bf 00000000 00000002
CPU: Common caps: 008021bf 808029bf 00000000 00000002
CPU: AMD-K6(tm) 3D processor stepping 0c
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: AMD K6
PCI: BIOS32 Service Directory structure at 0xc00f9b50
PCI: BIOS32 Service Directory entry at 0xf04d0
PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=00
PCI: PCI BIOS revision 2.10 entry at 0xf0500, last bus=0
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Setting max latency to 32
PCI: IDE base address trash cleared for 00:01.1
PCI: IDE base address fixup for 00:01.1
PCI: Scanning for ghost devices on bus 0
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00f0af0
00:0c slot=01 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8
00:0b slot=02 0:42/1eb8 1:43/1eb8 2:44/1eb8 3:41/1eb8
00:0a slot=03 0:43/1eb8 1:44/1eb8 2:41/1eb8 3:42/1eb8
00:09 slot=04 0:44/1eb8 1:41/1eb8 2:42/1eb8 3:43/1eb8
00:01 slot=00 0:62/1eb8 1:00/0000 2:00/0000 3:00/0000
00:13 slot=00 0:41/1eb8 1:42/1eb8 2:43/1eb8 3:44/1eb8
PCI: Using IRQ router SIS [1039/0008] at 00:01.0
PCI: IRQ fixup
PCI: Allocating resources
PCI: Resource 0000d000-0000d00f (f=101, d=0, p=0)
PCI: Resource dd000000-dd000fff (f=200, d=0, p=0)
PCI: Resource 0000b800-0000b807 (f=101, d=0, p=0)
PCI: Resource dc800000-dc87ffff (f=200, d=0, p=0)
PCI: Resource e0000000-e7ffffff (f=1208, d=0, p=0)
PCI: Resource df000000-df000fff (f=1208, d=0, p=0)
PCI: Resource 0000b400-0000b41f (f=101, d=0, p=0)
PCI: Resource dc000000-dc0fffff (f=200, d=0, p=0)
PCI: Resource de000000-de3fffff (f=1208, d=1, p=1)
PCI: Resource db800000-db80ffff (f=200, d=1, p=1)
PCI: Resource 0000b000-0000b07f (f=101, d=1, p=1)
PCI: Sorting device list...
Disabling direct PCI/PCI transfers.
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
DMI 2.0 present.
28 structures occupying 890 bytes.
DMI table at 0x000F540A.
BIOS Vendor: Award Software, Inc.
BIOS Version: ASUS SP97-V ACPI BIOS Revision 1001 B03/18/99
BIOS Release:
System Vendor: System Manufacturer.
Product Name: System Name.
Version System Version.
Serial Number SYS-1234567890.
Board Vendor: ASUSTeK Computer INC..
Board Name: SP97-V.
Board Version: REV 1.XX.
Asset Tag: Asset-1234567890.
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 41365kB/13788kB, 128 slots per queue
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller on PCI bus 00 dev 09
IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl 0000 -> newirq=10 -> got IRQ 7
PCI: Found IRQ 7 for device 00:01.1
IRQ routing conflict in pirq table for device 00:01.1
PCI: The same IRQ used for device 00:01.2
SIS5513: chipset revision 208
SIS5513: not 100% native mode: will probe irqs later
SiS5597
    ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio
keyboard: Timeout - AT keyboard not present?
keyboard: Timeout - AT keyboard not present?
hda: ST5660A, ATA DISK drive
hdb: IBM-DJAA-31700, ATA DISK drive
hdc: Maxtor 72700 AP, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 1066184 sectors (546 MB) w/256KiB Cache, CHS=528/32/63, DMA
hdb: 3334464 sectors (1707 MB) w/96KiB Cache, CHS=827/64/63, DMA
hdc: 5290320 sectors (2709 MB) w/128KiB Cache, CHS=5248/16/63, DMA
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2
 /dev/ide/host0/bus0/target1/lun0: p1
 /dev/ide/host0/bus1/target0/lun0: [PTBL] [656/128/63] p1
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ DETECT_IRQ
SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
IRQ for 00:0a.0:0 -> PIRQ 43, mask 1eb8, excl 0000 -> newirq=5 -> got IRQ 5
PCI: Found IRQ 5 for device 00:0a.0
ttyS02 at port 0xb800 (irq = 5) is a 16550A
Real Time Clock Driver v1.10d
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw@saw.sw.com.sg> and others
IRQ for 00:0c.0:0 -> PIRQ 41, mask 1eb8, excl 0000 -> newirq=10 -> got IRQ
10
PCI: Found IRQ 10 for device 00:0c.0
eth0: Intel Corporation 82557 [Ethernet Pro 100], 00:A0:C9:0D:A6:1F, IRQ 10.
  Board assembly 352509-003, Physical connectors present: RJ45
  Primary interface chip DP83840 PHY #1.
  DP83840 specific setup, setting register 23 to 8462.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x49caa8d6).
  Receiver lock-up workaround activated.
PPP generic driver version 2.4.1
PPP Deflate Compression module registered
PPP BSD Compression module registered
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
devfs: v0.102 (20000622) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
reiserfs: checking transaction log (device 03:41) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
VFS: Mounted root (reiserfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 180k freed
Adding Swap: 18136k swap-space (priority -1)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
IRQ for 00:01.2:0 -> PIRQ 62, mask 1eb8, excl 0000 -> newirq=7 -> got IRQ 7
PCI: Found IRQ 7 for device 00:01.2
IRQ routing conflict in pirq table for device 00:01.1
usb-ohci.c: USB OHCI at membase 0xc48c6000, IRQ 7
usb-ohci.c: usb-00:01.2, Silicon Integrated Systems [SiS] 7001
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
reiserfs: checking transaction log (device 03:01) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
Adding Swap: 65528k swap-space (priority -2)
Adding Swap: 131064k swap-space (priority -3)

Problem still exists, diffed to last kernel:

-Linux version 2.4.0-ac12 (root@lucretia.wmis.net) (gcc version 2.95.3
20010125 (prerelease)) #5 Mon Jan 29 01:59:59 EST 2001
+Linux version 2.4.1-pre12 (root@usr1-ip023-cs.wmis.net) (gcc version 2.95.3
20010125 (prerelease)) #2 Mon Jan 29 17:53:38 EST 2001
 SIS5513: IDE controller on PCI bus 00 dev 09
 IRQ for 00:01.1:0 -> PIRQ 62, mask 1eb8, excl 0000 -> newirq=10 -> got IRQ
7
-IRQ routing conflict in pirq table! Try 'pci=autoirq'
+PCI: Found IRQ 7 for device 00:01.1
+IRQ routing conflict in pirq table for device 00:01.1
+PCI: The same IRQ used for device 00:01.2
 SIS5513: chipset revision 208
 SIS5513: not 100% native mode: will probe irqs later
 SiS5597
 usb.c: registered new driver usbdevfs
 usb.c: registered new driver hub
 IRQ for 00:01.2:0 -> PIRQ 62, mask 1eb8, excl 0000 -> newirq=7 -> got IRQ 7
 PCI: Found IRQ 7 for device 00:01.2
-PCI: The same IRQ used for device 00:01.1
+IRQ routing conflict in pirq table for device 00:01.1
 usb-ohci.c: USB OHCI at membase 0xc48c6000, IRQ 7
 usb-ohci.c: usb-00:01.2, Silicon Integrated Systems [SiS] 7001


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

Re: 2.4.0-test12: SiS pirq handling..

[Linus Torvalds]

On Mon, 29 Jan 2001, Aaron Tiensivu wrote:
> 
> Problem still exists, diffed to last kernel:

Yes. But everything works for you, no? Including USB?

The problem is that you have this routing table entry:

	00:01 slot=00 0:62/1eb8 1:00/0000 2:00/0000 3:00/0000

which is really for the USB chip (PCI id 00:01.2), and which the PCI code
_does_ find for the USB chip. So it should set up the routing happily, and
everything should be ok.

The trouble is that the routing table entry _also_ gets a false match to
the IDE chip (PCI id 00:01.1), which doesn't get routed through the above
AT ALL. So every time it sees either the USB or the IDE device, it will
notice that there is a bogus routing table entry associated with the IDE
device.

As a result, 2.4.1-pre12 will now complain (twice - once when it tries to
find the IDE irq route, the other time when it tries to find the USB irq
route) that there seems to be a routing table conflict for device 00:01.1.

In reality, the IDE device is routed with a fixed routing by the BIOS, and
the BIOS has also set the device "irqline" config space entry to point to
the proper table. So the IDE controller should work fine - and in fact it
is this second piece of information from the PCI config space that makes
Linux notice the conflict in the first place.

So it does appear that everything is fine. Linux should be doing exactly
the right thing on your board now, and USB _should_ work for you. The
complaints are real, and more importantly I now think we understand _why_
they happen.

It probably all used to work for you before, but we didn't really know
_why_. Which is almost as nasty a situation as not working at all.

Basically, the way your chipset is laid out PCI-wise, they are
subfunctions of the same device (subfunction 1 is IDE, subfunction 2 is
USB. Because of this they share an irq routing entry, and if they were to
NOT clash they should have been given separate "irq pin" numbers in their
config space. So a _good_ routing entry might have looked like

	00:01 slot=00 0:fe/4000 1:62/1eb8 2:00/0000 3:00/0000

where the IDE device has "irqpin=1" and the USB device has "irqpin=2", and
USB points to link 62, while IDE points to link fe (ie "hardcode to 14").

But the BIOS didn't do this properly, and as a result we get these pirq
clashes. Which are real, but should be harmless.

Now, will the two people in the world who know the pirq black magic now
stand up and confirm or deride my interpretation?

		Linus

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

Re: 2.4.0-test12: SiS pirq handling..

[Aaron Tiensivu]

| > Problem still exists, diffed to last kernel:
| Yes. But everything works for you, no? Including USB?

Mmmhmm..

| The problem is that you have this routing table entry:
|
| 00:01 slot=00 0:62/1eb8 1:00/0000 2:00/0000 3:00/0000
|
| which is really for the USB chip (PCI id 00:01.2), and which the PCI code
| _does_ find for the USB chip. So it should set up the routing happily, and
| everything should be ok.

Leave it to me to have goofy hardware.. :)

| Basically, the way your chipset is laid out PCI-wise, they are
| subfunctions of the same device (subfunction 1 is IDE, subfunction 2 is
| USB. Because of this they share an irq routing entry, and if they were to
| NOT clash they should have been given separate "irq pin" numbers in their
| config space. So a _good_ routing entry might have looked like
|
| 00:01 slot=00 0:fe/4000 1:62/1eb8 2:00/0000 3:00/0000
|
| where the IDE device has "irqpin=1" and the USB device has "irqpin=2", and
| USB points to link 62, while IDE points to link fe (ie "hardcode to 14").

Does anyone know who to prod at ASUS to maybe update their BIOS with a
proper routing table?
Maybe even adding proper K6-2+/K6-3+ ids in the BIOS (we can dream I
suppose)..
This is a simple packet-pumping routing box so one of those chips would be
overkill anyway.

| Now, will the two people in the world who know the pirq black magic now
| stand up and confirm or deride my interpretation?

It sounds correct to me..


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

Re: 2.4.0-test12: SiS pirq handling..

[Martin Diehl]

On Mon, 29 Jan 2001, Linus Torvalds wrote:

> Now, will the two people in the world who know the pirq black magic now
> stand up and confirm or deride my interpretation?

since I'm certainly not the other one, I'm not going to confirm it ;-)
But, besides it sounds reasonable, I could give some more ammu:

my IDE controller is located in the SiS5591 hostbridge (device 00:00)
and the BIOS didn't provide a routing table entry for this device.
Hence, instead of the confusing conflict messages, I get:

SIS5513: IDE controller on PCI bus 00 dev 01
IRQ for 00:00.1:0 -> not found in routing table

which you may take for a vice-versa prove of your explanation.

Martin

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

Re: 2.4.0-test12: SiS pirq handling..

[Adam Huffman]

> The other changes in pre12 aren't likely to be all that noticeable, unless
> you happen to be hit by just that detail.. As always, fedback is
> appreciated.
> 
> 		Linus
> 
> 
> ----
> pre12:
>  - Get non-cpuid Cyrix probing right (it's not a NexGen)
>  - Jens Axboe: cdrom tray status and queing cleanups
>  - AGP GART: don't disable VIA, and allow i815 with external AGP
>  - Coda: use iget4() in order to have big inode numbers without clashes.
>  - Fix UDF writepage() page locking
>  - NIIBE Yutaka: SuperH update
>  - Martin Diehl and others: SiS pirq routing fixes
>  - Andy Grover: ACPI update
>  - Andrea Arkangeli: LVM update
>  - Ingo Molnar: RAID cleanups
>  - David Miller: sparc and networking updates
>  - Make NFS really be able to handle large files
> 

Despite the latest ACPI update, I still get the ACPI slowdown on
initialisation which started with the -pre10 changes.  Also, the uhci
module doesn't work for me (the latest patch from Johannes Erdfelt does
work).  This is an Abit KA7-100, which has the KX133 chipset.  Here is
the dmesg output for this kernel (I had to turn off ACPI in the BIOS in
order to have a usable system):


Linux version 2.4.1-pre12 (adam@bloch.verdurin.priv) (gcc version 2.96 20000731 (Red Hat Linux 7.0)) #3 Mon Jan 29 22:24:04 GMT 2001
BIOS-provided physical RAM map:
 BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable)
 BIOS-e820: 0000000000000400 @ 000000000009fc00 (usable)
 BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
 BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved)
 BIOS-e820: 000000000ff00000 @ 0000000000100000 (usable)
On node 0 totalpages: 65536
zone(0): 4096 pages.
zone(1): 61440 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hde6 vga=1 mem=262144K
Initializing CPU#0
Detected 800.059 MHz processor.
Console: colour VGA+ 80x50
Calibrating delay loop... 1595.80 BogoMIPS
Memory: 255488k/262144k available (1096k kernel code, 6268k reserved, 369k data, 184k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c3f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c3f9ff 00000000 00000000
CPU: After generic, caps: 0183f9ff c1c3f9ff 00000000 00000000
CPU: Common caps: 0183f9ff c1c3f9ff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 01
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb4d0, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
DMI 2.3 present.
42 structures occupying 1165 bytes.
DMI table at 0x000F0800.
BIOS Vendor: Award Software International, Inc.
BIOS Version: 6.00 PG
BIOS Release: 07/20/2000
System Vendor: VIA Technologies, Inc..
Product Name: VT8371.
Version  .
Serial Number  .
Starting kswapd v1.8
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
block: queued sectors max/low 169765kB/56588kB, 512 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: enabling 8 loop devices
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
    ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:pio
HPT370: IDE controller on PCI bus 00 dev 98
PCI: Found IRQ 11 for device 00:13.0
HPT370: chipset revision 3
HPT370: not 100% native mode: will probe irqs later
    ide2: BM-DMA at 0xe800-0xe807, BIOS settings: hde:DMA, hdf:pio
    ide3: BM-DMA at 0xe808-0xe80f, BIOS settings: hdg:DMA, hdh:pio
hda: Maxtor 92049U6, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hdc: Pioneer DVD-ROM ATAPIModel DVD-104S 020, ATAPI CD/DVD-ROM drive
hde: IBM-DTLA-307030, ATA DISK drive
hdg: IBM-DTLA-307030, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0xd800-0xd807,0xdc02 on irq 11
ide3 at 0xe000-0xe007,0xe402 on irq 11
hda: 40026672 sectors (20494 MB) w/2048KiB Cache, CHS=2491/255/63, UDMA(66)
hde: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
hdg: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=59560/16/63, UDMA(100)
hdc: ATAPI DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
 hda: hda1
 hde: [PTBL] [3737/255/63] hde1 hde2 < hde5 hde6 hde7 hde8 hde9 >
 hdg: [PTBL] [3737/255/63] hdg1 hdg2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
PPP generic driver version 2.4.1
PPP Deflate Compression module registered
PPP BSD Compression module registered
Registered PPPoX v0.5
Registered PPPoE v0.6.5
8139too Fast Ethernet driver 0.9.13 loaded
PCI: Found IRQ 10 for device 00:0d.0
eth0: RealTek RTL8139 Fast Ethernet at 0xd0800000, 00:c0:df:02:8b:11, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8139B'
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
ACPI: System description tables not found
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 184k freed
Adding Swap: 248968k swap-space (priority -1)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
PCI: Found IRQ 5 for device 00:07.2
PCI: The same IRQ used for device 00:07.3
PCI: The same IRQ used for device 00:08.0
uhci.c: USB UHCI at I/O 0xc400, IRQ 5
uhci.c: detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
uhci: host controller process error. something bad happened
uhci: host controller halted. very bad
usb.c: kmalloc IF c157ccc0, numif 1
usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1
usb.c: USB device number 1 default language ID 0x0
Product: USB UHCI-alt Root Hub
SerialNumber: c400
hub.c: USB hub found
hub.c: 2 ports detected
hub.c: standalone hub
hub.c: ganged power switching
hub.c: global over-current protection
hub.c: power on to power good time: 2ms
hub.c: hub controller current requirement: 0mA
hub.c: port removable status: RR
hub.c: local power source is good
hub.c: no over-current condition exists
hub.c: enabling power on all ports
usb.c: hub driver claimed interface c157ccc0
usb.c: kusbd: /sbin/hotplug add 1
PCI: Found IRQ 5 for device 00:07.3
PCI: The same IRQ used for device 00:07.2
PCI: The same IRQ used for device 00:08.0
uhci.c: USB UHCI at I/O 0xc800, IRQ 5
uhci.c: detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
uhci: host controller halted. very bad
uhci: host controller process error. something bad happened
uhci: host controller halted. very bad
usb.c: kmalloc IF c157cf40, numif 1
usb.c: new device strings: Mfr=0, Product=2, SerialNumber=1
usb.c: USB device number 2 default language ID 0x0
Product: USB UHCI-alt Root Hub
SerialNumber: c800
hub.c: USB hub found
hub.c: 2 ports detected
hub.c: standalone hub
hub.c: ganged power switching
hub.c: global over-current protection
hub.c: power on to power good time: 2ms
hub.c: hub controller current requirement: 0mA
hub.c: port removable status: RR
hub.c: local power source is good
hub.c: no over-current condition exists
hub.c: enabling power on all ports
usb.c: hub driver claimed interface c157cf40
usb.c: kusbd: /sbin/hotplug add 2
mice: PS/2 mouse device common for all mice
uhci.c: root-hub INT complete: port1: 5ab port2: 58a data: 6
hub.c: port 1 connection change
hub.c: port 1, portstatus 301, change 3, 1.5 Mb/s
hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s
hub.c: USB new device connect on bus1/1, assigned device number 3
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=3 (error=-110)
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s
hub.c: USB new device connect on bus1/1, assigned device number 4
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
uhci.c: root-hub INT complete: port1: 5a5 port2: 58a data: 4
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
usb_control/bulk_msg: timeout
usb.c: USB device not accepting new address=4 (error=-110)
hub.c: port 2 connection change
hub.c: port 2, portstatus 300, change 3, 1.5 Mb/s
uhci.c: root-hub INT complete: port1: 5a1 port2: 588 data: 4
hub.c: port 2 enable change, status 300
uhci.c: root-hub INT complete: port1: 58a port2: 58a data: 6
hub.c: port 1 connection change
hub.c: port 1, portstatus 300, change 3, 1.5 Mb/s
hub.c: port 2 connection change
hub.c: port 2, portstatus 300, change 3, 1.5 Mb/s
uhci.c: root-hub INT complete: port1: 588 port2: 588 data: 6
hub.c: port 1 enable change, status 300
hub.c: port 2 enable change, status 300
eth0: Setting full-duplex based on MII #32 link partner ability of 45e1.
VFS: Disk change detected on device ide1(22,0)
usb.c: registered new driver hid
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] minor ne2k-pci irq fix

[Martin Diehl]

Hi,

while testing the SiS routing code, at some point my ne2k-pci didn't work
anymore. Was when BIOS was set for PnP OS and IRQ set to "auto" for the
NIC. Had to rmmod/insmod the ne2k-pci module after reboot to make it
working again.

Reason: we fetched the irq too early, before calling pci_enable_device(),
so it was bogus after initial routing.
Patch below (prepared for 2.4.0 - should be fine for 2.4.1 too).

Regards
Martin

-----

--- linux-2.4.0/drivers/net/ne2k-pci.c.orig	Tue Jan 30 23:21:48 2001
+++ linux-2.4.0/drivers/net/ne2k-pci.c	Tue Jan 30 23:22:35 2001
@@ -203,7 +203,6 @@
 		printk(KERN_INFO "%s" KERN_INFO "%s", version1, version2);
 
 	ioaddr = pci_resource_start (pdev, 0);
-	irq = pdev->irq;
 
 	if (!ioaddr || ((pci_resource_flags (pdev, 0) & IORESOURCE_IO) == 0)) {
 		printk (KERN_ERR "ne2k-pci: no I/O resource at PCI BAR #0\n");
@@ -213,6 +212,7 @@
 	i = pci_enable_device (pdev);
 	if (i)
 		return i;
+	irq = pdev->irq;
 
 	if (request_region (ioaddr, NE_IO_EXTENT, "ne2k-pci") == NULL) {
 		printk (KERN_ERR "ne2k-pci: I/O resource 0x%x @ 0x%lx busy\n",


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

Re: [PATCH] minor ne2k-pci irq fix

[davej]

On Wed, 31 Jan 2001, Martin Diehl wrote:

> Reason: we fetched the irq too early, before calling pci_enable_device(),
> so it was bogus after initial routing.
> Patch below (prepared for 2.4.0 - should be fine for 2.4.1 too).

I think it would be better to move the pci_enable_device(pdev);
above all this, as we should enable the device before reading the
pdev->resource[] too iirc.

Something like this maybe ?

  	i = pci_enable_device (pdev);
  	if (i)
  		return i;

  	ioaddr = pci_resource_start (pdev, 0);

  	if (!ioaddr || ((pci_resource_flags (pdev, 0) & IORESOURCE_IO) == 0)) {
  		printk (KERN_ERR "ne2k-pci: no I/O resource at PCI BAR #0\n");

 	irq = pdev->irq;

Comments?

regards,

Davej.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

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

Re: [PATCH] minor ne2k-pci irq fix

[Martin Diehl]

On Wed, 31 Jan 2001 davej@suse.de wrote:

> I think it would be better to move the pci_enable_device(pdev);
> above all this, as we should enable the device before reading the
> pdev->resource[] too iirc.

Probably I've missed this because the last time I hit such a thing was
when my ob800 bios mapped the cardbus memory BAR's into bogus legacy
0xe0000 area. Hence there was good reason to read and correct this before
trying to enable the device.
The normal case however would be like you've suggested, IMHO.

BTW, will it ever happen the kernel starts remapping BAR's when enabling
devices?

Regards
Martin


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

Re: [PATCH] minor ne2k-pci irq fix

[Jeff Garzik]

On Thu, 1 Feb 2001, Martin Diehl wrote:
> On Wed, 31 Jan 2001 davej@suse.de wrote:
> > I think it would be better to move the pci_enable_device(pdev);
> > above all this, as we should enable the device before reading the
> > pdev->resource[] too iirc.

Agreed.


> Probably I've missed this because the last time I hit such a thing was
> when my ob800 bios mapped the cardbus memory BAR's into bogus legacy
> 0xe0000 area. Hence there was good reason to read and correct this before
> trying to enable the device.

This is a PCI fixup, the driver shouldn't have to worry about this..


> BTW, will it ever happen the kernel starts remapping BAR's when enabling
> devices?

huh?  The two steps do not occur simultaneously.  The enabling should
occur first, at which point the BARs should be useable.  The remapping
occurs after that.  If the BARs are not usable after remapping, that is
a PCI quirk that needs to be added to the list [probably].

	Jeff



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

Re: [PATCH] minor ne2k-pci irq fix

[Martin Diehl]

(apologies in case anybody should get this twice - was catched by the DUL
blocker again. Seems time to change my mail routing anyway...)

On Thu, 1 Feb 2001, Jeff Garzik wrote:

> > Probably I've missed this because the last time I hit such a thing was
> > when my ob800 bios mapped the cardbus memory BAR's into bogus legacy
> > 0xe0000 area. Hence there was good reason to read and correct this before
> > trying to enable the device.
> 
> This is a PCI fixup, the driver shouldn't have to worry about this..

Agreed. Point was when I discovered the broken BAR location the BIOS had
set, it was at late 2.4.0-test12. So I prefered a simple fix in the yenta
driver without touching other stuff like PCI, just in case Linus would
have liked it for 2.4.

> > BTW, will it ever happen the kernel starts remapping BAR's when enabling
> > devices?
> 
> huh?  The two steps do not occur simultaneously.  The enabling should
> occur first, at which point the BARs should be useable.  The remapping
> occurs after that.  If the BARs are not usable after remapping, that is
> a PCI quirk that needs to be added to the list [probably].

Sorry, wasn't clear enough. I've meant, the kernel (PCI stuff) changing
the BAR bus address in the config space when enabling the device (i.e.
the bus address value which is used for later mapping). Doing so would
make the pci_resource_start() value bogus (when obtained before enabling
the device) - even without accessing/ioremap() it.
My guess is this might happen, but I'm not sure when. Probably if our PCI
stuff assigned another BAR without inital bus address to overlap with
what the BIOS suggested for some initially disabled BAR. Or for real PCI
hotplugging in general.

Just to understand it's more than a cosmetical bug if a driver saves this
before the device is up...

Martin

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

Re: [PATCH] minor ne2k-pci irq fix

[Jeff Garzik]

On Fri, 2 Feb 2001, Martin Diehl wrote:
> Sorry, wasn't clear enough. I've meant, the kernel (PCI stuff) changing
> the BAR bus address in the config space when enabling the device (i.e.
> the bus address value which is used for later mapping). Doing so would
> make the pci_resource_start() value bogus (when obtained before enabling
> the device) - even without accessing/ioremap() it.

The pci_resource_start() value is only bogus if the driver is changing
the BAR value -- which it should never do.  Enabling the device could
indeed change the BAR address... that's why pci_enable_device must
ALWAYS be called before reading pci_dev->irq and pci_resource_start()
values.

	Jeff



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

Re: [PATCH] minor ne2k-pci irq fix

[Linus Torvalds]

On Thu, 1 Feb 2001, Jeff Garzik wrote:
> 
> > Probably I've missed this because the last time I hit such a thing was
> > when my ob800 bios mapped the cardbus memory BAR's into bogus legacy
> > 0xe0000 area. Hence there was good reason to read and correct this before
> > trying to enable the device.
> 
> This is a PCI fixup, the driver shouldn't have to worry about this..

Actually, I'd rather see the _drivers_ do most of the fixups for their own
chips, and leave the global PCI fixups for things like

 - PCI/ISA/whatever bridges that affect drivers for _other_ chips. I hate
   having some random PCI driver having to know about the fact that it
   might be behind a bridge that needs special initialization. That kind
   of "non-local" knowledge is that the PCI fixups are there for.

 - stuff that needs to be fixed up early in order to have a working system
   and make sure that we don't have any resource clashes we can't fix up
   later on.

But if there is a BIOS/chip bug that affects only one driver, and that bug
is local to that driver only and can't affect anything else, then I'd
rather see the driver keep track of it. It's easy enough for a driver to
do any required fixup before it actually calls "pci_enable_device()". 

		Linus

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