* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
@ 2002-03-11 22:40 ` Eyal Lebedinsky
2002-03-11 23:03 ` Alan Cox
2002-03-11 22:55 ` Stephan von Krawczynski
` (9 subsequent siblings)
10 siblings, 1 reply; 43+ messages in thread
From: Eyal Lebedinsky @ 2002-03-11 22:40 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
Marcelo Tosatti wrote:
>
> Hi,
>
> Here goes -pre3, with the new IDE code. It has been stable enough time in
ld -m elf_i386 -r -o ide-mod.o ide.o ide-features.o ide-taskfile.o
aec62xx.o alim15x3.o amd74xx.o cmd640.o cmd64x.o cs5530.o cy82c693.o
hpt34x.o hpt366.o ide-adma.o ide-dma.o ide-pci.o ns87415.o opti621.o
serverworks.o pdc202xx.o pdcadma.o piix.o rz1000.o sis5513.o slc90e66.o
trm290.o via82cxxx.o ide-proc.o
ld: cannot open pdcadma.o: No such file or directory
make[3]: *** [ide-mod.o] Error 1
make[3]: Leaving directory
`/data2/usr/local/src/linux-2.4-pre/drivers/ide'
--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-11 22:40 ` Eyal Lebedinsky
@ 2002-03-11 23:03 ` Alan Cox
0 siblings, 0 replies; 43+ messages in thread
From: Alan Cox @ 2002-03-11 23:03 UTC (permalink / raw)
To: Eyal Lebedinsky; +Cc: Marcelo Tosatti, lkml
> aec62xx.o alim15x3.o amd74xx.o cmd640.o cmd64x.o cs5530.o cy82c693.o
> hpt34x.o hpt366.o ide-adma.o ide-dma.o ide-pci.o ns87415.o opti621.o
> serverworks.o pdc202xx.o pdcadma.o piix.o rz1000.o sis5513.o slc90e66.o
> trm290.o via82cxxx.o ide-proc.o
> ld: cannot open pdcadma.o: No such file or directory
Interesting. That option should not be selectable. Try this
--- drivers/ide/Config.in~ Sat Mar 2 00:49:03 2002
+++ drivers/ide/Config.in Mon Mar 11 22:43:57 2002
@@ -82,7 +82,7 @@
fi
dep_bool ' NS87415 chipset support (EXPERIMENTAL)' CONFIG_BLK_DEV_NS87415 $CONFIG_BLK_DEV_IDEDMA_PCI $CONFIG_EXPERIMENTAL
dep_bool ' OPTi 82C621 chipset enhanced support (EXPERIMENTAL)' CONFIG_BLK_DEV_OPTI621 $CONFIG_EXPERIMENTAL
- dep_mbool ' Pacific Digital A-DMA support (EXPERIMENTAL)' CONFIG_BLK_DEV_PDC_ADMA $CONFIG_BLK_DEV_ADMA $CONFIG_IDEDMA_PCI_WIP $CONFIG_EXPERIMENTAL
+# dep_mbool ' Pacific Digital A-DMA support (EXPERIMENTAL)' CONFIG_BLK_DEV_PDC_ADMA $CONFIG_BLK_DEV_ADMA $CONFIG_IDEDMA_PCI_WIP $CONFIG_EXPERIMENTAL
dep_bool ' PROMISE PDC202{46|62|65|67|68|69|70} support' CONFIG_BLK_DEV_PDC202XX $CONFIG_BLK_DEV_IDEDMA_PCI
dep_bool ' Special UDMA Feature' CONFIG_PDC202XX_BURST $CONFIG_BLK_DEV_PDC202XX
dep_bool ' Special FastTrak Feature' CONFIG_PDC202XX_FORCE $CONFIG_BLK_DEV_PDC202XX
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
2002-03-11 22:40 ` Eyal Lebedinsky
@ 2002-03-11 22:55 ` Stephan von Krawczynski
2002-03-12 1:50 ` Mike Fedyk
2002-03-12 11:06 ` Stephan von Krawczynski
2002-03-11 23:04 ` Eyal Lebedinsky
` (8 subsequent siblings)
10 siblings, 2 replies; 43+ messages in thread
From: Stephan von Krawczynski @ 2002-03-11 22:55 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
>
> Hi,
>
> Here goes -pre3, with the new IDE code. It has been stable enough
time in
> the -ac tree, in my and Alan's opinion.
>
> The inclusion of the new IDE code makes me want to have a longer
2.4.19
> release cycle, for stress-testing reasons.
>
> Please stress test it with huge amounts of data ;)
Would like to, but:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.19-pre3/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -DMODULE -DKBUILD_BASENAME=pppoe -c -o pppoe.o pppoe.c
pppoe.c: In function `pppoe_flush_dev':
pppoe.c:282: `PPPOX_ZOMBIE' undeclared (first use in this function)
pppoe.c:282: (Each undeclared identifier is reported only once
pppoe.c:282: for each function it appears in.)
pppoe.c: In function `pppoe_disc_rcv':
pppoe.c:446: `PPPOX_ZOMBIE' undeclared (first use in this function)
pppoe.c: In function `pppoe_ioctl':
pppoe.c:730: `PPPOX_ZOMBIE' undeclared (first use in this function)
make[2]: *** [pppoe.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.4.19-pre3/drivers/net'
make[1]: *** [_modsubdir_net] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.19-pre3/drivers'
make: *** [_mod_drivers] Error 2
Regards,
Stephan
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-11 22:55 ` Stephan von Krawczynski
@ 2002-03-12 1:50 ` Mike Fedyk
2002-03-12 11:06 ` Stephan von Krawczynski
1 sibling, 0 replies; 43+ messages in thread
From: Mike Fedyk @ 2002-03-12 1:50 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Marcelo Tosatti, lkml
On Mon, Mar 11, 2002 at 11:55:23PM +0100, Stephan von Krawczynski wrote:
> >
> > Hi,
> >
> > Here goes -pre3, with the new IDE code. It has been stable enough
> time in
> > the -ac tree, in my and Alan's opinion.
> >
> > The inclusion of the new IDE code makes me want to have a longer
> 2.4.19
> > release cycle, for stress-testing reasons.
> >
> > Please stress test it with huge amounts of data ;)
>
> Would like to, but:
>
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.19-pre3/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -DMODULE -DKBUILD_BASENAME=pppoe -c -o pppoe.o pppoe.c
> pppoe.c: In function `pppoe_flush_dev':
> pppoe.c:282: `PPPOX_ZOMBIE' undeclared (first use in this function)
> pppoe.c:282: (Each undeclared identifier is reported only once
> pppoe.c:282: for each function it appears in.)
> pppoe.c: In function `pppoe_disc_rcv':
> pppoe.c:446: `PPPOX_ZOMBIE' undeclared (first use in this function)
> pppoe.c: In function `pppoe_ioctl':
> pppoe.c:730: `PPPOX_ZOMBIE' undeclared (first use in this function)
> make[2]: *** [pppoe.o] Error 1
> make[2]: Leaving directory `/usr/src/linux-2.4.19-pre3/drivers/net'
> make[1]: *** [_modsubdir_net] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.4.19-pre3/drivers'
> make: *** [_mod_drivers] Error 2
same here, with gcc 2.95.4 (debian -woody).
What is your compiler version (in case it's 3.x)?
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-11 22:55 ` Stephan von Krawczynski
2002-03-12 1:50 ` Mike Fedyk
@ 2002-03-12 11:06 ` Stephan von Krawczynski
1 sibling, 0 replies; 43+ messages in thread
From: Stephan von Krawczynski @ 2002-03-12 11:06 UTC (permalink / raw)
To: Mike Fedyk; +Cc: marcelo, linux-kernel
On Mon, 11 Mar 2002 17:50:59 -0800
Mike Fedyk <mfedyk@matchmail.com> wrote:
> On Mon, Mar 11, 2002 at 11:55:23PM +0100, Stephan von Krawczynski wrote:
> > >
> > > Hi,
> > >
> > > Here goes -pre3, with the new IDE code. It has been stable enough
> > time in
> > > the -ac tree, in my and Alan's opinion.
> > >
> > > The inclusion of the new IDE code makes me want to have a longer
> > 2.4.19
> > > release cycle, for stress-testing reasons.
> > >
> > > Please stress test it with huge amounts of data ;)
> >
> > Would like to, but:
> >
> > gcc -D__KERNEL__ -I/usr/src/linux-2.4.19-pre3/include -Wall
> > [...]
> > make[2]: *** [pppoe.o] Error 1
> > make[2]: Leaving directory `/usr/src/linux-2.4.19-pre3/drivers/net'
> > make[1]: *** [_modsubdir_net] Error 2
> > make[1]: Leaving directory `/usr/src/linux-2.4.19-pre3/drivers'
> > make: *** [_mod_drivers] Error 2
>
> same here, with gcc 2.95.4 (debian -woody).
>
> What is your compiler version (in case it's 3.x)?
gcc version 2.95.3 20010315 (SuSE)
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
2002-03-11 22:40 ` Eyal Lebedinsky
2002-03-11 22:55 ` Stephan von Krawczynski
@ 2002-03-11 23:04 ` Eyal Lebedinsky
2002-03-11 23:14 ` Keith Owens
` (2 more replies)
2002-03-11 23:21 ` Linux 2.4.19-pre3 Eyal Lebedinsky
` (7 subsequent siblings)
10 siblings, 3 replies; 43+ messages in thread
From: Eyal Lebedinsky @ 2002-03-11 23:04 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
Marcelo Tosatti wrote:
>
> Hi,
>
> Here goes -pre3, with the new IDE code. It has been stable enough time in
gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-pre/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -malign-functions=4 -DMODULE -DMODVERSIONS -include
/data2/usr/local/src/linux-2.4-pre/include/linux/modversions.h
-DKBUILD_BASENAME=indydog -c -o indydog.o indydog.c
indydog.c:25: asm/sgi/sgimc.h: No such file or directory
indydog.c:31: warning: function declaration isn't a prototype
indydog.c: In function `indydog_ping':
indydog.c:32: dereferencing pointer to incomplete type
indydog.c: In function `indydog_open':
indydog.c:52: `KSEG1' undeclared (first use in this function)
indydog.c:52: (Each undeclared identifier is reported only once
indydog.c:52: for each function it appears in.)
indydog.c:54: dereferencing pointer to incomplete type
indydog.c:54: `SGIMC_CCTRL0_WDOG' undeclared (first use in this
function)
indydog.c:55: dereferencing pointer to incomplete type
indydog.c: In function `indydog_release':
indydog.c:72: dereferencing pointer to incomplete type
indydog.c:73: `SGIMC_CCTRL0_WDOG' undeclared (first use in this
function)
indydog.c:74: dereferencing pointer to incomplete type
make[2]: *** [indydog.o] Error 1
make[2]: Leaving directory
`/data2/usr/local/src/linux-2.4-pre/drivers/char'
Now, I am on an i386 machine, and indydog.c looks like a foreign object
here.
Since I automatically select 'm' for all offered options (just for
testing)
I guess we have a bad dependency in the watchdog config (but I am only
guessing):
dep_tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG
$CONFIG_SGI_IP22
Looks OK to me though. However CONFIG_SGI_IP22 is not set anywhere,
should
dep_tristate treat it as FALSE?
--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-11 23:04 ` Eyal Lebedinsky
@ 2002-03-11 23:14 ` Keith Owens
2002-03-12 15:49 ` DevilKin
2002-03-21 12:06 ` [patch] Don't offer CONFIG_INDYDOG on non-ip22 machines Adrian Bunk
2 siblings, 0 replies; 43+ messages in thread
From: Keith Owens @ 2002-03-11 23:14 UTC (permalink / raw)
To: Eyal Lebedinsky; +Cc: Marcelo Tosatti, lkml
On Tue, 12 Mar 2002 10:04:42 +1100,
Eyal Lebedinsky <eyal@eyal.emu.id.au> wrote:
> dep_tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG
>$CONFIG_SGI_IP22
>
>Looks OK to me though. However CONFIG_SGI_IP22 is not set anywhere,
>should
>dep_tristate treat it as FALSE?
That is a restriction on CML1, particularly when using any of the
config options that rely on shell scripts. CONFIG_SGI_IP22 is
undefined for i386 and the shell converts $CONFIG_SGI_IP22 to blank,
before CML1 even sees it. Doing dep_* on options that might be
undefined is unreliable. This works :-
if [ "$CONFIG_SGI_IP22" = "y" ]; then
tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG
fi
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-11 23:04 ` Eyal Lebedinsky
2002-03-11 23:14 ` Keith Owens
@ 2002-03-12 15:49 ` DevilKin
2002-03-21 12:06 ` [patch] Don't offer CONFIG_INDYDOG on non-ip22 machines Adrian Bunk
2 siblings, 0 replies; 43+ messages in thread
From: DevilKin @ 2002-03-12 15:49 UTC (permalink / raw)
To: linux-kernel
Marcelo Tosatti wrote:
> Hi,
>
> Here goes -pre3, with the new IDE code. It has been stable enough time in
Compiles fine here. Is there any way how we should notice that these new
structures are being used? (proc interface/ ... whatever)
DK
^ permalink raw reply [flat|nested] 43+ messages in thread
* [patch] Don't offer CONFIG_INDYDOG on non-ip22 machines
2002-03-11 23:04 ` Eyal Lebedinsky
2002-03-11 23:14 ` Keith Owens
2002-03-12 15:49 ` DevilKin
@ 2002-03-21 12:06 ` Adrian Bunk
2002-03-22 21:13 ` Marcelo Tosatti
2 siblings, 1 reply; 43+ messages in thread
From: Adrian Bunk @ 2002-03-21 12:06 UTC (permalink / raw)
To: Eyal Lebedinsky; +Cc: Marcelo Tosatti, lkml
On Tue, 12 Mar 2002, Eyal Lebedinsky wrote:
> gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-pre/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -malign-functions=4 -DMODULE -DMODVERSIONS -include
> /data2/usr/local/src/linux-2.4-pre/include/linux/modversions.h
> -DKBUILD_BASENAME=indydog -c -o indydog.o indydog.c
> indydog.c:25: asm/sgi/sgimc.h: No such file or directory
> indydog.c:31: warning: function declaration isn't a prototype
> indydog.c: In function `indydog_ping':
> indydog.c:32: dereferencing pointer to incomplete type
> indydog.c: In function `indydog_open':
> indydog.c:52: `KSEG1' undeclared (first use in this function)
> indydog.c:52: (Each undeclared identifier is reported only once
> indydog.c:52: for each function it appears in.)
> indydog.c:54: dereferencing pointer to incomplete type
> indydog.c:54: `SGIMC_CCTRL0_WDOG' undeclared (first use in this
> function)
> indydog.c:55: dereferencing pointer to incomplete type
> indydog.c: In function `indydog_release':
> indydog.c:72: dereferencing pointer to incomplete type
> indydog.c:73: `SGIMC_CCTRL0_WDOG' undeclared (first use in this
> function)
> indydog.c:74: dereferencing pointer to incomplete type
> make[2]: *** [indydog.o] Error 1
> make[2]: Leaving directory
> `/data2/usr/local/src/linux-2.4-pre/drivers/char'
>
>
> Now, I am on an i386 machine, and indydog.c looks like a foreign object
> here.
> Since I automatically select 'm' for all offered options (just for
> testing)
> I guess we have a bad dependency in the watchdog config (but I am only
> guessing):
>
> dep_tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG
> $CONFIG_SGI_IP22
>
> Looks OK to me though. However CONFIG_SGI_IP22 is not set anywhere,
> should
> dep_tristate treat it as FALSE?
After reading Documentation/kbuild/config-language.txt it seems that this
should work in theory...
The following patch fixes it so that it works for me:
--- drivers/char/Config.in.old Thu Mar 21 12:48:57 2002
+++ drivers/char/Config.in Thu Mar 21 13:01:21 2002
@@ -201,7 +201,9 @@
tristate ' SBC-60XX Watchdog Timer' CONFIG_60XX_WDT
tristate ' W83877F (EMACS) Watchdog Timer' CONFIG_W83877F_WDT
tristate ' ZF MachZ Watchdog' CONFIG_MACHZ_WDT
- dep_tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG $CONFIG_SGI_IP22
+ if [ "$CONFIG_SGI_IP22" = "y" ]; then
+ tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG
+ fi
fi
endmenu
cu
Adrian
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [patch] Don't offer CONFIG_INDYDOG on non-ip22 machines
2002-03-21 12:06 ` [patch] Don't offer CONFIG_INDYDOG on non-ip22 machines Adrian Bunk
@ 2002-03-22 21:13 ` Marcelo Tosatti
0 siblings, 0 replies; 43+ messages in thread
From: Marcelo Tosatti @ 2002-03-22 21:13 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Eyal Lebedinsky, lkml
On Thu, 21 Mar 2002, Adrian Bunk wrote:
> After reading Documentation/kbuild/config-language.txt it seems that this
> should work in theory...
>
> The following patch fixes it so that it works for me:
>
> --- drivers/char/Config.in.old Thu Mar 21 12:48:57 2002
> +++ drivers/char/Config.in Thu Mar 21 13:01:21 2002
> @@ -201,7 +201,9 @@
> tristate ' SBC-60XX Watchdog Timer' CONFIG_60XX_WDT
> tristate ' W83877F (EMACS) Watchdog Timer' CONFIG_W83877F_WDT
> tristate ' ZF MachZ Watchdog' CONFIG_MACHZ_WDT
> - dep_tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG $CONFIG_SGI_IP22
> + if [ "$CONFIG_SGI_IP22" = "y" ]; then
> + tristate ' Indy/I2 Hardware Watchdog' CONFIG_INDYDOG
> + fi
> fi
> endmenu
>
Applied...
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
` (2 preceding siblings ...)
2002-03-11 23:04 ` Eyal Lebedinsky
@ 2002-03-11 23:21 ` Eyal Lebedinsky
2002-03-12 1:40 ` Takeo Saito
2002-03-12 0:04 ` J.A. Magallon
` (6 subsequent siblings)
10 siblings, 1 reply; 43+ messages in thread
From: Eyal Lebedinsky @ 2002-03-11 23:21 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
Marcelo Tosatti wrote:
>
> Hi,
>
> Here goes -pre3, with the new IDE code. It has been stable enough time in
> the -ac tree, in my and Alan's opinion.
gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-pre/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -malign-functions=4 -DMODULE -DMODVERSIONS -include
/data2/usr/local/src/linux-2.4-pre/include/linux/modversions.h
-DKBUILD_BASENAME=pppoe -c -o pppoe.o pppoe.c
pppoe.c: In function `pppoe_flush_dev':
pppoe.c:282: `PPPOX_ZOMBIE' undeclared (first use in this function)
pppoe.c:282: (Each undeclared identifier is reported only once
pppoe.c:282: for each function it appears in.)
pppoe.c: In function `pppoe_disc_rcv':
pppoe.c:446: `PPPOX_ZOMBIE' undeclared (first use in this function)
pppoe.c: In function `pppoe_ioctl':
pppoe.c:730: `PPPOX_ZOMBIE' undeclared (first use in this function)
make[2]: *** [pppoe.o] Error 1
make[2]: Leaving directory
`/data2/usr/local/src/linux-2.4-pre/drivers/net'
For me this makes it the third strike, so pre3 is out :-) Got to go
to work now.
--
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-11 23:21 ` Linux 2.4.19-pre3 Eyal Lebedinsky
@ 2002-03-12 1:40 ` Takeo Saito
0 siblings, 0 replies; 43+ messages in thread
From: Takeo Saito @ 2002-03-12 1:40 UTC (permalink / raw)
To: Eyal Lebedinsky, Marcelo Tosatti; +Cc: lkml
Hi,
I think lost patch bellow:
--- linux-2.4.18-pre8/include/linux/if_pppox.h Thu Nov 22 14:47:14 2001
+++ linux/include/linux/if_pppox.h Fri Jan 25 07:39:15 2002
@@ -126,13 +126,14 @@
extern int pppox_channel_ioctl(struct ppp_channel *pc, unsigned int cmd,
unsigned long arg);
-/* PPPoE socket states */
+/* PPPoX socket states */
enum {
PPPOX_NONE = 0, /* initial state */
PPPOX_CONNECTED = 1, /* connection established ==TCP_ESTABLISHED */
PPPOX_BOUND = 2, /* bound to ppp device */
PPPOX_RELAY = 4, /* forwarding is enabled */
- PPPOX_DEAD = 8
+ PPPOX_ZOMBIE = 8, /* dead, but still bound to ppp device */
+ PPPOX_DEAD = 16 /* dead, useless, please clean me up!*/
};
extern struct ppp_channel_ops pppoe_chan_ops;
Best Regrads,
Takeo Tung
Diyixian.Com Litmited Taiwan branch
----- Original Message -----
From: "Eyal Lebedinsky" <eyal@eyal.emu.id.au>
To: "Marcelo Tosatti" <marcelo@conectiva.com.br>
Cc: "lkml" <linux-kernel@vger.kernel.org>
Sent: Tuesday, March 12, 2002 7:21 AM
Subject: Re: Linux 2.4.19-pre3
> Marcelo Tosatti wrote:
> >
> > Hi,
> >
> > Here goes -pre3, with the new IDE code. It has been stable enough time
in
> > the -ac tree, in my and Alan's opinion.
>
> gcc -D__KERNEL__ -I/data2/usr/local/src/linux-2.4-pre/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -malign-functions=4 -DMODULE -DMODVERSIONS -include
> /data2/usr/local/src/linux-2.4-pre/include/linux/modversions.h
> -DKBUILD_BASENAME=pppoe -c -o pppoe.o pppoe.c
> pppoe.c: In function `pppoe_flush_dev':
> pppoe.c:282: `PPPOX_ZOMBIE' undeclared (first use in this function)
> pppoe.c:282: (Each undeclared identifier is reported only once
> pppoe.c:282: for each function it appears in.)
> pppoe.c: In function `pppoe_disc_rcv':
> pppoe.c:446: `PPPOX_ZOMBIE' undeclared (first use in this function)
> pppoe.c: In function `pppoe_ioctl':
> pppoe.c:730: `PPPOX_ZOMBIE' undeclared (first use in this function)
> make[2]: *** [pppoe.o] Error 1
> make[2]: Leaving directory
> `/data2/usr/local/src/linux-2.4-pre/drivers/net'
>
> For me this makes it the third strike, so pre3 is out :-) Got to go
> to work now.
>
> --
> Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
` (3 preceding siblings ...)
2002-03-11 23:21 ` Linux 2.4.19-pre3 Eyal Lebedinsky
@ 2002-03-12 0:04 ` J.A. Magallon
2002-03-12 0:37 ` Ken Brownfield
` (5 subsequent siblings)
10 siblings, 0 replies; 43+ messages in thread
From: J.A. Magallon @ 2002-03-12 0:04 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
On 2002.03.11 Marcelo Tosatti wrote:
>
>Hi,
>
>Please stress test it with huge amounts of data ;)
>
>pre3:
>
>- aic7xxx update (Justin T. Gibbs)
>- Do not consider SCSI recovered errors as fatal errors (Justin T. Gibbs)
Sure ?
werewolf:~/soft/kernel# grep aic7xxx patch-2.4.19-pre3
diff -Naur -X /home/marcelo/lib/dontdiff linux.orig/drivers/scsi/aic7xxx/aic7xxx.c linux/drivers/scsi/aic7xxx/aic7xxx.c
--- linux.orig/drivers/scsi/aic7xxx/aic7xxx.c Thu Oct 25 20:53:48 2001
+++ linux/drivers/scsi/aic7xxx/aic7xxx.c Thu Feb 28 17:50:49 2002
Just this hunk is present:
diff -Naur -X /home/marcelo/lib/dontdiff linux.orig/drivers/scsi/aic7xxx/aic7xxx.c linux/drivers/scsi/aic7xxx/aic7xxx.c
--- linux.orig/drivers/scsi/aic7xxx/aic7xxx.c Thu Oct 25 20:53:48 2001
+++ linux/drivers/scsi/aic7xxx/aic7xxx.c Thu Feb 28 17:50:49 2002
@@ -2584,7 +2584,7 @@
/*
* Read the latched byte, but turn off SPIOEN first
- * so that we don't inadvertantly cause a REQ for the
+ * so that we don't inadvertently cause a REQ for the
* next byte.
*/
ahc_outb(ahc, SXFRCTL0, ahc_inb(ahc, SXFRCTL0) & ~SPIOEN);
Nice update ;)...
BTW, this applies cleanly:
http://giga.cps.unizar.es/~magallon/linux/kernel/2.4.19-pre2-jam5/30-aic7xxx-6.2.5.gz
--
J.A. Magallon # Let the source be with you...
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.19-pre2-jam5 #1 SMP Mon Mar 11 16:08:11 CET 2002 i686
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
` (4 preceding siblings ...)
2002-03-12 0:04 ` J.A. Magallon
@ 2002-03-12 0:37 ` Ken Brownfield
2002-03-19 2:41 ` I/O APIC fixed in 2.4.19-pre3 & 2.5.6 (was Re: Linux 2.4.19-pre3) Ken Brownfield
2002-03-12 10:35 ` Linux 2.4.19-pre3 Gerd Knorr
` (4 subsequent siblings)
10 siblings, 1 reply; 43+ messages in thread
From: Ken Brownfield @ 2002-03-12 0:37 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
Can the authors of this patch post separately on what is fixed here? I
apply the following patch to work around an eventual hang of the machine
due to IRQ0 being "attached" to the IO APIC, and I'm hoping that this
2.4.19-pre3 patch fixes my problem the correct way. V.s. my workaround
hack.
Thanks much,
--
Ken.
brownfld@irridia.com
On Mon, Mar 11, 2002 at 06:08:19PM -0300, Marcelo Tosatti wrote:
| - Fix through-8259A mode for IRQ0 routing on APIC (Maciej W. Rozycki/Joe Korty)
--- linux/arch/i386/kernel/io_apic.c.orig Tue Nov 13 17:28:41 2001
+++ linux/arch/i386/kernel/io_apic.c Tue Dec 18 15:10:45 2001
@@ -172,6 +172,7 @@
int pirq_entries [MAX_PIRQS];
int pirqs_enabled;
int skip_ioapic_setup;
+int pintimer_setup;
static int __init ioapic_setup(char *str)
{
@@ -179,7 +180,14 @@
return 1;
}
+static int __init do_pintimer_setup(char *str)
+{
+ pintimer_setup = 1;
+ return 1;
+}
+
__setup("noapic", ioapic_setup);
+__setup("pintimer", do_pintimer_setup);
static int __init ioapic_pirq_setup(char *str)
{
@@ -1524,27 +1532,31 @@
printk(KERN_ERR "..MP-BIOS bug: 8254 timer not connected to IO-APIC\n");
}
- printk(KERN_INFO "...trying to set up timer (IRQ0) through the 8259A ... ");
- if (pin2 != -1) {
- printk("\n..... (found pin %d) ...", pin2);
- /*
- * legacy devices should be connected to IO APIC #0
- */
- setup_ExtINT_IRQ0_pin(pin2, vector);
- if (timer_irq_works()) {
- printk("works.\n");
- if (nmi_watchdog == NMI_IO_APIC) {
- setup_nmi();
- check_nmi_watchdog();
+ if ( pintimer_setup )
+ printk(KERN_INFO "...skipping 8259A init for IRQ0\n");
+ else {
+ printk(KERN_INFO "...trying to set up timer (IRQ0) through the 8259A ... ");
+ if (pin2 != -1) {
+ printk("\n..... (found pin %d) ...", pin2);
+ /*
+ * legacy devices should be connected to IO APIC #0
+ */
+ setup_ExtINT_IRQ0_pin(pin2, vector);
+ if (timer_irq_works()) {
+ printk("works.\n");
+ if (nmi_watchdog == NMI_IO_APIC) {
+ setup_nmi();
+ check_nmi_watchdog();
+ }
+ return;
}
- return;
+ /*
+ * Cleanup, just in case ...
+ */
+ clear_IO_APIC_pin(0, pin2);
}
- /*
- * Cleanup, just in case ...
- */
- clear_IO_APIC_pin(0, pin2);
+ printk(" failed.\n");
}
- printk(" failed.\n");
if (nmi_watchdog) {
printk(KERN_WARNING "timer doesnt work through the IO-APIC - disabling NMI Watchdog!\n");
^ permalink raw reply [flat|nested] 43+ messages in thread* I/O APIC fixed in 2.4.19-pre3 & 2.5.6 (was Re: Linux 2.4.19-pre3)
2002-03-12 0:37 ` Ken Brownfield
@ 2002-03-19 2:41 ` Ken Brownfield
2002-03-19 16:22 ` Bill Davidsen
0 siblings, 1 reply; 43+ messages in thread
From: Ken Brownfield @ 2002-03-19 2:41 UTC (permalink / raw)
To: marcelo, macro, manfred, alan, torvalds, mhunter; +Cc: lkml
As a followup, this APIC patch also prevents 2.4 machines on quite a bit
of common hardware from freezing up after a few hours to a few days of
production use. Especially ServerWorks boards distributed by HP and
Rackable/Tyan.
This patch (applied to 2.4.18) seems to fix my long-standing (and
oft-mentioned on LKML) I/O APIC issue with all 2.4 kernels, and I no
longer need my "pintimer" patch to disable the through-8259A mode.
Kudos to the authors -- this was definitely a hard one to find, and I
expect a lot of people will have more stable machines because of it.
I'm also sending this to the folks who helped me with this issue in the
past.
Good work!
--
Ken.
ken@irridia.com
<macro@ds2.pg.gda.pl> (02/03/05 1.466.1.12)
[PATCH] 2.4.18, 2.5.5: I/O APIC through-8259A mode IRQ 0 routing
There is a problem with the through-8259A mode for IRQ 0 on I/O APIC
systems. Depending on correctness of an MP table, IRQ 0 routing is
either not registered at all or registered at a wrong pin. As a result
the 8254 timer IRQ only works by an accident (it's edge-triggered and
never disabled/enabled so it happens to survive this incorrect
configuration). A visible effect is you can't change the affinity for
IRQ 0. Following is a patch that fixes both cases referred to above.
The code looks obvious but it was additionally run-time tested just in
case. The issue is serious -- please apply the patch ASAP. As no
changes were done to io_apic.c since the development fork, the patch
applies cleanly both to 2.4 and to 2.5. Credit goes to Joe for
discovering the affinity problem and providing a fix proposal
(incorporated in the final one). Maciej
On Mon, Mar 11, 2002 at 06:37:46PM -0600, Ken Brownfield wrote:
| Can the authors of this patch post separately on what is fixed here? I
| apply the following patch to work around an eventual hang of the machine
| due to IRQ0 being "attached" to the IO APIC, and I'm hoping that this
| 2.4.19-pre3 patch fixes my problem the correct way. V.s. my workaround
| hack.
|
| Thanks much,
| --
| Ken.
| brownfld@irridia.com
|
| On Mon, Mar 11, 2002 at 06:08:19PM -0300, Marcelo Tosatti wrote:
| | - Fix through-8259A mode for IRQ0 routing on APIC (Maciej W. Rozycki/Joe Korty)
|
|
| --- linux/arch/i386/kernel/io_apic.c.orig Tue Nov 13 17:28:41 2001
| +++ linux/arch/i386/kernel/io_apic.c Tue Dec 18 15:10:45 2001
| @@ -172,6 +172,7 @@
| int pirq_entries [MAX_PIRQS];
| int pirqs_enabled;
| int skip_ioapic_setup;
| +int pintimer_setup;
|
| static int __init ioapic_setup(char *str)
| {
| @@ -179,7 +180,14 @@
| return 1;
| }
|
| +static int __init do_pintimer_setup(char *str)
| +{
| + pintimer_setup = 1;
| + return 1;
| +}
| +
| __setup("noapic", ioapic_setup);
| +__setup("pintimer", do_pintimer_setup);
|
| static int __init ioapic_pirq_setup(char *str)
| {
| @@ -1524,27 +1532,31 @@
| printk(KERN_ERR "..MP-BIOS bug: 8254 timer not connected to IO-APIC\n");
| }
|
| - printk(KERN_INFO "...trying to set up timer (IRQ0) through the 8259A ... ");
| - if (pin2 != -1) {
| - printk("\n..... (found pin %d) ...", pin2);
| - /*
| - * legacy devices should be connected to IO APIC #0
| - */
| - setup_ExtINT_IRQ0_pin(pin2, vector);
| - if (timer_irq_works()) {
| - printk("works.\n");
| - if (nmi_watchdog == NMI_IO_APIC) {
| - setup_nmi();
| - check_nmi_watchdog();
| + if ( pintimer_setup )
| + printk(KERN_INFO "...skipping 8259A init for IRQ0\n");
| + else {
| + printk(KERN_INFO "...trying to set up timer (IRQ0) through the 8259A ... ");
| + if (pin2 != -1) {
| + printk("\n..... (found pin %d) ...", pin2);
| + /*
| + * legacy devices should be connected to IO APIC #0
| + */
| + setup_ExtINT_IRQ0_pin(pin2, vector);
| + if (timer_irq_works()) {
| + printk("works.\n");
| + if (nmi_watchdog == NMI_IO_APIC) {
| + setup_nmi();
| + check_nmi_watchdog();
| + }
| + return;
| }
| - return;
| + /*
| + * Cleanup, just in case ...
| + */
| + clear_IO_APIC_pin(0, pin2);
| }
| - /*
| - * Cleanup, just in case ...
| - */
| - clear_IO_APIC_pin(0, pin2);
| + printk(" failed.\n");
| }
| - printk(" failed.\n");
|
| if (nmi_watchdog) {
| printk(KERN_WARNING "timer doesnt work through the IO-APIC - disabling NMI Watchdog!\n");
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: I/O APIC fixed in 2.4.19-pre3 & 2.5.6 (was Re: Linux 2.4.19-pre3)
2002-03-19 2:41 ` I/O APIC fixed in 2.4.19-pre3 & 2.5.6 (was Re: Linux 2.4.19-pre3) Ken Brownfield
@ 2002-03-19 16:22 ` Bill Davidsen
2002-03-20 0:34 ` Ken Brownfield
0 siblings, 1 reply; 43+ messages in thread
From: Bill Davidsen @ 2002-03-19 16:22 UTC (permalink / raw)
To: Ken Brownfield; +Cc: alan, torvalds, lkml
On Mon, 18 Mar 2002, Ken Brownfield wrote:
> As a followup, this APIC patch also prevents 2.4 machines on quite a bit
> of common hardware from freezing up after a few hours to a few days of
> production use. Especially ServerWorks boards distributed by HP and
> Rackable/Tyan.
>
> This patch (applied to 2.4.18) seems to fix my long-standing (and
> oft-mentioned on LKML) I/O APIC issue with all 2.4 kernels, and I no
> longer need my "pintimer" patch to disable the through-8259A mode.
Any chance this will cure the lockups on a Dell Latitude C600 every time
you exit X? I've disabled both the IO-APIC and APIC-uni, which was
supposed to fix the problem but didn't. Dare I hope that the disable
wasn't enough?
A quick google tells me other people have the same problem, but I
haven't seen a working solution yet. Nice machine other than needing to be
rebooted after every use of X :-(
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: I/O APIC fixed in 2.4.19-pre3 & 2.5.6 (was Re: Linux 2.4.19-pre3)
2002-03-19 16:22 ` Bill Davidsen
@ 2002-03-20 0:34 ` Ken Brownfield
2002-03-20 4:36 ` Bill Davidsen
0 siblings, 1 reply; 43+ messages in thread
From: Ken Brownfield @ 2002-03-20 0:34 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-kernel
If noapic doesn't fix your problem, the I/O APIC patch won't help
unfortunately, AFAIK. Are these solid system-wide lockups not
attributable to a binary-only X driver? ;)
--
Ken.
ken@irridia.com
On Tue, Mar 19, 2002 at 11:22:44AM -0500, Bill Davidsen wrote:
| Any chance this will cure the lockups on a Dell Latitude C600 every time
| you exit X? I've disabled both the IO-APIC and APIC-uni, which was
| supposed to fix the problem but didn't. Dare I hope that the disable
| wasn't enough?
|
| A quick google tells me other people have the same problem, but I
| haven't seen a working solution yet. Nice machine other than needing to be
| rebooted after every use of X :-(
|
| --
| bill davidsen <davidsen@tmr.com>
| CTO, TMR Associates, Inc
| Doing interesting things with little computers since 1979.
|
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: I/O APIC fixed in 2.4.19-pre3 & 2.5.6 (was Re: Linux 2.4.19-pre3)
2002-03-20 0:34 ` Ken Brownfield
@ 2002-03-20 4:36 ` Bill Davidsen
0 siblings, 0 replies; 43+ messages in thread
From: Bill Davidsen @ 2002-03-20 4:36 UTC (permalink / raw)
To: Ken Brownfield; +Cc: linux-kernel
On Tue, 19 Mar 2002, Ken Brownfield wrote:
> If noapic doesn't fix your problem, the I/O APIC patch won't help
> unfortunately, AFAIK. Are these solid system-wide lockups not
> attributable to a binary-only X driver? ;)
Well, I used the Redhat compile of Xfree, but unless someone has a reason
to think that building from source will be in any way better I am not
about to do that, it's kind of major in terms of time and size.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
` (5 preceding siblings ...)
2002-03-12 0:37 ` Ken Brownfield
@ 2002-03-12 10:35 ` Gerd Knorr
2002-03-12 17:24 ` Trond Myklebust
2002-03-12 17:47 ` Gerd Knorr
2002-03-12 13:01 ` Karsten Weiss
` (3 subsequent siblings)
10 siblings, 2 replies; 43+ messages in thread
From: Gerd Knorr @ 2002-03-12 10:35 UTC (permalink / raw)
To: linux-kernel
> Here goes -pre3, with the new IDE code. It has been stable enough time in
> the -ac tree, in my and Alan's opinion.
Doesn't boot my machine. "Intel machine check architecture supported"
is the last message printed before it just hangs.
Gerd
==============================[ cut here ]==============================
Linux version 2.4.19-pre3 (root@bogomips) (gcc version 2.95.3 20010315 (SuSE)) #2 Tue Mar 12 10:53:06 CET 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fffc000 (usable)
BIOS-e820: 000000003fffc000 - 000000003ffff000 (ACPI data)
BIOS-e820: 000000003ffff000 - 0000000040000000 (ACPI NVS)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
On node 0 totalpages: 262140
zone(0): 4096 pages.
zone(1): 225280 pages.
zone(2): 32764 pages.
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Kernel command line: auto BOOT_IMAGE=2.4.19-pre3 ro root=306 console=ttyS0,115200n8 console=tty0
Initializing CPU#0
Detected 451.028 MHz processor.
Console: colour VGA+ 80x60
Calibrating delay loop... 897.84 BogoMIPS
Memory: 1033576k/1048560k available (784k kernel code, 14596k reserved, 275k data, 220k init, 131056k highmem)
Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes)
Page-cache hash table entries: 262144 (order: 8, 1048576 bytes)
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check architecture supported.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-12 10:35 ` Linux 2.4.19-pre3 Gerd Knorr
@ 2002-03-12 17:24 ` Trond Myklebust
2002-03-12 17:47 ` Gerd Knorr
1 sibling, 0 replies; 43+ messages in thread
From: Trond Myklebust @ 2002-03-12 17:24 UTC (permalink / raw)
To: Gerd Knorr; +Cc: linux-kernel, Marcelo Tosatti, Dave Jones
>>>>> " " == Gerd Knorr <kraxel@bytesex.org> writes:
>> Here goes -pre3, with the new IDE code. It has been stable
>> enough time in the -ac tree, in my and Alan's opinion.
> Doesn't boot my machine. "Intel machine check architecture
> supported" is the last message printed before it just hangs.
Ditto on my laptop. I've tracked it down to a change in the file
arch/i386/kernel/bluesmoke.c between pre2 and pre3. My guess is that
- Fix off-by-one error in bluesmoke (Dave Jones)
is wrong for some reason. Backing out that change using the appended
patch causes pre3 to boot normally.
Cheers,
Trond
--- linux-2.4.19-up/arch/i386/kernel/bluesmoke.c.orig Tue Mar 12 14:56:56 2002
+++ linux-2.4.19-up/arch/i386/kernel/bluesmoke.c Tue Mar 12 18:07:44 2002
@@ -169,7 +169,7 @@
if(l&(1<<8))
wrmsr(MSR_IA32_MCG_CTL, 0xffffffff, 0xffffffff);
banks = l&0xff;
- for(i=0;i<banks;i++)
+ for(i=1;i<banks;i++)
{
wrmsr(MSR_IA32_MC0_CTL+4*i, 0xffffffff, 0xffffffff);
}
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-12 10:35 ` Linux 2.4.19-pre3 Gerd Knorr
2002-03-12 17:24 ` Trond Myklebust
@ 2002-03-12 17:47 ` Gerd Knorr
1 sibling, 0 replies; 43+ messages in thread
From: Gerd Knorr @ 2002-03-12 17:47 UTC (permalink / raw)
To: linux-kernel
Gerd Knorr wrote:
> > Here goes -pre3, with the new IDE code. It has been stable enough time in
> > the -ac tree, in my and Alan's opinion.
>
> Doesn't boot my machine. "Intel machine check architecture supported"
> is the last message printed before it just hangs.
With the -pre2 version of arch/i386/kernel/bluesmoke.c the box does boot.
Gerd
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
` (6 preceding siblings ...)
2002-03-12 10:35 ` Linux 2.4.19-pre3 Gerd Knorr
@ 2002-03-12 13:01 ` Karsten Weiss
2002-03-12 13:17 ` Jens Axboe
` (3 more replies)
2002-03-12 13:31 ` Jurgen Philippaerts
` (2 subsequent siblings)
10 siblings, 4 replies; 43+ messages in thread
From: Karsten Weiss @ 2002-03-12 13:01 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
On Mon, 11 Mar 2002, Marcelo Tosatti wrote:
> Here goes -pre3, with the new IDE code. It has been stable enough time in
I´m surprised that there are no descriptions for the following
config options (after months of fights for inclusion of this
patch):
CONFIG_IDEDISK_STROKE
CONFIG_IDE_TASK_IOCTL
CONFIG_BLK_DEV_IDEDMA_FORCED
CONFIG_IDEDMA_ONLYDISK
CONFIG_BLK_DEV_ELEVATOR_NOOP
Or did you simply forget to merge them?
bye,
Karsten
--
Karsten Weiss - http://www.machineroom.de/knweiss
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-12 13:01 ` Karsten Weiss
@ 2002-03-12 13:17 ` Jens Axboe
2002-03-12 13:37 ` Alan Cox
` (2 subsequent siblings)
3 siblings, 0 replies; 43+ messages in thread
From: Jens Axboe @ 2002-03-12 13:17 UTC (permalink / raw)
To: Karsten Weiss; +Cc: Marcelo Tosatti, lkml
On Tue, Mar 12 2002, Karsten Weiss wrote:
> CONFIG_BLK_DEV_ELEVATOR_NOOP
This really ought to get killed in the 2.4 branch, btw, I'm surprised
it's still there. It's completely bogus.
--
Jens Axboe
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-12 13:01 ` Karsten Weiss
2002-03-12 13:17 ` Jens Axboe
@ 2002-03-12 13:37 ` Alan Cox
2002-03-12 13:46 ` Jens Axboe
2002-03-12 14:47 ` J.A. Magallon
3 siblings, 0 replies; 43+ messages in thread
From: Alan Cox @ 2002-03-12 13:37 UTC (permalink / raw)
To: Karsten Weiss; +Cc: Marcelo Tosatti, lkml
> I=B4m surprised that there are no descriptions for the following
> config options (after months of fights for inclusion of this
> patch):
>
> CONFIG_IDEDISK_STROKE
> CONFIG_IDE_TASK_IOCTL
> CONFIG_BLK_DEV_IDEDMA_FORCED
> CONFIG_IDEDMA_ONLYDISK
> CONFIG_BLK_DEV_ELEVATOR_NOOP
>
> Or did you simply forget to merge them?
I haven't extracted them and sent them yet - blame me not Marcelo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-12 13:01 ` Karsten Weiss
2002-03-12 13:17 ` Jens Axboe
2002-03-12 13:37 ` Alan Cox
@ 2002-03-12 13:46 ` Jens Axboe
2002-03-12 19:02 ` Marcelo Tosatti
2002-03-12 14:47 ` J.A. Magallon
3 siblings, 1 reply; 43+ messages in thread
From: Jens Axboe @ 2002-03-12 13:46 UTC (permalink / raw)
To: Karsten Weiss; +Cc: Marcelo Tosatti, lkml
On Tue, Mar 12 2002, Karsten Weiss wrote:
> > Here goes -pre3, with the new IDE code. It has been stable enough time in
Oh good god, the nr_sectors/current_nr_sectors for the pio data phases
haven't been fixed _yet_?!
task_in_intr()
{
...
pBuf = rq->buffer + ((rq->nr_sectors - rq->current_nr_sectors) * SECTOR_SIZE);
}
And that's just one instance. Good luck running 2.4.19-pre3, this is
just so badly broken I can't find words to explain it (again). It's
really puzzling why this is still broken. I fixed it in 2.5 when the
merge happened there, the issue has been known for at least that long. I
can only recommend that no one uses 2.4.19-pre3!
Marcelo, at least apply the noop patch here. If I get motivated I'll fix
the interrupt handlers as well, can't say I really want to though...
--- drivers/ide/Config.in~ Tue Mar 12 14:22:01 2002
+++ drivers/ide/Config.in Tue Mar 12 14:22:17 2002
@@ -159,8 +159,6 @@
bool ' UMC-8672 support' CONFIG_BLK_DEV_UMC8672
fi
fi
-
- bool ' Use the NOOP Elevator (WARNING)' CONFIG_BLK_DEV_ELEVATOR_NOOP
else
bool 'Old hard disk (MFM/RLL/IDE) driver' CONFIG_BLK_DEV_HD_ONLY
define_bool CONFIG_BLK_DEV_HD $CONFIG_BLK_DEV_HD_ONLY
--- drivers/ide/ide-probe.c~ Tue Mar 12 14:22:06 2002
+++ drivers/ide/ide-probe.c Tue Mar 12 14:22:23 2002
@@ -606,12 +606,6 @@
q->queuedata = HWGROUP(drive);
blk_init_queue(q, do_ide_request);
-
- if (drive->media == ide_disk) {
-#ifdef CONFIG_BLK_DEV_ELEVATOR_NOOP
- elevator_init(&q->elevator, ELEVATOR_NOOP);
-#endif
- }
}
/*
--
Jens Axboe
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-12 13:46 ` Jens Axboe
@ 2002-03-12 19:02 ` Marcelo Tosatti
2002-03-13 8:09 ` Jens Axboe
0 siblings, 1 reply; 43+ messages in thread
From: Marcelo Tosatti @ 2002-03-12 19:02 UTC (permalink / raw)
To: Jens Axboe; +Cc: Karsten Weiss, lkml, Andre Hedrick
On Tue, 12 Mar 2002, Jens Axboe wrote:
> On Tue, Mar 12 2002, Karsten Weiss wrote:
> > > Here goes -pre3, with the new IDE code. It has been stable enough time in
>
> Oh good god, the nr_sectors/current_nr_sectors for the pio data phases
> haven't been fixed _yet_?!
>
> task_in_intr()
> {
> ...
> pBuf = rq->buffer + ((rq->nr_sectors - rq->current_nr_sectors) * SECTOR_SIZE);
> }
>
> And that's just one instance. Good luck running 2.4.19-pre3, this is
> just so badly broken I can't find words to explain it (again). It's
> really puzzling why this is still broken. I fixed it in 2.5 when the
> merge happened there, the issue has been known for at least that long. I
> can only recommend that no one uses 2.4.19-pre3!
>
> Marcelo, at least apply the noop patch here. If I get motivated I'll fix
> the interrupt handlers as well, can't say I really want to though...
As I previously said, I will apply the noop patch.
I've read the flamewar which this mail generated, but I prefer to simply
ignore that: Its useless for me, it haven't explained me nothing which
matters (that is, the technical side of the problem Jens described).
So, Jens, could you please explain the problem in the interrupt handlers
in detail ?
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-12 19:02 ` Marcelo Tosatti
@ 2002-03-13 8:09 ` Jens Axboe
2002-03-13 9:00 ` Andre Hedrick
2002-03-14 3:32 ` Michal Jaegermann
0 siblings, 2 replies; 43+ messages in thread
From: Jens Axboe @ 2002-03-13 8:09 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Karsten Weiss, lkml, Andre Hedrick
On Tue, Mar 12 2002, Marcelo Tosatti wrote:
> So, Jens, could you please explain the problem in the interrupt handlers
> in detail ?
Ok... It affects all the pio handlers in ide-taskfile.c,
multi-write/read as well. The address for pio transfers is calculated
like so:
va = rq->buffer + (rq->nr_sectors - rq->current_nr_sectors) * SECTOR_SIZE;
which is wrong for two reasons. First of all, rq->buffer cannot be
indexed for the entire nr_sectors range -- it's per definition only the
first segment in the request, and can as such only be indexed within the
first current_nr_sectors number of sectors. The above can be grossly out
of range... Second, nr_sectors and current_nr_sectors are indexing two
different things -- the former indexes the entire request (all segments)
while the latter indexes only the first segments. So
foo = rq->nr_sectors - rq->current_nr_sectors;
makes no sense _at all_ and can only be wrong.
So why does 2.4.19-pre3 work for pio at all? For the same reason that
Andre never found this problem in 2.5 either: the taskfile interrupt
handlers are _never_ used in pio mode. In 2.5 it was by accident, and
when the merge happened they did indeed get used. It ate disks, very
quickly. Take a look at drivers/ide/ide-disk.c, line 64:
#ifdef CONFIG_IDE_TASKFILE_IO
# undef __TASKFILE__IO /* define __TASKFILE__IO */
#else /* CONFIG_IDE_TASKFILE_IO */
# undef __TASKFILE__IO
#endif /* CONFIG_IDE_TASKFILE_IO */
It's a mess... This really should have been fixed prior to 2.4
inclusion. Oh well.
--
Jens Axboe
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-13 8:09 ` Jens Axboe
@ 2002-03-13 9:00 ` Andre Hedrick
2002-03-13 9:27 ` Jens Axboe
2002-03-14 4:41 ` Marcelo Tosatti
2002-03-14 3:32 ` Michal Jaegermann
1 sibling, 2 replies; 43+ messages in thread
From: Andre Hedrick @ 2002-03-13 9:00 UTC (permalink / raw)
To: Jens Axboe; +Cc: Marcelo Tosatti, Karsten Weiss, lkml
Jens,
Please try again because that is not the real problem.
All you have shown is that we disagree on the method of page walking
between BLOCK v/s IOCTL. This is very minor and I agreed that it is
reasonable to map the IOCTL buffer in to BH or BIO so this is a net zero
of negative point.
How about attempting to describe the differences between the atomic and
what is violated by who and where. I will help you later if you get
stuck.
Regards,
Andre Hedrick
On Wed, 13 Mar 2002, Jens Axboe wrote:
> On Tue, Mar 12 2002, Marcelo Tosatti wrote:
> > So, Jens, could you please explain the problem in the interrupt handlers
> > in detail ?
>
> Ok... It affects all the pio handlers in ide-taskfile.c,
> multi-write/read as well. The address for pio transfers is calculated
> like so:
>
> va = rq->buffer + (rq->nr_sectors - rq->current_nr_sectors) * SECTOR_SIZE;
>
> which is wrong for two reasons. First of all, rq->buffer cannot be
> indexed for the entire nr_sectors range -- it's per definition only the
> first segment in the request, and can as such only be indexed within the
> first current_nr_sectors number of sectors. The above can be grossly out
> of range... Second, nr_sectors and current_nr_sectors are indexing two
> different things -- the former indexes the entire request (all segments)
> while the latter indexes only the first segments. So
>
> foo = rq->nr_sectors - rq->current_nr_sectors;
>
> makes no sense _at all_ and can only be wrong.
>
> So why does 2.4.19-pre3 work for pio at all? For the same reason that
> Andre never found this problem in 2.5 either: the taskfile interrupt
> handlers are _never_ used in pio mode. In 2.5 it was by accident, and
> when the merge happened they did indeed get used. It ate disks, very
> quickly. Take a look at drivers/ide/ide-disk.c, line 64:
>
> #ifdef CONFIG_IDE_TASKFILE_IO
> # undef __TASKFILE__IO /* define __TASKFILE__IO */
> #else /* CONFIG_IDE_TASKFILE_IO */
> # undef __TASKFILE__IO
> #endif /* CONFIG_IDE_TASKFILE_IO */
>
> It's a mess... This really should have been fixed prior to 2.4
> inclusion. Oh well.
>
> --
> Jens Axboe
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-13 9:00 ` Andre Hedrick
@ 2002-03-13 9:27 ` Jens Axboe
2002-03-13 9:33 ` Andre Hedrick
2002-03-14 4:41 ` Marcelo Tosatti
1 sibling, 1 reply; 43+ messages in thread
From: Jens Axboe @ 2002-03-13 9:27 UTC (permalink / raw)
To: Andre Hedrick; +Cc: Marcelo Tosatti, Karsten Weiss, lkml
On Wed, Mar 13 2002, Andre Hedrick wrote:
>
> Jens,
>
> Please try again because that is not the real problem.
> All you have shown is that we disagree on the method of page walking
> between BLOCK v/s IOCTL. This is very minor and I agreed that it is
> reasonable to map the IOCTL buffer in to BH or BIO so this is a net zero
> of negative point.
No this is two issues -- you (ab)using request interface for ioctls is
one thing, I don't care too much about that (although it spreads
confusion and I've already seen at least one copy this code). The other
is that the task handlers are now forced to be separate and the legacy
handlers in ide-disk used.
> How about attempting to describe the differences between the atomic and
> what is violated by who and where. I will help you later if you get
> stuck.
and bingo, here comes a third issue. Please stay on track.
--
Jens Axboe
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-13 9:27 ` Jens Axboe
@ 2002-03-13 9:33 ` Andre Hedrick
2002-03-13 17:32 ` Andre Hedrick
0 siblings, 1 reply; 43+ messages in thread
From: Andre Hedrick @ 2002-03-13 9:33 UTC (permalink / raw)
To: Jens Axboe; +Cc: Marcelo Tosatti, Karsten Weiss, lkml
On Wed, 13 Mar 2002, Jens Axboe wrote:
> On Wed, Mar 13 2002, Andre Hedrick wrote:
> >
> > Jens,
> >
> > Please try again because that is not the real problem.
> > All you have shown is that we disagree on the method of page walking
> > between BLOCK v/s IOCTL. This is very minor and I agreed that it is
> > reasonable to map the IOCTL buffer in to BH or BIO so this is a net zero
> > of negative point.
>
> No this is two issues -- you (ab)using request interface for ioctls is
> one thing, I don't care too much about that (although it spreads
> confusion and I've already seen at least one copy this code). The other
> is that the task handlers are now forced to be separate and the legacy
> handlers in ide-disk used.
Well, now that you see a little more.
The reason for segmenting the data handlers to separate and isolate the
errors and flaws in the Linus failed attempt to push forward multimode io.
Also it is not isolated to writes, it is a read issue too.
Since this is now moving to the technical asspect I wanted you to go,
please go on to the third point below.
> > How about attempting to describe the differences between the atomic and
> > what is violated by who and where. I will help you later if you get
> > stuck.
>
> and bingo, here comes a third issue. Please stay on track.
Please go on on the third point because coming full circle to see an error.
Cheers,
Andre Hedrick
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-13 9:33 ` Andre Hedrick
@ 2002-03-13 17:32 ` Andre Hedrick
2002-03-13 17:40 ` Jens Axboe
0 siblings, 1 reply; 43+ messages in thread
From: Andre Hedrick @ 2002-03-13 17:32 UTC (permalink / raw)
To: Jens Axboe; +Cc: Marcelo Tosatti, Karsten Weiss, lkml
On Wed, 13 Mar 2002, Andre Hedrick wrote:
> On Wed, 13 Mar 2002, Jens Axboe wrote:
>
> > On Wed, Mar 13 2002, Andre Hedrick wrote:
> > >
> > > Jens,
> > >
> > > Please try again because that is not the real problem.
> > > All you have shown is that we disagree on the method of page walking
> > > between BLOCK v/s IOCTL. This is very minor and I agreed that it is
> > > reasonable to map the IOCTL buffer in to BH or BIO so this is a net zero
> > > of negative point.
> >
> > No this is two issues -- you (ab)using request interface for ioctls is
> > one thing, I don't care too much about that (although it spreads
> > confusion and I've already seen at least one copy this code). The other
> > is that the task handlers are now forced to be separate and the legacy
> > handlers in ide-disk used.
>
> Well, now that you see a little more.
>
> The reason for segmenting the data handlers to separate and isolate the
> errors and flaws in the Linus failed attempt to push forward multimode io.
> Also it is not isolated to writes, it is a read issue too.
> Since this is now moving to the technical asspect I wanted you to go,
> please go on to the third point below.
>
> > > How about attempting to describe the differences between the atomic and
> > > what is violated by who and where. I will help you later if you get
> > > stuck.
> >
> > and bingo, here comes a third issue. Please stay on track.
>
> Please go on on the third point because coming full circle to see an error.
Well I promised to help you if you got stuck, so here is a hint.
Describe the variations between the hardware atomic segment wrt to the
bh/bio OS atomic segment. Then explain the event ordering of the state
diagram. Be specific when bh/bio's should be updated and reported to
block as complete. Finally then explain where things are wrong and why it
is wrong and a solution to fix it. You should note the policy which is
wrong belongs to Linus and not you, but you are charge to make it happen.
Cheers,
Andre Hedrick
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-13 17:32 ` Andre Hedrick
@ 2002-03-13 17:40 ` Jens Axboe
2002-03-13 18:52 ` Andre Hedrick
0 siblings, 1 reply; 43+ messages in thread
From: Jens Axboe @ 2002-03-13 17:40 UTC (permalink / raw)
To: Andre Hedrick; +Cc: Marcelo Tosatti, Karsten Weiss, lkml
On Wed, Mar 13 2002, Andre Hedrick wrote:
> >
> > Please go on on the third point because coming full circle to see an error.
>
> Well I promised to help you if you got stuck, so here is a hint.
I'm not stuck, I'm just done arguing with you. I have much better things
to do than waste my time doing that.
> Describe the variations between the hardware atomic segment wrt to the
[snip, class assignment]
This is not a class and you are definitely not my teacher. I've
described plenty of times before what the problems are, I don't see why
this should be any better.
--
Jens Axboe
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-13 17:40 ` Jens Axboe
@ 2002-03-13 18:52 ` Andre Hedrick
0 siblings, 0 replies; 43+ messages in thread
From: Andre Hedrick @ 2002-03-13 18:52 UTC (permalink / raw)
To: Jens Axboe; +Cc: Marcelo Tosatti, Karsten Weiss, lkml
On Wed, 13 Mar 2002, Jens Axboe wrote:
> On Wed, Mar 13 2002, Andre Hedrick wrote:
> > >
> > > Please go on on the third point because coming full circle to see an error.
> >
> > Well I promised to help you if you got stuck, so here is a hint.
>
> I'm not stuck, I'm just done arguing with you. I have much better things
> to do than waste my time doing that.
>
> > Describe the variations between the hardware atomic segment wrt to the
>
> [snip, class assignment]
>
> This is not a class and you are definitely not my teacher. I've
> described plenty of times before what the problems are, I don't see why
> this should be any better.
You answers have only addressed BLOCK, you have yet to address the
hardware. If you think this is a game, it is not. It is to try and get a
point across so that we can move forward. It is the same problem you have
in 2.5. I can post the solution to the hardware atomic. It does not
address the data integrity violations force upon it.
So if you think this is class fine. It is really a an issue of shared
learning. You brought me back up to date on how BLOCK behaves because I
forgot. All I ma trying to do is bring you up to date on how the hardware
works. But if you will not communitcate so I can see how far you have the
point in question it will never be resolved.
Also, I know you well enough. If there is an issue you do/will/can not
address you go quiet.
If you do not understand, I want to help you to.
I accepted your help when you offered it and thanked you for it.
Regards,
Andre Hedrick
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-13 9:00 ` Andre Hedrick
2002-03-13 9:27 ` Jens Axboe
@ 2002-03-14 4:41 ` Marcelo Tosatti
2002-03-14 6:28 ` Andre Hedrick
1 sibling, 1 reply; 43+ messages in thread
From: Marcelo Tosatti @ 2002-03-14 4:41 UTC (permalink / raw)
To: Andre Hedrick; +Cc: Jens Axboe, Karsten Weiss, lkml
On Wed, 13 Mar 2002, Andre Hedrick wrote:
>
> Jens,
>
> Please try again because that is not the real problem.
> All you have shown is that we disagree on the method of page walking
> between BLOCK v/s IOCTL. This is very minor and I agreed that it is
> reasonable to map the IOCTL buffer in to BH or BIO so this is a net zero
> of negative point.
>
> How about attempting to describe the differences between the atomic and
> what is violated by who and where.
Andre,
Jens just described what can be violated:
"First of all, rq->buffer cannot be indexed for the entire nr_sectors
range -- it's per definition only the first segment in the request, and
can as such only be indexed within the first current_nr_sectors number of
sectors. The above can be grossly out of range..."
Can you tell me why his is wrong ?
BTW, I just checked 2.5 and it seems to be the similar (on the non-BIO
case).
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-14 4:41 ` Marcelo Tosatti
@ 2002-03-14 6:28 ` Andre Hedrick
0 siblings, 0 replies; 43+ messages in thread
From: Andre Hedrick @ 2002-03-14 6:28 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Jens Axboe, Karsten Weiss, lkml
On Thu, 14 Mar 2002, Marcelo Tosatti wrote:
>
>
> On Wed, 13 Mar 2002, Andre Hedrick wrote:
>
> >
> > Jens,
> >
> > Please try again because that is not the real problem.
> > All you have shown is that we disagree on the method of page walking
> > between BLOCK v/s IOCTL. This is very minor and I agreed that it is
> > reasonable to map the IOCTL buffer in to BH or BIO so this is a net zero
> > of negative point.
> >
> > How about attempting to describe the differences between the atomic and
> > what is violated by who and where.
>
> Andre,
>
> Jens just described what can be violated:
>
> "First of all, rq->buffer cannot be indexed for the entire nr_sectors
> range -- it's per definition only the first segment in the request, and
> can as such only be indexed within the first current_nr_sectors number of
> sectors. The above can be grossly out of range..."
>
> Can you tell me why his is wrong ?
>
> BTW, I just checked 2.5 and it seems to be the similar (on the non-BIO
> case).
Jens is absolutely correct for the internal kernel usage of rq->buffer.
Given the kernel side of the equation uses single BH pages handed down
from block, the max. content represented by rq->current_nr_sectors is a
single page. This is depended on arch, but generally sized at 4k.
This 4k page represents a max. of 8 (512 byte) sectors. In general any
given driver does not know if it will have a full page or not. IIRC in an
irc chat with alex viro, he made it completely clear that it could/would
be acceptable to reject unaligned full pages from block. It startled me
at first but he is correct.
Now for the ioctl side of life. It creates and maps its list of pointer
to rq->buffer too, but it comes for a kmalloc. This is a contigious
buffer. Therefore in this case the computation for position for windowing
the hardware segment for IO is referenced by
rq->nr_sectors - rq->current_nr_sectors
Where rq->nr_sectors == rq->current_nr_sectors in the beginning when zero
sectors have been transfered. The difference provides your referrence
starting point on the contigious rq->buffer.
Again Jens' point about the kernel/block side of the issue is correct.
My point from the ioctl side of the issue is correct.
Now how do we make both sides of the interface use a comman IO path?
Cheers,
Andre Hedrick
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-13 8:09 ` Jens Axboe
2002-03-13 9:00 ` Andre Hedrick
@ 2002-03-14 3:32 ` Michal Jaegermann
1 sibling, 0 replies; 43+ messages in thread
From: Michal Jaegermann @ 2002-03-14 3:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Jens Axboe, Marcelo Tosatti
On Wed, Mar 13, 2002 at 09:09:46AM +0100, Jens Axboe wrote:
>
> So why does 2.4.19-pre3 work for pio at all? For the same reason that
> Andre never found this problem in 2.5 either: the taskfile interrupt
> handlers are _never_ used in pio mode. In 2.5 it was by accident, and
> when the merge happened they did indeed get used. It ate disks, very
> quickly. ...
Well, I tried 2.4.19-pre3 yesterday (Alpha with an IDE drive) and
my ext2 file system is indeed gone. I do not want to claim that this
is certainly due to an IDE driver from 2.4.19-pre3, as this is
a machine with a number still open issues and very experimental
installation, but it survived a number of very rough attempts on
file systems in the past and now it died. This _could be_ coincidental;
I did use various kernels from "ac" series on it in the past.
BTW - e2fsck made an impression that it is running in circles.
After mounting a disk from another system I have leftovers and number
of files can be read and copied but, among other things, '/lib' is
not a directory anymore. :-)
Michal
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-12 13:01 ` Karsten Weiss
` (2 preceding siblings ...)
2002-03-12 13:46 ` Jens Axboe
@ 2002-03-12 14:47 ` J.A. Magallon
3 siblings, 0 replies; 43+ messages in thread
From: J.A. Magallon @ 2002-03-12 14:47 UTC (permalink / raw)
To: Karsten Weiss; +Cc: Marcelo Tosatti, lkml
On 2002.03.12 Karsten Weiss wrote:
>On Mon, 11 Mar 2002, Marcelo Tosatti wrote:
>
>> Here goes -pre3, with the new IDE code. It has been stable enough time in
>
>I´m surprised that there are no descriptions for the following
>config options (after months of fights for inclusion of this
>patch):
>
>CONFIG_IDEDISK_STROKE
>CONFIG_IDE_TASK_IOCTL
>CONFIG_BLK_DEV_IDEDMA_FORCED
>CONFIG_IDEDMA_ONLYDISK
>CONFIG_BLK_DEV_ELEVATOR_NOOP
>
>Or did you simply forget to merge them?
>
This is the last version I grabbed fron the list:
diff -urN linux-2.4.17-pristine/Documentation/Configure.help linux-2.4.17/Documentation/Configure.help
--- linux-2.4.17-pristine/Documentation/Configure.help Fri Dec 21 09:41:53 2001
+++ linux-2.4.17/Documentation/Configure.help Sat Jan 19 18:30:28 2002
@@ -723,6 +723,59 @@
say M here and read <file:Documentation/modules.txt>. The module
will be called ide-floppy.o.
+AWARD Bios Work-Around
+CONFIG_IDEDISK_STROKE
+ Should you have a system w/ an AWARD Bios and your drives are larger
+ than 32GB and it will not boot, one is required to perform a few OEM
+ operations first. The option is called "STROKE" because it allows
+ one to "soft clip" the drive to work around a barrier limit. For
+ Maxtor drives it is called "jumpon.exe". Please search Maxtor's
+ web-site for "JUMPON.EXE". IBM has a similar tool at:
+ <http://www.storage.ibm.com/hdd/support/download.htm>.
+
+ If you are unsure, say N here.
+
+Raw Access to Media
+CONFIG_IDE_TASK_IOCTL
+ This is a direct raw access to the media. It is a complex but
+ elegant solution to test and validate the domain of the hardware and
+ perform below the driver data recover if needed. This is the most
+ basic form of media-forensics.
+
+ If you are unsure, say N here.
+
+Use Taskfile I/O
+CONFIG_IDE_TASKFILE_IO
+ This is the "Jewel" of the patch. It will go away and become the new
+ driver core. Since all the chipsets/host side hardware deal w/ their
+ exceptions in "their local code" currently, adoption of a
+ standardized data-transport is the only logical solution.
+ Additionally we packetize the requests and gain rapid performance and
+ a reduction in system latency. Additionally by using a memory struct
+ for the commands we can redirect to a MMIO host hardware in the next
+ generation of controllers, specifically second generation Ultra133
+ and Serial ATA.
+
+ Since this is a major transition, it was deemed necessary to make the
+ driver paths buildable in separtate models. Therefore if using this
+ option fails for your arch then we need to address the needs for that
+ arch.
+
+ If you want to test this functionality, say Y here.
+
+Force DMA
+CONFIG_BLK_DEV_IDEDMA_FORCED
+ This is an old piece of lost code from Linux 2.0 Kernels.
+
+ Generally say N here.
+
+DMA Only on Disks
+CONFIG_IDEDMA_ONLYDISK
+ This is used if you know your ATAPI Devices are going to fail DMA
+ Transfers.
+
+ Generally say N here.
+
SCSI emulation support
CONFIG_BLK_DEV_IDESCSI
This will provide SCSI host adapter emulation for IDE ATAPI devices,
@@ -747,6 +747,14 @@
If both this SCSI emulation and native ATAPI support are compiled
into the kernel, the native support will be used.
+Use the NOOP Elevator (WARNING)
+CONFIG_BLK_DEV_ELEVATOR_NOOP
+ If you are using a raid class top-level driver above the ATA/IDE core,
+ one may find a performance boost by preventing a merging and re-sorting
+ of the new requests.
+
+ If unsure, say N.
+
ISA-PNP EIDE support
CONFIG_BLK_DEV_ISAPNP
If you have an ISA EIDE card that is PnP (Plug and Play) and
--
J.A. Magallon # Let the source be with you...
mailto:jamagallon@able.es
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.19-pre3-jam1 #2 SMP Tue Mar 12 08:37:23 CET 2002 i686
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
` (7 preceding siblings ...)
2002-03-12 13:01 ` Karsten Weiss
@ 2002-03-12 13:31 ` Jurgen Philippaerts
2002-03-12 15:43 ` Geert Uytterhoeven
2002-03-12 21:59 ` Paul Mackerras
10 siblings, 0 replies; 43+ messages in thread
From: Jurgen Philippaerts @ 2002-03-12 13:31 UTC (permalink / raw)
To: linux-kernel
Marcelo Tosatti wrote:
> Here goes -pre3, with the new IDE code. It has been stable enough time in
> the -ac tree, in my and Alan's opinion.
>
> The inclusion of the new IDE code makes me want to have a longer 2.4.19
> release cycle, for stress-testing reasons.
>
> Please stress test it with huge amounts of data ;)
make[3]: Entering directory `/usr/src/linux2419pre3/drivers/ide'
sparc64-linux-gcc -D__KERNEL__ -I/usr/src/linux2419pre3/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fo
mit-frame-pointer -fno-strict-aliasing -fno-common -m64 -pipe -mno-fpu
-mcpu=ultrasparc -mcmodel=medlow -ffixed-
g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare
-Wa,--undeclared-regs -DKBUILD_BASENAME=ide -DEXPORT_SYMTA
B -c ide.c
In file included from /usr/src/linux2419pre3/include/linux/ide.h:301,
from ide.c:149:
/usr/src/linux2419pre3/include/asm/ide.h:132: warning: `/*' within
comment
In file included from /usr/src/linux2419pre3/include/linux/ide.h:301,
from ide.c:149:
/usr/src/linux2419pre3/include/asm/ide.h:153: parse error before
`static'
/usr/src/linux2419pre3/include/asm/ide.h:153: warning: no semicolon at
end of struct or union
/usr/src/linux2419pre3/include/asm/ide.h:153: warning: no semicolon at
end of struct or union
/usr/src/linux2419pre3/include/asm/ide.h: In function `ide_insw':
/usr/src/linux2419pre3/include/asm/ide.h:175: warning: implicit
declaration of function `inw_be'
/usr/src/linux2419pre3/include/asm/ide.h: At top level:
/usr/src/linux2419pre3/include/asm/ide.h:320: warning: This file
contains more `{'s than `}'s.
/usr/src/linux2419pre3/include/linux/ide.h:1103: warning: This file
contains more `{'s than `}'s.
ide.c: In function `ide_dump_status':
ide.c:993: warning: long long int format, long int arg (arg 2)
ide.c: In function `hwif_unregister':
ide.c:2188: warning: implicit declaration of function
`ide_release_region'
make[3]: *** [ide.o] Error 1
make[3]: Leaving directory `/usr/src/linux2419pre3/drivers/ide'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux2419pre3/drivers/ide'
make[1]: *** [_subdir_ide] Error 2
make[1]: Leaving directory `/usr/src/linux2419pre3/drivers'
make: *** [_dir_drivers] Error 2
Jurgen.
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
` (8 preceding siblings ...)
2002-03-12 13:31 ` Jurgen Philippaerts
@ 2002-03-12 15:43 ` Geert Uytterhoeven
2002-03-12 21:59 ` Paul Mackerras
10 siblings, 0 replies; 43+ messages in thread
From: Geert Uytterhoeven @ 2002-03-12 15:43 UTC (permalink / raw)
To: Alan Cox; +Cc: lkml
On Mon, 11 Mar 2002, Marcelo Tosatti wrote:
> Here goes -pre3, with the new IDE code. It has been stable enough time in
> the -ac tree, in my and Alan's opinion.
>
> The inclusion of the new IDE code makes me want to have a longer 2.4.19
> release cycle, for stress-testing reasons.
It looks like {IN,OUT}_{BYTE,WORD}() are now the arch-specific routines to
access the IDE registers, controlled by HAVE_ARCH_{IN,OUT}_BYTE?
If yes,
- Why not call them ide_{in,out}[bw]()?
- What about {in,out}s[wl]{,_swapw}()? Don't we need abstractions for those
as well?
- The old (ISA/PCI I/O only) {in,out}[bwl]() are still used in many places.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: Linux 2.4.19-pre3
2002-03-11 21:08 Linux 2.4.19-pre3 Marcelo Tosatti
` (9 preceding siblings ...)
2002-03-12 15:43 ` Geert Uytterhoeven
@ 2002-03-12 21:59 ` Paul Mackerras
10 siblings, 0 replies; 43+ messages in thread
From: Paul Mackerras @ 2002-03-12 21:59 UTC (permalink / raw)
To: Stephan von Krawczynski; +Cc: Marcelo Tosatti, mostrows, lkml
Stephan von Krawczynski writes:
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.19-pre3/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -DMODULE -DKBUILD_BASENAME=pppoe -c -o pppoe.o pppoe.c
> pppoe.c: In function `pppoe_flush_dev':
> pppoe.c:282: `PPPOX_ZOMBIE' undeclared (first use in this function)
Blast, I missed the patch to include/linux/if_pppox.h. Here it is.
Marcelo, could you include this in the next -pre?
Paul.
diff -urN linux-2.4.19-pre3/include/linux/if_pppox.h pmac/include/linux/if_pppox.h
--- linux-2.4.19-pre3/include/linux/if_pppox.h Sat Jul 21 09:51:58 2001
+++ pmac/include/linux/if_pppox.h Fri Mar 8 12:39:32 2002
@@ -126,13 +126,14 @@
extern int pppox_channel_ioctl(struct ppp_channel *pc, unsigned int cmd,
unsigned long arg);
-/* PPPoE socket states */
+/* PPPoX socket states */
enum {
PPPOX_NONE = 0, /* initial state */
PPPOX_CONNECTED = 1, /* connection established ==TCP_ESTABLISHED */
PPPOX_BOUND = 2, /* bound to ppp device */
PPPOX_RELAY = 4, /* forwarding is enabled */
- PPPOX_DEAD = 8
+ PPPOX_ZOMBIE = 8, /* dead, but still bound to ppp device */
+ PPPOX_DEAD = 16 /* dead, useless, please clean me up!*/
};
extern struct ppp_channel_ops pppoe_chan_ops;
^ permalink raw reply [flat|nested] 43+ messages in thread