2.4.1-test10

2.4.1-test10

[Linus Torvalds]

The ChangeLog may not be 100% complete. The physically big things are the
PPC and ACPI updates, even if most people won't notice.

		Linus

----

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.1-test10

[David Ford]

Linus Torvalds wrote:

> The ChangeLog may not be 100% complete. The physically big things are the
> PPC and ACPI updates, even if most people won't notice.
>
>                 Linus
>
> ----
>
> 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

Do the tulip driver updates address the increasingly common NETDEV timeout
repots?

-d

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

Re: 2.4.1-test10

[Marcelo Tosatti]

Any technical reason why the background page aging fix was not applied?

On Mon, 22 Jan 2001, Linus Torvalds wrote:

> The ChangeLog may not be 100% complete. The physically big things are the
> PPC and ACPI updates, even if most people won't notice.

-
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.1-test10

[Derek Wildstar]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am having ACPI problems with a dell inspiron 5000e, I hear it has a
broken implementation of APM, so could quite possibly have a broken ACPI
also.  When ACPI is enabled in the kernel (-pre10 and earlier ones also)
the system soft-hangs after loading the ACPI definitions.  both
ctrl-alt-del and alt-sysrq-b will restart the system.  If there is
anything else i can do to provide more info please let me know.  Running
without ACPI or APM is stable, even with the r128 kernel
drivers/XF4.0.2...battery usage is a bit quick, however =)

- -dwild


Linus Torvalds wrote:

> The ChangeLog may not be 100% complete. The physically big things are the
> PPC and ACPI updates, even if most people won't notice.
>
>                 Linus
>
> ----
>
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6bRDYmFSlcxy4R48RAjx8AJ9EgM9A8k5sUQWu91w/lt2hZcfW5wCdFYi8
S+lZ54tOtr9BMUSn503hj68=
=d48f
-----END PGP SIGNATURE-----

-
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.1-test10

[Jeff Garzik]

David Ford wrote:
> 
> Linus Torvalds wrote:
> 
> > The ChangeLog may not be 100% complete. The physically big things are the
> > PPC and ACPI updates, even if most people won't notice.
> >
> >                 Linus
> >
> > ----
> >
> > 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
> 
> Do the tulip driver updates address the increasingly common NETDEV timeout
> repots?

In general you can answer this yourself by reading
drivers/net/tulip/ChangeLog.

I don't see increasingly common timeout reports.. with which hardware? 
They are likely on the newer LinkSys 4.1 cards, and there are still
problesm with PNIC.  Outside of that, other cards should be ok.

	Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie
-
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.1-test10

[Ben Ford]

Jeff Garzik wrote:

> David Ford wrote:
> >
> > Linus Torvalds wrote:
> >
> > > The ChangeLog may not be 100% complete. The physically big things are the
> > > PPC and ACPI updates, even if most people won't notice.
> > >
> > >                 Linus
> > >
> > > ----
> > >
> > > 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
> >
> > Do the tulip driver updates address the increasingly common NETDEV timeout
> > repots?
>
> In general you can answer this yourself by reading
> drivers/net/tulip/ChangeLog.
>
> I don't see increasingly common timeout reports.. with which hardware?
> They are likely on the newer LinkSys 4.1 cards, and there are still
> problesm with PNIC.  Outside of that, other cards should be ok.
>

I have this problem also.

I have several machines that are almost unuseable due to the network device.  I
need to do an ifconfig down/up to get connectivity back again.  That doesn't
work so handy for a headless router . . . .

My desktop machine (2.3.9x - present) has dropped the network 4 or 5 times a day
for months.

-b


>
>         Jeff
>
> --
> Jeff Garzik       | "You see, in this world there's two kinds of
> Building 1024     |  people, my friend: Those with loaded guns
> MandrakeSoft      |  and those who dig. You dig."  --Blondie
> -
> 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/

NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[David Ford]

> > Do the tulip driver updates address the increasingly common NETDEV timeout
> > repots?
>
> In general you can answer this yourself by reading
> drivers/net/tulip/ChangeLog.
>
> I don't see increasingly common timeout reports.. with which hardware?
> They are likely on the newer LinkSys 4.1 cards, and there are still
> problesm with PNIC.  Outside of that, other cards should be ok.

I have four machines now that exhibit this problem.  Three have in them the
Linksys card family, similar PCI cards, one is my laptop which I have three
different cardbus cards but they all use the tulip driver.

In the PCI situation, not all machines using these cards act the same way.
I got a 10 pack of LNE100TX cards and so far only two out of the batch are doing
this, they are all the same revision, identical in every way that I've found.

The three cardbus cards are slightly different in numerous ways.  For them they
normally fault with an APM event, an eject/insert cycle via software will reset
them and a link down/up won't fix it.  For the PCI cards most times a link
down/up cycle will fix them.  It's a 2.4 v.s. 2.2 issue, the 2.2 kernels aren't
exhibiting this error.

The PCI cards are hard to get into this state, sometimes they'll run millions of
packets for months on end before they'll burp.  Sometimes it'll happen three
times a night.  The amount of traffic doesn't seem to matter, nor does the type
of traffic.

00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
        Subsystem: Netgear FA310TX
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 set
        Interrupt: pin A routed to IRQ 9
        Region 0: I/O ports at 6400 [size=256]
        Region 1: Memory at e4000000 (32-bit, non-prefetchable) [size=256]
        Expansion ROM at <unassigned> [disabled] [size=256K]


I say increasingly common because the more machines I bring on with 2.4 v.s. 2.3
or testNN kernels, the more the systems burp on this.  I.e. a kernel from 6
months ago takes 2-3 months to burp.  Last week's kernel burps once a week.

-d

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

Re: NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[Matti Aarnio]

On Tue, Jan 23, 2001 at 10:48:16AM +0000, David Ford wrote:
> The three cardbus cards are slightly different in numerous ways.  For
> them they normally fault with an APM event, an eject/insert cycle via
> software will reset hem and a link down/up won't fix it.  For the PCI
> cards most times a link down/up cycle will fix them.  It's a 2.4 v.s. 2.2
> issue, the 2.2 kernels aren't exhibiting this error.

	I see that with my AT2800TX cardbus card as well.
	(Using Tulip driver, no less.)

> The PCI cards are hard to get into this state, sometimes they'll run
> millions of packets for months on end before they'll burp.  Sometimes
> it'll happen three times a night.  The amount of traffic doesn't seem
> to matter, nor does the type of traffic.

	Sounds like timing issue.

> -d

/Matti Aarnio
-
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: NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[David Ford]

Matti Aarnio wrote:

> On Tue, Jan 23, 2001 at 10:48:16AM +0000, David Ford wrote:
> > The three cardbus cards are slightly different in numerous ways.  For
> > them they normally fault with an APM event, an eject/insert cycle via
> > software will reset hem and a link down/up won't fix it.  For the PCI
> > cards most times a link down/up cycle will fix them.  It's a 2.4 v.s. 2.2
> > issue, the 2.2 kernels aren't exhibiting this error.
>
>         I see that with my AT2800TX cardbus card as well.
>         (Using Tulip driver, no less.)
>
> > The PCI cards are hard to get into this state, sometimes they'll run
> > millions of packets for months on end before they'll burp.  Sometimes
> > it'll happen three times a night.  The amount of traffic doesn't seem
> > to matter, nor does the type of traffic.
>
>         Sounds like timing issue.

Hmm, should we class these as two similar but different bugs?  I suspect they
are both timing but there is another stimulus operating differently.

-d

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

Re: NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[Matti Aarnio]

On Tue, Jan 23, 2001 at 11:13:48AM +0000, David Ford wrote:
> > > The three cardbus cards are slightly different in numerous ways.  For
> > > them they normally fault with an APM event, an eject/insert cycle via
> > > software will reset hem and a link down/up won't fix it.  For the PCI
....
> > > The PCI cards are hard to get into this state, sometimes they'll run
> > > millions of packets for months on end before they'll burp.  Sometimes
> > > it'll happen three times a night.  The amount of traffic doesn't seem
> > > to matter, nor does the type of traffic.
> >
> >         Sounds like timing issue.
> 
> Hmm, should we class these as two similar but different bugs?  I suspect they
> are both timing but there is another stimulus operating differently.

  I think they are separate problems.
  The first is power-management suspend/resume issue, and possibly
  PCMCIA problem at software re-insert of card (which never was taken
  out *physically*).

  If I pull the cardbus card out, make sure the  "dhcpcd eth0" has
  died (e.g. I kill it), and re-insert the card, system is highly
  likely to work.

  It is just that if I suspend my laptop with card in, and wakeup it
  latter, there I encounter dead network card.


  Hangup/barfing on system which never suspends will never excercise
  suspend/resume codepaths, but may poke at wrong moment at some register,
  which causes card severe indigestion problems - rx/tx hangup.

  Sadly a "100% Compatible" usually means: "beware odd problems"

> -d

/Matti Aarnio
-
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: NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[David Ford]

Matti Aarnio wrote:

>   I think they are separate problems.
>   The first is power-management suspend/resume issue, and possibly
>   PCMCIA problem at software re-insert of card (which never was taken
>   out *physically*).
>
>   If I pull the cardbus card out, make sure the  "dhcpcd eth0" has
>   died (e.g. I kill it), and re-insert the card, system is highly
>   likely to work.

In my cardbus instance, a simple cardctl eject/insert is sufficient, I don't need
to manually cycle it.

-d

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

Re: 2.4.1-test10

[Marcelo Tosatti]

On Tue, 23 Jan 2001, Andre Hedrick wrote:

> Just my nickel on the issue.

Andre, 

This patch I'm talking about is for a different issue from what was
discussed in the IO clustering thread.


-
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: NETDEV timeout on tulips [was: Re: 2.4.1-test10]

[Jeff Garzik]

David Ford wrote:
> 
> > > Do the tulip driver updates address the increasingly common NETDEV timeout
> > > repots?
> >
> > In general you can answer this yourself by reading
> > drivers/net/tulip/ChangeLog.
> >
> > I don't see increasingly common timeout reports.. with which hardware?
> > They are likely on the newer LinkSys 4.1 cards, and there are still
> > problesm with PNIC.  Outside of that, other cards should be ok.
> 
> I have four machines now that exhibit this problem.  Three have in them the
> Linksys card family, similar PCI cards, one is my laptop which I have three
> different cardbus cards but they all use the tulip driver.
> 
> In the PCI situation, not all machines using these cards act the same way.
> I got a 10 pack of LNE100TX cards and so far only two out of the batch are doing
> this, they are all the same revision, identical in every way that I've found.
> 
> The three cardbus cards are slightly different in numerous ways.  For them they
> normally fault with an APM event, an eject/insert cycle via software will reset
> them and a link down/up won't fix it.  For the PCI cards most times a link
> down/up cycle will fix them.  It's a 2.4 v.s. 2.2 issue, the 2.2 kernels aren't
> exhibiting this error.

Sounds like the PCI PM state is getting mangled.  Can you provide a
"lspci -vvv", as root, for each of the three cardbus cards?  Make sure
to run lspci when the cards are up and active and working.


> The PCI cards are hard to get into this state, sometimes they'll run millions of
> packets for months on end before they'll burp.  Sometimes it'll happen three
> times a night.  The amount of traffic doesn't seem to matter, nor does the type
> of traffic.
> 

> 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
>         Subsystem: Netgear FA310TX

If the link is getting lost (which may explain the randomness of the
error), the following patch might help: 
http://sourceforge.net/patch/?func=detailpatch&patch_id=103294&group_id=13004

There are still some media fixes that need to be integrated from the
Becker driver, and tested, too.

Also, downloading tulip-diag.c and capturing the register state before
and after the breakage is useful.  A useful command line is "tulip-diag
-mmmaaavvveef".

	Jeff


-- 
Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie
-
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.1-test10

[Linus Torvalds]

On Tue, 23 Jan 2001, Marcelo Tosatti wrote:
> 
> Any technical reason why the background page aging fix was not applied?

Because I have not heard anybody claim that it makes a huge difference..

		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.1-test10

[Andre Hedrick]

On Tue, 23 Jan 2001, Linus Torvalds wrote:

> 
> 
> On Tue, 23 Jan 2001, Marcelo Tosatti wrote:
> > 
> > Any technical reason why the background page aging fix was not applied?
> 
> Because I have not heard anybody claim that it makes a huge difference..

Linus,

If it could help speed up the page_list movements because of what appears
to be an offset seek and step direction, thus it is referrence frame for
find these pages is local.  The local reference frame could/should be tied
back to either the head or tail of the page_list for track purposes.

The idea is if we can keep ahead of the laundry list, we may avoid crunch
time in the event that a request of a huge chunk is requested and the busy
beaver has quietly gotten most of the needed pages prepared.  Thus the
possible system-wide delay that can occur may be minimized.

Obviously if you have several big request you get slapped hard.

The point may be that if we have some extra cycles spinning, why not use
them to a painful task when it will not hurt as much?

Just my nickel on the issue.

Cheers,

Andre Hedrick
Linux ATA Development

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

Under 2.4.0 I can mount same partition twice.

[Dan Graham]

Hello;
  I don't know if this is a bug or a feature.  While I was
playing around with 2.4.0 I (mistakenly) mounted an ext2
partition twice.  

The excerpt from mount looks like this.
/dev/hda1 on /a1 type ext2 (rw)
/dev/hda1 on /mnt type ext2 (rw)

Under 2.2.13 I get 

mount: /dev/hda1 already mounted or /mnt busy
mount: according to mtab, /dev/hda1 is mounted on /a1

Is this a bug or a feature? 

System is an ABIT VP6, dual PIII 733Mhz, 1gb RAM, 
30g ATA 100 drive, IBM Deskstar.  DMA is on.

Dan 
graham@balance.uoregon.edu


-
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: Under 2.4.0 I can mount same partition twice.

[Andreas Dilger]

Dan Graham writes:
>   I don't know if this is a bug or a feature.  While I was
> playing around with 2.4.0 I (mistakenly) mounted an ext2
> partition twice.  

Feature.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
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/