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 ([email protected]) (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 ([email protected])
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 [email protected]).
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)
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 ([email protected]) (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 ([email protected])
> 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 [email protected]).
>
> 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)
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)
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 ([email protected]) (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 ([email protected])
> 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 [email protected]).
>
> Hope this helps,
>
> -Yenya
>
>
> This is why our next patch will detect the use of gcc 2.96, and complain, in the
> reiserfs Makefile.
What makes you think its gcc 2.96 ?
If the person concerned can clarify what they built with (2.96-69 or
egcs-1.1.2 (kgcc)), that would be useful.
I've certainly done the Reiserfs testing I did with gcc 2.96-69 with no
problems at all. Reiserfsck was having _bad_ problems but I saw those with
egcs-1.1.2 too and I understand there is a new reiserfsck about to appear
or just out which is much better.
[I've been simulating the effect of bad blocks on file systems]
Worse behaviour so far is minixfs. If an inode rewrite fails leaving what
is now a directory as a file the minix fsck prunes the entire subtree. Very
nasty
Alan
> 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.
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)
> > What makes you think its gcc 2.96 ?
>
> We have had many reports of exactly this symlink problem, and each time it
> was a redhat user with a gcc 2.96, and switching to kgcc fixed it. We have
> one report (now two with Alan's) that 2.96-69 does not show this crash.
Ok. That would make sense.
> Hans, decisions about proper compilers should not be made in each
> individual part of the kernel. If unpatched gcc 2.96 is getting reiserfs
> wrong, it is compiling other parts of the kernel wrong as well. l-k has
> discussed this at length already ;-)
Unpatched 2.96 miscompiles some of the asm in the audio drivers for one.
2.96-69 as far as I can tell breaks just DAC960 and thats an apparently
accidental ABI change in 2.96 and the CVS gcc about how packed enums are
handled.
2.95 and egcs 1.1.2 miscompile strstr() instead 8)
So yes.. nobody should be compiling kernels with 2.96 without the errata
rpm. With it nobody should see any problems and if they do find ones that
go away with kgcc I'd like to know about them (bug me Im sure Linus doesnt care
about them ;))
Alan
On Friday, February 02, 2001 12:26:52 PM +0000 Alan Cox
<[email protected]> wrote:
>> This is why our next patch will detect the use of gcc 2.96, and
>> complain, in the reiserfs Makefile.
>
> What makes you think its gcc 2.96 ?
>
We have had many reports of exactly this symlink problem, and each time it
was a redhat user with a gcc 2.96, and switching to kgcc fixed it. We have
one report (now two with Alan's) that 2.96-69 does not show this crash.
Hans, decisions about proper compilers should not be made in each
individual part of the kernel. If unpatched gcc 2.96 is getting reiserfs
wrong, it is compiling other parts of the kernel wrong as well. l-k has
discussed this at length already ;-)
> If the person concerned can clarify what they built with (2.96-69 or
> egcs-1.1.2 (kgcc)), that would be useful.
>
> I've certainly done the Reiserfs testing I did with gcc 2.96-69 with no
> problems at all. Reiserfsck was having _bad_ problems but I saw those with
> egcs-1.1.2 too and I understand there is a new reiserfsck about to appear
> or just out which is much better.
>
Yes.
-chris
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)
> : 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.
Chris Mason wrote:
> Hans, decisions about proper compilers should not be made in each
> individual part of the kernel. If unpatched gcc 2.96 is getting reiserfs
broke is broke. If you use reiserfs, DO NOT use 2.96. Period. Nobody gains
by letting a single user make this mistake.
> wrong, it is compiling other parts of the kernel wrong as well. l-k has
> discussed this at length already ;-)
So, did Linus say no? If not, let's ask him with a patch. Quite simply,
neither we nor the users should be burdened with this, and the patch removes
the burden.
Hans
> So, did Linus say no? If not, let's ask him with a patch. Quite simply,
> neither we nor the users should be burdened with this, and the patch removes
> the burden.
Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget
to stop those being used as well. Oh look you'll need CVS gcc to build the
kernel... ah but wait that misbuilds DAC960.c...
Oh look nothing compiles the kernel.
Congratulations 8)
Alan
Alan Cox wrote:
>
> > So, did Linus say no? If not, let's ask him with a patch. Quite simply,
> > neither we nor the users should be burdened with this, and the patch removes
> > the burden.
>
> Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget
> to stop those being used as well. Oh look you'll need CVS gcc to build the
> kernel... ah but wait that misbuilds DAC960.c...
>
> Oh look nothing compiles the kernel.
>
> Congratulations 8)
>
> Alan
Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use
reiserfs. It is that simple. How can you even consider defending allowing the
use of it without requiring a positive affirmation by the user that they don't
know what they are doing and want to do it anyway?:-) I could understand
arguing that you don't want to be bothered with protecting the users because you
don't have the time, but if somebody else finds the time to write the patch....
I would indeed encourage Linus to accept patches to test for known bad compilers
at make time. It is less work for us all to prevent users from having bugs than
to respond to their having them. I look forward to gcc 3.00, and I encourage
the compiler guys to get over being (understandably) irked that somebody else
released their code prematurely, and to increment the version number to 2.97 so
that users can more easily avoid the baddie.
Hans
> Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use
> reiserfs. It is that simple. How can you even consider defending allowing the
> use of it without requiring a positive affirmation by the user that they don't
> know what they are doing and want to do it anyway?:-) I could understand
The kernel documentation explicitly says to use egcs-1.1.2 or 2.95 for x86.
If you want to put in #ifdefs then let me assure you that you will then get
a million emails that 'reiserfs doesnt build'. I went this way with older
gcc's in 2.0 and the amount of mail more than doubled by doing the check
If people use other compilers then certainly ignore the bug reports. For 2.2
until recently that was policy with gcc 2.95
Also remember to check for 2.96 but not 2.96-69 (the errata one) and remember
to do specific architecture tests as there is no other compiler set available
for IA64 for example.
> to respond to their having them. I look forward to gcc 3.00, and I encourage
> the compiler guys to get over being (understandably) irked that somebody else
Gcc 3.0 CVS branch wont build the kernel either right now - DAC960 fails.
Alan
My last comment on this...
It makes sense to refuse to build a piece of the kernel if it break's
a machine - anything else is a timebomb waiting to explode.
I feel politics are at play here...I don't really care who's bug it is -
all I know is using pre 2.96 fixes it and everyone needs to be aware of
this. If this means checking in Reiserfs makefile or the main Linux
makefile then so be it.
Its simple logic ;-)
John
> Alan Cox wrote:
> >
> > > So, did Linus say no? If not, let's ask him with a patch. Quite simply,
> > > neither we nor the users should be burdened with this, and the patch removes
> > > the burden.
> >
> > Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget
> > to stop those being used as well. Oh look you'll need CVS gcc to build the
> > kernel... ah but wait that misbuilds DAC960.c...
> >
> > Oh look nothing compiles the kernel.
> >
> > Congratulations 8)
> >
> > Alan
>
>
> Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use
> reiserfs. It is that simple. How can you even consider defending allowing the
> use of it without requiring a positive affirmation by the user that they don't
> know what they are doing and want to do it anyway?:-) I could understand
> arguing that you don't want to be bothered with protecting the users because you
> don't have the time, but if somebody else finds the time to write the patch....
>
> I would indeed encourage Linus to accept patches to test for known bad compilers
> at make time. It is less work for us all to prevent users from having bugs than
> to respond to their having them. I look forward to gcc 3.00, and I encourage
> the compiler guys to get over being (understandably) irked that somebody else
> released their code prematurely, and to increment the version number to 2.97 so
> that users can more easily avoid the baddie.
>
> Hans
>
> It makes sense to refuse to build a piece of the kernel if it break's
> a machine - anything else is a timebomb waiting to explode.
The logical conclusion of that is to replace the entire kernel tree with
#error "compiler or program might have a bug. Aborting"
The kernel is NOT some US home appliance festooned with 'do not eat this
furniture' and 'do not expose your laserwrite to naked flame' messages.
The readme says its been tested with egcs-1.1.2 and gcc 2.95.
The same people who can't read documentation will just mail the list with
'it doesnt compile, help' or 'it doesnt compile, you suck' in less enlightened
cases/
Large numbers of people routinely build the kernel with 'unsupported' compilers
notably the pgcc project people and another group you will cause problems for
- the GCC maintainers. They use the kernel tree as part of the test set for
their kernel, something putting #ifdefs all over it will mean they have to
mess around to fix too.
Alan
Lets not go overboard Alan ;-)
> > It makes sense to refuse to build a piece of the kernel if it break's
> > a machine - anything else is a timebomb waiting to explode.
>
> The logical conclusion of that is to replace the entire kernel tree with
>
> #error "compiler or program might have a bug. Aborting"
>
> The kernel is NOT some US home appliance festooned with 'do not eat this
> furniture' and 'do not expose your laserwrite to naked flame' messages.
> The readme says its been tested with egcs-1.1.2 and gcc 2.95.
>
> The same people who can't read documentation will just mail the list with
> 'it doesnt compile, help' or 'it doesnt compile, you suck' in less enlightened
> cases/
>
> Large numbers of people routinely build the kernel with 'unsupported' compilers
> notably the pgcc project people and another group you will cause problems for
> - the GCC maintainers. They use the kernel tree as part of the test set for
> their kernel, something putting #ifdefs all over it will mean they have to
> mess around to fix too.
>
> Alan
>
Alan Cox wrote:
>
> > Users cannot use gcc 2.96 as shipped in RedHat 7.0 if they want to use
> > reiserfs. It is that simple. How can you even consider defending allowing the
> > use of it without requiring a positive affirmation by the user that they don't
> > know what they are doing and want to do it anyway?:-) I could understand
>
> The kernel documentation explicitly says to use egcs-1.1.2 or 2.95 for x86.
> If you want to put in #ifdefs then let me assure you that you will then get
> a million emails that 'reiserfs doesnt build'. I went this way with older
> gcc's in 2.0 and the amount of mail more than doubled by doing the check
I'd rather have them complain it doesn't build than never complain because they
think reiserfs is still a little too new and has bugs. Also, I just don't think
my convenience matters as much as that of the users. I don't want to use
#ifdefs, I want it to die explosively and verbosely informatively. make isn't
the most natural language for that, but I am sure Yura can find a way.
>
> If people use other compilers then certainly ignore the bug reports. For 2.2
> until recently that was policy with gcc 2.95
We don't (at least not intentionally, surely someone is going to mention one
where we did) ignore bug reports on our mailing list. Period.
We are capable of telling users, you know, this is user error, if you want
detailed help send me a note that you have put $25 in the mail, and I'll have
someone give you step by step help with it. If it is easy to narrow the user
error down from the first email I typically just tell them what it is.
>
> Also remember to check for 2.96 but not 2.96-69 (the errata one) and remember
> to do specific architecture tests as there is no other compiler set available
> for IA64 for example.
>
> > to respond to their having them. I look forward to gcc 3.00, and I encourage
> > the compiler guys to get over being (understandably) irked that somebody else
>
> Gcc 3.0 CVS branch wont build the kernel either right now - DAC960 fails.
>
> Alan
Please delay shipping the 3.0 CVS branch on RedHat for a while.:-) Sorry, I
couldn't resist.
Look, everybody lets a piece of software slip out that should not have gone at
some point in their career. It is just that RedHat is big enough that everyone
is inconvenienced when they do so, and so we need to patch a Makefile to reduce
the annoyance. No biggie.
Hans
> my convenience matters as much as that of the users. I don't want to use
> #ifdefs, I want it to die explosively and verbosely informatively. make isn't
> the most natural language for that, but I am sure Yura can find a way.
Run a small shell check and let it fail if the shell stuff errors.
The fragment you want is
if [ -e /bin/rpm ]; then
X=`rpm -q gcc`
if [ "$X" = "gcc-2.96-54" ]; then
echo "*** GCC 2.96-54 will miscompile Reiserfs. Please update your compiler"
echo "See http://www.redhat.com/support/errata/RHBA-2000-132.html"
exit 255
fi
fi
> Please delay shipping the 3.0 CVS branch on RedHat for a while.:-) Sorry, I
> couldn't resist.
Grin. gcc 3.0 is going to be just as much fun Im sure, but finally should give
everyone a stable C and more importantly C++ base including the LSB standards.
Alan
Alan Cox wrote:
>
> > It makes sense to refuse to build a piece of the kernel if it break's
> > a machine - anything else is a timebomb waiting to explode.
>
> The logical conclusion of that is to replace the entire kernel tree with
>
> #error "compiler or program might have a bug. Aborting"
No, this is a compiler that DOES have a bug. ReiserFS is, as best as I can make
it, for mission critical servers where some sysadmin doesn't want to
explain it to the CEO. There are plenty of ways that I fail at this, but not
intentionally.
These sorts of mission critical servers are frequently installed by persons
short on sleep because a whole lot of things more interesting than ReiserFS
had to be gotten working for that server, and who are barely able to convince
their boss that compiling a kernel themselves is an okay thing for them to be
allowed to do.
Taking an attitude of, you didn't read the README, you didn't read Slashdot, you
just assumed the distro wouldn't install a compiler unable to compile the
kernel, you lose, is not the way I treat such customers.
Our users have better things to do than read our FAQ. They REALLY do. ReiserFS
is a product of only marginal interest to them. They trust that
it will just work because it isn't a Microsoft product.
My design objective in ReiserFS is not to say that it wasn't my fault they had
that bug because they are so ignorant about a filesystem that
really isn't very important to them unless it screws up. My design objective is
to ensure they don't have that bug. They are more important than me.
>
> The kernel is NOT some US home appliance festooned with 'do not eat this
> furniture' and 'do not expose your laserwrite to naked flame' messages.
> The readme says its been tested with egcs-1.1.2 and gcc 2.95.
>
> The same people who can't read documentation will just mail the list with
> 'it doesnt compile, help' or 'it doesnt compile, you suck' in less enlightened
> cases/
>
> Large numbers of people routinely build the kernel with 'unsupported' compilers
> notably the pgcc project people and another group you will cause problems for
> - the GCC maintainers. They use the kernel tree as part of the test set for
> their kernel, something putting #ifdefs all over it will mean they have to
> mess around to fix too.
>
> Alan
A moment of precision here. We won't test to see if the right compiler is used,
we will just test for the wrong one.
Hans
> > their kernel, something putting #ifdefs all over it will mean they have to
> > mess around to fix too.
> >
> A moment of precision here. We won't test to see if the right compiler is used,
> we will just test for the wrong one.
Ok that makes a lot more sense
Alan Cox wrote:
>
> > my convenience matters as much as that of the users. I don't want to use
> > #ifdefs, I want it to die explosively and verbosely informatively. make isn't
> > the most natural language for that, but I am sure Yura can find a way.
>
> Run a small shell check and let it fail if the shell stuff errors.
>
> The fragment you want is
>
> if [ -e /bin/rpm ]; then
> X=`rpm -q gcc`
> if [ "$X" = "gcc-2.96-54" ]; then
> echo "*** GCC 2.96-54 will miscompile Reiserfs. Please update your compiler"
> echo "See http://www.redhat.com/support/errata/RHBA-2000-132.html"
> exit 255
> fi
> fi
>
> > Please delay shipping the 3.0 CVS branch on RedHat for a while.:-) Sorry, I
> > couldn't resist.
>
> Grin. gcc 3.0 is going to be just as much fun Im sure, but finally should give
> everyone a stable C and more importantly C++ base including the LSB standards.
>
> Alan
Ok, thanks Alan, we'll use it, Yura, write something resembling or equal to
this, test it, and check it into our CVS branch.
Hans
Alan Cox wrote:
>
> > > their kernel, something putting #ifdefs all over it will mean they have to
> > > mess around to fix too.
> > >
> > A moment of precision here. We won't test to see if the right compiler is used,
> > we will just test for the wrong one.
>
> Ok that makes a lot more sense
Ok, so with that last clarification, we are all in agreement I think.
Thanks for the code frag Alan,
Hans
On Fri, 2 Feb 2001 16:39:18 -0500 (EST),
Alan Cox <[email protected]> wrote:
>Large numbers of people routinely build the kernel with 'unsupported' compilers
<irony>
gcc version 2.96-ia64-000717 snap 001117 - works for me doing cross
compile from ia32 to ia64. Anybody adding #ifdef, please include this
version, oh and also include the version of gcc on the latest Redhat
ia64 beta, and the version of gcc on the latest Turbolinux ia64 beta.
Don't forget to include a check for cross compile, querying the local
rpm will not work in cross compile mode.
On second thoughts, forget about #ifdef.
</irony>
On Sat, Feb 03, 2001 at 01:03:00AM +0300, Hans Reiser wrote:
> My design objective in ReiserFS is not to say that it wasn't my fault they had
> that bug because they are so ignorant about a filesystem that
> really isn't very important to them unless it screws up. My design objective is
> to ensure they don't have that bug. They are more important than me.
The whole argument back and forth here seems to be:
Hans: It's better if it fails to compile with a clear message than compiling
ok and breaking horribly and unpredictably later.
Alan: It won't work and it'll generate more mail, not less.
Now, it seems to me, as long as the ReiserFS folks are going to be getting the
bulk of the extra work(/mail/whatever) out of this, and they've been advised
of the risks to their own person and are ok with that (which they apparently
are), then they might as well go ahead and try it. It's their inboxes.
The one thing I do have to say about all of this, however, is that if this
sort of testing for compiler issues (or tool issues, or library issues or
anything else) is going to be done as part of individual kernel components,
there should be some way to globally configure this, so that it can be turned
off should someone, for some reason, want (or need) to do something with an
unsupported version of something and know what they're doing, without having
to hunt through every line of kernel source to find the multiple places
different developers have put in different checks for the thing they're
trying to do.
Perhaps a "Kernel Hacking" configuration option (or just something in a
documented .h file) for "Allow compiling with buggy GCC 2.96" which would turn
off all such checks?
-alex
On 02.02 Hans Reiser wrote:
> Alan Cox wrote:
> > Run a small shell check and let it fail if the shell stuff errors.
> >
> > The fragment you want is
> >
> > if [ -e /bin/rpm ]; then
> > X=`rpm -q gcc`
> > if [ "$X" = "gcc-2.96-54" ]; then
> > echo "*** GCC 2.96-54 will miscompile Reiserfs. Please
> update your compiler"
> > echo "See http://www.redhat.com/support/errata/RHBA-2000-132.html"
> > exit 255
> > fi
> > fi
> Ok, thanks Alan, we'll use it, Yura, write something resembling or equal to
> this, test it, and check it into our CVS branch.
>
Please, do not do so. That depends on the PACKAGE name and version, and there
is no standard way of versioning a patched gcc.
The -54 is a RH'ism, for example Mandrake Cooker includes patches from
different sources, and gcc is versioned like
werewolf:~# rpm -q gcc
gcc-2.96-0.33mdk
and ChangeLog is:
werewolf:~# rpm -q --changelog gcc
* Mon Jan 15 2001 David BAUDENS <[email protected]> 2.96-0.33mdk
- Fix build on PPC
* Mon Jan 15 2001 Chmouel Boudjnah <[email protected]> 2.96-0.32mdk
- Try to fix when alternatives is broken in %post.
- Merge with RH package (rel70) of Jakub :
^^^^^^^
..
so it suits a 2.96-70 gcc.
--
J.A. Magallon $> cd pub
mailto:[email protected] $> more beer
Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686
I would agree with you, and I was about to write something saying that trusting
that rpm is installed is bad, except that then I realized, only RedHat made this
error, and only RedHat installs need this protection.
Now, if we want to have a more general bad gcc's list, and we envision this code
evolving, then yes, Alan's code is way too specific, and we should do it
differently so as to force them to increment what gcc -v returns whenever they
want anybody to pay attention to their having fixed a bug. I was trying to be
sociable for once though....
Hans
"J . A . Magallon" wrote:
>
> On 02.02 Hans Reiser wrote:
> > Alan Cox wrote:
> > > Run a small shell check and let it fail if the shell stuff errors.
> > >
> > > The fragment you want is
> > >
> > > if [ -e /bin/rpm ]; then
> > > X=`rpm -q gcc`
> > > if [ "$X" = "gcc-2.96-54" ]; then
> > > echo "*** GCC 2.96-54 will miscompile Reiserfs. Please
> > update your compiler"
> > > echo "See http://www.redhat.com/support/errata/RHBA-2000-132.html"
> > > exit 255
> > > fi
> > > fi
> > Ok, thanks Alan, we'll use it, Yura, write something resembling or equal to
> > this, test it, and check it into our CVS branch.
> >
>
> Please, do not do so. That depends on the PACKAGE name and version, and there
> is no standard way of versioning a patched gcc.
> The -54 is a RH'ism, for example Mandrake Cooker includes patches from
> different sources, and gcc is versioned like
>
> werewolf:~# rpm -q gcc
> gcc-2.96-0.33mdk
>
> and ChangeLog is:
>
> werewolf:~# rpm -q --changelog gcc
> * Mon Jan 15 2001 David BAUDENS <[email protected]> 2.96-0.33mdk
>
> - Fix build on PPC
>
> * Mon Jan 15 2001 Chmouel Boudjnah <[email protected]> 2.96-0.32mdk
>
> - Try to fix when alternatives is broken in %post.
> - Merge with RH package (rel70) of Jakub :
> ^^^^^^^
> ..
>
> so it suits a 2.96-70 gcc.
>
> --
> J.A. Magallon $> cd pub
> mailto:[email protected] $> more beer
>
> Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686
On Sat, Feb 03, 2001 at 12:40:03AM +0100, J . A . Magallon wrote:
> Please, do not do so. That depends on the PACKAGE name and version, and there
> is no standard way of versioning a patched gcc.
> The -54 is a RH'ism, for example Mandrake Cooker includes patches from
> different sources, and gcc is versioned like
You can do:
if [ "$CC" = gcc ]; then
echo 'inline void f(unsigned int n){int i,j=-1;for(i=0;i<10&&j<0;i++)if((1UL<<i)==n)j=i;if(j<0)exit(0);}main(){f(64);exit(1);}' > test.c
gcc -O2 -o test test.c
if ./test; then echo "*** Please don't use this compiler to compile kernel"; fi
rm -f test.c test
fi
(the $CC = gcc test is there e.g. so that the test is not done when
cross-compiling or when there is a separate kernel compiler and userland
compiler (e.g. on sparc64). This test will barf on gcc-2.96 up to -67 and
on 2.97 until end of November or so).
Similarly a testcase for the reload bug which caused in 2.95.2
miscompilation of some long long stuff in the kernel could be added as well
if you want to go that way.
Jakub
On Fri, Feb 02, 2001 at 02:58:14PM -0800, [email protected] wrote:
> Now, it seems to me, as long as the ReiserFS folks are going to be getting the
> bulk of the extra work(/mail/whatever) out of this, and they've been advised
> of the risks to their own person and are ok with that (which they apparently
> are), then they might as well go ahead and try it. It's their inboxes.
okay, i don't really want to prolong this debate any longer, but why not put
something in Documentation/Configure.help along the lines of "warning: gcc
2.96 has been known to cause errors with reiserfs! if it goes weird on you,
_upgrade (or downgrade) your compiler and re-compile your kernel_."
imho Configure.help would be one of the best places to put notices such as
these.
--
/ #ozone <[email protected]>; (mobile# 0411 882299)
trust in love to save
On Sat, 3 Feb 2001, Hans Reiser wrote:
> Alan Cox wrote:
> >
> > > It makes sense to refuse to build a piece of the kernel if it break's
> > > a machine - anything else is a timebomb waiting to explode.
> >
> > The logical conclusion of that is to replace the entire kernel tree with
> >
> > #error "compiler or program might have a bug. Aborting"
>
> No, this is a compiler that DOES have a bug. ReiserFS is, as best as
> I can make it, for mission critical servers where some sysadmin
> doesn't want to explain it to the CEO. There are plenty of ways that
> I fail at this, but not intentionally.
Yep. For once, I agree with Hans here: if you *KNOW* the current compiler
is fatally broken, the best thing to do is blow up. As hard as possible,
as soon as possible. Anything else is just hiding the problem.
(snip)
> My design objective in ReiserFS is not to say that it wasn't my fault
> they had that bug because they are so ignorant about a filesystem that
> really isn't very important to them unless it screws up. My design
> objective is to ensure they don't have that bug. They are more
> important than me.
Hrm... better idiot-proofing just tends to produce better idiots.
> > The kernel is NOT some US home appliance festooned with 'do not eat this
> > furniture' and 'do not expose your laserwrite to naked flame' messages.
> > The readme says its been tested with egcs-1.1.2 and gcc 2.95.
Hrm. Ever wonder which country Alan lives in? :-)
(Alan: Visit the next McDonalds you pass, and buy a coffee. Look at the
warning on the side about the coffee being hot... then complain it isn't,
after a suitable delay...)
> > Large numbers of people routinely build the kernel with 'unsupported' compilers
> > notably the pgcc project people and another group you will cause problems for
> > - the GCC maintainers. They use the kernel tree as part of the test set for
> > their kernel, something putting #ifdefs all over it will mean they have to
> > mess around to fix too.
If it's specific enough to that particular gcc, it won't trip the gcc
people up - unless they're really using that specific version, in which
case it SHOULD blow up anyway!
> A moment of precision here. We won't test to see if the right
> compiler is used, we will just test for the wrong one.
Which is fine, IMO. "Warning: your compiler MIGHT be broken - please look
at README" is OK, as is "Error: this compiler *IS* broken - it's gcc X.XX,
which we know is broken because (foo)". "Error: this compiler looks like
version foo, which we think might be broken" isn't, as Alan says...
James.
On Fri, 2 Feb 2001, Jakub Jelinek wrote:
> You can do:
> if [ "$CC" = gcc ]; then
> echo 'inline void f(unsigned int n){int i,j=-1;for(i=0;i<10&&j<0;i++)if((1UL<<i)==n)j=i;if(j<0)exit(0);}main(){f(64);exit(1);}' > test.c
> gcc -O2 -o test test.c
> if ./test; then echo "*** Please don't use this compiler to compile kernel"; fi
> rm -f test.c test
> fi
>
> (the $CC = gcc test is there e.g. so that the test is not done when
> cross-compiling or when there is a separate kernel compiler and userland
> compiler (e.g. on sparc64). This test will barf on gcc-2.96 up to -67 and
>
> Jakub
ehhmm..
[root@fogarty /tmp]# rpm -q gcc
gcc-2.96-70
[root@fogarty /tmp]# cat test.c
inline void f(unsigned int n){int
i,j=-1;for(i=0;i<10&&j<0;i++)if((1UL<<i)==n)j=i;if(j<0)exit(0);}main(){f(64);
exit(1);}
[root@fogarty /tmp]# gcc -o test test.c
[root@fogarty /tmp]# ./test
didn't barf here with 2.96-70.
regards,
--
Paul Jakma [email protected] [email protected]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
One person's error is another person's data.
> Please, do not do so. That depends on the PACKAGE name and version, and there
> is no standard way of versioning a patched gcc.
> The -54 is a RH'ism, for example Mandrake Cooker includes patches from
> different sources, and gcc is versioned like
>
> werewolf:~# rpm -q gcc
> gcc-2.96-0.33mdk
Thats fine. It doesnt matcht he problem one. If you know which are the problem
ones on Mandrake add those too
You can also use
if [ -e /bin/rpm ]; then
if [ -e /etc/redhat-release ]; then
> > compiler (e.g. on sparc64). This test will barf on gcc-2.96 up to -67 and
> > Jakub
>
> ehhmm..
>
> didn't barf here with 2.96-70.
Which is correct
On 02.03 Paul Jakma wrote:
>
> didn't barf here with 2.96-70.
>
Does not barf nor 1 nor 0. Check return core (ie, echo $?).
--
J.A. Magallon $> cd pub
mailto:[email protected] $> more beer
Linux werewolf 2.4.1-ac1 #2 SMP Fri Feb 2 00:19:04 CET 2001 i686
On Sat, Feb 03, 2001 at 04:25:20AM +0000, Paul Jakma wrote:
> On Fri, 2 Feb 2001, Jakub Jelinek wrote:
>
> > You can do:
> > if [ "$CC" = gcc ]; then
> > echo 'inline void f(unsigned int n){int i,j=-1;for(i=0;i<10&&j<0;i++)if((1UL<<i)==n)j=i;if(j<0)exit(0);}main(){f(64);exit(1);}' > test.c
> > gcc -O2 -o test test.c
> > if ./test; then echo "*** Please don't use this compiler to compile kernel"; fi
> > rm -f test.c test
> > fi
> >
> > (the $CC = gcc test is there e.g. so that the test is not done when
> > cross-compiling or when there is a separate kernel compiler and userland
> > compiler (e.g. on sparc64). This test will barf on gcc-2.96 up to -67 and
> >
> > Jakub
>
> ehhmm..
>
> [root@fogarty /tmp]# rpm -q gcc
> gcc-2.96-70
> [root@fogarty /tmp]# cat test.c
> inline void f(unsigned int n){int
> i,j=-1;for(i=0;i<10&&j<0;i++)if((1UL<<i)==n)j=i;if(j<0)exit(0);}main(){f(64);
> exit(1);}
> [root@fogarty /tmp]# gcc -o test test.c
> [root@fogarty /tmp]# ./test
>
> didn't barf here with 2.96-70.
I used a wrong word (the test originally had abort() instead of exit(0) and
exit(0) instead of exit(1)). The test will exit with 0 if it was
miscompiled, 1 if it was not. And on 2.96-70 it should exit with 1 as it
should not be miscompiled.
Jakub
On Fri, 2 Feb 2001, Alan Cox wrote:
> if [ -e /bin/rpm ]; then
> X=`rpm -q gcc`
> if [ "$X" = "gcc-2.96-54" ]; then
> echo "*** GCC 2.96-54 will miscompile Reiserfs. Please update your compiler"
> echo "See http://www.redhat.com/support/errata/RHBA-2000-132.html"
> exit 255
> fi
> fi
-a "$CC" = "gcc"
--
dwmw2
David Woodhouse writes:
> -a "$CC" = "gcc"
Not worth it; they should upgrade the local gcc too.
If anything, they are getting a reminder that they need.
> David Woodhouse writes:
>
> > -a "$CC" = "gcc"
>
> Not worth it; they should upgrade the local gcc too.
> If anything, they are getting a reminder that they need.
The local gcc has no bearing on the compiler. The local compiler might not
even be gcc - eg if they are cross building off non Linux systems
Alan Cox writes:
> [Albert Cahalan]
>> David Woodhouse writes:
>>> -a "$CC" = "gcc"
>>
>> Not worth it; they should upgrade the local gcc too.
>> If anything, they are getting a reminder that they need.
>
> The local gcc has no bearing on the compiler. The local
> compiler might not even be gcc - eg if they are cross
> building off non Linux systems
I know, and it still doesn't matter. So we test Solaris cc.
If it happens to have the same bug as gcc 2.96, then it is
broken and ought to be replaced.
I wouldn't want "menuconfig" messed up by a broken compiler,
even if I'm cross-compiling from HP-UX to sh4 Linux.
> Since egcs-1.1.2 and gcc 2.95 miscompile the kernel strstr code dont forget
> to stop those being used as well. Oh look you'll need CVS gcc to build the
> kernel... ah but wait that misbuilds DAC960.c...
How did you come to the conclusion that egcs-1.1.2 miscompiles the kernel?
I am using gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) for a
while now and did not notice anything weird.
Tom
--
T h o m a s Z e h e t b a u e r ( TZ251 )
PGP encrypted mail preferred - KeyID 96FFCB89
mail [email protected]