Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Hans Reiser]

This is why our next patch will detect the use of gcc 2.96, and complain, in the
reiserfs Makefile.

Hans

Jan Kasprzak wrote:
> 
>         Hello,
> 
>         with ReiserFS support in 2.4.1 I have decided to give it a try.
> I created a filesystem on a spare partition, mounted it as /mnt,
> and tried to use it. The kernel crashed - I am able to reproduce it
> with the following steps:
> 
> - boot linux with init=/bin/bash
> - [optional] /sbin/mkreiserfs /dev/hdd1 (it can be reproduced even
>         on freshly created FS)
> - mount -t reiserfs /dev/hdd1 /mnt
> - cp -arv /usr /mnt
> 
>         I am attaching the details, feel free to ask for more information,
> if you want it. Please Cc: me in any reply.
> 
> Oops is a NULL pointer dereference at address 00000010,
> EIP is c017c7c3 (in check_leaf), EFLAGS is 00010292, Process is "cp",
> Code: 8b 52 10 ff d2 59 5b 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02,
> Call trace is the following:
>         c015f459 (in do_balance)
>         c0179466 (in fix_nodes)
>         c0179476 (also in fix_nodes)
>         c018612c (in reiserfs_insert_item)
>         c0173cb4 (near the end of reiserfs_new_symlink)
>         c0174170 (in reiserfs_new_inode)
>         c0170cbd (in reiserfs_symlink)
>         c0142a45 (in d_alloc)
>         c013c825 (in vfs_symlink)
>         c013c8de (in sys_symlink)
>         c0109023 (in system_call)
> 
>         All numbers are written by hand from the screen, so there may
> be a minor mistakes. Looking at the cp output, it seems it crashed
> while copying the symlink "/usr/bin/sgml2xml -> osx" to /mnt/bin.
> 
>         My computer is almost generic Red Hat 7.0 with all updates.
> Hardware is K6-2 @523 MHz, 128M RAM, VIA VT82C598 north bridge.
> 
>         I tried to create ext2 filesystem on /dev/hdd1, and then
> cp -arv /usr /mnt worked fine.
> 
>         The kernel config (grep '=[ym]' /usr/src/linux/.config) is the
> following (no modules were loadaed, though):
> 
> CONFIG_X86=y
> CONFIG_ISA=y
> CONFIG_UID16=y
> CONFIG_EXPERIMENTAL=y
> CONFIG_MODULES=y
> CONFIG_KMOD=y
> CONFIG_MK6=y
> CONFIG_X86_WP_WORKS_OK=y
> CONFIG_X86_INVLPG=y
> CONFIG_X86_CMPXCHG=y
> CONFIG_X86_BSWAP=y
> CONFIG_X86_POPAD_OK=y
> CONFIG_X86_ALIGNMENT_16=y
> CONFIG_X86_TSC=y
> CONFIG_X86_USE_PPRO_CHECKSUM=y
> CONFIG_NOHIGHMEM=y
> CONFIG_MTRR=y
> CONFIG_NET=y
> CONFIG_PCI=y
> CONFIG_PCI_GOANY=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> CONFIG_HOTPLUG=y
> CONFIG_PCMCIA=y
> CONFIG_CARDBUS=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSCTL=y
> CONFIG_KCORE_ELF=y
> CONFIG_BINFMT_AOUT=m
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_MISC=y
> CONFIG_PARPORT=m
> CONFIG_PARPORT_PC=m
> CONFIG_PARPORT_PC_FIFO=y
> CONFIG_PARPORT_PC_SUPERIO=y
> CONFIG_PARPORT_1284=y
> CONFIG_BLK_DEV_FD=m
> CONFIG_BLK_DEV_LOOP=m
> CONFIG_PACKET=y
> CONFIG_PACKET_MMAP=y
> CONFIG_NETLINK=y
> CONFIG_RTNETLINK=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_INET_ECN=y
> CONFIG_IPV6=m
> CONFIG_IPV6_EUI64=y
> CONFIG_IDE=y
> CONFIG_BLK_DEV_IDE=y
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> CONFIG_BLK_DEV_IDECS=m
> CONFIG_BLK_DEV_IDECD=m
> 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_IDEDMA_PCI_WIP=y
> CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y
> CONFIG_BLK_DEV_VIA82CXXX=y
> CONFIG_IDEDMA_AUTO=y
> CONFIG_BLK_DEV_IDE_MODES=y
> CONFIG_NETDEVICES=y
> CONFIG_NET_ETHERNET=y
> CONFIG_NET_VENDOR_3COM=y
> CONFIG_VORTEX=y
> CONFIG_HAMACHI=m
> CONFIG_PPP=m
> CONFIG_PPP_ASYNC=m
> CONFIG_PPP_DEFLATE=m
> CONFIG_PPP_BSDCOMP=m
> CONFIG_WAN=y
> CONFIG_COSA=m
> CONFIG_VT=y
> CONFIG_VT_CONSOLE=y
> CONFIG_SERIAL=y
> CONFIG_UNIX98_PTYS=y
> CONFIG_PRINTER=m
> CONFIG_MOUSE=y
> CONFIG_PSMOUSE=y
> CONFIG_NVRAM=m
> CONFIG_RTC=m
> CONFIG_AGP=y
> CONFIG_AGP_VIA=y
> CONFIG_DRM=y
> CONFIG_DRM_MGA=y
> CONFIG_PCMCIA_SERIAL=y
> CONFIG_AUTOFS4_FS=y
> CONFIG_REISERFS_FS=y
> CONFIG_REISERFS_CHECK=y
> CONFIG_ISO9660_FS=m
> CONFIG_PROC_FS=y
> CONFIG_DEVPTS_FS=y
> CONFIG_EXT2_FS=y
> CONFIG_CODA_FS=m
> CONFIG_NFS_FS=y
> CONFIG_NFS_V3=y
> CONFIG_NFSD=m
> CONFIG_NFSD_V3=y
> CONFIG_SUNRPC=y
> CONFIG_LOCKD=y
> CONFIG_LOCKD_V4=y
> CONFIG_MSDOS_PARTITION=y
> CONFIG_VGA_CONSOLE=y
> CONFIG_VIDEO_SELECT=y
> CONFIG_SOUND=y
> CONFIG_SOUND_ES1371=y
> CONFIG_USB=m
> CONFIG_USB_DEVICEFS=y
> CONFIG_USB_UHCI=m
> CONFIG_USB_AUDIO=m
> CONFIG_USB_SCANNER=m
> 
>         The dmesg output:
> 
> Linux version 2.4.1 (root@calypso.fi.muni.cz) (gcc version 2.96 20000731 (Red Hat Linux 7.0)) #2 Fri Feb 2 11:46:21 CET 2001
> BIOS-provided physical RAM map:
>  BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable)
>  BIOS-e820: 0000000000000400 @ 000000000009fc00 (usable)
>  BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
>  BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved)
>  BIOS-e820: 0000000007ef0000 @ 0000000000100000 (usable)
>  BIOS-e820: 000000000000d000 @ 0000000007ff3000 (ACPI data)
>  BIOS-e820: 0000000000003000 @ 0000000007ff0000 (ACPI NVS)
> On node 0 totalpages: 32752
> zone(0): 4096 pages.
> zone(1): 28656 pages.
> zone(2): 0 pages.
> Kernel command line: auto BOOT_IMAGE=linux ro root=301 BOOT_FILE=/boot/linux no-hlt
> Initializing CPU#0
> Detected 524.100 MHz processor.
> Console: colour VGA+ 80x50
> Calibrating delay loop... 1045.29 BogoMIPS
> Memory: 126608k/131008k available (1153k kernel code, 4012k reserved, 396k data, 64k init, 0k highmem)
> Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
> Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
> CPU: Before vendor init, caps: 008021bf 808029bf 00000000, vendor = 2
> CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
> CPU: After vendor init, caps: 008021bf 808029bf 00000000 00000002
> CPU: After generic, caps: 008021bf 808029bf 00000000 00000002
> CPU: Common caps: 008021bf 808029bf 00000000 00000002
> CPU: AMD-K6(tm) 3D processor stepping 0c
> Checking 'hlt' instruction... disabled
> POSIX conformance testing by UNIFIX
> mtrr: v1.37 (20001109) Richard Gooch (rgooch@atnf.csiro.au)
> mtrr: detected mtrr type: AMD K6
> PCI: PCI BIOS revision 2.10 entry at 0xfb2b0, last bus=1
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> PCI: Using IRQ router VIA [1106/0586] at 00:07.0
> Activating ISA DMA hang workarounds.
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> DMI 2.2 present.
> 33 structures occupying 873 bytes.
> DMI table at 0x000F0800.
> BIOS Vendor: Award Software International, Inc.
> BIOS Version: 4.51 PG
> BIOS Release: 03/15/99
> System Vendor: VIA Technologies, Inc..
> Product Name: VT82C597.
> Version  .
> Serial Number  .
> Starting kswapd v1.8
> Detected PS/2 Mouse Port.
> pty: 256 Unix98 ptys configured
> block: queued sectors max/low 84088kB/28029kB, 256 slots per queue
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt82c586b IDE UDMA33 controller on pci0:7.1
>     ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
>     ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
> hda: ST38410A, ATA DISK drive
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> hdd: ST320423A, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 16841664 sectors (8623 MB) w/512KiB Cache, CHS=1048/255/63, UDMA(33)
> hdd: 40011300 sectors (20486 MB) w/512KiB Cache, CHS=39693/16/63, UDMA(33)
> Partition check:
>  hda: hda1 hda2 hda3
>  hdd: hdd1
> Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 3) is a 16550A
> PCI: Found IRQ 9 for device 00:09.0
> PCI: The same IRQ used for device 00:08.1
> 3c59x.c:LK1.1.12 06 Jan 2000  Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
> See Documentation/networking/vortex.txt
> eth0: 3Com PCI 3c905 Boomerang 100baseTx at 0xe000,  00:60:97:36:90:ac, IRQ 9
>   product code 'HH' rev 00.0 date 11-11-96
>   8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
>   MII transceiver found at address 24, status 782f.
>   Enabling bus-master transmits and whole-frame receives.
> Linux agpgart interface v0.99 (c) Jeff Hartmann
> agpgart: Maximum main memory to use for agp memory: 94M
> agpgart: Detected Via MVP3 chipset
> agpgart: AGP aperture is 64M @ 0xe0000000
> [drm] AGP 0.99 on VIA MVP3 @ 0xe0000000 64MB
> [drm] Initialized mga 2.0.1 20000928 on minor 63
> es1371: version v0.27 time 10:11:49 Feb  2 2001
> es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
> PCI: Assigned IRQ 9 for device 00:0b.0
> es1371: found es1371 rev 8 at io 0xe400 irq 9
> es1371: features: joystick 0x0
> ac97_codec: AC97 Audio codec, id: 0x4352:0x5913 (Cirrus Logic CS4297A)
> Linux PCMCIA Card Services 3.1.22
>   options:  [pci] [cardbus]
> PCI: Found IRQ 9 for device 00:08.0
> IRQ routing conflict in pirq table for device 00:08.0
> PCI: Found IRQ 9 for device 00:08.1
> PCI: The same IRQ used for device 00:09.0
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 8192 bind 8192)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Yenta IRQ list 0000, PCI irq11
> Socket status: 10000006
> Yenta IRQ list 0000, PCI irq9
> Socket status: 10000006
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 64k freed
> Adding Swap: 265064k swap-space (priority -1)
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> usb-uhci.c: $Revision: 1.251 $ time 10:23:17 Feb  2 2001
> usb-uhci.c: High bandwidth mode enabled
> usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 12
> usb-uhci.c: Detected 2 ports
> usb.c: new USB bus registered, assigned bus number 1
> hub.c: USB hub found
> hub.c: 2 ports detected
> eth0: first available media type: MII
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> 
>         Hope this helps,
> 
> -Yenya
> 
> --
> \ Jan "Yenya" Kasprzak <kas at fi.muni.cz>       http://www.fi.muni.cz/~kas/
> \\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
> \\\             Czech Linux Homepage:  http://www.linux.cz/              ///
> > Is there anything else I can contribute? -- The latitude and longtitude of
> the bios writers current position, and a ballistic missile.       (Alan Cox)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[John Morrison]

Recompile with pre 2.96.


John

> 	Hello,
>
> 	with ReiserFS support in 2.4.1 I have decided to give it a try.
> I created a filesystem on a spare partition, mounted it as /mnt,
> and tried to use it. The kernel crashed - I am able to reproduce it
> with the following steps:
>
> - boot linux with init=/bin/bash
> - [optional] /sbin/mkreiserfs /dev/hdd1 (it can be reproduced even
> 	on freshly created FS)
> - mount -t reiserfs /dev/hdd1 /mnt
> - cp -arv /usr /mnt
>
> 	I am attaching the details, feel free to ask for more information,
> if you want it. Please Cc: me in any reply.
>
> Oops is a NULL pointer dereference at address 00000010,
> EIP is c017c7c3 (in check_leaf), EFLAGS is 00010292, Process is "cp",
> Code: 8b 52 10 ff d2 59 5b 8b 54 24 14 8b 42 34 89 c7 0f b7 47 02,
> Call trace is the following:
> 	c015f459 (in do_balance)
> 	c0179466 (in fix_nodes)
> 	c0179476 (also in fix_nodes)
> 	c018612c (in reiserfs_insert_item)
> 	c0173cb4 (near the end of reiserfs_new_symlink)
> 	c0174170 (in reiserfs_new_inode)
> 	c0170cbd (in reiserfs_symlink)
> 	c0142a45 (in d_alloc)
> 	c013c825 (in vfs_symlink)
> 	c013c8de (in sys_symlink)
> 	c0109023 (in system_call)
>
> 	All numbers are written by hand from the screen, so there may
> be a minor mistakes. Looking at the cp output, it seems it crashed
> while copying the symlink "/usr/bin/sgml2xml -> osx" to /mnt/bin.
>
> 	My computer is almost generic Red Hat 7.0 with all updates.
> Hardware is K6-2 @523 MHz, 128M RAM, VIA VT82C598 north bridge.
>
> 	I tried to create ext2 filesystem on /dev/hdd1, and then
> cp -arv /usr /mnt worked fine.
>
> 	The kernel config (grep '=[ym]' /usr/src/linux/.config) is the
> following (no modules were loadaed, though):
>
> CONFIG_X86=y
> CONFIG_ISA=y
> CONFIG_UID16=y
> CONFIG_EXPERIMENTAL=y
> CONFIG_MODULES=y
> CONFIG_KMOD=y
> CONFIG_MK6=y
> CONFIG_X86_WP_WORKS_OK=y
> CONFIG_X86_INVLPG=y
> CONFIG_X86_CMPXCHG=y
> CONFIG_X86_BSWAP=y
> CONFIG_X86_POPAD_OK=y
> CONFIG_X86_ALIGNMENT_16=y
> CONFIG_X86_TSC=y
> CONFIG_X86_USE_PPRO_CHECKSUM=y
> CONFIG_NOHIGHMEM=y
> CONFIG_MTRR=y
> CONFIG_NET=y
> CONFIG_PCI=y
> CONFIG_PCI_GOANY=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
> CONFIG_HOTPLUG=y
> CONFIG_PCMCIA=y
> CONFIG_CARDBUS=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSCTL=y
> CONFIG_KCORE_ELF=y
> CONFIG_BINFMT_AOUT=m
> CONFIG_BINFMT_ELF=y
> CONFIG_BINFMT_MISC=y
> CONFIG_PARPORT=m
> CONFIG_PARPORT_PC=m
> CONFIG_PARPORT_PC_FIFO=y
> CONFIG_PARPORT_PC_SUPERIO=y
> CONFIG_PARPORT_1284=y
> CONFIG_BLK_DEV_FD=m
> CONFIG_BLK_DEV_LOOP=m
> CONFIG_PACKET=y
> CONFIG_PACKET_MMAP=y
> CONFIG_NETLINK=y
> CONFIG_RTNETLINK=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_INET_ECN=y
> CONFIG_IPV6=m
> CONFIG_IPV6_EUI64=y
> CONFIG_IDE=y
> CONFIG_BLK_DEV_IDE=y
> CONFIG_BLK_DEV_IDEDISK=y
> CONFIG_IDEDISK_MULTI_MODE=y
> CONFIG_BLK_DEV_IDECS=m
> CONFIG_BLK_DEV_IDECD=m
> 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_IDEDMA_PCI_WIP=y
> CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y
> CONFIG_BLK_DEV_VIA82CXXX=y
> CONFIG_IDEDMA_AUTO=y
> CONFIG_BLK_DEV_IDE_MODES=y
> CONFIG_NETDEVICES=y
> CONFIG_NET_ETHERNET=y
> CONFIG_NET_VENDOR_3COM=y
> CONFIG_VORTEX=y
> CONFIG_HAMACHI=m
> CONFIG_PPP=m
> CONFIG_PPP_ASYNC=m
> CONFIG_PPP_DEFLATE=m
> CONFIG_PPP_BSDCOMP=m
> CONFIG_WAN=y
> CONFIG_COSA=m
> CONFIG_VT=y
> CONFIG_VT_CONSOLE=y
> CONFIG_SERIAL=y
> CONFIG_UNIX98_PTYS=y
> CONFIG_PRINTER=m
> CONFIG_MOUSE=y
> CONFIG_PSMOUSE=y
> CONFIG_NVRAM=m
> CONFIG_RTC=m
> CONFIG_AGP=y
> CONFIG_AGP_VIA=y
> CONFIG_DRM=y
> CONFIG_DRM_MGA=y
> CONFIG_PCMCIA_SERIAL=y
> CONFIG_AUTOFS4_FS=y
> CONFIG_REISERFS_FS=y
> CONFIG_REISERFS_CHECK=y
> CONFIG_ISO9660_FS=m
> CONFIG_PROC_FS=y
> CONFIG_DEVPTS_FS=y
> CONFIG_EXT2_FS=y
> CONFIG_CODA_FS=m
> CONFIG_NFS_FS=y
> CONFIG_NFS_V3=y
> CONFIG_NFSD=m
> CONFIG_NFSD_V3=y
> CONFIG_SUNRPC=y
> CONFIG_LOCKD=y
> CONFIG_LOCKD_V4=y
> CONFIG_MSDOS_PARTITION=y
> CONFIG_VGA_CONSOLE=y
> CONFIG_VIDEO_SELECT=y
> CONFIG_SOUND=y
> CONFIG_SOUND_ES1371=y
> CONFIG_USB=m
> CONFIG_USB_DEVICEFS=y
> CONFIG_USB_UHCI=m
> CONFIG_USB_AUDIO=m
> CONFIG_USB_SCANNER=m
>
> 	The dmesg output:
>
> Linux version 2.4.1 (root@calypso.fi.muni.cz) (gcc version 2.96 20000731 (Red Hat Linux 7.0)) #2 Fri Feb 2 11:46:21 CET 2001
> BIOS-provided physical RAM map:
>  BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable)
>  BIOS-e820: 0000000000000400 @ 000000000009fc00 (usable)
>  BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
>  BIOS-e820: 0000000000010000 @ 00000000ffff0000 (reserved)
>  BIOS-e820: 0000000007ef0000 @ 0000000000100000 (usable)
>  BIOS-e820: 000000000000d000 @ 0000000007ff3000 (ACPI data)
>  BIOS-e820: 0000000000003000 @ 0000000007ff0000 (ACPI NVS)
> On node 0 totalpages: 32752
> zone(0): 4096 pages.
> zone(1): 28656 pages.
> zone(2): 0 pages.
> Kernel command line: auto BOOT_IMAGE=linux ro root=301 BOOT_FILE=/boot/linux no-hlt
> Initializing CPU#0
> Detected 524.100 MHz processor.
> Console: colour VGA+ 80x50
> Calibrating delay loop... 1045.29 BogoMIPS
> Memory: 126608k/131008k available (1153k kernel code, 4012k reserved, 396k data, 64k init, 0k highmem)
> Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
> Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
> CPU: Before vendor init, caps: 008021bf 808029bf 00000000, vendor = 2
> CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
> CPU: After vendor init, caps: 008021bf 808029bf 00000000 00000002
> CPU: After generic, caps: 008021bf 808029bf 00000000 00000002
> CPU: Common caps: 008021bf 808029bf 00000000 00000002
> CPU: AMD-K6(tm) 3D processor stepping 0c
> Checking 'hlt' instruction... disabled
> POSIX conformance testing by UNIFIX
> mtrr: v1.37 (20001109) Richard Gooch (rgooch@atnf.csiro.au)
> mtrr: detected mtrr type: AMD K6
> PCI: PCI BIOS revision 2.10 entry at 0xfb2b0, last bus=1
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> PCI: Using IRQ router VIA [1106/0586] at 00:07.0
> Activating ISA DMA hang workarounds.
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> DMI 2.2 present.
> 33 structures occupying 873 bytes.
> DMI table at 0x000F0800.
> BIOS Vendor: Award Software International, Inc.
> BIOS Version: 4.51 PG
> BIOS Release: 03/15/99
> System Vendor: VIA Technologies, Inc..
> Product Name: VT82C597.
> Version  .
> Serial Number  .
> Starting kswapd v1.8
> Detected PS/2 Mouse Port.
> pty: 256 Unix98 ptys configured
> block: queued sectors max/low 84088kB/28029kB, 256 slots per queue
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 6
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt82c586b IDE UDMA33 controller on pci0:7.1
>     ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
>     ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
> hda: ST38410A, ATA DISK drive
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> hdd: ST320423A, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 16841664 sectors (8623 MB) w/512KiB Cache, CHS=1048/255/63, UDMA(33)
> hdd: 40011300 sectors (20486 MB) w/512KiB Cache, CHS=39693/16/63, UDMA(33)
> Partition check:
>  hda: hda1 hda2 hda3
>  hdd: hdd1
> Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 3) is a 16550A
> PCI: Found IRQ 9 for device 00:09.0
> PCI: The same IRQ used for device 00:08.1
> 3c59x.c:LK1.1.12 06 Jan 2000  Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $
> See Documentation/networking/vortex.txt
> eth0: 3Com PCI 3c905 Boomerang 100baseTx at 0xe000,  00:60:97:36:90:ac, IRQ 9
>   product code 'HH' rev 00.0 date 11-11-96
>   8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
>   MII transceiver found at address 24, status 782f.
>   Enabling bus-master transmits and whole-frame receives.
> Linux agpgart interface v0.99 (c) Jeff Hartmann
> agpgart: Maximum main memory to use for agp memory: 94M
> agpgart: Detected Via MVP3 chipset
> agpgart: AGP aperture is 64M @ 0xe0000000
> [drm] AGP 0.99 on VIA MVP3 @ 0xe0000000 64MB
> [drm] Initialized mga 2.0.1 20000928 on minor 63
> es1371: version v0.27 time 10:11:49 Feb  2 2001
> es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08
> PCI: Assigned IRQ 9 for device 00:0b.0
> es1371: found es1371 rev 8 at io 0xe400 irq 9
> es1371: features: joystick 0x0
> ac97_codec: AC97 Audio codec, id: 0x4352:0x5913 (Cirrus Logic CS4297A)
> Linux PCMCIA Card Services 3.1.22
>   options:  [pci] [cardbus]
> PCI: Found IRQ 9 for device 00:08.0
> IRQ routing conflict in pirq table for device 00:08.0
> PCI: Found IRQ 9 for device 00:08.1
> PCI: The same IRQ used for device 00:09.0
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 8192 bind 8192)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Yenta IRQ list 0000, PCI irq11
> Socket status: 10000006
> Yenta IRQ list 0000, PCI irq9
> Socket status: 10000006
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 64k freed
> Adding Swap: 265064k swap-space (priority -1)
> usb.c: registered new driver usbdevfs
> usb.c: registered new driver hub
> usb-uhci.c: $Revision: 1.251 $ time 10:23:17 Feb  2 2001
> usb-uhci.c: High bandwidth mode enabled
> usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 12
> usb-uhci.c: Detected 2 ports
> usb.c: new USB bus registered, assigned bus number 1
> hub.c: USB hub found
> hub.c: 2 ports detected
> eth0: first available media type: MII
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
>
> 	Hope this helps,
>
> -Yenya
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Jan Kasprzak]

Hans Reiser wrote:
: This is why our next patch will detect the use of gcc 2.96, and complain, in the
: reiserfs Makefile.
: 
	OK, thanks. It works with older compiler (altough I use gcc 2.96
for a long time for compiling various 2.[34] kernels without problem).

-Yenya

-- 
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz>       http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\             Czech Linux Homepage:  http://www.linux.cz/              ///
> Is there anything else I can contribute? -- The latitude and longtitude of
the bios writers current position, and a ballistic missile.       (Alan Cox)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Alan Cox]

> Hans Reiser wrote:
> : This is why our next patch will detect the use of gcc 2.96, and complain, in the
> : reiserfs Makefile.
> : 
> 	OK, thanks. It works with older compiler (altough I use gcc 2.96
> for a long time for compiling various 2.[34] kernels without problem).

Ok which 2.96 compiler do you have. I need to get this one chased down since
its probably also going to be in the current gcc CVS branches heading for 3.0

2.96-69 should be ok (thats the one I've been using without trouble). The 
original one with RH 7.0 off the CD does miscompile a few kernel things.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Jan Kasprzak]

Alan Cox wrote:
: > Hans Reiser wrote:
: >: This is why our next patch will detect the use of gcc 2.96, and complain, in the
: >: reiserfs Makefile.
: >: 
: > 	OK, thanks. It works with older compiler (altough I use gcc 2.96
: > for a long time for compiling various 2.[34] kernels without problem).
: 
: Ok which 2.96 compiler do you have. I need to get this one chased down since
: its probably also going to be in the current gcc CVS branches heading for 3.0
: 
: 2.96-69 should be ok (thats the one I've been using without trouble). The 
: original one with RH 7.0 off the CD does miscompile a few kernel things.

	It is the original one. I'll try with the -69:

$ rpm -q gcc
gcc -gcc-2.96-54
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)

-Yenya

-- 
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz>       http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\             Czech Linux Homepage:  http://www.linux.cz/              ///
> Is there anything else I can contribute? -- The latitude and longtitude of
the bios writers current position, and a ballistic missile.       (Alan Cox)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Jan Kasprzak]

Jan Kasprzak wrote:
: : 
: : 2.96-69 should be ok (thats the one I've been using without trouble). The 
: : original one with RH 7.0 off the CD does miscompile a few kernel things.
: 
: 	It is the original one. I'll try with the -69:
: 
	With 2.96-69 the reiserfs seems to work well.
Sorry for the confusion, I forgot to upgrade the gcc on my machine.

-Yenya

-- 
\ Jan "Yenya" Kasprzak <kas at fi.muni.cz>       http://www.fi.muni.cz/~kas/
\\ PGP: finger kas at aisa.fi.muni.cz   0D99A7FB206605D7 8B35FCDE05B18A5E //
\\\             Czech Linux Homepage:  http://www.linux.cz/              ///
> Is there anything else I can contribute? -- The latitude and longtitude of
the bios writers current position, and a ballistic missile.       (Alan Cox)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Alan Cox]

> : 	It is the original one. I'll try with the -69:
> : 
> 	With 2.96-69 the reiserfs seems to work well.
> Sorry for the confusion, I forgot to upgrade the gcc on my machine.

Excellent. Im just glad to know its a fixed bug.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Ion Badulescu]

On Fri, 2 Feb 2001 16:46:45 +0000 (GMT), Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> : 	It is the original one. I'll try with the -69:
>> : 
>> 	With 2.96-69 the reiserfs seems to work well.
>> Sorry for the confusion, I forgot to upgrade the gcc on my machine.
> 
> Excellent. Im just glad to know its a fixed bug.

Yes. But since Red Hat took upon themselves to define "gcc 2.96", they
should have created a new patchlevel (2.96.1) for their fixed compiler.

As it stands, there is no way to determine programatically whether
gcc-2.96 is broken or now. The only way to do it is to check the RPM
version -- which, needless to say, is a bit difficult to do from the
C code about to be compiled. So I can't really blame Hans if he decides
to outlaw gcc-2.96[.0] for reiserfs compiles.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Alan Cox]

> As it stands, there is no way to determine programatically whether
> gcc-2.96 is broken or now. The only way to do it is to check the RPM
> version -- which, needless to say, is a bit difficult to do from the
> C code about to be compiled. So I can't really blame Hans if he decides
> to outlaw gcc-2.96[.0] for reiserfs compiles.

Oh I can see why Hans wants to cut down his bug reporting load. I can also
say from experience it wont work. If you put #error in then everyone will
mail him and complain it doesnt build, if you put #warning in nobody will
read it and if you dont put anything in you get the odd bug report anyway.

Basically you can't win and unfortunately a shrink wrap forcing the user
to read the README file for the kernel violates the GPL ..

Jaded, me ?

Alan



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Arthur Erhardt]

On Fri, Feb 02, 2001 at 09:57:39PM +0000, Alan Cox wrote:
: > As it stands, there is no way to determine programatically whether
: > gcc-2.96 is broken or now. The only way to do it is to check the RPM
: > version -- which, needless to say, is a bit difficult to do from the
: > C code about to be compiled. So I can't really blame Hans if he decides
: > to outlaw gcc-2.96[.0] for reiserfs compiles.
: 
: Oh I can see why Hans wants to cut down his bug reporting load. I can also
: say from experience it wont work. If you put #error in then everyone will
: mail him and complain it doesnt build, if you put #warning in nobody will
: read it and if you dont put anything in you get the odd bug report anyway.
: 
: Basically you can't win and unfortunately a shrink wrap forcing the user
: to read the README file for the kernel violates the GPL ..

Alan, as a user (one of those few that actually read documentation), I
think it is a good idea to stop people from hurting their data by using
the wrong compiler and assuming everything is ok until shit happens. 

As you explained, one either gets the bug reports or the complaints 
that $SOURCE doesn't compile. The work for the developers might be 
about the same size, the impact on the users' side is less
destructive, though.

Arthur

-- 
arthur dot erhardt at pit dot physik dot uni dash tuebingen dot de 
*pgp key available*                                         dg7sea

A physicist is an atom's way of knowing about atoms.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Hans Reiser]

Alan Cox wrote:
> 
> > As it stands, there is no way to determine programatically whether
> > gcc-2.96 is broken or now. The only way to do it is to check the RPM
> > version -- which, needless to say, is a bit difficult to do from the
> > C code about to be compiled. So I can't really blame Hans if he decides
> > to outlaw gcc-2.96[.0] for reiserfs compiles.
> 
> Oh I can see why Hans wants to cut down his bug reporting load. I can also
> say from experience it wont work. If you put #error in then everyone will
> mail him and complain it doesnt build, if you put #warning in nobody will
> read it and if you dont put anything in you get the odd bug report anyway.
> 
> Basically you can't win and unfortunately a shrink wrap forcing the user
> to read the README file for the kernel violates the GPL ..
> 
> Jaded, me ?
> 
> Alan

I fear that you are speaking from experience about the complaints it doesn't
build, and that there is a strong element of truth in what you say.

That said, my opinion is that bug reporting load is not as important as bug
avoidance, but I understand your position has merit to it also.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Ion Badulescu]

On Fri, 2 Feb 2001, Alan Cox wrote:

> Oh I can see why Hans wants to cut down his bug reporting load. I can also
> say from experience it wont work. If you put #error in then everyone will
> mail him and complain it doesnt build, if you put #warning in nobody will
> read it and if you dont put anything in you get the odd bug report anyway.
>
> Basically you can't win and unfortunately a shrink wrap forcing the user
> to read the README file for the kernel violates the GPL ..

Oh, don't get me wrong, I fully understand that it's a lose-lose
situation. All I'm saying is that it was an incredibly bad idea to have
two compilers, one broken and one ok, identify themselves as the same
version.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Ion Badulescu]

On Sat, 3 Feb 2001, Hans Reiser wrote:

> That said, my opinion is that bug reporting load is not as important as bug
> avoidance, but I understand your position has merit to it also.

If you do it, at least restrict it to 2.96.0. Maybe Red Hat will see the
light and release a fixed 2.96.1...

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ReiserFS Oops (2.4.1, deterministic, symlink related)

[Johan Kullstam]

Ion Badulescu <ionut@cs.columbia.edu> writes:

> On Fri, 2 Feb 2001, Alan Cox wrote:
> 
> > Oh I can see why Hans wants to cut down his bug reporting load. I can also
> > say from experience it wont work. If you put #error in then everyone will
> > mail him and complain it doesnt build, if you put #warning in nobody will
> > read it and if you dont put anything in you get the odd bug report anyway.
> >
> > Basically you can't win and unfortunately a shrink wrap forcing the user
> > to read the README file for the kernel violates the GPL ..
> 
> Oh, don't get me wrong, I fully understand that it's a lose-lose
> situation. All I'm saying is that it was an incredibly bad idea to have
> two compilers, one broken and one ok, identify themselves as the same
> version.

unfortunately, it's not limited to redhat and it's not limited to
redhat's gcc-2.96.  gcc-2.95.2 has some bugs (a certain strength
reduction bug comes to mind).  no new official gcc has come for over a
year.  many distributions have applied a patch to fix the strength
reduction bug.  do they all alter their version number?  of those that
do, do they alter it consistently?

-- 
J o h a n  K u l l s t a m
[kullstam@ne.mediaone.net]
Don't Fear the Penguin!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[David Ford]

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

How about a simple patch to the top level makefile that checks the gcc
version then prints a distinct message ..'this compiler hasn't been approved
for compiling the kernel', sleeping for one second, then continuing on.  This
solution doesn't stop compiling and makes a visible indicator without forcing
anything.

Sample attached.

-d

Alan Cox wrote:

> > As it stands, there is no way to determine programatically whether
> > gcc-2.96 is broken or now. The only way to do it is to check the RPM
> > version -- which, needless to say, is a bit difficult to do from the
> > C code about to be compiled. So I can't really blame Hans if he decides
> > to outlaw gcc-2.96[.0] for reiserfs compiles.
>
> Oh I can see why Hans wants to cut down his bug reporting load. I can also
> say from experience it wont work. If you put #error in then everyone will
> mail him and complain it doesnt build, if you put #warning in nobody will
> read it and if you dont put anything in you get the odd bug report anyway.
>
> Basically you can't win and unfortunately a shrink wrap forcing the user
> to read the README file for the kernel violates the GPL ..
>
> Jaded, me ?
>
> Alan

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



[-- Attachment #2: lkml-gccversion.patch --]
[-- Type: text/plain, Size: 961 bytes --]

--- Makefile.orig	Sat Feb  3 00:48:26 2001
+++ Makefile	Sat Feb  3 00:45:00 2001
@@ -253,11 +253,23 @@
 		-o vmlinux
 	$(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map
 
-symlinks:
+symlinks: gccversioncheck
 	rm -f include/asm
 	( cd include ; ln -sf asm-$(ARCH) asm)
 	@if [ ! -d include/linux/modules ]; then \
 		mkdir include/linux/modules; \
+	fi
+
+gccversioncheck:
+	@gccversion=`${HOSTCC} --version`;\
+	echo Using gcc version: $$gccversion;\
+	if [ "x$${gccversion}" != "x2.95.2" ]; then \
+		echo "********************************************************************"; \
+		echo "***  This compiler version is not approved for compiling the kernel"; \
+		echo "***  version: " $$HOSTCC $$gccversion ; \
+		echo "***  Please consider this when reporting bugs" ;\
+		echo "********************************************************************"; \
+		sleep 1; \
 	fi
 
 oldconfig: symlinks

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[J . A . Magallon]

On 02.03 David Ford wrote:
> How about a simple patch to the top level makefile that checks the gcc
> version then prints a distinct message ..'this compiler hasn't been approved
> for compiling the kernel', sleeping for one second, then continuing on.  This
> solution doesn't stop compiling and makes a visible indicator without forcing
> anything.
> 

Or a config option like CONFIG_TRUSTED_COMPILER, and everyone that wants
can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
fails with untrusted compilers it is just not selectable.

-- 
J.A. Magallon                                                      $> cd pub
mailto:jamagallon@able.es                                          $> more beer

Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Felix von Leitner]

Thus spake J . A . Magallon (jamagallon@able.es):
> > How about a simple patch to the top level makefile that checks the gcc
> > version then prints a distinct message ..'this compiler hasn't been approved
> > for compiling the kernel', sleeping for one second, then continuing on.  This
> > solution doesn't stop compiling and makes a visible indicator without forcing
> > anything.
> Or a config option like CONFIG_TRUSTED_COMPILER, and everyone that wants
> can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
> fails with untrusted compilers it is just not selectable.

What kind of crap is this?
It is not the kernel's job to work around RedHat bugs.
If RedHat ships a broken compiler, it is their responsibility to tell
their customers and provide a working one.

This kind of compatibility crap has caused commercial Unices to
suffocate in their own bloat.  We don't need this.  And we don't want
this.

Felix
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[John Alvord]

On Sat, 03 Feb 2001 00:57:45 -0800, David Ford <david@linux.com>
wrote:

>How about a simple patch to the top level makefile that checks the gcc
>version then prints a distinct message ..'this compiler hasn't been approved
>for compiling the kernel', sleeping for one second, then continuing on.  This
>solution doesn't stop compiling and makes a visible indicator without forcing
>anything.

A while ago I worked up a nasty bit of make logic which prompted the
user for yes or no... and then did one thing or the other. You could
ask the user if he REALLY wants to continue and wait for a response.
Following is the model code...
John Alvord
=================

_ECHO=@

all:  t0 t1 t2 t3 t4 t5 t6

# prompt for input, must be in a separate rule to unbuffer terminal
# output.
t0:
     $(_ECHO)echo Enter Y or N: \\c

# capture a line of terminal input, copy to a file, tell user
t1:
     $(_ECHO)echo $(shell read ans; echo ans) > ans
     $(_ECHO)echo The answer is \\c
     $(_ECHO)cat ans

# take first character of answer, upper case, store in another file
# then create two files, one for yes and one for no
# the || exit 0 is to mask the potential grep error, which
# would result in an error message even a - was used to ignore error
# and continue. The result is two files, which may be zero byte
t2:
     $(_ECHO)cat ans | cut -c 1-1 | tr 'a-z' 'A-Z' >ans1
     $(_ECHO)rm -f ansy
     $(_ECHO)rm -f ansn
     $(_ECHO)grep Y ans1 > ansy || exit 0
     $(_ECHO)grep N ans1 > ansn || exit 0

# Check for case where neither answer file is > 0 bytes
t3:
     $(_ECHO)test -s ansy || test -s ansn && exit 0; \
 echo Answer [$(shell cat ans)] is neither Y or N! && exit 1

# handle Yes case. Exit if Y answer file is 0 bytes or missing
t4:
     $(_ECHO)test ! -s ansy  && exit 0; \
     echo in YES processing

# handle No case
t5:
     $(_ECHO)test ! -s ansn  && exit 0; \
     echo in NO processing


# remove files used during processing
t6:
     $(_ECHO)rm -f ans
     $(_ECHO)rm -f ans1
     $(_ECHO)rm -f ansn
     $(_ECHO)rm -f ansy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Alan Cox]

> > can bracket his code in 'if [ $TRUSTED = "y" ] ... fi', so if some driver-fs
> > fails with untrusted compilers it is just not selectable.
> 
> What kind of crap is this?
> It is not the kernel's job to work around RedHat bugs.

The kernel actually works round gcc 2.7.2, egcs-1.1.2 and gcc-2.95 bugs, but
in this case having some CONFIG option and all the glue for it isnt right
especially because there _is_ a fixed compiler and the documentation tells
you to use 1.1.2 or 2.95 anyway
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Brian Wolfe]

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

	I hate to say it but I think Hans might have the right answer here. As an administrator that has worked in large multi hundred million dollar companies where 1 hour of downtime == $75,000 in lost income proactive prevention IS the right answer. If the gcc people need to compile with the .96 rh version then they can apply a removal patch hans provides in the crash message. This makes it easy to remove the safeguard and blow yourself up at will after being suitibly called a dumbass.

	I do understand your desire to keep things simple and not put a safetynet out for every single moron out there. Personaly I despise them. But I also understand the evil necessity of doign this for somet hings that are this serious of a risk.

	From the debate raging here is what I gathered is acceptable....

make it blow up fataly and immediatly if it detects Red Hat + gcc 2.96-red_hat_broken(forgot version num)
make it provide a URL to get the patch to remove this safeguard if you really want this.

	The fatal crash should be VERY carefull to only trigger on a redhat system with the broken compiler. And to satisfy your agument that people may need to be able to use it, provide a reverse patch to remove this safeguard in one easy cat file | patch.

	Brian Wolfe

On Sat, Feb 03, 2001 at 01:06:52AM +0300, Hans Reiser wrote:
> Alan Cox wrote:
> > 
> > > As it stands, there is no way to determine programatically whether
> > > gcc-2.96 is broken or now. The only way to do it is to check the RPM
> > > version -- which, needless to say, is a bit difficult to do from the
> > > C code about to be compiled. So I can't really blame Hans if he decides
> > > to outlaw gcc-2.96[.0] for reiserfs compiles.
> > 
> > Oh I can see why Hans wants to cut down his bug reporting load. I can also
> > say from experience it wont work. If you put #error in then everyone will
> > mail him and complain it doesnt build, if you put #warning in nobody will
> > read it and if you dont put anything in you get the odd bug report anyway.
> > 
> > Basically you can't win and unfortunately a shrink wrap forcing the user
> > to read the README file for the kernel violates the GPL ..
> > 
> > Jaded, me ?
> > 
> > Alan
> 
> I fear that you are speaking from experience about the complaints it doesn't
> build, and that there is a strong element of truth in what you say.
> 
> That said, my opinion is that bug reporting load is not as important as bug
> avoidance, but I understand your position has merit to it also.
> 
> Hans

[-- Attachment #2: Type: application/pgp-signature, Size: 882 bytes --]

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Albert D. Cahalan]

Brian Wolfe writes:

> I hate to say it but I think Hans might have the right answer here.
> As an administrator that has worked in large multi hundred million
> dollar companies where 1 hour of downtime == $75,000 in lost income
...
> From the debate raging here is what I gathered is acceptable....
> 
> make it blow up fataly and immediatly if it detects Red Hat +
> gcc 2.96-red_hat_broken(forgot version num) make it provide a URL
> to get the patch to remove this safeguard if you really want this.
>
> The fatal crash should be VERY carefull to only trigger on a redhat
> system with the broken compiler. And to satisfy your agument that
> people may need to be able to use it, provide a reverse patch to
> remove this safeguard in one easy cat file | patch.

There is another way: directly test for the bug.

In an __init function, have some code that will trigger the bug.
This can be used to disable Reiserfs if the compiler was bad.
Then the admin gets a printk() and the Reiserfs mount fails.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Gregory Maxwell]

On Sun, Feb 04, 2001 at 08:50:13PM -0600, Brian Wolfe wrote:
[snip]
> 	From the debate raging here is what I gathered is acceptable....
> 
> make it blow up fataly and immediatly if it detects Red Hat + gcc 2.96-red_hat_broken(forgot version num)
> make it provide a URL to get the patch to remove this safeguard if you really want this.
> 
> 	The fatal crash should be VERY carefull to only trigger on a redhat system with the broken compiler. And to satisfy your agument that people may need to be able to use it, provide a reverse patch to remove this safeguard in one easy cat file | patch.

No. There are *many* other compilers out there which are much *more* broken
then anything RedHat has recently shipped. Unfortunatly, there is no easy
way to accuratly test for such bugs (because once they can be boiled down to
a simple test they are very rapidly fixed, what's left is voodoo).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Hans Reiser]

Alan Cox wrote:
> 
> > administrator that has worked in large multi hundred million dollar compani=
> > es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
> > ion IS the right answer. If the gcc people need to compile with the .96 rh =
> > version then they can apply a removal patch hans provides in the crash mess=
> > age. This makes it easy to remove the safeguard and blow yourself up at wil=
> > l after being suitibly called a dumbass.
> 
> With all due respect, if you are running $75,000/hr of lost income (which btw
> is small fry to a lot of folks) shouldn't you have an engineering team who
> a) read the documentation.
> b) run tests before rolling out software
> 
> Alan


Think of it as being like gun safety.  You don't seek to develop habits that
protect you when you are awake and alert and paying attention, you strongly seek
to develop the sort of habits that will protect you if for one moment your
attention wanders and you do something completely stupid.  Oh dear, there may be
some cultural translation difficulty with this example.:-)

User protection is a variant on that.  To have an attitude that if the user was
only alert and intelligent at the moment and as educated as you are in how to
compile a kernel, this is just, ahem, not right. 

All things must be kept in balance though, and not taken to extremes.  But when
the number of users complaining exceeds some amount relative to the cost to
protect them, they should be protected from their lack of education in what
distro to not trust the compiler on.

You can go ahead and write software for the always alert and always intelligent
and never too hasty and always read the README users, and I'll be happy with
having the rest of the market for ReiserFS.:-)

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Hans Reiser]

Alan Cox wrote:
> 
> > In an __init function, have some code that will trigger the bug.
> > This can be used to disable Reiserfs if the compiler was bad.
> > Then the admin gets a printk() and the Reiserfs mount fails.
> 
> Thats actually quite doable. I'll see about dropping the test into -ac that
> way.
NOOOOO!!!!!! It should NOT fail at mount time, it should fail at compile time.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Hans Reiser]

Alan Cox wrote:
> 
> > No. There are *many* other compilers out there which are much *more* broken
> > then anything RedHat has recently shipped. Unfortunatly, there is no easy
> > way to accuratly test for such bugs (because once they can be boiled down to
> > a simple test they are very rapidly fixed, what's left is voodoo).
> 
> The problem isn't so much that compilers get bugs and they get fixed as
> soon as a good test case pops up, its that end users don't habitually check
> for a compiler update. Being able to say 'look go get a new compiler' is
> productive. Especially as the kernel can panic with a URL ;)
> 
> Alan

Here we agree.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Alan Cox]

> administrator that has worked in large multi hundred million dollar compani=
> es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
> ion IS the right answer. If the gcc people need to compile with the .96 rh =
> version then they can apply a removal patch hans provides in the crash mess=
> age. This makes it easy to remove the safeguard and blow yourself up at wil=
> l after being suitibly called a dumbass.

With all due respect, if you are running $75,000/hr of lost income (which btw
is small fry to a lot of folks) shouldn't you have an engineering team who
a) read the documentation. 
b) run tests before rolling out software

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Alan Cox]

> In an __init function, have some code that will trigger the bug.
> This can be used to disable Reiserfs if the compiler was bad.
> Then the admin gets a printk() and the Reiserfs mount fails.

Thats actually quite doable. I'll see about dropping the test into -ac that
way.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Alan Cox]

> No. There are *many* other compilers out there which are much *more* broken
> then anything RedHat has recently shipped. Unfortunatly, there is no easy
> way to accuratly test for such bugs (because once they can be boiled down to
> a simple test they are very rapidly fixed, what's left is voodoo).

The problem isn't so much that compilers get bugs and they get fixed as
soon as a good test case pops up, its that end users don't habitually check
for a compiler update. Being able to say 'look go get a new compiler' is
productive. Especially as the kernel can panic with a URL ;)

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink

[Hans Reiser]

Alan Cox wrote:
> 
> > > Thats actually quite doable. I'll see about dropping the test into -ac that
> > > way.
> > NOOOOO!!!!!! It should NOT fail at mount time, it should fail at compile time.
> 
> I was thinking boot time.
and if reiserfs is the root partition?  You really want to make them reboot to
the old kernel and recompile rather than making them just recompile?

Stop trying to blame something other than the compiler, it is ridiculous.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Dr. David Gilbert]

On Mon, 5 Feb 2001, Alan Cox wrote:

> > In an __init function, have some code that will trigger the bug.
> > This can be used to disable Reiserfs if the compiler was bad.
> > Then the admin gets a printk() and the Reiserfs mount fails.
>
> Thats actually quite doable. I'll see about dropping the test into -ac that
> way.

It would actually be nice to have a whole collect of compiler tests in the
kernel; whenever we fall over a compiler bug add the test and leave it in.
Possibly as a separate block of the code.

One thing to remember is not to test for compiler versions; versions which
cause problems on x86 might work fine on real systems and the otherway
round.

Dave

-- 
/------------------------------------------------------------------\
| Dr. David Alan Gilbert | Work:dg@px.uk.com +44-161-286-2000 Ex258|
| -------- G7FHJ --------|---------------------------------------- |
| Home: dave@treblig.org            http://www.treblig.org         |
\------------------------------------------------------------------/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink

[Hans Reiser]

Alan Cox wrote:
> 
> > > I was thinking boot time.
> > and if reiserfs is the root partition?  You really want to make them reboot to
> > the old kernel and recompile rather than making them just recompile?
> 
> I want to make sure they get a sane clear message telling them where to
> find the correct compiler and that they didnt read the docs
> 
> > Stop trying to blame something other than the compiler, it is ridiculous.
> 
> WTF does it have to dow with blaming something other than the compiler ?
> 
> Its going to print something like
> 
> Linux 2.4.2-ac3 blah blah
> Error: This kernel was built with a buggy gcc. Please go to
>         http://.... and upgrade

Sorry, thought you were going to make it only reiserfs disabling, ok, if we do
both this and make the compile fail, that is pretty thorough, effective, useful,
etc.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink

[Alan Cox]

> > Thats actually quite doable. I'll see about dropping the test into -ac that
> > way.
> NOOOOO!!!!!! It should NOT fail at mount time, it should fail at compile time.

I was thinking boot time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink

[Alan Cox]

> > I was thinking boot time.
> and if reiserfs is the root partition?  You really want to make them reboot to
> the old kernel and recompile rather than making them just recompile?

I want to make sure they get a sane clear message telling them where to
find the correct compiler and that they didnt read the docs

> Stop trying to blame something other than the compiler, it is ridiculous.

WTF does it have to dow with blaming something other than the compiler ?

Its going to print something like

Linux 2.4.2-ac3 blah blah
Error: This kernel was built with a buggy gcc. Please go to 
	http://.... and upgrade


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink

[Dr. David Gilbert]

On Mon, 5 Feb 2001, Hans Reiser wrote:

> and if reiserfs is the root partition?  You really want to make them reboot to
> the old kernel and recompile rather than making them just recompile?
>
> Stop trying to blame something other than the compiler, it is ridiculous.

Blaming the compiler is one thing - however stopping the user running into
a bug caused by a dodgy compiler is a different one.

Putting a test in to identify a duff compiler and then stop the kernel
doing something potentially dangerous given that it has been compiled in a
broken way is perfectly reasonable.

Dave

-- 
/------------------------------------------------------------------\
| Dr. David Alan Gilbert | Work:dg@px.uk.com +44-161-286-2000 Ex258|
| -------- G7FHJ --------|---------------------------------------- |
| Home: dave@treblig.org            http://www.treblig.org         |
\------------------------------------------------------------------/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[James Sutherland]

On Mon, 5 Feb 2001, Hans Reiser wrote:

> Alan Cox wrote:
> > 
> > > In an __init function, have some code that will trigger the bug.
> > > This can be used to disable Reiserfs if the compiler was bad.
> > > Then the admin gets a printk() and the Reiserfs mount fails.
> > 
> > Thats actually quite doable. I'll see about dropping the test into -ac that
> > way.
> NOOOOO!!!!!! It should NOT fail at mount time, it should fail at compile time.

A simple "make test" to run this sort of automated sanity check would be
good, I think?


James.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink related)

[Brian Wolfe]

	Oh believe ,e I agree. But here we run into the dilbert principal and we really should be sarter than the IT Diredtor that makes stupid decisions and overrides thier admins with insane schedules that prevent a full reading of the docs. 8-( Believe me, it's far more common a situation than you would ever expect.

	Brian

On Mon, Feb 05, 2001 at 11:55:16AM +0000, Alan Cox wrote:
> > administrator that has worked in large multi hundred million dollar compani=
> > es where 1 hour of downtime =3D=3D $75,000 in lost income proactive prevent=
> > ion IS the right answer. If the gcc people need to compile with the .96 rh =
> > version then they can apply a removal patch hans provides in the crash mess=
> > age. This makes it easy to remove the safeguard and blow yourself up at wil=
> > l after being suitibly called a dumbass.
> 
> With all due respect, if you are running $75,000/hr of lost income (which btw
> is small fry to a lot of folks) shouldn't you have an engineering team who
> a) read the documentation. 
> b) run tests before rolling out software
> 
> Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink

[Albert D. Cahalan]

Hans Reiser writes:
> Alan Cox wrote:
>> [Ablert Cahalan]

>>> In an __init function, have some code that will trigger the bug.
>>> This can be used to disable Reiserfs if the compiler was bad.
>>> Then the admin gets a printk() and the Reiserfs mount fails.
>>
>> Thats actually quite doable. I'll see about dropping the test
>> into -ac that way.
>
> NOOOOO!!!!!! It should NOT fail at mount time, it should fail
> at compile time.

Detection at compile time is not reliable. Just last week, on a
plain x86 box with a good gcc, I was compiling with a compiler
called "/usr/local/bin/powerpc-linux-gcc". Guess what that does.

My compiler was not in the RPM database. My compiler could not
produce executables that would run on the build system, so build-time
tests wouldn't work. Compiler version information is fairly useless,
since x86-specific bugs don't matter at all. Maybe I even patched
my compiler.

Complaints about the local compiler are useful, but not sufficient.
They only protect the menuconfig program, the mkdep program...
As above, actual bug tests are better than trying to interpret
what the compiler reports for a version.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] ReiserFS Oops (2.4.1, deterministic, symlink

[Hans Reiser]

"Albert D. Cahalan" wrote:
> 
> Hans Reiser writes:
> > Alan Cox wrote:
> >> [Ablert Cahalan]
> 
> >>> In an __init function, have some code that will trigger the bug.
> >>> This can be used to disable Reiserfs if the compiler was bad.
> >>> Then the admin gets a printk() and the Reiserfs mount fails.
> >>
> >> Thats actually quite doable. I'll see about dropping the test
> >> into -ac that way.
> >
> > NOOOOO!!!!!! It should NOT fail at mount time, it should fail
> > at compile time.
> 
> Detection at compile time is not reliable. Just last week, on a
> plain x86 box with a good gcc, I was compiling with a compiler
> called "/usr/local/bin/powerpc-linux-gcc". Guess what that does.
> 
> My compiler was not in the RPM database. My compiler could not
> produce executables that would run on the build system, so build-time
> tests wouldn't work. Compiler version information is fairly useless,
> since x86-specific bugs don't matter at all. Maybe I even patched
> my compiler.
> 
> Complaints about the local compiler are useful, but not sufficient.
> They only protect the menuconfig program, the mkdep program...
> As above, actual bug tests are better than trying to interpret
> what the compiler reports for a version.

We only detect bad compilers, and our particular bad compiler only exists on one
particular distro, so it works.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/