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

[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

Re: Linux 2.4.21-rc3

[Melchior FRANZ]

* Marcelo Tosatti -- Friday 23 May 2003 00:47:
> Here goes the third release candidate of 2.4.21.

o The i2c "Philips style parallel port adapter" is only selectable
  as a module in "make menuconfig", although the help text suggests
  that it can be compiled in.

o With all i2c options activated, I still get this:
  drivers/i2c/i2c.o: In function `scx200_i2c_setscl':
  drivers/i2c/i2c.o(.text+0x636f): undefined reference to `scx200_gpio_base'
  drivers/i2c/i2c.o(.text+0x6396): undefined reference to `scx200_gpio_shadow'
  drivers/i2c/i2c.o(.text+0x63a1): undefined reference to `scx200_gpio_shadow'
  drivers/i2c/i2c.o(.text+0x63b4): undefined reference to `scx200_gpio_shadow'
  drivers/i2c/i2c.o: In function `scx200_i2c_setsda':
  drivers/i2c/i2c.o(.text+0x63cf): undefined reference to `scx200_gpio_base'
  drivers/i2c/i2c.o(.text+0x63f6): undefined reference to `scx200_gpio_shadow'
  drivers/i2c/i2c.o(.text+0x6401): undefined reference to `scx200_gpio_shadow'
  drivers/i2c/i2c.o(.text+0x6414): undefined reference to `scx200_gpio_shadow'
  drivers/i2c/i2c.o: In function `scx200_i2c_getscl':
  drivers/i2c/i2c.o(.text+0x6423): undefined reference to `scx200_gpio_base'
  drivers/i2c/i2c.o: In function `scx200_i2c_getsda':
  drivers/i2c/i2c.o(.text+0x6463): undefined reference to `scx200_gpio_base'
  drivers/i2c/i2c.o: In function `scx200_i2c_init':
  drivers/i2c/i2c.o(.text+0x64f0): undefined reference to `scx200_gpio_base'
  drivers/i2c/i2c.o(.text+0x655b): undefined reference to `scx200_gpio_configure'
  drivers/i2c/i2c.o(.text+0x6578): undefined reference to `scx200_gpio_configure'

o Some help texts are missing, e.g for
  "Generic PCI IDE Chipset Support"
  i2c/"NatSemi SCx200 I2C using GPIO pins"

Apart from that, 2.4.21-rc3 compiles, boots and runs OK.

m.

[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: 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: [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

[Martijn Uffing]

Ave

Modular ide is still broken in 2.4.21-rc3  with my config.

"make modules_install" gives a:

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: 	cmd640_vlb
depmod: 	ide_probe_for_cmd640x
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


The .config of these errors.


#
# Automatically generated make config: don't edit
#
CONFIG_X86=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_HAS_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_F00F_WORKS_OK=y
CONFIG_X86_MCE=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_HIGHMEM is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
# CONFIG_X86_UP_APIC is not set
# CONFIG_X86_UP_IOAPIC is not set
# CONFIG_X86_TSC_DISABLE is not set
CONFIG_X86_TSC=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
# CONFIG_ISA is not set
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
# CONFIG_HOTPLUG_PCI is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PM=y
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
# CONFIG_APM_CPU_IDLE is not set
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play configuration
#
CONFIG_PNP=y
# CONFIG_ISAPNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_BLK_STATS=y

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_VLAN_8021Q is not set

#
#  
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set

#
# Appletalk devices
#
# CONFIG_DEV_APPLETALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
# CONFIG_PHONE_IXJ_PCMCIA is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=m

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=m

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=m
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set

#
# IDE chipset support/bugfixes
#
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_AEC62XX_TUNING is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CMD680 is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_PIIX_TUNING is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX is not set
# CONFIG_PDC202XX_BURST is not set
# CONFIG_PDC202XX_FORCE is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set

#
# SCSI support
#
# CONFIG_SCSI is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set

#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_LAN is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC is not set

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_SUNLANCE is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_APRICOT is not set
# CONFIG_CS89x0 is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_DGRS is not set
# CONFIG_DM9102 is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_LNE390 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_NE3210 is not set
# CONFIG_ES3210 is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_SUNDANCE_MMIO is not set
# CONFIG_TLAN is not set
# CONFIG_TC35815 is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_RHINE_MMIO is not set
CONFIG_WINBOND_840=y
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Input core support
#
# CONFIG_INPUT is not set
# CONFIG_INPUT_KEYBDEV is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=m
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set
# CONFIG_MK712_MOUSE is not set

#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set

#
# Input core support is needed for gameports
#

#
# Input core support is needed for joysticks
#
# CONFIG_QIC02_TAPE is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_AMD_RNG is not set
# CONFIG_INTEL_RNG is not set
# CONFIG_AMD_PM768 is not set
CONFIG_NVRAM=m
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=m
# CONFIG_AGP_INTEL is not set
# CONFIG_AGP_I810 is not set
CONFIG_AGP_VIA=y
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD_8151 is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# File systems
#
# CONFIG_QUOTA is not set
CONFIG_AUTOFS_FS=m
# CONFIG_AUTOFS4_FS is not set
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=m
CONFIG_JBD=m
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_UMSDOS_FS=m
CONFIG_VFAT_FS=m
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_CRAMFS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_JFS_FS=m
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_MINIX_FS=m
CONFIG_VXFS_FS=m
CONFIG_NTFS_FS=m
# CONFIG_NTFS_RW is not set
CONFIG_HPFS_FS=m
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
CONFIG_QNX4FS_FS=m
# CONFIG_QNX4FS_RW is not set
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=m
CONFIG_SYSV_FS=m
CONFIG_UDF_FS=m
# CONFIG_UDF_RW is not set
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set

#
# Network File Systems
#
CONFIG_CODA_FS=m
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=y
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
CONFIG_ZISOFS_FS=m

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y

#
# Sound
#
CONFIG_SOUND=m
# CONFIG_SOUND_ALI5455 is not set
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_CMPCI is not set
# CONFIG_SOUND_EMU10K1 is not set
# CONFIG_MIDI_EMU10K1 is not set
# CONFIG_SOUND_FUSION is not set
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
# CONFIG_SOUND_FORTE is not set
# CONFIG_SOUND_ICH is not set
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
CONFIG_SOUND_VIA82CXXX=m
CONFIG_MIDI_VIA82CXXX=y
# CONFIG_SOUND_OSS is not set
# CONFIG_SOUND_TVMIXER is not set

#
# USB support
#
# CONFIG_USB is not set

#
# Bluetooth support
#
# CONFIG_BLUEZ is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set

#
# Library routines
#
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=y

Re: Linux 2.4.21-rc3

[Carl-Daniel Hailfinger]

Martijn Uffing wrote:
> Ave
> 
> Modular ide is still broken in 2.4.21-rc3  with my config.

IIRC, Alan said it is not suposed to work yet. However, if you're
feeling brave (and have no valuable data), you can try to export these
symbols to make depmod happy. (Please read on)

> "make modules_install" gives a:
> 
> 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: 	cmd640_vlb
> depmod: 	ide_probe_for_cmd640x
> 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
> 
> 
> The .config of these errors.
> 
> CONFIG_IDE=m
> CONFIG_BLK_DEV_IDE=m
> CONFIG_BLK_DEV_IDEDISK=m
> CONFIG_IDEDISK_MULTI_MODE=y
> CONFIG_BLK_DEV_IDECD=m
> CONFIG_BLK_DEV_CMD640=y
> CONFIG_BLK_DEV_RZ1000=y
> CONFIG_BLK_DEV_IDEPCI=y
> CONFIG_IDEPCI_SHARE_IRQ=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> CONFIG_IDEDMA_PCI_AUTO=y
> CONFIG_BLK_DEV_IDEDMA=y
> CONFIG_BLK_DEV_ADMA=y
> CONFIG_BLK_DEV_VIA82CXXX=y
> CONFIG_IDEDMA_AUTO=y
> CONFIG_BLK_DEV_IDE_MODES=y

Alan? It might be prudent to make all IDE CONFIG_XYZ bools for -rc4 so
no one can complain that the released kernel does not compile. Marcelo
could just revert it for 2.4.22-pre then.

This is mainly to keep the complaint level down.


Regards,
Carl-Daniel

Re: Linux 2.4.21-rc3

[Martijn Uffing]

On Fri, 23 May 2003, Carl-Daniel Hailfinger wrote:

> Martijn Uffing wrote:
> > Ave
> > 
> > Modular ide is still broken in 2.4.21-rc3  with my config.
> 
> IIRC, Alan said it is not suposed to work yet. However, if you're
> feeling brave (and have no valuable data), you can try to export these
> symbols to make depmod happy. (Please read on)

I found "o fix modular ide build and other makefile bug" in Changelog so
 I thought to give it another try.



> 
> > "make modules_install" gives a:
> > 
> > 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: 	cmd640_vlb
> > depmod: 	ide_probe_for_cmd640x
> > 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
> > 
> > 
> no one can complain that the released kernel does not compile. Marcelo
> could just revert it for 2.4.22-pre then.
> 
> This is mainly to keep the complaint level down.
> 
> 
> Regards,
> Carl-Daniel
> 


Ehh 2.4.21-rc3 compiles fine with my config. It even runs fine! Only 
modular ide won't work. But if the changes are to invasive for 2.4.21 I 
can understand.

Greetz Mu

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

[Matthias Andree]

On Fri, 23 May 2003, Carl-Daniel Hailfinger wrote:

> Martijn Uffing wrote:
> > Ave
> > 
> > Modular ide is still broken in 2.4.21-rc3  with my config.
> 
> IIRC, Alan said it is not suposed to work yet. However, if you're
> feeling brave (and have no valuable data), you can try to export these
> symbols to make depmod happy. (Please read on)

In that case, it's about time to disable "modular IDE" in the
corresponding config.in file if we're talking about "release candidate"
of a "stable" kernel?

If it's known to be broken, it shouldn't be allowed IMO.

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

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

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

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

[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: 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

[Andrzej Krzysztofowicz]

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

The following short patch should fix this problem
(AFAIK, also not fixed in -ac tree)
****************************************************
--- linux-2.4.21-rc3/drivers/ide/Makefile~	Mon May 26 14:02:47 2003
+++ linux-2.4.21-rc3/drivers/ide/Makefile	Mon May 26 15:49:27 2003
@@ -44,8 +44,8 @@
 obj-$(CONFIG_BLK_DEV_ISAPNP)		+= ide-pnp.o
 
 
-ifeq ($(CONFIG_BLK_DEV_IDE),y)
-obj-$(CONFIG_PROC_FS)			+= ide-proc.o
+ifeq ($(CONFIG_PROC_FS),y)
+obj-$(CONFIG_BLK_DEV_IDE)			+= ide-proc.o
 endif
 
 ifeq ($(CONFIG_BLK_DEV_IDE),y)

-- 
=======================================================================
  Andrzej M. Krzysztofowicz               ankry@mif.pg.gda.pl
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Gdansk University of Technology

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

[Alan Cox]

On Gwe, 2003-05-23 at 14:10, Carl-Daniel Hailfinger wrote:
> Martijn Uffing wrote:
> > Ave
> > 
> > Modular ide is still broken in 2.4.21-rc3  with my config.
> 
> IIRC, Alan said it is not suposed to work yet. However, if you're
> feeling brave (and have no valuable data), you can try to export these
> symbols to make depmod happy. (Please read on)

Thats the problem - you can't. You have to link the ide core code into one
file, which itself is easy (now I've fixed the pdc4030 in my tree) except
fo the cmd640 vlb hooks which are nasty as it sucks in a driver from a sub
directory.

That one is the remaining horror and I'm not sure how best to tackle it

Re: Linux 2.4.21-rc3

[Santiago Garcia Mantinan]

The patch Andrzej sent only solves part of the problem, I can still see
this:

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: *** Unresolved symbols in
/lib/modules/2.4.21-rc3/kernel/drivers/ide/ide-proc.o
depmod:         ide_find_setting_by_name
depmod:         ide_modules
depmod:         ide_read_setting
depmod:         generic_subdriver_entries
depmod: *** Unresolved symbols in
/lib/modules/2.4.21-rc3/kernel/drivers/ide/ide.o
depmod:         ide_release_dma
depmod:         pnpide_init
depmod:         ide_scan_pcibus

I have seen that even though I have CONFIG_BLK_DEV_ISAPNP=y on the config
file, ide-pnp.c is not compiled, this raises a warning when compiling ide.c:
ide.c: In function 	de_unregister_subdriver':
ide.c:2625: warning: implicit declaration of function `pnpide_init'

On the others I suppose that the problem is that the symbols are not
exported :-(

Hope this helps fixing ide modules compiling before 2.4.21 is released.

Regards...
-- 
Manty/BestiaTester -> http://manty.net

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

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

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

[Alan Cox]

On Gwe, 2003-05-30 at 21:55, Krzysiek Taraszka wrote:
> Dnia pon 26. maja 2003 19:53, Santiago Garcia Mantinan napisał:
> > The patch Andrzej sent only solves part of the problem, I can still see
> > this:

You have to fix up things like the CMD640 dependancies too. I've actually 
been hacking on this today too. I'll upload a new -ac with the stuff so
far which seems to work if people want to hack on it too

Re: Linux 2.4.21-rc3

[Krzysiek Taraszka]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

Dnia pon 26. maja 2003 19:53, Santiago Garcia Mantinan napisał:
> The patch Andrzej sent only solves part of the problem, I can still see
> this:
>
> 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: *** Unresolved symbols in
> /lib/modules/2.4.21-rc3/kernel/drivers/ide/ide-proc.o
> depmod:         ide_find_setting_by_name
> depmod:         ide_modules
> depmod:         ide_read_setting
> depmod:         generic_subdriver_entries
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.21-rc3/kernel/drivers/ide/ide.o
> depmod:         ide_release_dma
> depmod:         pnpide_init
> depmod:         ide_scan_pcibus

> Hope this helps fixing ide modules compiling before 2.4.21 is released.

Yes, my patch should fix it (I test it :))
So, Marcelo, Alan, please apply my patch.

-- 
Krzysiek Taraszka			(dzimi@pld.org.pl)
http://cyborg.kernel.pl/~dzimi/

[-- Attachment #2: ide-symbols.patch --]
[-- Type: text/x-diff, Size: 2619 bytes --]

diff -urN linux-2.4.20-rc6.orig/drivers/ide/Makefile linux-2.4.20-rc6/drivers/ide/Makefile
--- linux-2.4.20-rc6.orig/drivers/ide/Makefile	Fri May 30 22:52:30 2003
+++ linux-2.4.20-rc6/drivers/ide/Makefile	Fri May 30 22:17:16 2003
@@ -43,9 +43,8 @@
 endif
 obj-$(CONFIG_BLK_DEV_ISAPNP)		+= ide-pnp.o
 
-
-ifeq ($(CONFIG_BLK_DEV_IDE),y)
-obj-$(CONFIG_PROC_FS)			+= ide-proc.o
+ifeq ($(CONFIG_PROC_FS),y)
+obj-$(CONFIG_BLK_DEV_IDE)		+= ide-proc.o
 endif
 
 ifeq ($(CONFIG_BLK_DEV_IDE),y)
diff -urN linux-2.4.20-rc6.orig/drivers/ide/ide-io.c linux-2.4.20-rc6/drivers/ide/ide-io.c
--- linux-2.4.20-rc6.orig/drivers/ide/ide-io.c	Fri May 30 22:52:30 2003
+++ linux-2.4.20-rc6/drivers/ide/ide-io.c	Fri May 30 22:25:30 2003
@@ -896,6 +896,8 @@
 	ide_do_request(q->queuedata, IDE_NO_IRQ);
 }
 
+EXPORT_SYMBOL(do_ide_request);
+
 /*
  * un-busy the hwgroup etc, and clear any pending DMA status. we want to
  * retry the current request in pio mode instead of risking tossing it
diff -urN linux-2.4.20-rc6.orig/drivers/ide/ide.c linux-2.4.20-rc6/drivers/ide/ide.c
--- linux-2.4.20-rc6.orig/drivers/ide/ide.c	Fri May 30 22:52:31 2003
+++ linux-2.4.20-rc6/drivers/ide/ide.c	Fri May 30 22:47:00 2003
@@ -190,6 +190,8 @@
 ide_module_t *ide_modules;
 ide_module_t *ide_probe;
 
+EXPORT_SYMBOL(ide_modules);
+
 /*
  * This is declared extern in ide.h, for access by other IDE modules:
  */
@@ -597,6 +599,9 @@
 	{ "capacity",	S_IFREG|S_IRUGO,	proc_ide_read_capacity,	NULL },
 	{ NULL, 0, NULL, NULL }
 };
+
+EXPORT_SYMBOL(generic_subdriver_entries);
+
 #endif
 
 
@@ -1181,6 +1186,8 @@
 	return setting;
 }
 
+EXPORT_SYMBOL(ide_find_setting_by_name);
+
 /**
  *	auto_remove_settings	-	remove driver specific settings
  *	@drive: drive
@@ -1241,6 +1248,8 @@
 	return val;
 }
 
+EXPORT_SYMBOL(ide_read_setting);
+
 int ide_spin_wait_hwgroup (ide_drive_t *drive)
 {
 	ide_hwgroup_t *hwgroup = HWGROUP(drive);
@@ -1414,6 +1423,8 @@
 #endif		
 }
 
+EXPORT_SYMBOL(ide_add_generic_settings);
+
 /*
  * Delay for *at least* 50ms.  As we don't know how much time is left
  * until the next tick occurs, we wait an extra tick to be safe.
@@ -2820,6 +2831,8 @@
 	devfs_unregister (ide_devfs_handle);
 }
 
+EXPORT_SYMBOL(ide_release_dma);
+
 #else /* !MODULE */
 
 __setup("", ide_setup);
diff -urN linux-2.4.20-rc6.orig/drivers/ide/setup-pci.c linux-2.4.20-rc6/drivers/ide/setup-pci.c
--- linux-2.4.20-rc6.orig/drivers/ide/setup-pci.c	Fri May 30 22:52:31 2003
+++ linux-2.4.20-rc6/drivers/ide/setup-pci.c	Fri May 30 22:49:02 2003
@@ -830,3 +830,5 @@
 		pci_register_driver(d);
 	}
 }
+
+EXPORT_SYMBOL(ide_scan_pcibus);
\ No newline at end of file