* Linux 2.4.21-rc3 @ 2003-05-22 22:19 Marcelo Tosatti 2003-05-22 23:46 ` J.A. Magallon ` (7 more replies) 0 siblings, 8 replies; 47+ messages in thread From: Marcelo Tosatti @ 2003-05-22 22:19 UTC (permalink / raw) To: lkml Hi, Here goes the third release candidate of 2.4.21. Summary of changes from v2.4.21-rc2 to v2.4.21-rc3 ============================================ <bk@suse.de>: o fix unresolved symbol rtnetlink_rcv_skb with gcc-3.3 <riel@redhat.com>: o mm/mmap.c address overflow fix <viro@parcelfarce.linux.theplanet.co.uk>: o TIOCCONS fix Adrian Bunk <bunk@fs.tum.de>: o fix sound/kahlua.c .text.exit error o fix ips.c .text.exit error o Configure.help updates from -ac Alan Cox <alan@lxorguk.ukuu.org.uk>: o fix ipmi screwup o IDE config fixes o allow rw_disk in IDE to be hooked o clean up the pdc4030 to use the new hooks not ifdefs o fix modular ide build and other makefile bug o correct ALi doc o hpt37x o add Intel ICH5 Serial ATA o fix wrong clocking selection on CMD680/SII3112 o ensure we dont turn DMA on by accident on early sl82c05 o fix missing wakeup on hisax pci (breaks v.110) o mpt fusion assorted small fixes o fix config error o resync lasi id (somehow out of sync) o vrify_area fix o pci id table update o add a quirk for the serverworks irq o pass the right object to presto o merge the kerneldoc for uaccess o parisc headers o parisc headers 2 o update IDE headers to match IDE changes o extra PCI Ident o export fc_type_trans o add a hold field to reserve ide slots (needed for PPC) Andrea Arcangeli <andrea@suse.de>: o Fix race between remove_inode_page and prune_icache Arjan van de Ven <arjanv@redhat.com>: o ioperm fix Marcelo Tosatti <marcelo@freak.distro.conectiva>: o Changed EXTRAVERSION to -rc3 o Cset exclude: alan@lxorguk.ukuu.org.uk|ChangeSet|20030522194932|46894 (wolfson codec upd) Nicolas Pitre <nico@cam.org>: o set_task_state() UP memory barriers Olaf Hering <olh@suse.de>: o 2.4.21-rc2 syntax error in toplevel Makefile Oleg Drokin <green@angband.namesys.com>: o Fix reiserfs options parser, return error if given incorrect options on remount o reiserfs: One of the O_DIRECT fixes disabled tail packing by mistake. Enable it again o reiserfs: Fix another O_DIRECT vs tails problem. Mostly by Chris Mason o reiserfs: Refuse to mount/remount if "alloc=" option had incorect parameter o reiserfs: iget4() race fix Oleg Drokin <green@namesys.com>: o [2.4] export balance_dirty Stephen C. Tweedie <sct@redhat.com>: o Fix mmap+IO potential dangling IO in ext3 Tom Rini <trini@kernel.crashing.org>: o PPC32: Fix 'make znetboot'. From Cort Dougan o PPC32: Important fixes in the MPC8xx enet driver o PPC32: Allow for the RTC IRQ to be board-defined Vojtech Pavlik <vojtech@suse.cz>: o Fix incorrect enablebits for all AMD IDE chips ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 2003-05-22 22:19 Linux 2.4.21-rc3 Marcelo Tosatti @ 2003-05-22 23:46 ` J.A. Magallon 2003-05-26 17:04 ` Alan Cox 2003-05-23 0:51 ` Barry K. Nathan ` (6 subsequent siblings) 7 siblings, 1 reply; 47+ messages in thread From: J.A. Magallon @ 2003-05-22 23:46 UTC (permalink / raw) To: linux-kernel On 05.23, Marcelo Tosatti wrote: > > Hi, > > Here goes the third release candidate of 2.4.21. > > --- linux/drivers/ide/Config.in.orig 2003-05-23 01:42:20.000000000 +0200 +++ linux/drivers/ide/Config.in 2003-05-23 01:42:37.000000000 +0200 @@ -66,7 +66,7 @@ dep_bool ' Special UDMA Feature' CONFIG_PDC202XX_BURST $CONFIG_BLK_DEV_PDC202XX_OLD $CONFI_BLK_DEV_IDEDMA_PCI dep_tristate ' PROMISE PDC202{68|69|70|71|75|76|77} support' CONFIG_BLK_DEV_PDC202XX_NEW $CONFIG_BLK_DEV_IDEDMA_PCI # FIXME - probably wants to be one for old and for new - dep_bool ' Special FastTrak Feature' CONFIG_PDC202XX_FORCE + dep_bool ' Special FastTrak Feature' CONFIG_PDC202XX_FORCE $CONFIG_BLK_DEV_IDEDMA_PCI dep_tristate ' RZ1000 chipset bugfix/support' CONFIG_BLK_DEV_RZ1000 $CONFIG_X86 dep_tristate ' SCx200 chipset support' CONFIG_BLK_DEV_SC1200 $CONFIG_BLK_DEV_IDEDMA_PCI dep_tristate ' ServerWorks OSB4/CSB5/CSB6 chipsets support' CONFIG_BLK_DEV_SVWKS $CONFIG_BLK_DEV_IDEDMA_PCI Plz, could you run make xconfig sometime ? I know it is too friendly for kernel hackers... -- J.A. Magallon <jamagallon@able.es> \ Software is like sex: werewolf.able.es \ It's better when it's free Mandrake Linux release 9.2 (Cooker) for i586 Linux 2.4.21-rc2-jam2 (gcc 3.2.3 (Mandrake Linux 9.2 3.2.3-1mdk)) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 2003-05-22 23:46 ` J.A. Magallon @ 2003-05-26 17:04 ` Alan Cox 0 siblings, 0 replies; 47+ messages in thread From: Alan Cox @ 2003-05-26 17:04 UTC (permalink / raw) To: J.A. Magallon; +Cc: Linux Kernel Mailing List On Gwe, 2003-05-23 at 00:46, J.A. Magallon wrote: > - dep_bool ' Special FastTrak Feature' CONFIG_PDC202XX_FORCE > + dep_bool ' Special FastTrak Feature' CONFIG_PDC202XX_FORCE $CONFIG_BLK_DEV_IDEDMA_PCI > dep_tristate ' RZ1000 chipset bugfix/support' CONFIG_BLK_DEV_RZ1000 $CONFIG_X86 This fix is the wrong way around. Make it "bool" for now ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 2003-05-22 22:19 Linux 2.4.21-rc3 Marcelo Tosatti 2003-05-22 23:46 ` J.A. Magallon @ 2003-05-23 0:51 ` Barry K. Nathan 2003-05-23 5:32 ` Marc-Christian Petersen 2003-05-23 8:27 ` Linux 2.4.21-rc3 Benjamin Herrenschmidt ` (5 subsequent siblings) 7 siblings, 1 reply; 47+ messages in thread From: Barry K. Nathan @ 2003-05-23 0:51 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml On Thu, May 22, 2003 at 07:19:38PM -0300, Marcelo Tosatti wrote: > Arjan van de Ven <arjanv@redhat.com>: > o ioperm fix If this is the same code that's in Red Hat's latest security errata, I think this may be broken (makes some programs segfault). 2.5 seems fine. I'll reply with more details (and/or file a RH Bugzilla report) later today, after I double-check things in a more controlled environment. -Barry K. Nathan <barryn@pobox.com> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 2003-05-23 0:51 ` Barry K. Nathan @ 2003-05-23 5:32 ` Marc-Christian Petersen 2003-05-23 7:04 ` [BUG] 2.[45] ioperm fix seems broken (was Re: Linux 2.4.21-rc3) Barry K. Nathan 0 siblings, 1 reply; 47+ messages in thread From: Marc-Christian Petersen @ 2003-05-23 5:32 UTC (permalink / raw) To: Barry K. Nathan, Marcelo Tosatti; +Cc: lkml On Friday 23 May 2003 02:51, Barry K. Nathan wrote: Hi Barry, > > o ioperm fix > If this is the same code that's in Red Hat's latest security errata, I > think this may be broken (makes some programs segfault). 2.5 seems fine. > I'll reply with more details (and/or file a RH Bugzilla report) later > today, after I double-check things in a more controlled environment. nono, this fix is the right one. All works fine :-) ciao, Marc ^ permalink raw reply [flat|nested] 47+ messages in thread
* [BUG] 2.[45] ioperm fix seems broken (was Re: Linux 2.4.21-rc3) 2003-05-23 5:32 ` Marc-Christian Petersen @ 2003-05-23 7:04 ` Barry K. Nathan 2003-05-23 9:00 ` Barry K. Nathan 0 siblings, 1 reply; 47+ messages in thread From: Barry K. Nathan @ 2003-05-23 7:04 UTC (permalink / raw) To: Marc-Christian Petersen; +Cc: Barry K. Nathan, Marcelo Tosatti, lkml On Fri, May 23, 2003 at 07:32:49AM +0200, Marc-Christian Petersen wrote: > nono, this fix is the right one. All works fine :-) Nope, the ioperm fix seems to be breaking something alright. Eventually I was able to reproduce this on 2.5.69-mm[78] as well. Here's my distilled test case. (My real test case is FCE Ultra, compiled for svgalib. The crash happens in svgalib, version 1.4.3-cl1 if that matters.) ---cut here--- #include <sys/io.h> int main() { char c; if (ioperm(0x3b4, 0x3df - 0x3b4 + 1, 1)) { perror("ugh"); exit(1); } else printf("ioperm succeeded\n"); printf("About to perform inb...\n"); c = inb(0x3cc); printf("result: %d\n", (int)c); return 0; } ---cut here--- Steps to reproduce: 1. Compile this program (e.g., "gcc iopt.c" or "gcc -O2 iopt.c"). 2. Switch to a text virtual console. 3. Log in as root (or log in as a normal user and su to root). This program does not crash from within X, nor does it crash from an SSH session. 4. Run the program (e.g., "./a.out"). 5. The program will probably crash after "About to perfrom inb" but before "result:...". If not, try it again a few times. If it still doesn't crash for you, try logging in on another virtual console, or just wait a few minutes and try again. Sometimes it's 10% reproducible and sometimes it's well over 90% reproducible... 6. Examine the code/core using gdb. Notice that the inb caused the segfault. The real-world effect of this bug is that my NES emulator just broke almost completely. :( Interestingly, a somewhat reliable workaround for fceu (but not for my test case AFAICT) is to strace it rather than running it directly -- then it usually doesn't segfault. -Barry K. Nathan <barryn@pobox.com> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [BUG] 2.[45] ioperm fix seems broken (was Re: Linux 2.4.21-rc3) 2003-05-23 7:04 ` [BUG] 2.[45] ioperm fix seems broken (was Re: Linux 2.4.21-rc3) Barry K. Nathan @ 2003-05-23 9:00 ` Barry K. Nathan 0 siblings, 0 replies; 47+ messages in thread From: Barry K. Nathan @ 2003-05-23 9:00 UTC (permalink / raw) To: Barry K. Nathan; +Cc: Marc-Christian Petersen, Marcelo Tosatti, lkml On Fri, May 23, 2003 at 12:04:16AM -0700, Barry K. Nathan wrote: > Nope, the ioperm fix seems to be breaking something alright. Eventually > I was able to reproduce this on 2.5.69-mm[78] as well. The reason I "eventually" "reproduced" it on 2.5 is because I "eventually" ran an old, buggy version of my test case program that I forgot to delete. :( 2.5 is actually not affected by this bug. The 2.4 ioperm fix is truly, genuinely buggy, however. I'm going to send a patch within the next few hours (if not the next few minutes). -Barry K. Nathan <barryn@pobox.com> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 2003-05-22 22:19 Linux 2.4.21-rc3 Marcelo Tosatti 2003-05-22 23:46 ` J.A. Magallon 2003-05-23 0:51 ` Barry K. Nathan @ 2003-05-23 8:27 ` Benjamin Herrenschmidt 2003-05-23 13:38 ` Linux 2.4.21-rc3 - ipmi unresolved Eyal Lebedinsky ` (4 subsequent siblings) 7 siblings, 0 replies; 47+ messages in thread From: Benjamin Herrenschmidt @ 2003-05-23 8:27 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml > o add a hold field to reserve ide slots (needed for PPC) Ah good, you merged this one. I'm sending you separately a patch that makes use of this field in the pmac driver to fix the problem we had with ide-cs (among others) Ben. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 - ipmi unresolved 2003-05-22 22:19 Linux 2.4.21-rc3 Marcelo Tosatti ` (2 preceding siblings ...) 2003-05-23 8:27 ` Linux 2.4.21-rc3 Benjamin Herrenschmidt @ 2003-05-23 13:38 ` Eyal Lebedinsky 2003-05-23 13:41 ` Marc-Christian Petersen 2003-05-25 7:57 ` Keith Owens 2003-05-23 21:10 ` Linux 2.4.21-rc3 [net-pf-4, devfs audio, drm radeon] Gabor Z. Papp ` (3 subsequent siblings) 7 siblings, 2 replies; 47+ messages in thread From: Eyal Lebedinsky @ 2003-05-23 13:38 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml [-- Attachment #1: Type: text/plain, Size: 744 bytes --] Marcelo Tosatti wrote: > > Hi, > > Here goes the third release candidate of 2.4.21. > > Summary of changes from v2.4.21-rc2 to v2.4.21-rc3 > ============================================ [trim] > Alan Cox <alan@lxorguk.ukuu.org.uk>: > o fix ipmi screwup The exports in ksyms are still necessary, and missing: depmod: *** Unresolved symbols in /lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_msghandler.o depmod: panic_notifier_list depmod: *** Unresolved symbols in /lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_watchdog.o depmod: panic_notifier_list depmod: panic_timeout The attached snippet was part of the earlier, larger patch. -- Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/> [-- Attachment #2: 2.4.21-rc3-ipmi.patch --] [-- Type: text/plain, Size: 581 bytes --] --- linux/kernel/ksyms.c.orig Fri May 23 22:17:07 2003 +++ linux/kernel/ksyms.c Fri May 23 22:16:38 2003 @@ -65,6 +65,7 @@ extern int request_dma(unsigned int dmanr, char * deviceID); extern void free_dma(unsigned int dmanr); extern spinlock_t dma_spin_lock; +extern int panic_timeout; #ifdef CONFIG_MODVERSIONS const struct module_symbol __export_Using_Versions @@ -471,6 +472,8 @@ /* misc */ EXPORT_SYMBOL(panic); +EXPORT_SYMBOL(panic_notifier_list); +EXPORT_SYMBOL(panic_timeout); EXPORT_SYMBOL(__out_of_line_bug); EXPORT_SYMBOL(sprintf); EXPORT_SYMBOL(snprintf); ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 - ipmi unresolved 2003-05-23 13:38 ` Linux 2.4.21-rc3 - ipmi unresolved Eyal Lebedinsky @ 2003-05-23 13:41 ` Marc-Christian Petersen 2003-05-26 2:09 ` Corey Minyard 2003-05-25 7:57 ` Keith Owens 1 sibling, 1 reply; 47+ messages in thread From: Marc-Christian Petersen @ 2003-05-23 13:41 UTC (permalink / raw) To: Eyal Lebedinsky, Marcelo Tosatti; +Cc: lkml On Friday 23 May 2003 15:38, Eyal Lebedinsky wrote: Hi Eyal, > The exports in ksyms are still necessary, and missing: > depmod: *** Unresolved symbols in > /lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_msghandler.o > depmod: panic_notifier_list > depmod: *** Unresolved symbols in > /lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_watchdog.o > depmod: panic_notifier_list > depmod: panic_timeout > The attached snippet was part of the earlier, larger patch. I've send this fix 3 times and I gave up after silent ignores ;) ciao, Marc ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 - ipmi unresolved 2003-05-23 13:41 ` Marc-Christian Petersen @ 2003-05-26 2:09 ` Corey Minyard 0 siblings, 0 replies; 47+ messages in thread From: Corey Minyard @ 2003-05-26 2:09 UTC (permalink / raw) To: Marc-Christian Petersen; +Cc: Eyal Lebedinsky, Marcelo Tosatti, lkml Marc-Christian Petersen wrote: >On Friday 23 May 2003 15:38, Eyal Lebedinsky wrote: > >Hi Eyal, > > > >>The exports in ksyms are still necessary, and missing: >>depmod: *** Unresolved symbols in >>/lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_msghandler.o >>depmod: panic_notifier_list >>depmod: *** Unresolved symbols in >>/lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_watchdog.o >>depmod: panic_notifier_list >>depmod: panic_timeout >>The attached snippet was part of the earlier, larger patch. >> >> >I've send this fix 3 times and I gave up after silent ignores ;) > I've resent my fixes, Marcelo said earlier he would take them, but they didn't get into this release. -Corey ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 - ipmi unresolved 2003-05-23 13:38 ` Linux 2.4.21-rc3 - ipmi unresolved Eyal Lebedinsky 2003-05-23 13:41 ` Marc-Christian Petersen @ 2003-05-25 7:57 ` Keith Owens 2003-05-26 3:37 ` Corey Minyard 2003-05-26 17:08 ` Linux 2.4.21-rc3 - ipmi unresolved Alan Cox 1 sibling, 2 replies; 47+ messages in thread From: Keith Owens @ 2003-05-25 7:57 UTC (permalink / raw) To: Eyal Lebedinsky; +Cc: Marcelo Tosatti, lkml On Fri, 23 May 2003 23:38:53 +1000, Eyal Lebedinsky <eyal@eyal.emu.id.au> wrote: >The exports in ksyms are still necessary, and missing: > >depmod: *** Unresolved symbols in >/lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_msghandler.o >depmod: panic_notifier_list >depmod: *** Unresolved symbols in >/lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_watchdog.o >depmod: panic_notifier_list >depmod: panic_timeout Danger Will Robinson: panic notification to modules is racy. Registering via panic_notifier_list does not bump the module use count, a panic can occur while a module is being unloaded and you are dead. No big deal for panic, you are already dying, but it is just a symptom of a larger problem, yet another uncounted reference to module code. _ANY_ notifier callback to a module is racy, think very carefully before exporting any XXX_notifier_list. I would go so far as to say that no XXX_notifier_list should be exported, that includes notifier_chain_register() itself. If a module needs to be notified then it should have glue code in the main kernel that does try_inc_mod_count() on the module before calling any module functions. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 - ipmi unresolved 2003-05-25 7:57 ` Keith Owens @ 2003-05-26 3:37 ` Corey Minyard 2003-05-26 3:54 ` Keith Owens 2003-05-26 17:08 ` Linux 2.4.21-rc3 - ipmi unresolved Alan Cox 1 sibling, 1 reply; 47+ messages in thread From: Corey Minyard @ 2003-05-26 3:37 UTC (permalink / raw) To: Keith Owens; +Cc: Eyal Lebedinsky, Marcelo Tosatti, lkml Keith Owens wrote: >On Fri, 23 May 2003 23:38:53 +1000, >Eyal Lebedinsky <eyal@eyal.emu.id.au> wrote: > > >>The exports in ksyms are still necessary, and missing: >> >>depmod: *** Unresolved symbols in >>/lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_msghandler.o >>depmod: panic_notifier_list >>depmod: *** Unresolved symbols in >>/lib/modules/2.4.21-rc3/kernel/drivers/char/ipmi/ipmi_watchdog.o >>depmod: panic_notifier_list >>depmod: panic_timeout >> >> > >Danger Will Robinson: panic notification to modules is racy. > >Registering via panic_notifier_list does not bump the module use count, >a panic can occur while a module is being unloaded and you are dead. >No big deal for panic, you are already dying, but it is just a symptom >of a larger problem, yet another uncounted reference to module code. >_ANY_ notifier callback to a module is racy, think very carefully >before exporting any XXX_notifier_list. > >I would go so far as to say that no XXX_notifier_list should be >exported, that includes notifier_chain_register() itself. If a module >needs to be notified then it should have glue code in the main kernel >that does try_inc_mod_count() on the module before calling any module >functions. > Although, as you noted, this one is not a problem, you are probably right in general. However, having every modules that uses a notifier list have its own custom code in the kernel is probably not a very good option, either. It makes things messy and adds unneeded bloat to the kernel. Would it be possible to have a notifier_chain_register_module() that did the job generically? Or maybe if notifier_chain_unregister() did a synchronize_kernel() (the RCU call to wait until everything is clear) would that be good enough? It would only work if all the notifier chain calls where done while the kernel was unpreemptable, if I understand this correctly. I realize the RCU option is not available in 2.4, though. -Corey ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 - ipmi unresolved 2003-05-26 3:37 ` Corey Minyard @ 2003-05-26 3:54 ` Keith Owens 2003-05-27 0:30 ` Corey Minyard 0 siblings, 1 reply; 47+ messages in thread From: Keith Owens @ 2003-05-26 3:54 UTC (permalink / raw) To: Corey Minyard; +Cc: lkml On Sun, 25 May 2003 22:37:17 -0500, Corey Minyard <minyard@acm.org> wrote: >Keith Owens wrote: >>Danger Will Robinson: panic notification to modules is racy. >> >>Registering via panic_notifier_list does not bump the module use count, >>a panic can occur while a module is being unloaded and you are dead. >>No big deal for panic, you are already dying, but it is just a symptom >>of a larger problem, yet another uncounted reference to module code. >>_ANY_ notifier callback to a module is racy, think very carefully >>before exporting any XXX_notifier_list. >> >>I would go so far as to say that no XXX_notifier_list should be >>exported, that includes notifier_chain_register() itself. If a module >>needs to be notified then it should have glue code in the main kernel >>that does try_inc_mod_count() on the module before calling any module >>functions. >> >Although, as you noted, this one is not a problem, you are probably >right in general. > >However, having every modules that uses a notifier list have its own >custom code in the kernel is probably not a very good option, either. >It makes things messy and adds unneeded bloat to the kernel. > >Would it be possible to have a notifier_chain_register_module() that did >the job generically? notifier_chain_register_module() is possible, just pass __THIS_MODULE and the code that runs the notifier chain does try_inc_mod_count() before making the upcall. But that new function cannot be mixed with notifier_chain_register(), it has to be a complete replacement. Not going to happen in 2.4. I considered making notifier_chain_register() a macro which called notifier_chain_register_module() with __THIS_MODULE, but that assumes that all calls to notifier_chain_register() are local, i.e. from the top level functions. Alas there are any service routines that call notifier_chain_register() on behalf of their caller, so the macro approach will result in the wrong value for __THIS_MODULE. >Or maybe if notifier_chain_unregister() did a >synchronize_kernel() >(the RCU call to wait until everything is clear) would that be good >enough? It would >only work if all the notifier chain calls where done while the kernel >was unpreemptable, >if I understand this correctly. I realize the RCU option is not >available in 2.4, though. notifier_chain_unregister() is not a problem, that is a downcall from the module into the kernel when the module is going away, downcalls are "always" safe. The race is a module that has started to unload, and another cpu (or even the same cpu under some circumstances) runs the notifier chain, doing an upcall from the kernel into a module without locking or refcounts. Given the right timing, the notifier code could even branch to a module that has been completely removed. Note that notifier_call_chain() has no locking, so it is also racy against notifier_chain_unregister(). ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 - ipmi unresolved 2003-05-26 3:54 ` Keith Owens @ 2003-05-27 0:30 ` Corey Minyard 2003-05-27 3:09 ` Keith Owens 0 siblings, 1 reply; 47+ messages in thread From: Corey Minyard @ 2003-05-27 0:30 UTC (permalink / raw) To: Keith Owens; +Cc: lkml Keith Owens wrote: >On Sun, 25 May 2003 22:37:17 -0500, >Corey Minyard <minyard@acm.org> wrote: > > >>Keith Owens wrote: >> >> >>>Danger Will Robinson: panic notification to modules is racy. >>> >>>Registering via panic_notifier_list does not bump the module use count, >>>a panic can occur while a module is being unloaded and you are dead. >>>No big deal for panic, you are already dying, but it is just a symptom >>>of a larger problem, yet another uncounted reference to module code. >>>_ANY_ notifier callback to a module is racy, think very carefully >>>before exporting any XXX_notifier_list. >>> >>>I would go so far as to say that no XXX_notifier_list should be >>>exported, that includes notifier_chain_register() itself. If a module >>>needs to be notified then it should have glue code in the main kernel >>>that does try_inc_mod_count() on the module before calling any module >>>functions. >>> >>> >>> >>Although, as you noted, this one is not a problem, you are probably >>right in general. >> >>However, having every modules that uses a notifier list have its own >>custom code in the kernel is probably not a very good option, either. >>It makes things messy and adds unneeded bloat to the kernel. >> >>Would it be possible to have a notifier_chain_register_module() that did >>the job generically? >> >> > >notifier_chain_register_module() is possible, just pass __THIS_MODULE >and the code that runs the notifier chain does try_inc_mod_count() >before making the upcall. But that new function cannot be mixed with >notifier_chain_register(), it has to be a complete replacement. Not >going to happen in 2.4. > >I considered making notifier_chain_register() a macro which called >notifier_chain_register_module() with __THIS_MODULE, but that assumes >that all calls to notifier_chain_register() are local, i.e. from the >top level functions. Alas there are any service routines that call >notifier_chain_register() on behalf of their caller, so the macro >approach will result in the wrong value for __THIS_MODULE. > Why can't you have a module id in the notifier chain, and use a boolean to tell if it is set, or something similar to that? That way you could mix them, if the bool is set then do the try_in_module_count thing, if not then just call the function. It does add some components to the register structure, but that shouldn't hurt anything besides taking a little more memory. > > > >>Or maybe if notifier_chain_unregister() did a >>synchronize_kernel() >>(the RCU call to wait until everything is clear) would that be good >>enough? It would >>only work if all the notifier chain calls where done while the kernel >>was unpreemptable, >>if I understand this correctly. I realize the RCU option is not >>available in 2.4, though. >> >> > >notifier_chain_unregister() is not a problem, that is a downcall from >the module into the kernel when the module is going away, downcalls are >"always" safe. The race is a module that has started to unload, and >another cpu (or even the same cpu under some circumstances) runs the >notifier chain, doing an upcall from the kernel into a module without >locking or refcounts. Given the right timing, the notifier code could >even branch to a module that has been completely removed. Note that >notifier_call_chain() has no locking, so it is also racy against >notifier_chain_unregister(). > > You don't understand how the RCU code works. The race is as you describe. If notifier_chain_unregister() removes the item from the list and then calls synchronize_kernel(), and all the notifier calls are in unpreemptable sections, you guarantee that no one can be left that can call the notifier, they will all have left their preemptable sections before synchronize_kernel() will return. It's a little wierd, but it does work. If the calls to the notifier chain are outside unpreemptable sections, though, then there's no guaranteed of when they will run (with a preemptable kernel) so this won't work. -Corey ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 - ipmi unresolved 2003-05-27 0:30 ` Corey Minyard @ 2003-05-27 3:09 ` Keith Owens 2003-05-27 4:45 ` Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved) Corey Minyard 0 siblings, 1 reply; 47+ messages in thread From: Keith Owens @ 2003-05-27 3:09 UTC (permalink / raw) To: Corey Minyard; +Cc: lkml On Mon, 26 May 2003 19:30:04 -0500, Corey Minyard <minyard@acm.org> wrote: >Keith Owens wrote: >>I considered making notifier_chain_register() a macro which called >>notifier_chain_register_module() with __THIS_MODULE, but that assumes >>that all calls to notifier_chain_register() are local, i.e. from the >>top level functions. Alas there are any service routines that call >>notifier_chain_register() on behalf of their caller, so the macro >>approach will result in the wrong value for __THIS_MODULE. >> >Why can't you have a module id in the notifier chain, and use a boolean >to tell if it is set, or something similar to that? That way you could >mix them, if the bool is set then do the try_in_module_count thing, if >not then just call the function. It does add some components to the >register structure, but that shouldn't hurt anything besides taking a >little more memory. It is a change of API in a 2.4 kernel. Not a good idea. >>notifier_chain_unregister() is not a problem, that is a downcall from >>the module into the kernel when the module is going away, downcalls are >>"always" safe. The race is a module that has started to unload, and >>another cpu (or even the same cpu under some circumstances) runs the >>notifier chain, doing an upcall from the kernel into a module without >>locking or refcounts. Given the right timing, the notifier code could >>even branch to a module that has been completely removed. Note that >>notifier_call_chain() has no locking, so it is also racy against >>notifier_chain_unregister(). >> >> >You don't understand how the RCU code works. (a) I understand how RCU works, I was working on lock free code for years before RCU appeared in the kernel. (b) This is 2.4, not 2.5, there is no RCU. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved) 2003-05-27 3:09 ` Keith Owens @ 2003-05-27 4:45 ` Corey Minyard 2003-05-27 5:30 ` Keith Owens 0 siblings, 1 reply; 47+ messages in thread From: Corey Minyard @ 2003-05-27 4:45 UTC (permalink / raw) To: Keith Owens; +Cc: lkml Keith Owens wrote: >On Mon, 26 May 2003 19:30:04 -0500, >Corey Minyard <minyard@acm.org> wrote: > > >>Keith Owens wrote: >> >> >>>I considered making notifier_chain_register() a macro which called >>>notifier_chain_register_module() with __THIS_MODULE, but that assumes >>>that all calls to notifier_chain_register() are local, i.e. from the >>>top level functions. Alas there are any service routines that call >>>notifier_chain_register() on behalf of their caller, so the macro >>>approach will result in the wrong value for __THIS_MODULE. >>> >>> >>> >>Why can't you have a module id in the notifier chain, and use a boolean >>to tell if it is set, or something similar to that? That way you could >>mix them, if the bool is set then do the try_in_module_count thing, if >>not then just call the function. It does add some components to the >>register structure, but that shouldn't hurt anything besides taking a >>little more memory. >> >> > >It is a change of API in a 2.4 kernel. Not a good idea. > Does adding a field to a structure (where the user does not have to do anything with the field) change the API? That would be the only API change here. > > > >>>notifier_chain_unregister() is not a problem, that is a downcall from >>>the module into the kernel when the module is going away, downcalls are >>>"always" safe. The race is a module that has started to unload, and >>>another cpu (or even the same cpu under some circumstances) runs the >>>notifier chain, doing an upcall from the kernel into a module without >>>locking or refcounts. Given the right timing, the notifier code could >>>even branch to a module that has been completely removed. Note that >>>notifier_call_chain() has no locking, so it is also racy against >>>notifier_chain_unregister(). >>> >>> >>> >>> >>You don't understand how the RCU code works. >> >> > >(a) I understand how RCU works, I was working on lock free code for > years before RCU appeared in the kernel. > Then maybe I don't understand it. The writers of the RCU code pointed it out to me for a very similar situation. Why doesn't calling synchronize_kernel() in notifier_chain_unregister() fix the module unload and unregister races? Or perhaps not all notifier chains get called when the kernel is unpreemptable? You could turn preempt off in notifier_call_chain(), though that might have some bad effects. In the preemptable kernel case, I'm not sure if the RCU code waits until all threads of execution leave the kernel. If it does, then preemption shouldn't even matter. > >(b) This is 2.4, not 2.5, there is no RCU. > > Understood (I already said this). But I was thinking it might be a good addition to 2.5, if it solved the problem. -Corey ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved) 2003-05-27 4:45 ` Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved) Corey Minyard @ 2003-05-27 5:30 ` Keith Owens 2003-05-27 14:48 ` Corey Minyard 0 siblings, 1 reply; 47+ messages in thread From: Keith Owens @ 2003-05-27 5:30 UTC (permalink / raw) To: lkml On Mon, 26 May 2003 23:45:39 -0500, Corey Minyard <minyard@acm.org> wrote: >Keith Owens wrote: >>>Why can't you have a module id in the notifier chain, and use a boolean >>>to tell if it is set, or something similar to that? That way you could >>>mix them, if the bool is set then do the try_in_module_count thing, if >>>not then just call the function. It does add some components to the >>>register structure, but that shouldn't hurt anything besides taking a >>>little more memory. >> >>It is a change of API in a 2.4 kernel. Not a good idea. >> >Does adding a field to a structure (where the user does not have to do >anything with the >field) change the API? That would be the only API change here. The user does have to do something. Every piece of code that calls notify_register has to set the new field to __THIS_MODULE. WIthout that field being set, you are no better off, the race still exists. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved) 2003-05-27 5:30 ` Keith Owens @ 2003-05-27 14:48 ` Corey Minyard 2003-05-27 16:02 ` viro 0 siblings, 1 reply; 47+ messages in thread From: Corey Minyard @ 2003-05-27 14:48 UTC (permalink / raw) To: Keith Owens; +Cc: lkml [-- Attachment #1: Type: text/plain, Size: 1346 bytes --] Keith Owens wrote: >On Mon, 26 May 2003 23:45:39 -0500, >Corey Minyard <minyard@acm.org> wrote: > > >>Keith Owens wrote: >> >> >>>>Why can't you have a module id in the notifier chain, and use a boolean >>>>to tell if it is set, or something similar to that? That way you could >>>>mix them, if the bool is set then do the try_in_module_count thing, if >>>>not then just call the function. It does add some components to the >>>>register structure, but that shouldn't hurt anything besides taking a >>>>little more memory. >>>> >>>> >>>It is a change of API in a 2.4 kernel. Not a good idea. >>> >>> >>> >>Does adding a field to a structure (where the user does not have to do >>anything with the >>field) change the API? That would be the only API change here. >> >> > >The user does have to do something. Every piece of code that calls >notify_register has to set the new field to __THIS_MODULE. WIthout >that field being set, you are no better off, the race still exists. > Why? The user doesn't have to set the field, you can let the registration code do that. I have attached a patch as an example. (It also seems safer to get the next field from the notifier before calling it, in case the called code removes itself and puts itself on another list, or something like that, so I made that change). -Corey [-- Attachment #2: module-notifier.diff --] [-- Type: text/plain, Size: 3732 bytes --] Index: include/linux/notifier.h =================================================================== RCS file: /home/cvs/linux-2.4/include/linux/notifier.h,v retrieving revision 1.3 diff -u -r1.3 notifier.h --- include/linux/notifier.h 4 Aug 2002 00:02:49 -0000 1.3 +++ include/linux/notifier.h 27 May 2003 13:39:02 -0000 @@ -10,18 +10,22 @@ #ifndef _LINUX_NOTIFIER_H #define _LINUX_NOTIFIER_H #include <linux/errno.h> +#include <linux/module.h> struct notifier_block { int (*notifier_call)(struct notifier_block *self, unsigned long, void *); struct notifier_block *next; int priority; + + struct module *owner; /* NULL if not from a module */ }; #ifdef __KERNEL__ extern int notifier_chain_register(struct notifier_block **list, struct notifier_block *n); +extern int notifier_chain_register_module(struct notifier_block **list, struct notifier_block *n, struct module *owner); extern int notifier_chain_unregister(struct notifier_block **nl, struct notifier_block *n); extern int notifier_call_chain(struct notifier_block **n, unsigned long val, void *v); Index: kernel/sys.c =================================================================== RCS file: /home/cvs/linux-2.4/kernel/sys.c,v retrieving revision 1.14 diff -u -r1.14 sys.c --- kernel/sys.c 9 May 2003 00:35:17 -0000 1.14 +++ kernel/sys.c 27 May 2003 13:39:03 -0000 @@ -71,16 +71,19 @@ rwlock_t notifier_lock = RW_LOCK_UNLOCKED; /** - * notifier_chain_register - Add notifier to a notifier chain + * notifier_chain_register_module - Add notifier to a notifier chain + * for a module. + * * @list: Pointer to root list pointer * @n: New entry in notifier chain + * @owner: The module that owns this notifier block * * Adds a notifier to a notifier chain. * * Currently always returns zero. */ -int notifier_chain_register(struct notifier_block **list, struct notifier_block *n) +int notifier_chain_register_module(struct notifier_block **list, struct notifier_block *n, struct module *owner) { write_lock(¬ifier_lock); while(*list) @@ -90,12 +93,28 @@ list= &((*list)->next); } n->next = *list; + n->owner = owner; *list=n; write_unlock(¬ifier_lock); return 0; } /** + * notifier_chain_register - Add notifier to a notifier chain + * @list: Pointer to root list pointer + * @n: New entry in notifier chain + * + * Adds a notifier to a notifier chain. + * + * Currently always returns zero. + */ + +int notifier_chain_register(struct notifier_block **list, struct notifier_block *n) +{ + return notifier_chain_register_module(list, n, NULL); +} + +/** * notifier_chain_unregister - Remove notifier from a notifier chain * @nl: Pointer to root list pointer * @n: New entry in notifier chain @@ -128,7 +147,8 @@ * @val: Value passed unmodified to notifier function * @v: Pointer passed unmodified to notifier function * - * Calls each function in a notifier chain in turn. + * Calls each function in a notifier chain in turn. If it is owned + * by a module, increment that module's use count while in the call. * * If the return value of the notifier can be and'd * with %NOTIFY_STOP_MASK, then notifier_call_chain @@ -142,15 +162,24 @@ { int ret=NOTIFY_DONE; struct notifier_block *nb = *n; + struct notifier_block *next; + struct module *owner; - while(nb) + for (; nb; nb=next) { + owner = nb->owner; + next = nb->next; + if ((owner) && (!try_inc_mod_count(owner))) + /* The module that owns us has ceased to + exist, just go on. */ + continue; ret=nb->notifier_call(nb,val,v); + if (owner) + __MOD_DEC_USE_COUNT(owner); if(ret&NOTIFY_STOP_MASK) { return ret; } - nb=nb->next; } return ret; } ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved) 2003-05-27 14:48 ` Corey Minyard @ 2003-05-27 16:02 ` viro 2003-05-27 17:09 ` Corey Minyard 0 siblings, 1 reply; 47+ messages in thread From: viro @ 2003-05-27 16:02 UTC (permalink / raw) To: Corey Minyard; +Cc: Keith Owens, lkml On Tue, May 27, 2003 at 09:48:53AM -0500, Corey Minyard wrote: > >The user does have to do something. Every piece of code that calls > >notify_register has to set the new field to __THIS_MODULE. WIthout > >that field being set, you are no better off, the race still exists. > > > Why? The user doesn't have to set the field, you can let the > registration code do that. I have attached a patch as an example. How the devil would registration code figure out which module should be used? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved) 2003-05-27 16:02 ` viro @ 2003-05-27 17:09 ` Corey Minyard 2003-05-28 0:15 ` Keith Owens 0 siblings, 1 reply; 47+ messages in thread From: Corey Minyard @ 2003-05-27 17:09 UTC (permalink / raw) To: viro; +Cc: Keith Owens, lkml viro@parcelfarce.linux.theplanet.co.uk wrote: >On Tue, May 27, 2003 at 09:48:53AM -0500, Corey Minyard wrote: > > > >>>The user does have to do something. Every piece of code that calls >>>notify_register has to set the new field to __THIS_MODULE. WIthout >>>that field being set, you are no better off, the race still exists. >>> >>> >>> >>Why? The user doesn't have to set the field, you can let the >>registration code do that. I have attached a patch as an example. >> >> > >How the devil would registration code figure out which module should >be used? > > You create a new call that also takes the module as a parameter, and have the old call set the module owner to NULL. You export the new call, and modules use it. -Corey ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved) 2003-05-27 17:09 ` Corey Minyard @ 2003-05-28 0:15 ` Keith Owens 0 siblings, 0 replies; 47+ messages in thread From: Keith Owens @ 2003-05-28 0:15 UTC (permalink / raw) To: Corey Minyard; +Cc: viro, lkml On Tue, 27 May 2003 12:09:12 -0500, Corey Minyard <minyard@acm.org> wrote: >viro@parcelfarce.linux.theplanet.co.uk wrote: viro>>How the devil would registration code figure out which module should viro>>be used? I am glad that somebody gets it. minyard>You create a new call that also takes the module as a parameter, and minyard>have the old call set the module owner to NULL. You export the new minyard>call, and modules use it. Which brings us right back to where we started. * Find all users of notifier_chain_register() and change them to the new API. * If any of the calls to notifier_chain_register() are in service routines then add a new parameter to the service routine to pass in the module owner. There are several service routines that do this, especially in the network code. * Find all callers of all the modified service routines and change them to use the new API for these service routines. * Repeat until you have propagated the new API all the way out to the end points, to the only code that knows the module owner. Not in 2.4 thanks. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 - ipmi unresolved 2003-05-25 7:57 ` Keith Owens 2003-05-26 3:37 ` Corey Minyard @ 2003-05-26 17:08 ` Alan Cox 1 sibling, 0 replies; 47+ messages in thread From: Alan Cox @ 2003-05-26 17:08 UTC (permalink / raw) To: Keith Owens; +Cc: Eyal Lebedinsky, Marcelo Tosatti, lkml On Sul, 2003-05-25 at 08:57, Keith Owens wrote: > I would go so far as to say that no XXX_notifier_list should be > exported, that includes notifier_chain_register() itself. If a module > needs to be notified then it should have glue code in the main kernel > that does try_inc_mod_count() on the module before calling any module > functions. That would be mindbogglingly ugly. Unfortunately Rusty has still only half solved the module problem because modules are refcounted as an "entity" not the module info and the module code/data split into two. Ie I can't unload a module that has module object references because we have no way to seperate "I'm talking about module xyz" and "I'm jumping into module xyz". That IMHO is what is causing much of the remaining mess. Were they split then I could safely take a module object reference in the notifiers and have try_inc_mod_count() do the right thing passed a module handle to a module that is unloaded but has object references left. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 [net-pf-4, devfs audio, drm radeon] 2003-05-22 22:19 Linux 2.4.21-rc3 Marcelo Tosatti ` (3 preceding siblings ...) 2003-05-23 13:38 ` Linux 2.4.21-rc3 - ipmi unresolved Eyal Lebedinsky @ 2003-05-23 21:10 ` Gabor Z. Papp 2003-05-25 17:36 ` Linux 2.4.21-rc3 : IDE pb on Alpha Willy Tarreau ` (2 subsequent siblings) 7 siblings, 0 replies; 47+ messages in thread From: Gabor Z. Papp @ 2003-05-23 21:10 UTC (permalink / raw) To: linux-kernel * Marcelo Tosatti <marcelo@conectiva.com.br>: | Here goes the third release candidate of 2.4.21. A few comments: kmod: failed to exec /sbin/modprobe -s -k net-pf-4, errno = 2 appears since 2.4.18 or so, dunno what really mean. net-pf-4 set to off in modules.conf... devfs_register(audio): could not append to parent, err: -17 New in -rc3. Soundcard: 02:09.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev 12) Using alsa driver 0.9.3c. And finally: [drm] Initialized radeon 1.1.1 20010405 on minor 0 [drm:radeon_unlock] *ERROR* Process 100 using kernel context 0 00:01.0 PCI bridge: Intel Corp. 82830 830 Chipset AGP Bridge (rev 04) (prog-if 00 [Normal decode]) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA]) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-22 22:19 Linux 2.4.21-rc3 Marcelo Tosatti ` (4 preceding siblings ...) 2003-05-23 21:10 ` Linux 2.4.21-rc3 [net-pf-4, devfs audio, drm radeon] Gabor Z. Papp @ 2003-05-25 17:36 ` Willy Tarreau 2003-05-25 17:00 ` Willy Tarreau 2003-05-26 7:28 ` Linux 2.4.21-rc3: doesn't build with CONFIG_BLK_DEV_HD_ONLY=y Jerome Chantelauze 2003-05-26 13:16 ` Linux 2.4.21-rc3 Santiago Garcia Mantinan 7 siblings, 1 reply; 47+ messages in thread From: Willy Tarreau @ 2003-05-25 17:36 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml Hi all ! I've upgraded my Alpha's kernel to 2.4.21-rc3, but it hangs on IDE at boot. Same with 2.4.21-rc2. It has been working one year on with 2.4.19-pre7 + Andre Hedrick's IDE patch. I'm now recompiling without DMA support, just in case. For info, this is a DS10, EV6/466, 256 MB RAM, with an ALI 1543 IDE controller. The first IDE controller has an old WD23200 (3.2GB) disk attached, which hosts the root FS. The second controller has a 120 GB Maxtor drive. I tried to boot with ide[01]=reset, ide[01]=noprobe, but with no luck. I've quickly written down the last messages during ide0=noprobe : hdc: Maxtor 6Y120L0, ATA DISK drive blk: queue at ffff...?????, no I/O memory limit ide1 at 0x170-0x177,0x376 on irq 15 hdc: attached ide-disk driver ------ stops here ------ I can play with sysrq during a few seconds, before the keyboard finally locks. I'll try to get some pointers with SysRq-P. If I boot with ide0=noprobe ide1=noprobe, it goes further, even detects the SCSI disks attached to an Adaptec controller, then panics because of a missing root device, thus proving that IDE really is the culprit here :-) GCC is 3.2.3. I could revert to an old 2.91.66 which is still installed on this system, if needed. The compilation just ended, I'll retry without DMA. Cheers, Willy .config appended with all unset options stripped : CONFIG_ALPHA=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_KMOD=y CONFIG_ALPHA_DP264=y CONFIG_ISA=y CONFIG_EISA=y CONFIG_PCI=y CONFIG_ALPHA_EV6=y CONFIG_ALPHA_TSUNAMI=y CONFIG_ALPHA_SRM=y CONFIG_EARLY_PRINTK=y CONFIG_PCI_NAMES=y CONFIG_NET=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_SRM_ENV=y CONFIG_BINFMT_ELF=y CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y CONFIG_PNP=y CONFIG_ISAPNP=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y CONFIG_BLK_DEV_LVM=y CONFIG_PACKET=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_INET_ECN=y CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_PKTTYPE=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_AH_ESP=y CONFIG_IP_NF_MATCH_LENGTH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_UNCLEAN=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_MIRROR=y CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_TCPMSS=y CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_VLAN_8021Q=y CONFIG_BRIDGE=m CONFIG_NET_PKTGEN=m CONFIG_IDE=y MAX_HWIFS=4 CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDESCSI=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_GENERIC=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=y CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=253 CONFIG_AIC7XXX_RESET_DELAY_MS=5000 CONFIG_SCSI_MEGARAID=m CONFIG_SCSI_NCR53C8XX=m CONFIG_SCSI_SYM53C8XX=m CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8 CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32 CONFIG_SCSI_NCR53C8XX_SYNC=20 CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_NET_ETHERNET=y CONFIG_HAPPYMEAL=m CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_ADAPTEC_STARFIRE=m CONFIG_TULIP=m CONFIG_TULIP_MWI=y CONFIG_EEPRO100=m CONFIG_8139TOO=m CONFIG_ACENIC=m CONFIG_ACENIC_OMIT_TIGON_I=y CONFIG_DL2K=m CONFIG_E1000=m CONFIG_TIGON3=m CONFIG_PPP=m CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m CONFIG_I2C=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_CHARDEV=m CONFIG_I2C_PROC=m CONFIG_MOUSE=y CONFIG_PSMOUSE=y CONFIG_WATCHDOG=y CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m CONFIG_SOFT_WATCHDOG=m CONFIG_RTC=y CONFIG_VIDEO_DEV=m CONFIG_REISERFS_FS=y CONFIG_EXT3_FS=y CONFIG_JBD=y CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_MINIX_FS=m CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=y CONFIG_CODA_FS=m CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_TCP=y CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_ZISOFS_FS=y CONFIG_PARTITION_ADVANCED=y CONFIG_OSF_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_15=y CONFIG_VGA_CONSOLE=y CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y CONFIG_FB_MATROX=y CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_PCI_CONSOLE=y CONFIG_SOUND=y CONFIG_SOUND_ES1371=m CONFIG_ALPHA_LEGACY_START_ADDRESS=y CONFIG_DEBUG_KERNEL=y CONFIG_MATHEMU=y CONFIG_MAGIC_SYSRQ=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-25 17:36 ` Linux 2.4.21-rc3 : IDE pb on Alpha Willy Tarreau @ 2003-05-25 17:00 ` Willy Tarreau 2003-05-25 20:37 ` Mike Fedyk 0 siblings, 1 reply; 47+ messages in thread From: Willy Tarreau @ 2003-05-25 17:00 UTC (permalink / raw) To: Willy Tarreau; +Cc: Marcelo Tosatti, lkml Hi again ! the system could boot without DMA. It displayed lots of messages, but it seems to work : Linux version 2.4.21-rc3 (root@alpha) (gcc version 3.2.3) #4 Sun May 25 19:16:43 CEST 2003 Booting on Tsunami variation Webbrick using machine vector Webbrick from SRM Command line: root=/dev/hda2 console=tty0 console=ttyS0,9600 bootdevice=scd0 bootfile=2.4.21-rc3/vmlinux memcluster 0, usage 1, start 0, end 256 memcluster 1, usage 0, start 256, end 32655 memcluster 2, usage 1, start 32655, end 32768 freeing pages 256:384 freeing pages 805:32655 reserving pages 805:806 On node 0 totalpages: 32655 zone(0): 32655 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/hda2 console=tty0 console=ttyS0,9600 bootdevice=scd0 bootfile=2.4.21-rc3/vmlinux Using epoch = 1952 Console: colour VGA+ 80x25 Calibrating delay loop... 921.84 BogoMIPS Memory: 252720k/261240k available (2094k kernel code, 6472k reserved, 451k data, 320k init) Dentry cache hash table entries: 32768 (order: 6, 524288 bytes) Inode cache hash table entries: 16384 (order: 5, 262144 bytes) Mount cache hash table entries: 512 (order: 0, 8192 bytes) Buffer-cache hash table entries: 8192 (order: 3, 65536 bytes) Page-cache hash table entries: 32768 (order: 5, 262144 bytes) POSIX conformance testing by UNIFIX PCI: dev Adaptec AIC-7892A U160/m type 64-bit isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket srm_env: version 0.0.5 loaded successfully Starting kswapd Journalled Block Device driver loaded pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A rtc: Digital UNIX epoch (1952) detected Real Time Clock Driver v1.10e Floppy drive(s): fd0 is 2.88M FDC 0 is a post-1991 82077 Uniform Multi-Platform E-IDE driver Revision: 7.00beta3-.2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hda: WDC AC23200L, ATA DISK drive hdc: Maxtor 6Y120L0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: attached ide-disk driver. hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } hda: task_no_data_intr: error=0x04 { DriveStatusError } hda: host protected area => 1 hda: 6346368 sectors (3249 MB) w/256KiB Cache, CHS=6296/16/63 hdc: attached ide-disk driver. hdc: host protected area => 1 hdc: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=238216/16/63 Partition check: hda: hda1 hda2 hda3 hda7 hdc: hdc1 SCSI subsystem driver Revision: 1.00 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8 <Adaptec 29160 Ultra160 SCSI adapter> aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs blk: queue fffffc00002214e8, no I/O memory limit Vendor: HP Model: C1537A Rev: L706 Type: Sequential-Access ANSI SCSI revision: 02 blk: queue fffffc00002216e8, no I/O memory limit Vendor: COMPAQ Model: BD01864552 Rev: 3B04 Type: Direct-Access ANSI SCSI revision: 02 blk: queue fffffc00002218e8, no I/O memory limit Vendor: COMPAQ Model: BD01864552 Rev: 3B04 Type: Direct-Access ANSI SCSI revision: 02 blk: queue fffffc0000221ae8, no I/O memory limit Vendor: COMPAQ Model: BD01864552 Rev: 3B04 Type: Direct-Access ANSI SCSI revision: 02 blk: queue fffffc0000221ce8, no I/O memory limit Vendor: COMPAQ Model: BD01864552 Rev: 3B04 Type: Direct-Access ANSI SCSI revision: 02 blk: queue fffffc000feee128, no I/O memory limit ------ After that, nothing special. I'm amazed by the number of "blk: queue..." messages. This time, it only appears on SCSI, and not on IDE anymore. So it seems as the IDE problem is in the ALI 1543 / DMA code. I have an old K6/2 notebook somewhere with the same IDE controller, so I may retry on it. I'm interested in any suggestion, of course ;-) Willy ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-25 17:00 ` Willy Tarreau @ 2003-05-25 20:37 ` Mike Fedyk 2003-05-25 20:45 ` Bartlomiej Zolnierkiewicz 0 siblings, 1 reply; 47+ messages in thread From: Mike Fedyk @ 2003-05-25 20:37 UTC (permalink / raw) To: Willy Tarreau; +Cc: Marcelo Tosatti, lkml On Sun, May 25, 2003 at 07:00:46PM +0200, Willy Tarreau wrote: > hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } > hda: task_no_data_intr: error=0x04 { DriveStatusError } Can you revert back to your previous kernel and run badblocks read-only on it a few times. Your drive may be going bad. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-25 20:37 ` Mike Fedyk @ 2003-05-25 20:45 ` Bartlomiej Zolnierkiewicz 2003-05-25 20:55 ` Mike Fedyk 0 siblings, 1 reply; 47+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2003-05-25 20:45 UTC (permalink / raw) To: Mike Fedyk; +Cc: Willy Tarreau, Marcelo Tosatti, lkml Everything is okay, older drives don't understand some commands. I will fix it, but now its low on my TODO list. On Sun, 25 May 2003, Mike Fedyk wrote: > On Sun, May 25, 2003 at 07:00:46PM +0200, Willy Tarreau wrote: > > hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } > > hda: task_no_data_intr: error=0x04 { DriveStatusError } > > Can you revert back to your previous kernel and run badblocks read-only on > it a few times. Your drive may be going bad. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-25 20:45 ` Bartlomiej Zolnierkiewicz @ 2003-05-25 20:55 ` Mike Fedyk 2003-05-25 21:23 ` Bartlomiej Zolnierkiewicz 0 siblings, 1 reply; 47+ messages in thread From: Mike Fedyk @ 2003-05-25 20:55 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz; +Cc: Willy Tarreau, Marcelo Tosatti, lkml On Sun, May 25, 2003 at 10:45:00PM +0200, Bartlomiej Zolnierkiewicz wrote: > On Sun, 25 May 2003, Mike Fedyk wrote: > > > On Sun, May 25, 2003 at 07:00:46PM +0200, Willy Tarreau wrote: > > > hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } > > > hda: task_no_data_intr: error=0x04 { DriveStatusError } > > > > Can you revert back to your previous kernel and run badblocks read-only on > > it a few times. Your drive may be going bad. > > > > Everything is okay, older drives don't understand some commands. > I will fix it, but now its low on my TODO list. > Bart, is there any chace you could change the printks to show the name of the command that caused the drive to produce the error (assuming non ide-tcq, with tcq I'd immagine that it'd be a bit harder). This way someone who hasn't read the IDE spec might be able to tell that this isn't a warning of impending failure. BTW, is this information encoded in the two lines above somewhere, and if so how would I read it? Thanks, Mike ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-25 20:55 ` Mike Fedyk @ 2003-05-25 21:23 ` Bartlomiej Zolnierkiewicz 0 siblings, 0 replies; 47+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2003-05-25 21:23 UTC (permalink / raw) To: Mike Fedyk; +Cc: Willy Tarreau, Marcelo Tosatti, lkml On Sun, 25 May 2003, Mike Fedyk wrote: > On Sun, May 25, 2003 at 10:45:00PM +0200, Bartlomiej Zolnierkiewicz wrote: > > On Sun, 25 May 2003, Mike Fedyk wrote: > > > > > On Sun, May 25, 2003 at 07:00:46PM +0200, Willy Tarreau wrote: > > > > hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } > > > > hda: task_no_data_intr: error=0x04 { DriveStatusError } > > > > > > Can you revert back to your previous kernel and run badblocks read-only on > > > it a few times. Your drive may be going bad. > > > > > > > > Everything is okay, older drives don't understand some commands. > > I will fix it, but now its low on my TODO list. > Bart, is there any chace you could change the printks to show the name of > the command that caused the drive to produce the error (assuming non > ide-tcq, with tcq I'd immagine that it'd be a bit harder). For taskfile based IO its trivial, but IDE is not yet switched to it (will be soon). > This way someone who hasn't read the IDE spec might be able to tell that > this isn't a warning of impending failure. > BTW, is this information encoded in the two lines above somewhere, and if so > how would I read it? Only failed irq handler, drive status and error returned by drive. "error = 0x04" means command aborted. Regards, -- Bartlomiej > Thanks, > > Mike ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3: doesn't build with CONFIG_BLK_DEV_HD_ONLY=y 2003-05-22 22:19 Linux 2.4.21-rc3 Marcelo Tosatti ` (5 preceding siblings ...) 2003-05-25 17:36 ` Linux 2.4.21-rc3 : IDE pb on Alpha Willy Tarreau @ 2003-05-26 7:28 ` Jerome Chantelauze 2003-05-26 13:16 ` Linux 2.4.21-rc3 Santiago Garcia Mantinan 7 siblings, 0 replies; 47+ messages in thread From: Jerome Chantelauze @ 2003-05-26 7:28 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: linux-kernel On Thu, May 22, 2003 at 07:19:38PM -0300, Marcelo Tosatti wrote: > > Hi, > > Here goes the third release candidate of 2.4.21. > kernel 2.4.21-rc3 doesn't build with CONFIG_BLK_DEV_HD_ONLY=y and CONFIG_BLK_DEV_IDE not set (a patch is included): make -C ide make[2]: Entering directory `/usr/src/linux-2.4.21-rc3/drivers/ide' make all_targets make[3]: Entering directory `/usr/src/linux-2.4.21-rc3/drivers/ide' rm -f idedriver.o ld -m elf_i386 -r -o idedriver.o legacy/idedriver-legacy.o ld: cannot open legacy/idedriver-legacy.o: No such file or directory make[3]: *** [idedriver.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.21-rc3/drivers/ide' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.21-rc3/drivers/ide' make[1]: *** [_subdir_ide] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.21-rc3/drivers' make: *** [_dir_drivers] Error 2 This patch fixes the problem. *** drivers/ide/Makefile.orig Sun May 25 17:51:24 2003 --- drivers/ide/Makefile Sun May 25 17:51:32 2003 *************** *** 19,24 **** --- 19,26 ---- obj-m := ide-obj-y := + subdir-$(CONFIG_BLK_DEV_HD_ONLY) += legacy + subdir-$(CONFIG_BLK_DEV_IDE) += legacy ppc arm raid pci # First come modules that register themselves with the core Best regards. -- Jerome Chantelauze. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 2003-05-22 22:19 Linux 2.4.21-rc3 Marcelo Tosatti ` (6 preceding siblings ...) 2003-05-26 7:28 ` Linux 2.4.21-rc3: doesn't build with CONFIG_BLK_DEV_HD_ONLY=y Jerome Chantelauze @ 2003-05-26 13:16 ` Santiago Garcia Mantinan 2003-05-27 1:14 ` Jeff Chua 7 siblings, 1 reply; 47+ messages in thread From: Santiago Garcia Mantinan @ 2003-05-26 13:16 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: lkml This has been around the 2.4.21 pre series for quite some time, I thought it was known, but as it has not yet been fixed, I'm doubting it. If you try to compile ide as modules you get unresolved symbols: depmod: *** Unresolved symbols in /lib/modules/2.4.21-rc3/kernel/drivers/ide/ide-disk.o depmod: proc_ide_read_geometry depmod: ide_remove_proc_entries depmod: *** Unresolved symbols in /lib/modules/2.4.21-rc3/kernel/drivers/ide/ide-probe.o depmod: do_ide_request depmod: ide_add_generic_settings depmod: create_proc_ide_interfaces depmod: *** Unresolved symbols in /lib/modules/2.4.21-rc3/kernel/drivers/ide/ide.o depmod: ide_release_dma depmod: ide_add_proc_entries depmod: pnpide_init depmod: ide_scan_pcibus depmod: proc_ide_read_capacity depmod: proc_ide_create depmod: ide_remove_proc_entries depmod: destroy_proc_ide_drives depmod: proc_ide_destroy depmod: create_proc_ide_interfaces In case the compiler or anything else could affect this, I'm running gcc 3.3 in Debian sid. Regards... -- Manty/BestiaTester -> http://manty.net ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 2003-05-26 13:16 ` Linux 2.4.21-rc3 Santiago Garcia Mantinan @ 2003-05-27 1:14 ` Jeff Chua 0 siblings, 0 replies; 47+ messages in thread From: Jeff Chua @ 2003-05-27 1:14 UTC (permalink / raw) To: Santiago Garcia Mantinan; +Cc: Marcelo Tosatti, lkml The only around the problem is to do this ... CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=m CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDEFLOPPY=m CONFIG_BLK_DEV_IDESCSI=m CONFIG_BLK_DEV_IDEPCI=y Thanks, Jeff [ jchua@fedex.com ] On Mon, 26 May 2003, Santiago Garcia Mantinan wrote: > This has been around the 2.4.21 pre series for quite some time, I thought it > was known, but as it has not yet been fixed, I'm doubting it. > > If you try to compile ide as modules you get unresolved symbols: > > depmod: *** Unresolved symbols in > /lib/modules/2.4.21-rc3/kernel/drivers/ide/ide-disk.o > depmod: proc_ide_read_geometry > depmod: ide_remove_proc_entries > depmod: *** Unresolved symbols in > /lib/modules/2.4.21-rc3/kernel/drivers/ide/ide-probe.o > depmod: do_ide_request > depmod: ide_add_generic_settings > depmod: create_proc_ide_interfaces > depmod: *** Unresolved symbols in > /lib/modules/2.4.21-rc3/kernel/drivers/ide/ide.o > depmod: ide_release_dma > depmod: ide_add_proc_entries > depmod: pnpide_init > depmod: ide_scan_pcibus > depmod: proc_ide_read_capacity > depmod: proc_ide_create > depmod: ide_remove_proc_entries > depmod: destroy_proc_ide_drives > depmod: proc_ide_destroy > depmod: create_proc_ide_interfaces > > In case the compiler or anything else could affect this, I'm running gcc 3.3 > in Debian sid. > > Regards... > -- > Manty/BestiaTester -> http://manty.net > - > 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] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha @ 2003-05-27 3:37 Jason Papadopoulos 2003-05-27 4:53 ` Willy Tarreau 0 siblings, 1 reply; 47+ messages in thread From: Jason Papadopoulos @ 2003-05-27 3:37 UTC (permalink / raw) To: linux-kernel >the system could boot without DMA. It displayed lots of messages, but it seems >to work : >So it seems as the IDE problem is in the ALI 1543 / DMA code. I have an old >K6/2 notebook somewhere with the same IDE controller, so I may retry on it. > >I'm interested in any suggestion, of course ;-) I have the same system and run into the same problems here. The HD is a Fujitsu MPD3108AT (10GB ATA33/66 drive, what the machine shipped with) on hda. Even with the 2.4.21-rc4 kernel, the machine will not boot beyond the "attached ide-disk driver" message if IDE DMA is compiled in. Whatever's going wrong doesn't require an older drive to show up. Let me know how I can help, jasonp ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-27 3:37 Linux 2.4.21-rc3 : IDE pb on Alpha Jason Papadopoulos @ 2003-05-27 4:53 ` Willy Tarreau 2003-05-27 9:40 ` Ivan Kokshaysky 0 siblings, 1 reply; 47+ messages in thread From: Willy Tarreau @ 2003-05-27 4:53 UTC (permalink / raw) To: Jason Papadopoulos; +Cc: linux-kernel, marcelo On Mon, May 26, 2003 at 11:37:04PM -0400, Jason Papadopoulos wrote: > I have the same system and run into the same problems here. The HD is a > Fujitsu MPD3108AT (10GB ATA33/66 drive, what the machine shipped with) > on hda. Even with the 2.4.21-rc4 kernel, the machine will not boot beyond > the "attached ide-disk driver" message if IDE DMA is compiled in. > > Whatever's going wrong doesn't require an older drive to show up. I could finally enable DMA, only if I do it at run time : - enable "Generic PCI bus master DMA support" - disable "Use PCI DMA by default when available" - hdparm -d 1 /dev/every_disk I realized that a "idex=nodma" option is really lacking here. Shouldn't we disable IDE by default on Alpha at the moment, so that it at least boots ? The adventurous could always use hdparm to enable it again (it survived my 39 GB save/restore). Regards, Willy ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-27 4:53 ` Willy Tarreau @ 2003-05-27 9:40 ` Ivan Kokshaysky 2003-05-27 12:31 ` Willy Tarreau 0 siblings, 1 reply; 47+ messages in thread From: Ivan Kokshaysky @ 2003-05-27 9:40 UTC (permalink / raw) To: Willy Tarreau; +Cc: Jason Papadopoulos, linux-kernel, marcelo On Tue, May 27, 2003 at 06:53:02AM +0200, Willy Tarreau wrote: > I realized that a "idex=nodma" option is really lacking here. Shouldn't we > disable IDE by default on Alpha at the moment, so that it at least boots ? According to your .config and dmesg output, you didn't have the chipset driver compiled in (CONFIG_BLK_DEV_ALI15X3). Naturally, you would have troubles with DMA. Ivan. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-27 9:40 ` Ivan Kokshaysky @ 2003-05-27 12:31 ` Willy Tarreau 2003-05-27 14:04 ` Ivan Kokshaysky 0 siblings, 1 reply; 47+ messages in thread From: Willy Tarreau @ 2003-05-27 12:31 UTC (permalink / raw) To: Ivan Kokshaysky; +Cc: Willy Tarreau, Jason Papadopoulos, linux-kernel, marcelo On Tue, May 27, 2003 at 01:40:17PM +0400, Ivan Kokshaysky wrote: > On Tue, May 27, 2003 at 06:53:02AM +0200, Willy Tarreau wrote: > > I realized that a "idex=nodma" option is really lacking here. Shouldn't we > > disable IDE by default on Alpha at the moment, so that it at least boots ? > > According to your .config and dmesg output, you didn't have the > chipset driver compiled in (CONFIG_BLK_DEV_ALI15X3). > Naturally, you would have troubles with DMA. Sorry, I pasted the .config that I used just after, and which allowed me to boot. Later I set CONFIG_BLK_DEV_ALI15X3 again and CONFIG_BLK_DEV_IDEDMA_PCI, but I left CONFIG_IDEDMA_PCI_AUTO disabled. I now can boot and enable DMA later. That's weird, but it works. Regards, Willy ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-27 12:31 ` Willy Tarreau @ 2003-05-27 14:04 ` Ivan Kokshaysky 2003-05-27 14:37 ` Willy Tarreau ` (3 more replies) 0 siblings, 4 replies; 47+ messages in thread From: Ivan Kokshaysky @ 2003-05-27 14:04 UTC (permalink / raw) To: Willy Tarreau; +Cc: Jason Papadopoulos, linux-kernel, marcelo On Tue, May 27, 2003 at 02:31:52PM +0200, Willy Tarreau wrote: > Sorry, I pasted the .config that I used just after, and which allowed me to > boot. Later I set CONFIG_BLK_DEV_ALI15X3 again and CONFIG_BLK_DEV_IDEDMA_PCI, > but I left CONFIG_IDEDMA_PCI_AUTO disabled. I now can boot and enable DMA > later. That's weird, but it works. Perhaps not that weird. From my experience, ALi DMA is sensitive to some of "PIO timings". That is, if SRM hasn't initialized the chipset properly (on Nautilus it has, BTW), DMA won't work. When you boot with DMA disabled, driver has to set right PIO mode, so you can safely enable DMA later. Can you (and Jason) try this patch with CONFIG_IDEDMA_PCI_AUTO=y? Ivan. --- linux/drivers/ide/pci/alim15x3.c.orig Tue Apr 22 19:17:22 2003 +++ linux/drivers/ide/pci/alim15x3.c Tue May 27 17:42:17 2003 @@ -525,10 +525,14 @@ static int ali15x3_config_drive_for_dma( drive->init_speed = 0; + /* Set reasonable PIO timings first - some of them are needed + for DMA as well. */ + hwif->tuneproc(drive, 255); + if ((id->capability & 1) != 0 && drive->autodma) { /* Consult the list of known "bad" drives */ if (hwif->ide_dma_bad_drive(drive)) - goto ata_pio; + goto no_dma_set; if ((id->field_valid & 4) && (m5229_revision >= 0xC2)) { if (id->dma_ultra & hwif->ultra_mask) { /* Force if Capable UltraDMA */ @@ -550,11 +554,9 @@ try_dma_modes: if (!config_chipset_for_dma(drive)) goto no_dma_set; } else { - goto ata_pio; + goto no_dma_set; } } else { -ata_pio: - hwif->tuneproc(drive, 255); no_dma_set: return hwif->ide_dma_off_quietly(drive); } ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-27 14:04 ` Ivan Kokshaysky @ 2003-05-27 14:37 ` Willy Tarreau 2003-05-28 0:38 ` Willy Tarreau ` (2 subsequent siblings) 3 siblings, 0 replies; 47+ messages in thread From: Willy Tarreau @ 2003-05-27 14:37 UTC (permalink / raw) To: Ivan Kokshaysky; +Cc: Willy Tarreau, Jason Papadopoulos, linux-kernel, marcelo On Tue, May 27, 2003 at 06:04:03PM +0400, Ivan Kokshaysky wrote: > On Tue, May 27, 2003 at 02:31:52PM +0200, Willy Tarreau wrote: > > Sorry, I pasted the .config that I used just after, and which allowed me to > > boot. Later I set CONFIG_BLK_DEV_ALI15X3 again and CONFIG_BLK_DEV_IDEDMA_PCI, > > but I left CONFIG_IDEDMA_PCI_AUTO disabled. I now can boot and enable DMA > > later. That's weird, but it works. > > Perhaps not that weird. From my experience, ALi DMA is sensitive to > some of "PIO timings". That is, if SRM hasn't initialized the chipset > properly (on Nautilus it has, BTW), DMA won't work. When you boot with > DMA disabled, driver has to set right PIO mode, so you can safely > enable DMA later. > > Can you (and Jason) try this patch with CONFIG_IDEDMA_PCI_AUTO=y? Compilation in progress, but it will wait for me to get in touch with the machine to reboot it (probably this evening). Cheers, Willy ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-27 14:04 ` Ivan Kokshaysky 2003-05-27 14:37 ` Willy Tarreau @ 2003-05-28 0:38 ` Willy Tarreau 2003-05-28 1:41 ` Jason Papadopoulos 2003-05-31 15:24 ` Ben Collins 3 siblings, 0 replies; 47+ messages in thread From: Willy Tarreau @ 2003-05-28 0:38 UTC (permalink / raw) To: Ivan Kokshaysky; +Cc: Willy Tarreau, Jason Papadopoulos, linux-kernel, marcelo Hi ! On Tue, May 27, 2003 at 06:04:03PM +0400, Ivan Kokshaysky wrote: > Can you (and Jason) try this patch with CONFIG_IDEDMA_PCI_AUTO=y? Well, I tried to reboot (blindly, only with a keyboard attached) on the new kernel, but it behave the same way : "boot -fl 1" (1 is the new kernel) does a few disk accesses to load the kernel, then hangs, while "0" boots correctly, so I'm sure my keyboard is correctly plugged and I don't mistype. Sorry Ivan for such a miserable report, but I couldn't plug either a VT or a VGA display. I will retry -rc5 (or -rc6) ASAP, but for now I'm going to bed. Marcelo, the AHA29160 on this system (alpha) spurts lots of debug messages "blk: queue 0xffff..." at boot with the version in -rc3. Justin pointed me to drivers/block/ll_rw_blk.c:268 which is responsible for the message. It's marked as debug, but no KERN_XXX prefix is used. So I think that either KERN_DEBUG should be added, or the message should simply disappear, since it sends garbage on the screen which makes SCSI detection a bit hard to read. Here are two quickly written, completely untested patch proposals. Please note that this code has not changed since 2.4.20 (which I never tested on this machine). Regards, Willy ######## the most correct one ? ######## --- ./drivers/block/ll_rw_blk.c Fri May 9 21:33:10 2003 +++ /tmp/ll_rw_blk.c-debug Wed May 28 02:33:05 2003 @@ -265,7 +265,7 @@ */ if (dma_addr != BLK_BOUNCE_HIGH && q != old_q) { old_q = q; - printk("blk: queue %p, ", q); + printk(KERN_DEBUG "blk: queue %p, ", q); if (dma_addr == BLK_BOUNCE_ANY) printk("no I/O memory limit\n"); else ##### this one hides the message. Note that it may lead to a warning ##### with mb defined but not used ! --- ./drivers/block/ll_rw_blk.c Fri May 9 21:33:10 2003 +++ /tmp/ll_rw_blk.c-nomsg Wed May 28 02:32:50 2003 @@ -265,12 +265,14 @@ */ if (dma_addr != BLK_BOUNCE_HIGH && q != old_q) { old_q = q; +#ifdef BLK_QUEUE_DEBUG printk("blk: queue %p, ", q); if (dma_addr == BLK_BOUNCE_ANY) printk("no I/O memory limit\n"); else printk("I/O limit %luMb (mask 0x%Lx)\n", mb, (long long) dma_addr); +#endif } q->bounce_pfn = bounce_pfn; ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-27 14:04 ` Ivan Kokshaysky 2003-05-27 14:37 ` Willy Tarreau 2003-05-28 0:38 ` Willy Tarreau @ 2003-05-28 1:41 ` Jason Papadopoulos 2003-05-28 3:12 ` Jeff Garzik 2003-05-28 14:45 ` Ivan Kokshaysky 2003-05-31 15:24 ` Ben Collins 3 siblings, 2 replies; 47+ messages in thread From: Jason Papadopoulos @ 2003-05-28 1:41 UTC (permalink / raw) To: linux-kernel At 06:04 PM 5/27/03 +0400, you wrote: > >Perhaps not that weird. From my experience, ALi DMA is sensitive to >some of "PIO timings". That is, if SRM hasn't initialized the chipset >properly (on Nautilus it has, BTW), DMA won't work. When you boot with >DMA disabled, driver has to set right PIO mode, so you can safely >enable DMA later. > >Can you (and Jason) try this patch with CONFIG_IDEDMA_PCI_AUTO=y? Sorry, no change. I do get behavior that matches Willy's though: use hdparm and you can get DMA turned on. Another clue is that the ALI controller is capable of udma2 (and older kernels achieve that) but even with hdparm the best I can get seems to be mode mdma2. Also, I've found that lately I have to attempt to boot from the hard drive (dqa0) about three times before the kernel finally gets pulled off of disk. SRM reports a bootstrap failure each time, but otherwise the system seems to work fine. Has anyone seen this behavior? Anything else I can do? jasonp ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-28 1:41 ` Jason Papadopoulos @ 2003-05-28 3:12 ` Jeff Garzik 2003-05-29 0:35 ` Jason Papadopoulos 2003-05-28 14:45 ` Ivan Kokshaysky 1 sibling, 1 reply; 47+ messages in thread From: Jeff Garzik @ 2003-05-28 3:12 UTC (permalink / raw) To: Jason Papadopoulos; +Cc: linux-kernel Jason Papadopoulos wrote: > Sorry, no change. I do get behavior that matches Willy's though: use > hdparm and you can get DMA turned on. Another clue is that the ALI > controller is capable of udma2 (and older kernels achieve that) but even > with hdparm the best I can get seems to be mode mdma2. FWIW, udma2 is the best you can do without accurate cable detection and an 80-conductor cable. Jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-28 3:12 ` Jeff Garzik @ 2003-05-29 0:35 ` Jason Papadopoulos 2003-05-29 1:10 ` Jeff Garzik 0 siblings, 1 reply; 47+ messages in thread From: Jason Papadopoulos @ 2003-05-29 0:35 UTC (permalink / raw) To: linux-kernel At 11:12 PM 5/27/03 -0400, Jeff Garzik wrote: > >FWIW, udma2 is the best you can do without accurate cable detection and >an 80-conductor cable. > Well, even with a drive capable of ATA66, an 80-pin cable, and a kernel configured to force assumption of higher UDMA modes, the best I've ever done with this stupid ALI controller is udma2. I think it's deliberately crippled. jasonp ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-29 0:35 ` Jason Papadopoulos @ 2003-05-29 1:10 ` Jeff Garzik 0 siblings, 0 replies; 47+ messages in thread From: Jeff Garzik @ 2003-05-29 1:10 UTC (permalink / raw) To: Jason Papadopoulos; +Cc: linux-kernel Jason Papadopoulos wrote: > At 11:12 PM 5/27/03 -0400, Jeff Garzik wrote: > > > >FWIW, udma2 is the best you can do without accurate cable detection and > >an 80-conductor cable. > > > > Well, even with a drive capable of ATA66, an 80-pin cable, and a kernel > configured to force assumption of higher UDMA modes, the best I've ever > done with this stupid ALI controller is udma2. I think it's deliberately > crippled. "configured to force the assumption" does no good if the host controller driver isn't detecting the cable correctly, or is not programming 80c cable info into the host controller correctly. That's a code change not a configuration thing. Jeff ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-28 1:41 ` Jason Papadopoulos 2003-05-28 3:12 ` Jeff Garzik @ 2003-05-28 14:45 ` Ivan Kokshaysky 1 sibling, 0 replies; 47+ messages in thread From: Ivan Kokshaysky @ 2003-05-28 14:45 UTC (permalink / raw) To: Jason Papadopoulos; +Cc: linux-kernel On Tue, May 27, 2003 at 09:41:12PM -0400, Jason Papadopoulos wrote: > Also, I've found that lately I have to attempt to boot from the hard > drive (dqa0) about three times before the kernel finally gets pulled > off of disk. SRM reports a bootstrap failure each time, but otherwise > the system seems to work fine. Has anyone seen this behavior? Yes, it's known problem. Recent 2.4 kernels shutdown the IDE disks on halt/poweroff, which is extremely annoying on alpha when you return to SRM prompt to boot another kernel. You'll have to wait until the disk spins up again. > Anything else I can do? Send me please "lspci -vxxx -s 0:d" outputs for - old (working) kernel; - new kernel before and after "hdparm -d1". Ivan. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-27 14:04 ` Ivan Kokshaysky ` (2 preceding siblings ...) 2003-05-28 1:41 ` Jason Papadopoulos @ 2003-05-31 15:24 ` Ben Collins 2003-06-01 18:40 ` Ivan Kokshaysky 3 siblings, 1 reply; 47+ messages in thread From: Ben Collins @ 2003-05-31 15:24 UTC (permalink / raw) To: Ivan Kokshaysky; +Cc: Willy Tarreau, Jason Papadopoulos, linux-kernel, marcelo On Tue, May 27, 2003 at 06:04:03PM +0400, Ivan Kokshaysky wrote: > On Tue, May 27, 2003 at 02:31:52PM +0200, Willy Tarreau wrote: > > Sorry, I pasted the .config that I used just after, and which allowed me to > > boot. Later I set CONFIG_BLK_DEV_ALI15X3 again and CONFIG_BLK_DEV_IDEDMA_PCI, > > but I left CONFIG_IDEDMA_PCI_AUTO disabled. I now can boot and enable DMA > > later. That's weird, but it works. > > Perhaps not that weird. From my experience, ALi DMA is sensitive to > some of "PIO timings". That is, if SRM hasn't initialized the chipset > properly (on Nautilus it has, BTW), DMA won't work. When you boot with > DMA disabled, driver has to set right PIO mode, so you can safely > enable DMA later. > > Can you (and Jason) try this patch with CONFIG_IDEDMA_PCI_AUTO=y? Dave Miller asked me to try this patch. On sparc64, we've had a never ending battle with ALi 5229 on Sun Blade 100's. After some time, files would start to get corrupted (in memory, not on disk, unless the corruption was saved somehow inadvertently). It exposed itself as two null bytes at the start of a file. I just tried this patch, and for the first time in a long time, I've been able to boot with UDMA(66) enabled and not get the corruption. Usually I can expose the corruption with kernel compiles within 10-60 minutes. I've been running your patch for almost 2 days now, and so far have not been able get corruption. I even left a looping 2.5.69 compile going (make clean; make) for over 10 hours. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Linux 2.4.21-rc3 : IDE pb on Alpha 2003-05-31 15:24 ` Ben Collins @ 2003-06-01 18:40 ` Ivan Kokshaysky 0 siblings, 0 replies; 47+ messages in thread From: Ivan Kokshaysky @ 2003-06-01 18:40 UTC (permalink / raw) To: Ben Collins; +Cc: Willy Tarreau, Jason Papadopoulos, linux-kernel, marcelo On Sat, May 31, 2003 at 11:24:17AM -0400, Ben Collins wrote: > I just tried this patch, and for the first time in a long time, I've > been able to boot with UDMA(66) enabled and not get the corruption. Excellent, thanks for the report. :-) Ivan. ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2003-06-01 18:28 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-22 22:19 Linux 2.4.21-rc3 Marcelo Tosatti 2003-05-22 23:46 ` J.A. Magallon 2003-05-26 17:04 ` Alan Cox 2003-05-23 0:51 ` Barry K. Nathan 2003-05-23 5:32 ` Marc-Christian Petersen 2003-05-23 7:04 ` [BUG] 2.[45] ioperm fix seems broken (was Re: Linux 2.4.21-rc3) Barry K. Nathan 2003-05-23 9:00 ` Barry K. Nathan 2003-05-23 8:27 ` Linux 2.4.21-rc3 Benjamin Herrenschmidt 2003-05-23 13:38 ` Linux 2.4.21-rc3 - ipmi unresolved Eyal Lebedinsky 2003-05-23 13:41 ` Marc-Christian Petersen 2003-05-26 2:09 ` Corey Minyard 2003-05-25 7:57 ` Keith Owens 2003-05-26 3:37 ` Corey Minyard 2003-05-26 3:54 ` Keith Owens 2003-05-27 0:30 ` Corey Minyard 2003-05-27 3:09 ` Keith Owens 2003-05-27 4:45 ` Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved) Corey Minyard 2003-05-27 5:30 ` Keith Owens 2003-05-27 14:48 ` Corey Minyard 2003-05-27 16:02 ` viro 2003-05-27 17:09 ` Corey Minyard 2003-05-28 0:15 ` Keith Owens 2003-05-26 17:08 ` Linux 2.4.21-rc3 - ipmi unresolved Alan Cox 2003-05-23 21:10 ` Linux 2.4.21-rc3 [net-pf-4, devfs audio, drm radeon] Gabor Z. Papp 2003-05-25 17:36 ` Linux 2.4.21-rc3 : IDE pb on Alpha Willy Tarreau 2003-05-25 17:00 ` Willy Tarreau 2003-05-25 20:37 ` Mike Fedyk 2003-05-25 20:45 ` Bartlomiej Zolnierkiewicz 2003-05-25 20:55 ` Mike Fedyk 2003-05-25 21:23 ` Bartlomiej Zolnierkiewicz 2003-05-26 7:28 ` Linux 2.4.21-rc3: doesn't build with CONFIG_BLK_DEV_HD_ONLY=y Jerome Chantelauze 2003-05-26 13:16 ` Linux 2.4.21-rc3 Santiago Garcia Mantinan 2003-05-27 1:14 ` Jeff Chua 2003-05-27 3:37 Linux 2.4.21-rc3 : IDE pb on Alpha Jason Papadopoulos 2003-05-27 4:53 ` Willy Tarreau 2003-05-27 9:40 ` Ivan Kokshaysky 2003-05-27 12:31 ` Willy Tarreau 2003-05-27 14:04 ` Ivan Kokshaysky 2003-05-27 14:37 ` Willy Tarreau 2003-05-28 0:38 ` Willy Tarreau 2003-05-28 1:41 ` Jason Papadopoulos 2003-05-28 3:12 ` Jeff Garzik 2003-05-29 0:35 ` Jason Papadopoulos 2003-05-29 1:10 ` Jeff Garzik 2003-05-28 14:45 ` Ivan Kokshaysky 2003-05-31 15:24 ` Ben Collins 2003-06-01 18:40 ` Ivan Kokshaysky
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).