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 ;)
pre3:
- -ac merge (including new IDE) (Alan Cox)
- S390 merge (IBM)
- More cciss fixes (Stephen Cameron)
- Eicon SMP race fix (Armin Schindler)
- w9966 driver update (Jakob Kemi)
- Unify crc32 routine (removes lots of duplicated
code from drivers) (Matt Domsch)
- Lanstreamer bugfixes (Kent Yoder)
- Update scsi_debug (Douglas Gilbert)
- MCE Configure.help update (Paul Gortmaker)
- Fix SMB NLS oops (Urban Widmark)
- AGP Config.in update (Daniele Venzano)
- Fix small thinko in UFS set_blocksize return handling (me)
- Avoid unecessary cache flushes on PPC (Paul Mackerras)
- PPP deadlock fixes (Paul Mackerras)
- Signal changes for thread groups (Dave McCracken)
- Make max_threads be based on normal zone size (Dave McCracken)
- ray_cs wireless extension fix (Jean Tourrilhes)
- irda bugfixes and enhancements (Jean Tourrilhes)
- USB update (Greg KH)
- Fix through-8259A mode for IRQ0 routing on APIC (Maciej W. Rozycki/Joe Korty)
- Add Dell Inspiron 2500 to broken APM blacklist (Arjan van de Ven)
- Fix off-by-one error in bluesmoke (Dave Jones)
- Reiserfs update (Oleg Drokin)
- Fix PCI compile without /proc support (Eric Sandeen)
- Fix problem with bad inode handling (Alexander Viro)
- aic7xxx update (Justin T. Gibbs)
- Do not consider SCSI recovered errors as fatal errors (Justin T. Gibbs)
- Add Memory-Write-Invalidate support to PCI (Jeff Garzik)
- Starfire update (Ion Badulescu)
- tulip update (Jeff Garzik)
pre2:
- -ac merge (Alan Cox)
- Huge MIPS/MIPS64 merge (Ralf Baechle)
- IA64 update (David Mosberger)
- PPC update (Tom Rini)
- Shrink struct page (Rik van Riel)
- QNX4 update (now its able to mount QNX 6.1 fses) (Anders Larsen)
- Make max_map_count sysctl configurable (Christoph Hellwig)
- matroxfb update (Petr Vandrovec)
- ymfpci update (Pete Zaitcev)
- LVM update (Heinz J . Mauelshagen)
- btaudio driver update (Gerd Knorr)
- bttv update (Gerd Knorr)
- Out of line code cleanup (Keith Owens)
- Add watchdog API documentation (Christer Weinigel)
- Rivafb update (Ani Joshi)
- Enable PCI buses above quad0 on NUMA-Q (Martin J. Bligh)
- Fix PIIX IDE slave PCI timings (Dave Bogdanoff)
- Make PLIP work again (Tim Waugh)
- Remove unecessary printk from lp.c (Tim Waugh)
- Make parport_daisy_select work for ECP/EPP modes (Max Vorobiev)
- Support O_NONBLOCK on lp/ppdev correctly (Tim Waugh)
- Add PCI card hooks to parport (Tim Waugh)
- Compaq cciss driver fixes (Stephen Cameron)
- VFS cleanups and fixes (Alexander Viro)
- USB update (including USB 2.0 support) (Greg KH)
- More jiffies compare cleanups (Tim Schmielau)
- PCI hotplug update (Greg KH)
- bluesmoke fixes (Dave Jones)
- Fix off-by-one in ide-scsi (John Fremlin)
- Fix warnings in make xconfig (Ren? Scharfe)
- Make x86 MCE a configure option (Paul Gortmaker)
- Small ramdisk fixes (Christoph Hellwig)
- Add missing atime update to pipe code (Christoph Hellwig)
- Serialize microcode access (Tigran Aivazian)
- AMD Elan handling on serial.c (Robert Schwebel)
pre1:
- Add tape support to cciss driver (Stephen Cameron)
- Add Permedia3 fb driver (Romain Dolbeau)
- meye driver update (Stelian Pop)
- opl3sa2 update (Zwane Mwaikambo)
- JFFS2 update (David Woodhouse)
- NBD deadlock fix (Steven Whitehouse)
- Correct sys_shmdt() return value on failure (Adam Bottchen)
- Apply the SET_PERSONALITY patch missing from 2.4.18 (me)
- Alpha update (Jay Estabrook)
- SPARC64 update (David S. Miller)
- Fix potential blk freelist corruption (Jens Axboe)
- Fix potential hpfs oops (Chris Mason)
- get_request() starvation fix (Andrew Morton)
- cramfs update (Daniel Quinlan)
- Allow binfmt_elf as module (Paul Gortmaker)
- ymfpci Configure.help update (Pete Zaitcev)
- Backout one eepro100 change made in 2.4.18: it
was causing slowdowns on some cards (Jeff Garzik)
- Tridentfb compilation fix (Jani Monoses)
- Fix refcounting of directories on renames in tmpfs (Christoph Rohland)
- Add Fujitsu notebook to broken APM implementation
blacklist (Arjan Van de Ven)
- "do { ... } while(0)" cleanups on some fb drivers (Geert Uytterhoeven)
- Fix natsemi's ETHTOOL_GLINK ioctl (Tim Hockin)
- Fix clik! drive detection code in ide-floppy (Paul Bristow)
- Add additional support for the 82801 I/O controller (Wim Van Sebroeck)
- Remove duplicates in pci_ids.h (Wim Van Sebroeck)
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 ([email protected]) <http://samba.org/eyal/>
> 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
>
> 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
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 ([email protected]) <http://samba.org/eyal/>
On Tue, 12 Mar 2002 10:04:42 +1100,
Eyal Lebedinsky <[email protected]> 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
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 ([email protected]) <http://samba.org/eyal/>
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:[email protected]
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
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.
[email protected]
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");
Marcelo wrote in the 2.4.19-pre3 announcement:
>pre3:
>- Fix off-by-one error in bluesmoke (Dave Jones)
NO NO NO! This is the same broken patch that somehow got into
2.2.21pre4 as well. The patch changes the code to write to the
IA32_MC0_CTL MSR, which is a big no-no. Intel's IA32 Vol3 manual
(#245472-03) sections 13.3.2.1 and 13.5 make that point quite clear.
I have several P6 boxes that hang hard in MCE init trying to boot
vanilla 2.2.21pre4 and 2.4.19-pre3. The issue is real.
Please apply the backup patch below.
/Mikael
--- linux-2.4.19-pre3/arch/i386/kernel/bluesmoke.c.~1~ Tue Mar 12 00:25:53 2002
+++ linux-2.4.19-pre3/arch/i386/kernel/bluesmoke.c Tue Mar 12 01:11:58 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);
}
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" <[email protected]>
To: "Marcelo Tosatti" <[email protected]>
Cc: "lkml" <[email protected]>
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 ([email protected]) <http://samba.org/eyal/>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
________________________________________________________________________
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
________________________________________________________________________
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)?
On Tue, 12 Mar 2002, Mikael Pettersson wrote:
> Marcelo wrote in the 2.4.19-pre3 announcement:
> >pre3:
> >- Fix off-by-one error in bluesmoke (Dave Jones)
>
> NO NO NO! This is the same broken patch that somehow got into
> 2.2.21pre4 as well. The patch changes the code to write to the
> IA32_MC0_CTL MSR, which is a big no-no. Intel's IA32 Vol3 manual
> (#245472-03) sections 13.3.2.1 and 13.5 make that point quite clear.
>
> I have several P6 boxes that hang hard in MCE init trying to boot
> vanilla 2.2.21pre4 and 2.4.19-pre3. The issue is real.
>
> Please apply the backup patch below.
>
> /Mikael
>
> --- linux-2.4.19-pre3/arch/i386/kernel/bluesmoke.c.~1~ Tue Mar 12 00:25:53 2002
> +++ linux-2.4.19-pre3/arch/i386/kernel/bluesmoke.c Tue Mar 12 01:11:58 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);
> }
Just to confirm your patch fixes my MCE init lockup problem here as well.
--
Chad Young - Registered Linux User #195191 @ http://counter.li.org
-----------------------------------------------------------------------
Linux localhost 2.4.19-pre3 #1 Tue Mar 12 00:43:17 AST 2002 i686 unknown
1:10am up 0 min, 0 users, load average: 0.39, 0.11, 0.03
This update seems to have the same change as 2.2.21-pre4 in
arch/i386/kernel/bluesmoke.c that broke booting some Intel SMP
boxes over the weekend and was reported by many people.
--- 2.4.19-pre2/arch/i386/kernel/bluesmoke.c Sun Mar 10 20:43:53 2002
+++ 2.4.19-pre3/arch/i386/kernel/bluesmoke.c Mon Mar 11 23:14:14 2002
@@ -169,7 +169,7 @@
if(l&(1<<8))
wrmsr(MSR_IA32_MCG_CTL, 0xffffffff, 0xffffffff);
banks = l&0xff;
- for(i=1;i<banks;i++)
+ for(i=0;i<banks;i++)
{
wrmsr(MSR_IA32_MC0_CTL+4*i, 0xffffffff, 0xffffffff);
}
On Mon, 11 Mar 2002 17:50:59 -0800
Mike Fedyk <[email protected]> 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)
> 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.
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
> 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
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.
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:[email protected]
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
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 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
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
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
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
>>>>> " " == Gerd Knorr <[email protected]> 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);
}
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
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 ?
On Tue, Mar 12, 2002 at 01:51:42AM +0100, Mikael Pettersson wrote:
> >- Fix off-by-one error in bluesmoke (Dave Jones)
> NO NO NO! This is the same broken patch that somehow got into
> 2.2.21pre4 as well.
Agreed, it should get backed out as it was in 2.2.21rc1
> The patch changes the code to write to the
> IA32_MC0_CTL MSR, which is a big no-no. Intel's IA32 Vol3 manual
> (#245472-03) sections 13.3.2.1 and 13.5 make that point quite clear.
Without the change however, Athlons won't report Icache errors.
Possibly we need a seperate init path for Athlon/Intel
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
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;
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
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
>
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
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
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
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
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
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
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).
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
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.
[email protected]
<[email protected]> (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.
| [email protected]
|
| 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 [email protected]
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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.
[email protected]
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 <[email protected]>
| 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 [email protected]
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
> 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?
Does it also lock up when the text console blanks?
The X lockups were what had been plaguing me for the past two weeks.
I thought it was the new Radeon (7500), but it seems[1] to have been my
Asus CUSL2-C's[2] broken APM implementation (Quite recently Alan Cox
mentioned this problem with Asus' BIOS).
Out of fear, I do not compile in ACPI[3].
I have since recompiled with APM as a module and life seems much more
stable. (I issue "modprobe apm" at shutdown so the box actually turns
off :)
Perhaps your BIOS has similar "issues"?
John Klar
[1] No lockup in 3 days. Knock bits.
[2] Intel 815ep, 700MHz Coppermine PIII not overclocked.
RH6.2 frankensteined to 7.2 (mostly)
kernel 2.4.15 (with Viro's inode patch) (yes, yes, I'm slow)
(RH's gcc-2.96-98)
XFree86 4.2.0 from their binary tarballs.
[3] One of the side-effects of ACPI support is disabling APM if
an ACPI capable board is found. This, I suspect, is why reports
of CUSL2 hangs are rare...
On Tue, 19 Mar 2002, PlasmaJohn 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?
>
> Does it also lock up when the text console blanks?
Never. Not when it's in X except when I logout.
> The X lockups were what had been plaguing me for the past two weeks.
> I thought it was the new Radeon (7500), but it seems[1] to have been my
> Asus CUSL2-C's[2] broken APM implementation (Quite recently Alan Cox
> mentioned this problem with Asus' BIOS).
>
> Out of fear, I do not compile in ACPI[3].
Never did after I saw the problem. And tried both noapic and disabling the
kernel option for IO-APIC and local APIC.
> I have since recompiled with APM as a module and life seems much more
> stable. (I issue "modprobe apm" at shutdown so the box actually turns
> off :)
Can't remember if it's a module, I kind of doubt it but it might be, I use
a LOT of modules.
> Perhaps your BIOS has similar "issues"?
Since I see this on lots of Dells I suspect a hardware issue. I may try a
FB version of X, but mainly I plan to get something else less broken
unless I can find a fix. Pity, the machine is really nice otherwise, other
than the WinModem it uses.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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 <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
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
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...