Linux 2.4.21-rc3

Linux 2.4.21-rc3

[Marcelo Tosatti]

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

Re: Linux 2.4.21-rc3

[J.A. Magallon]

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

Re: Linux 2.4.21-rc3

[Alan Cox]

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

Re: Linux 2.4.21-rc3

[Barry K. Nathan]

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>

Re: Linux 2.4.21-rc3

[Marc-Christian Petersen]

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

[BUG] 2.[45] ioperm fix seems broken (was Re: Linux 2.4.21-rc3)

[Barry K. Nathan]

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>

Re: [BUG] 2.[45] ioperm fix seems broken (was Re: Linux 2.4.21-rc3)

[Barry K. Nathan]

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>

Re: Linux 2.4.21-rc3

[Benjamin Herrenschmidt]

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

Re: Linux 2.4.21-rc3 - ipmi unresolved

[Eyal Lebedinsky]

[-- 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);

Re: Linux 2.4.21-rc3 - ipmi unresolved

[Marc-Christian Petersen]

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

Re: Linux 2.4.21-rc3 - ipmi unresolved

[Corey Minyard]

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

Re: Linux 2.4.21-rc3 - ipmi unresolved

[Keith Owens]

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.

Re: Linux 2.4.21-rc3 - ipmi unresolved

[Corey Minyard]

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

Re: Linux 2.4.21-rc3 - ipmi unresolved

[Keith Owens]

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().

Re: Linux 2.4.21-rc3 - ipmi unresolved

[Corey Minyard]

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

Re: Linux 2.4.21-rc3 - ipmi unresolved

[Keith Owens]

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.

Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved)

[Corey Minyard]

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

Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved)

[Keith Owens]

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.

Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved)

[Corey Minyard]

[-- 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(&notifier_lock);
 	while(*list)
@@ -90,12 +93,28 @@
 		list= &((*list)->next);
 	}
 	n->next = *list;
+	n->owner = owner;
 	*list=n;
 	write_unlock(&notifier_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;
 }

Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved)

[viro]

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?

Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved)

[Corey Minyard]

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

Re: Registering for notifier chains in modules (was Linux 2.4.21-rc3 - ipmi unresolved)

[Keith Owens]

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.

Re: Linux 2.4.21-rc3 - ipmi unresolved

[Alan Cox]

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.

Re: Linux 2.4.21-rc3 [net-pf-4, devfs audio, drm radeon]

[Gabor Z. Papp]

* 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])

Linux 2.4.21-rc3 : IDE pb on Alpha

[Willy Tarreau]

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

Re: Linux 2.4.21-rc3 : IDE pb on Alpha

[Willy Tarreau]

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

Re: Linux 2.4.21-rc3 : IDE pb on Alpha

[Mike Fedyk]

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.

Re: Linux 2.4.21-rc3 : IDE pb on Alpha

[Bartlomiej Zolnierkiewicz]

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.

Re: Linux 2.4.21-rc3 : IDE pb on Alpha

[Mike Fedyk]

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

Re: Linux 2.4.21-rc3 : IDE pb on Alpha

[Bartlomiej Zolnierkiewicz]

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

Re: Linux 2.4.21-rc3: doesn't build with CONFIG_BLK_DEV_HD_ONLY=y

[Jerome Chantelauze]

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.

Re: Linux 2.4.21-rc3

[Santiago Garcia Mantinan]

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

Re: Linux 2.4.21-rc3

[Jeff Chua]

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