Liebe Listigen, Hab mir gerade den k_athlon-2.4.19-128.i586.rpm eingespielt und dann den mk_initrd nachgesetzt. Beim Booten bleibt das System beim Starting hardwarescan on boot/usr/sbin/hwbootscan line 16: 877 segmentationfault /usr/sbin/hwscan --cdrom hängen. Hab dann wieder den originalen aus der SuSE 8.1 zurückgemoved! Hat da jemand von Euch ne Idee, woran das liegen könnte! Bin etwas ratlos! Anbei die Ausgabe von dmesg für den Original-Kernel: Linux version 2.4.19-4GB (root@Athlon.suse.de) (gcc version 3.2) #1 Fri Sep 13 13:19:15 UTC 2002 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009e800 (usable) BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000002ffec000 (usable) BIOS-e820: 000000002ffec000 - 000000002ffef000 (ACPI data) BIOS-e820: 000000002ffef000 - 000000002ffff000 (reserved) BIOS-e820: 000000002ffff000 - 0000000030000000 (ACPI NVS) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 767MB LOWMEM available. ACPI: have wakeup address 0xc0001000 Advanced speculative caching feature not present On node 0 totalpages: 196588 zone(0): 4096 pages. zone(1): 192492 pages. zone(2): 0 pages. ACPI: RSDP (v000 ASUS ) @ 0x000f67c0 ACPI: RSDT (v001 ASUS A7V-133 12336.12337) @ 0x2ffec000 ACPI: FADT (v001 ASUS A7V-133 12336.12337) @ 0x2ffec080 ACPI: BOOT (v001 ASUS A7V-133 12336.12337) @ 0x2ffec040 ACPI: MADT not present Building zonelist for node : 0 Kernel command line: root=/dev/hde5 hdc=ide-scsi vga=791 ide_setup: hdc=ide-scsi Initializing CPU#0 Detected 1009.013 MHz processor. Console: colour dummy device 80x25 Calibrating delay loop... 2011.95 BogoMIPS Memory: 773624k/786352k available (1685k kernel code, 12336k reserved, 413k data, 164k init, 0k highmem) Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode cache hash table entries: 65536 (order: 7, 524288 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000 CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000 CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel ACPI: Subsystem revision 20020829 PCI: PCI BIOS revision 2.10 entry at 0xf1150, last bus=1 PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: System [ACPI] (supports S0 S1 S4 S5) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12 14 15, disabled) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) Disabling VIA memory write queue (PCI ID 0305, rev 03): [55] 28 & 1f -> 08 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] PCI: Probing PCI hardware PCI: Using IRQ router VIA [1106/0686] at 00:04.0 Applying VIA southbridge workaround. PCI: Disabling Via external APIC routing Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16) apm: overridden by ACPI. Starting kswapd bigpage subsystem: allocated 0 bigpages (=0MB). kinoded started VFS: Diskquotas version dquot_6.5.0 initialized aio_setup: num_physpages = 49147 aio_setup: sizeof(struct page) = 48 vesafb: framebuffer at 0xd8000000, mapped to 0xf0817000, size 65536k vesafb: mode is 1024x768x16, linelength=2048, pages=41 vesafb: protected mode interface info at c000:53ab vesafb: scrolling: redraw vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0 Looking for splash picture.... found (1024x768, 27920 bytes). Console: switching to colour frame buffer device 106x34 fb0: VESA VGA frame buffer device pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10e 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 21 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:04.1 ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:DMA, hdd:pio PDC20265: IDE controller on PCI bus 00 dev 88 PCI: Found IRQ 10 for device 00:11.0 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. ide2: BM-DMA at 0x7800-0x7807, BIOS settings: hde:DMA, hdf:DMA ide3: BM-DMA at 0x7808-0x780f, BIOS settings: hdg:DMA, hdh:DMA hda: Pioneer DVD-ROM ATAPIModel DVD-116 0107, ATAPI CD/DVD-ROM drive hdc: CD-W58E, ATAPI CD/DVD-ROM drive hde: Maxtor 34098H4, ATA DISK drive hdg: WDC WD307AA-00BAA0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 ide2 at 0x9000-0x9007,0x8802 on irq 10 ide3 at 0x8400-0x8407,0x8002 on irq 10 blk: queue c039cfbc, I/O limit 4095Mb (mask 0xffffffff) hde: failed write cache flush, disabling ordered write support hde: 80043264 sectors (40982 MB) w/2048KiB Cache, CHS=79408/16/63, UDMA(100) blk: queue c039d318, I/O limit 4095Mb (mask 0xffffffff) hdg: safely enabled flush hdg: 60074784 sectors (30758 MB) w/2048KiB Cache, CHS=59598/16/63, UDMA(66) ide-floppy driver 0.99.newide Partition check: hde: hde1 < hde5 hde6 hde7 hde8 hde9 hde10 hde11 hde12 > hdg: hdg1 < hdg5 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 RAMDISK driver initialized: 16 RAM disks of 64000K size 1024 blocksize loop: loaded (max 16 devices) Cronyx Ltd, Synchronous PPP and CISCO HDLC (c) 1994 Linux port (c) 1998 Building Number Three Ltd & Jan "Yenya" Kasprzak. ide-floppy driver 0.99.newide SCSI subsystem driver Revision: 1.00 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 8192 buckets, 64Kbytes TCP: Hash tables configured (established 262144 bind 65536) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. RAMDISK: Compressed image found at block 0 Freeing initrd memory: 277k freed VFS: Mounted root (ext2 filesystem). hda: no flushcache support hda: ATAPI 40X DVD-ROM drive, 256kB Cache Uniform CD-ROM driver Revision: 3.12 hdc: no flushcache support scsi0 : SCSI host adapter emulation for IDE ATAPI devices Vendor: TEAC Model: CD-W58E Rev: 1.0A Type: CD-ROM ANSI SCSI revision: 02 sd_attach() reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (ide2(33,5)) for (ide2(33,5)) reiserfs: using ordered data mode Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Trying to move old root to /initrd ... failed Unmounting old root Trying to free ramdisk memory ... okay Freeing unused kernel memory: 164k freed md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. LVM version 1.0.5(mp-v6)(15/07/2002) module loaded Adding Swap: 768056k swap-space (priority 42) reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (ide2(33,10)) for (ide2(33,10)) reiserfs: using ordered data mode Using r5 hash to sort names reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (ide2(33,12)) for (ide2(33,12)) reiserfs: using ordered data mode Using r5 hash to sort names reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (ide2(33,9)) for (ide2(33,9)) reiserfs: using ordered data mode Using r5 hash to sort names reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (ide2(33,6)) for (ide2(33,6)) reiserfs: using ordered data mode Using r5 hash to sort names reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (ide2(33,8)) for (ide2(33,8)) reiserfs: using ordered data mode Using r5 hash to sort names reiserfs: found format "3.6" with standard journal reiserfs: checking transaction log (ide3(34,5)) for (ide3(34,5)) reiserfs: using ordered data mode Using r5 hash to sort names 8139too Fast Ethernet driver 0.9.26 PCI: Found IRQ 5 for device 00:0d.0 PCI: Sharing IRQ 5 with 00:04.2 PCI: Sharing IRQ 5 with 00:04.3 PCI: Sharing IRQ 5 with 00:09.0 eth0: RealTek RTL8139 Fast Ethernet at 0xf4ebe000, 00:e0:7d:98:6e:99, IRQ 5 eth0: Identified 8139 chip type 'RTL-8139C' eth0: Setting half-duplex based on auto-negotiated partner ability 0000. usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.275 $ time 13:56:25 Sep 13 2002 usb-uhci.c: High bandwidth mode enabled PCI: Found IRQ 5 for device 00:04.2 PCI: Sharing IRQ 5 with 00:04.3 PCI: Sharing IRQ 5 with 00:09.0 PCI: Sharing IRQ 5 with 00:0d.0 usb-uhci.c: USB UHCI at I/O 0xb400, IRQ 5 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 PCI: Found IRQ 5 for device 00:04.3 PCI: Sharing IRQ 5 with 00:04.2 PCI: Sharing IRQ 5 with 00:09.0 PCI: Sharing IRQ 5 with 00:0d.0 usb-uhci.c: USB UHCI at I/O 0xb000, IRQ 5 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected usb-uhci.c: v1.275:USB Universal Host Controller Interface driver uhci.c: USB Universal Host Controller Interface driver v1.1 sg: find_free_slot ...<7>sg: initializing sg_major_array ...<4>sg: allocated major 21 sg: ... found 15:00 sg_attach: dev0=(21:0) Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0 sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray PCI: Found IRQ 5 for device 00:09.0 PCI: Sharing IRQ 5 with 00:04.2 PCI: Sharing IRQ 5 with 00:04.3 PCI: Sharing IRQ 5 with 00:0d.0 IPv6 v0.8 for NET4.0 IPv6 over IPv4 tunneling driver parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport_pc: Via 686A parallel port: io=0x378 lp0: using parport0 (polling). usb.c: registered new driver serial usbserial.c: USB Serial support registered for Generic usbserial.c: USB Serial Driver core v1.4 eth0: no IPv6 routers present isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found cdrom: open failed. cdrom: open failed. ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 64 ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 66 ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 68 ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 70 ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 72 ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 74 ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 76 ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 78 cdrom: open failed. Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 690M agpgart: Detected Via Apollo Pro KT133 chipset agpgart: AGP aperture is 64M @ 0xe4000000 [drm] AGP 0.99 on VIA Apollo KT133 @ 0xe4000000 64MB [drm] Initialized radeon 1.1.1 20010405 on minor 0 Linux video capture interface: v1.00 CSLIP: code copyright 1989 Regents of the University of California PPP generic driver version 2.4.2 Vielen Dank Dieter -- Registered Linux-user # 129446
Hy, Am 02/11/10@12:56 schrieb Dieter Resnikschek:
Hab mir gerade den k_athlon-2.4.19-128.i586.rpm eingespielt und dann den mk_initrd nachgesetzt. Beim Booten bleibt das System beim Starting hardwarescan on boot/usr/sbin/hwbootscan line 16: 877 segmentationfault /usr/sbin/hwscan --cdrom hängen.
Hab dann wieder den originalen aus der SuSE 8.1 zurückgemoved!
Hat da jemand von Euch ne Idee, woran das liegen könnte! Bin etwas ratlos!
Anbei die Ausgabe von dmesg für den Original-Kernel:
ACPI: RSDP (v000 ASUS ) @ 0x000f67c0 ACPI: RSDT (v001 ASUS A7V-133 12336.12337) @ 0x2ffec000 ACPI: FADT (v001 ASUS A7V-133 12336.12337) @ 0x2ffec080 ACPI: BOOT (v001 ASUS A7V-133 12336.12337) @ 0x2ffec040 ACPI: MADT not present
Kenne ich mich ueberhaupt nicht mit aus macht aber AFAIK manchmal Probleme und man kann es per bootloader option abschalten, was ich probieren wuerde.
Kernel command line: root=/dev/hde5 hdc=ide-scsi vga=791
Diese command line muesste auch bei Deinem neuen kernel verwendet werden (ich kenne grub nicht). Deine root partion haengt am promise richtig? Schau ob Du das in Deinem neuen kernel hast: CONFIG_BLK_DEV_OFFBOARD=y (bin mir nicht sicher ob Du es brauchst) CONFIG_BLK_DEV_PDC202XX=y CONFIG_BLK_DEV_VIA82CXXX=y
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE.
Ich bin mir nicht sicher, ob das heisst das bei Dir Platten im promise raid laufen, falls ja, davon habe ich auch keine Ahnung :(.
ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 64
*Hm*, da wuerde ich das Problem vermuten. Hast Du es mal mit abgeklemmten cdrom und ohne ide-scsi versucht? Anscheinend laeuft Dein cdrom auch mit dem normalen kernel nicht. HTH. -- bye maik
Hallo Maik, Am Sonntag, 10. November 2002 16:28 schrieb Maik Holtkamp:
Am 02/11/10@12:56 schrieb Dieter Resnikschek:
Hab mir gerade den k_athlon-2.4.19-128.i586.rpm eingespielt und dann den mk_initrd nachgesetzt. Beim Booten bleibt das System beim Starting hardwarescan on boot/usr/sbin/hwbootscan line 16: 877 segmentationfault /usr/sbin/hwscan --cdrom hängen.
Hab dann wieder den originalen aus der SuSE 8.1 zurückgemoved!
Hat da jemand von Euch ne Idee, woran das liegen könnte! Bin etwas ratlos!
Anbei die Ausgabe von dmesg für den Original-Kernel:
ACPI: RSDP (v000 ASUS ) @ 0x000f67c0 ACPI: RSDT (v001 ASUS A7V-133 12336.12337) @ 0x2ffec000 ACPI: FADT (v001 ASUS A7V-133 12336.12337) @ 0x2ffec080 ACPI: BOOT (v001 ASUS A7V-133 12336.12337) @ 0x2ffec040 ACPI: MADT not present
Kenne ich mich ueberhaupt nicht mit aus macht aber AFAIK manchmal Probleme und man kann es per bootloader option abschalten, was ich probieren wuerde.
Hab jetzt mal ACPI ausgeschaltet, geht mit Grub recht einfach!
Kernel command line: root=/dev/hde5 hdc=ide-scsi vga=791
Stamd genauso drin, auch als ich den Kernel k_athlon-2.4.19-128 von Mantel/Next hatte! Jetzt mit dem originalen k_athlon-2.4.19-66 von der 8.1er: Kernel command line: root=/dev/hde5 hdc=ide-scsi apci=off vga=791
Diese command line muesste auch bei Deinem neuen kernel verwendet werden (ich kenne grub nicht). Deine root partion haengt am promise richtig?
Genau so ist es.
Schau ob Du das in Deinem neuen kernel hast:
CONFIG_BLK_DEV_OFFBOARD=y (bin mir nicht sicher ob Du es brauchst)
CONFIG_BLK_DEV_PDC202XX=y CONFIG_BLK_DEV_VIA82CXXX=y
Weiss ich leider nicht, da ich den k_athlon-2.4.19-128 wieder deinstalliert habe!
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE.
Ich bin mir nicht sicher, ob das heisst das bei Dir Platten im promise raid laufen, falls ja, davon habe ich auch keine Ahnung :(.
Die beiden Festplatten sind da angeschlossen!
ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 64
*Hm*, da wuerde ich das Problem vermuten. Hast Du es mal mit abgeklemmten cdrom und ohne ide-scsi versucht? Anscheinend laeuft Dein cdrom auch mit dem normalen kernel nicht.
Mit dem normalen Kernel läuft das DVD/Cdrom ganz normal! Was mir evtl. noch einfällt, das CDROm ebenfalls mit SCSI zu emulieren! Liebe Grüsse Dieter -- Registered Linux-user # 129446
Hi, Dieter Resnikschek wrote:
Am Sonntag, 10. November 2002 16:28 schrieb Maik Holtkamp:
Am 02/11/10@12:56 schrieb Dieter Resnikschek:
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE.
Ich bin mir nicht sicher, ob das heisst das bei Dir Platten im promise raid laufen, falls ja, davon habe ich auch keine Ahnung :(.
Die beiden Festplatten sind da angeschlossen!
Ich meinte ob die beiden Platten auch im Raid laufen, AFAIK hat doch Dein board einen Promise Raid Controller und wenn Du die Platten auch im Raid laufen hast, dann sind AFAIK noch andere Module in der Ramdisk oder direkt im Kernel wichtig. Die obige Meldung kenne ich so nicht, daher viel sie mir auf.
ide-scsi: hdc: unsupported command in request queue (0) end_request: I/O error, dev 16:00 (hdc), sector 64
*Hm*, da wuerde ich das Problem vermuten. Hast Du es mal mit abgeklemmten cdrom und ohne ide-scsi versucht? Anscheinend laeuft Dein cdrom auch mit dem normalen kernel nicht.
Mit dem normalen Kernel läuft das DVD/Cdrom ganz normal!
Die obigen kernel Meldungen würde ich aber nicht als normale Status Meldungen verstehen. Da geht IMHO was schief, doch wenn es nicht stört, kannst Du das ja zunächst mal vernachlässigen. IIRC habe ich in den letzten tagen aber öfter solche Meldungen hier auf der Liste gelesen, da scheint irgendwie der Wurm drin.
Was mir evtl. noch einfällt, das CDROm ebenfalls mit SCSI zu emulieren!
Ja, das könntest Du probieren. -- - maik
Hallo, On Sun, 10 Nov 2002, Dieter Resnikschek wrote:
Hab mir gerade den k_athlon-2.4.19-128.i586.rpm eingespielt und dann den mk_initrd nachgesetzt. Beim Booten bleibt das System beim Starting hardwarescan on boot/usr/sbin/hwbootscan line 16: 877 segmentationfault /usr/sbin/hwscan --cdrom hängen.
Ich tippe, das ist der IDE-Bug, den SuSE eingebaut hat... Nimm nen Vanilla-Kernel oder den neuesten von Mantel (AFAIR 2.4.19-138 oder groesser). Das Thema ging hier in letzter Zeit ja oft genug ueber die Liste... [..]
SCSI subsystem driver Revision: 1.00 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
Was steht in der modules.conf bei 'scsi_hostadapter'? [..]
VFS: Mounted root (reiserfs filesystem) readonly. Trying to move old root to /initrd ... failed
Verwendest du eigentlich ne initrd? [..]
PCI: Found IRQ 5 for device 00:0d.0 PCI: Sharing IRQ 5 with 00:04.2 PCI: Sharing IRQ 5 with 00:04.3 PCI: Sharing IRQ 5 with 00:09.0
Autsch. Gleich 4 devices auf einem IRQ... -dnh -- Aus der Beschreibung entnehme ich, daß deine Fonts nach Typ 3 konvertiert werden (Finger im Hals) und deine Bilder auf Screen-Qualität (Fuß zum Finger dazusteck...) -- ratti in suse-linux
On Sonntag, 10. November 2002 20:02 David Haller wrote:
Nimm nen Vanilla-Kernel oder den neuesten von Mantel (AFAIR 2.4.19-138 oder groesser). Das Thema ging hier in letzter Zeit ja oft genug ueber die Liste...
Ich habe nun ftp://ftp.suse.com/pub/people/mantel/next/RPM/k_deflt-2.4.19-135.i586.rpm installiert und habe seit 3 Tagen Dauerbetrieb keine Probleme gehabt. Allerdings habe ich bereits bei 2 Rechnern mit nur 1 IDE-HD auch Probleme gehabt. Hier hält mich aber die Nvidia-Graka ab, den Kernel upzudaten, solange die Probleme vernachlässigbar sind. Bist Du sicher, dass man >= 138 verwenden sollte? Ich finde nur ftp://ftp.suse.com/pub/people/mantel/test/k_deflt-2.4.19-140.i586.rpm und da schreckt mich "test" etwas ab. Albert
Hallo, On Sun, 10 Nov 2002, Al Bogner wrote:
On Sonntag, 10. November 2002 20:02 David Haller wrote:
Nimm nen Vanilla-Kernel oder den neuesten von Mantel (AFAIR 2.4.19-138 oder groesser). Das Thema ging hier in letzter Zeit ja oft genug ueber die Liste... [..] Bist Du sicher, dass man >= 138 verwenden sollte?
Nein. Ich verwende seit 2.2.10 nur selbstgebackene "Vanilla"-Kernel. Das mit dem 138 war mir nur in Erinnerung, dass das wohl der war, mit denen das Problem dann behoben war... Kann auch -135 gewesen sein oder sonstwas. Aber irgendwas mit -13x...
Ich finde nur ftp://ftp.suse.com/pub/people/mantel/test/k_deflt-2.4.19-140.i586.rpm und da schreckt mich "test" etwas ab.
Ja, an 'test' muesstest du dich wohl "ranwagen"... Die Kernel, die das Problem beheben sind AFAIK immer noch in /test/... Oder du "inhalierst" am besten "einfach" erstens das Kernel-HOWTO, zweitens mein "Multikernel-HOWTO" auf [1] und drittens nimmst du dir einen Vanilla-Kernel von kernel.org vor... Falls du besondere Features (d.h. Patches, die SuSE per default drin hat) der SuSE Kernels brauchst, waere das ein kleiner Nachteil. Aber wenn du Fragen/Probleme damit hast, dann kann man das bei Bedarf immer noch angehen, wg. [1] duerfte es auf keinen Fall eine "Verschlimmerung" des bisherigen Zustands sein, du kannst immer noch den bis dahin am besten funktionierenden Kernel booten, und erst wenn sich dann der neue bewaehrt hat, jenen zum default machen. Ich verwende z.B. seit 2.4.0-test1 die 2.4.x Kernels, aber habe immer noch nen 2.2.x in der lilo.conf d.h. in der Hinterhand... (ob der allerdings noch bootet? Muesste, aber hab's mangels Bedarf ewig nicht mehr getestet und seitdem einiges grundlegendes aktualisiert -- aber von den 2.4.x Kernels habe ich einige (mind. 3) in der Hinterhand, die teilweise ueber 1 Jahr "im Dauerbetrieb" waren, sich also auf meiner HW bewaehrt haben ;) Kurz: um ehrlich zu sein: so sehr ich die Arbeit von Hubert Mantel u.a. bei SuSE schaetze, die SuSE-Kernels (oder vielmehr die angewendeten Patches) scheinen z.Z. "die Seuche" zu haben... Sicher, einige Patches sind "lobenswert" (z.B. der fuer /proc/config.gz), aber grad bei IDE... Da is eigentlich seit 2.4 schon der Wurm drin -- AFAIR zuerst durch den Vanilla-Kernel bedingt (das wurde im "Vanilla" spaetestens mit 2.4.16 behoben[2]), dann wegen anderen/eigenen Patches... Zwischen 8.0 und 8.1 liess sich der 2.4.19-SuSE auf vielen IDE-Boards nichtmal mehr booten... -dnh [1] http://www.dhaller.de/linux/multikernel.html [2] oder war das das mit der VM? Egal -- "nix ging" jedenfalls ;) -- 7: DOS Denial Of Service (Kristian Köhntopp)
Hallo David, Am Sonntag, 10. November 2002 20:02 schrieb David Haller:
On Sun, 10 Nov 2002, Dieter Resnikschek wrote:
Hab mir gerade den k_athlon-2.4.19-128.i586.rpm eingespielt und dann den mk_initrd nachgesetzt. Beim Booten bleibt das System beim Starting hardwarescan on boot/usr/sbin/hwbootscan line 16: 877 segmentationfault /usr/sbin/hwscan --cdrom hängen.
Ich tippe, das ist der IDE-Bug, den SuSE eingebaut hat...
Denk ich auch, da mir immer wieder mal das Systerm einfriert :-(
Nimm nen Vanilla-Kernel oder den neuesten von Mantel (AFAIR 2.4.19-138 oder groesser). Das Thema ging hier in letzter Zeit ja oft genug ueber die Liste...
Drum wollte ich ja nen neuen Kernel installieren :-( Brauch ja den athlon-kernel!
[..]
SCSI subsystem driver Revision: 1.00 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
Was steht in der modules.conf bei 'scsi_hostadapter'?
alias scsi_hostadapter off
[..]
VFS: Mounted root (reiserfs filesystem) readonly. Trying to move old root to /initrd ... failed
Verwendest du eigentlich ne initrd?
Verwende als Bootloader Grub! In /boot ist allerdings eine initrd zufinden!
[..]
PCI: Found IRQ 5 for device 00:0d.0 PCI: Sharing IRQ 5 with 00:04.2 PCI: Sharing IRQ 5 with 00:04.3 PCI: Sharing IRQ 5 with 00:09.0
Autsch. Gleich 4 devices auf einem IRQ...
Sound funzt auch nicht! :-(((( Wollte eh noch die Soundkarte umhängen! Liebe Grüsse Dieter -- Registered Linux-user # 129446
Hallo, On Sun, 10 Nov 2002, Dieter Resnikschek wrote:
Am Sonntag, 10. November 2002 20:02 schrieb David Haller:
On Sun, 10 Nov 2002, Dieter Resnikschek wrote: [..] Nimm nen Vanilla-Kernel oder den neuesten von Mantel (AFAIR 2.4.19-138 oder groesser). Das Thema ging hier in letzter Zeit ja oft genug ueber die Liste...
Drum wollte ich ja nen neuen Kernel installieren :-( Brauch ja den athlon-kernel!
??? Noe. Du kannst auch alle ix86 mit x <= 6 verwenden. Musst halt evtl. auf das letzte Quentchen Performance verzichten. Aber selbst- kompilieren halte ich sowieso fuer besser ;) Im Zweifelsfall sowieso immer den Vanilla-Kernel von kernel.org sowie ggfs. ausgewaehlte patches (z.B. fuer reiserfs als das noch nicht im "Vanilla"-Kernel war... ;)
[..]
SCSI subsystem driver Revision: 1.00 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
Was steht in der modules.conf bei 'scsi_hostadapter'?
alias scsi_hostadapter off
Komisch. das 'kmod' hab ich hier auch net... Ich vermute, das ist irgendso'n Script, der irgendwas automatisch laden soll... Kruschtel mal in /etc/sysconfig (und oder Yast), ob da irgendwo was sagt, dass scsi geladen werden soll... (evtl. statte auch /etc/init.d mal einen "greppenden Besuch" ab ;)
[..]
VFS: Mounted root (reiserfs filesystem) readonly. Trying to move old root to /initrd ... failed
Verwendest du eigentlich ne initrd?
Verwende als Bootloader Grub!
Ahso. Den kenn ich bisher noch zuwenig...
In /boot ist allerdings eine initrd zufinden!
"Eine" sagt allerdings nicht viel. Interessant ist die, die fuer den jew. aktuell verwendeten Kernel erstellt wurde (nach Vorgabe in Yast).
[..]
PCI: Found IRQ 5 for device 00:0d.0 PCI: Sharing IRQ 5 with 00:04.2 PCI: Sharing IRQ 5 with 00:04.3 PCI: Sharing IRQ 5 with 00:09.0
Autsch. Gleich 4 devices auf einem IRQ...
Sound funzt auch nicht! :-((((
Ok, das kann (schon traditionell!) viele Gruende haben ;(
Wollte eh noch die Soundkarte umhängen!
Ohem, soweit moeglich sollte man IRQs/IOPorts/DMA immer "entpfriemeln". Gemeinsam verwendete IRQs (z.B.) machen immer mehr Aerger, als wenn jedes device einen eigenen IRQ hat -- ohne APIC (nicht zu verwechseln mit ACPI!) ist das aber heutzutage recht schwierig -- versuchen sollte man's, spaetestens bei "komischen Fehlern", aber auf jeden Fall... (und das war u.a. ein Punkt, der mich immer an Win* gestoert hat -- das will IRQs selber verteilen und packt sie dann gern alle auf einen IRQ -- und der Aerger ist vorprogrammiert, weil $DEVICE[1] nicht mit $DEVICE[2] will... *grrr*). -dnh -- STRG+ALT+Entf ? Strangulier die Alte und Entferne Sie ! ;) -- Thomas Findeisen in danm und dafc
Hi David, Am Montag, 11. November 2002 00:59 schrieb David Haller:
On Sun, 10 Nov 2002, Dieter Resnikschek wrote:
Am Sonntag, 10. November 2002 20:02 schrieb David Haller:
On Sun, 10 Nov 2002, Dieter Resnikschek wrote:
[..]
Nimm nen Vanilla-Kernel oder den neuesten von Mantel (AFAIR 2.4.19-138 oder groesser). Das Thema ging hier in letzter Zeit ja oft genug ueber die Liste...
Drum wollte ich ja nen neuen Kernel installieren :-( Brauch ja den athlon-kernel!
??? Noe. Du kannst auch alle ix86 mit x <= 6 verwenden. Musst halt evtl. auf das letzte Quentchen Performance verzichten. Aber selbst- kompilieren halte ich sowieso fuer besser ;)
Im Zweifelsfall sowieso immer den Vanilla-Kernel von kernel.org sowie ggfs. ausgewaehlte patches (z.B. fuer reiserfs als das noch nicht im "Vanilla"-Kernel war... ;)
Hab ewig schon nicht mehr nen Kernel kompiliert und selbst gebaut. Mal sehen, werd's mal machen, wenn ich Zeit und Lust dazu habe, vorher muss ich halt mal wieder das Howto dazu lesen ;-)
[..]
SCSI subsystem driver Revision: 1.00 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
Was steht in der modules.conf bei 'scsi_hostadapter'?
alias scsi_hostadapter off
Komisch. das 'kmod' hab ich hier auch net... Ich vermute, das ist irgendso'n Script, der irgendwas automatisch laden soll... Kruschtel mal in /etc/sysconfig (und oder Yast), ob da irgendwo was sagt, dass scsi geladen werden soll... (evtl. statte auch /etc/init.d mal einen "greppenden Besuch" ab ;)
Der Brenner ist scsi-emuliert, vieilleicht deswegen??? Möglicherweise ist es das???? Ausschnitt der /var/log/boot.msg in Yast2: <6>scsi0 : SCSI host adapter emulation for IDE ATAPI devices <4> Vendor: TEAC Model: CD-W58E Rev: 1.0A <4> Type: CD-ROM ANSI SCSI revision: 02
[..]
VFS: Mounted root (reiserfs filesystem) readonly. Trying to move old root to /initrd ... failed
Verwendest du eigentlich ne initrd?
Verwende als Bootloader Grub!
Ahso. Den kenn ich bisher noch zuwenig...
In /boot ist allerdings eine initrd zufinden!
"Eine" sagt allerdings nicht viel. Interessant ist die, die fuer den jew. aktuell verwendeten Kernel erstellt wurde (nach Vorgabe in Yast).
Wenn Du dies meinst, das steht in den initrd_modules: cdrom ide-cd reiserfs ide-scsi
[..]
PCI: Found IRQ 5 for device 00:0d.0 PCI: Sharing IRQ 5 with 00:04.2 PCI: Sharing IRQ 5 with 00:04.3 PCI: Sharing IRQ 5 with 00:09.0
Autsch. Gleich 4 devices auf einem IRQ...
Sound funzt auch nicht! :-((((
Ok, das kann (schon traditionell!) viele Gruende haben ;(
Wollte eh noch die Soundkarte umhängen!
Hab da ein bischen rumexperemientiert und musste dann feststellen, dass die Kiste bei einem gewissen Slot Konflikte mit anderen IRQ's hatte, wie schon oben genannt, und dadurch das Einfrieren der Box entstand. Bei einem anderen hatte ich dann Probleme mit den IRQ's mit dem Promise-Controller :-( Jetzt hat die Soundkarte alleine den IRQ 5!
Ohem, soweit moeglich sollte man IRQs/IOPorts/DMA immer "entpfriemeln". Gemeinsam verwendete IRQs (z.B.) machen immer mehr Aerger, als wenn jedes device einen eigenen IRQ hat -- ohne APIC (nicht zu verwechseln mit ACPI!) ist das aber heutzutage recht schwierig -- versuchen sollte man's, spaetestens bei "komischen Fehlern", aber auf jeden Fall... (und das war u.a. ein Punkt, der mich immer an Win* gestoert hat -- das will IRQs selber verteilen und packt sie dann gern alle auf einen IRQ -- und der Aerger ist vorprogrammiert, weil $DEVICE[1] nicht mit $DEVICE[2] will... *grrr*).
Nachdem ich im Grub den Kernelparameter pci=bios eigegeben hatte, und die Box neu gebootet habe, funzt jetzt auch der Sound! Vielen Dank und liebe Grüsse Dieter -- Registered Linux-user # 129446
David Haller <david@dhaller.de> [Sun, 10 Nov 2002 20:02:02 +0100]:
Ich tippe, das ist der IDE-Bug, den SuSE eingebaut hat...
Mit Verlaub, ich wage zu widersprechen. Das war kein IDE-Bug, den SuSE eingebaut hat, sondern ein Bug (genauer zwei Bugs) in den Barrier-Patches, dessen Auswirkungen unter IDE bemerkbar wurden und die mittlerweile analysiert und gefixt wurden. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
Philipp Thomas wrote:
David Haller <david@dhaller.de> [Sun, 10 Nov 2002 20:02:02 +0100]:
Ich tippe, das ist der IDE-Bug, den SuSE eingebaut hat...
Mit Verlaub, ich wage zu widersprechen. Das war kein IDE-Bug, den SuSE eingebaut hat, sondern ein Bug (genauer zwei Bugs) in den Barrier-Patches, dessen Auswirkungen unter IDE bemerkbar wurden und die mittlerweile analysiert und gefixt wurden.
...nachdem sowohl auf der SuSE 8.0 und der SuSE 8.1 Distribution jeweils ein buggy Kernel als default installiert wurde und, wie man auch anhand dieser Liste feststellen durfte, wohl auf so eini- gen Systemen Probleme bereitet hat. Sicher kann so etwas mal pas- sieren, keine Frage, aber spaetestens nach den Erfahrungen mit der SuSE 8.0 haette IMHO das Problem behoben werden und in 8.1 nie wieder autauchen duerfen! Das muss sich SuSE Ankreiden lassen. Das Problem wurde wohl nicht so ganz ernst genommen.... Was mich ebenso wundert, dass es nach dem Fixen kein ehrliches Kernel- Update gegeben hat oder einen SDB Artikel - man kann kaum erwar- ten, dass die Kaeufer von SuSE-Linux das Verzeichnis von H. Man- tel auf dem FTP-Server kennen, wo man einen gefixten Kernel be- kommt.... Trotz allem vielen Dank fuer Deinen persoenlichen Einsatz in die- ser Sache, Philipp. Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Hallo allerseits, Thomas.Hertweck@gpi.uni-karlsruhe.de:
man kann kaum erwarten, dass die Kaeufer von SuSE-Linux das Verzeichnis von H. Man- tel auf dem FTP-Server kennen, wo man einen gefixten Kernel be- kommt....
ich habe unter ftp://ftp.suse.com/pub/people/mantel/next folgendes gefunden: kernel-source-changes linux-2.4.19.SuSE-32.tar.bz ~ 31MB patches-2.4.19-32.tar.bz ~ 8MB suse-2.4.19-32.tar.bz ~ 8MB bevor ich mir nun über ISDN 47MB abhole (Tja, *-DSL gibt's hier Karlsruhe Innenstadt leider nicht, hier liegt Glasfaser :-) was steckt da wohl in welcher Datei drin? Ich habe in kernel-source-changes Hinweise gefunden, die was mit ACPI zu tun haben, welches mir hier Probleme machen, may be, es hilft. Von SuSE 60-Tage-Support erfährt man leider nicht allzuviel Hilfe (sorry, musste aber mal gesagt werden). Oder wo gibt es Updates für den SuSe-Kernel (8.1). Bye Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 9204871 Fax: +49(721) 24874 juergen@informatik-vollmer.de,vollmer@cocolab.de,Juergen.Vollmer@acm.org www.informatik-vollmer.de
Jürgen Vollmer wrote:
ich habe unter ftp://ftp.suse.com/pub/people/mantel/next folgendes gefunden:
Verwende aus Deutschland besser einen Mirror, siehe dazu http://www.suse.de/de/private/download/ftp/inland.html.
kernel-source-changes linux-2.4.19.SuSE-32.tar.bz ~ 31MB patches-2.4.19-32.tar.bz ~ 8MB suse-2.4.19-32.tar.bz ~ 8MB bevor ich mir nun über ISDN 47MB abhole (Tja, *-DSL gibt's hier Karlsruhe Innenstadt leider nicht, hier liegt Glasfaser :-) was steckt da wohl in welcher Datei drin?
o linux-2.4.19.SuSE-32.tar.bz2: Die Quellen des neusten SuSE- Kernels als bzip2-komprimiertes Tar-Archiv o patches-2.4.19-32.tar.bz2 : Alle individuellen SuSE-Patches, zusammengefasst in einem bzip2-komprimierten Tar-Archiv o suse-2.4.19-32.bz2 (das hast Du wohl falsch abgeschrieben, das ist kein Tar-Archiv!): Ein kompletter SuSE-Patch (kom- primiert mit bzip2), der einen Vanilla-Kernel 2.4.19 in einem Rutsch auf einen SuSE-Kernel bringt Bei all diesen Varianten ist logischerweise ein eigenes Com- pilieren des Kernels angesagt. Wenn Du einen vorcompilierten Kernel moechtest, dann solltest Du Dir eines der RPMs aus dem Unterverzeichnis <..>/next/RPM/ besorgen: o k_athlon-2.4.19-128.i586.rpm: Kernel fuer Systeme mit Ath- lonprozessoren (Uniprozessor) o k_deflt-2.4.19-135.i586.rpm: Der SuSE Default-Kernel fuer alle Systeme ab 586er (Uniprozessor) o k_psmp-2.4.19-130.i586.rpm: SuSE-SMP-Kernel fuer aeltere Pentiumsysteme (Multiprozessor) o k_smp-2.4.19-127.i586.rpm: SuSE-Default-SMP-Kernel (Multi- prozessor) o kernel-source-2.4.19.SuSE-87.i586.rpm: Die Quellen des SuSE- Kernels als RPM File. HTH, Thomson -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
Am Montag, 11. November 2002 18:18 schrieb Thomas Hertweck:
Wenn Du einen vorcompilierten Kernel moechtest, dann solltest Du Dir eines der RPMs aus dem Unterverzeichnis <..>/next/RPM/ besorgen: o k_athlon-2.4.19-128.i586.rpm: Kernel fuer Systeme mit Ath- lonprozessoren (Uniprozessor)
o kernel-source-2.4.19.SuSE-87.i586.rpm: Die Quellen des SuSE- Kernels als RPM File.
Hallo Thomas, mich wundern hier die Versionsnummern etwas. Wenn ich mir kernel-source-2.419.SuSE-87.i586.rpm installiere und dann kompiliere , dürfte ich doch kaum zu der Version xxx-2.4.19-128 gelangen. Wo also liegt der Unterschied bzw wo liegt kernel-source-2.4.19-128 ? Mich wundert da auch die Informationspolitik von SuSE. Nicht jeder der ein schrottiges Billig-Mainboard (K7S5A) wie ich sein eigen nennt dürfte hier mitlesen. Auf den Webseiten von SuSE konnte ich zu dem IDE-Buck nichts finden und manche werden den Kauf der (ansonsten recht guten 8.1) schon verflucht haben... Gruß Harald
Harald Huthmann wrote:
[...] mich wundern hier die Versionsnummern etwas. Wenn ich mir kernel-source-2.419.SuSE-87.i586.rpm installiere und dann kompiliere , dürfte ich doch kaum zu der Version xxx-2.4.19-128 gelangen. Wo also liegt der Unterschied bzw wo liegt kernel-source-2.4.19-128 ?
Ja, das ist so etwas, was ich auch nicht so ganz verstanden habe... Ich denke, der Quellcode duerfte vermutlich der gleiche sein. Ich kenne leider die Politik von SuSE nicht, wann die Minor-Release-Number (das duerfte wohl die Zahl nach dem Bindestrich sein) erhoeht wird. Eventuell geht das ja fuer Quellcode und erstellte RPMs separat. Vielleicht weiss da jemand mehr, wuerde mich auch interessieren.
Mich wundert da auch die Informationspolitik von SuSE. Nicht jeder der ein schrottiges Billig-Mainboard (K7S5A) wie ich sein eigen nennt dürfte hier mitlesen. Auf den Webseiten von SuSE konnte ich zu dem IDE-Buck nichts finden und manche werden den Kauf der (ansonsten recht guten 8.1) schon verflucht haben...
Das ist, was ich heute morgen schrieb. Ich finde es auch ko- misch, dass von SuSE offiziell bisher keine Auesserung dazu kam oder zumindest ein SDB-Artikel. Uebrigens heisst es "Bug" (Kaefer) nicht "Buck" (Bock). Das ist zwar auch ein Tier, aber das Falsche :-) Der Begriff ruehrt noch aus den Zeiten, bei denen Rechner ziemlich gross waren. Wenn dann mal was nicht so funktionierte wie es soll- te, dann war oft ein Kaefer (Bug) im Rechner und hat fuer diese Stoerung gesorgt. In heutiger Zeit und mit den klei- neren Rechnern ist das natuerlich nicht mehr der Fall, aber der Begriff hat sich gehalten. Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
Am Montag, 11. November 2002 20:08 schrieb Thomas Hertweck:
Uebrigens heisst es "Bug" (Kaefer) nicht "Buck" (Bock). Das ist zwar auch ein Tier, aber das Falsche :-)
... da kann ich nur noch sagen: "Rocca Ventosa -Montepulciano D`Abruzzo -1998 macht blöd" :-) Schönen Tag noch... Harald
Thomas Hertweck <Thomas.Hertweck@gpi.uni-karlsruhe.de> [20021111 20:08]:
wo liegt kernel-source-2.4.19-128 ?
wann die Minor-Release-Number (das duerfte wohl die Zahl nach dem Bindestrich sein) erhoeht wird. Eventuell geht das
Das ist keine Release-Nummer sondern die Build-Nummer. Diese hat *nichts* mit der eigentlichen Version gemein und wird mit jedem Bauen des Paketes hochgezählt. Ergo wurde das Paket kernel-source bisher 128 mal neu gebaut.
Das ist, was ich heute morgen schrieb. Ich finde es auch ko- misch, dass von SuSE offiziell bisher keine Auesserung dazu kam oder zumindest ein SDB-Artikel.
Erst einmal muss abgewartet werden, ob es wirklich alles wie gewünscht funktioniert und die Rückmeldungen haben nun einmal gedauert. Auf die Idee, einen SDB-Artikel zu schreiben bin ich einfach nicht gekommen. Ich werde mal sehen, ob ich dieser Tage dazu komme. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
Philipp Thomas wrote:
[kernel-source-2.4.19-128; fuer was steht die 128?]
Das ist keine Release-Nummer sondern die Build-Nummer. Diese hat *nichts* mit der eigentlichen Version gemein und wird mit jedem Bauen des Paketes hochgezählt. Ergo wurde das Paket kernel-source bisher 128 mal neu gebaut.
Das mag alles sicherlich Sinn machen, aber verwirrend finde ich es auch, dass man nicht genau nachvollziehen kann, aus welchem Quellcode nun die einzelnen RPMs ge- baut wurden. Im Prinzip kann ich nur sagen, dass z.B. k_deflt-2.4.19-135.i586.rpm aus dem ./nexr/RPM/ Ver- zeichnis 135 mal neu gebaut wurde. Aber es ist mir nun nicht ersichtlich, welche Quellen dafuer wirklich ver- wendet wurden (per rpm-Kommando bekomme ich nur heraus, dass es eben das SRC-RPM mit gleicher Versions- und Build-Nummer war, aus dem das binary-RPM gebaut wurde). Oder sehe ich das jetzt falsch? So gesehen kann ich ja nur hoffen, dass die Quellen linux-2.4.19.SuSE-32.tar.bz2 im ./next Verzeichnis auch wirklich die richtigen sind, die zum Erstellen verwendet wurden. Oder kann man die Zusammenhaenge sonst irgendwie aufloesen? Man sollte also einfach schauen, dass man immer moeglichst hohe Build-Nummern erwischt, sei es bei den Kernel-Quellen im komprimierten Tar-Archiv oder bei Binary-RPMs, auch wenn diese Build-Nummern zwischen diesen beiden Paketen nichts mehr gemeinsam haben (... und dann eben hoffen, dass der FTP-Uploader nicht aus Versehen ein Paket vergessen hat neu einzuspielen ;-)
[Warum gibt es eigentlich keine SDB Artikel zum Thema?]
Erst einmal muss abgewartet werden, ob es wirklich alles wie gewünscht funktioniert und die Rückmeldungen haben nun einmal gedauert. Auf die Idee, einen SDB-Artikel zu schreiben bin ich einfach nicht gekommen. Ich werde mal sehen, ob ich dieser Tage dazu komme.
Nicht persoenlich nehmen ;-) Es verwundert einfach ein bisschen, da die Probleme mit dem Bug auch hier auf der Liste in letzter Zeit ja vermehrt aufgetreten sind und es fuer Nicht-SuSE-Linux-Mailinglistenleser natuerlich schwer wird, dem Problem ueberhaupt auf die Spur zu kommen.... Gruesse, Thoson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Thomas Hertweck <Thomas.Hertweck@gpi.uni-karlsruhe.de> [20021112 14:43]:
aus welchem Quellcode nun die einzelnen RPMs gebaut wurden.
Gebaut werden sie immer aus dem kernel-source RPM. Änderungen am Kernelquellcode bewirken also einen Neubau des kernel-source Pakets. Wenn hingegen einfach nur Änderungen in der Konfiguration des Kernels gemacht werden, betrifft dies nur die Binär-Pakete, sprich k_*.rpm. Aber ich werde mal prüfen, ob man nicht evtl. irgendwo die Information unterbringen kann, die einen Bezug zwischen kernel-source und den binären Kernel-Pakete herstellt. Ansonsten sind die Build-Nummern sind eine rein interne Geschichte und haben keine weitere Aussagekraft. In einem Build-System wie dem unseren werden Pakete automatisch neu kompiliert, wenn die ihnen zugrunde liegenden Pakete sich ändern. Änderungen an Basispaketen wie der glibc oder dem gcc bewirken sogar einen kompletten Neubau der Distribution.
Oder kann man die Zusammenhaenge sonst irgendwie aufloesen?
AFAIK, nein.
und es fuer Nicht-SuSE-Linux-Mailinglistenleser natuerlich schwer wird, dem Problem ueberhaupt auf die Spur zu kommen....
Das ist richtig, aber die werden sich, zumindest zum Teil, dann an die Kolleginnen/Kollegen vom Support wenden. Ich habe einfach keine Ahnung, wie viele Leute das Problem betroffen hat und das würde helfen, den Bedarf an einem SDB-Artikel abzuschätzen. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
Am Mit, 2002-11-13 um 01.40 schrieb Philipp Thomas:
Thomas Hertweck <Thomas.Hertweck@gpi.uni-karlsruhe.de> [20021112 14:43]:
aus welchem Quellcode nun die einzelnen RPMs gebaut wurden.
Gebaut werden sie immer aus dem kernel-source RPM. Änderungen am Kernelquellcode bewirken also einen Neubau des kernel-source Pakets. Wenn hingegen einfach nur Änderungen in der Konfiguration des Kernels gemacht werden, betrifft dies nur die Binär-Pakete, sprich k_*.rpm.
Aber ich werde mal prüfen, ob man nicht evtl. irgendwo die Information unterbringen kann, die einen Bezug zwischen kernel-source und den binären Kernel-Pakete herstellt. Steckt im RPM.
Ansonsten sind die Build-Nummern sind eine rein interne Geschichte und haben keine weitere Aussagekraft. kein Kommentar ;)
Oder kann man die Zusammenhaenge sonst irgendwie aufloesen? rpm -qi -p <...>.rpm
rpm -q --queryformat "%{SOURCERPM}" -p <...>.rpm
und es fuer Nicht-SuSE-Linux-Mailinglistenleser natuerlich schwer wird, dem Problem ueberhaupt auf die Spur zu kommen....
Das ist richtig, aber die werden sich, zumindest zum Teil, dann an die Kolleginnen/Kollegen vom Support wenden. Ich habe einfach keine Ahnung, wie viele Leute das Problem betroffen hat und das würde helfen, den Bedarf an einem SDB-Artikel abzuschätzen.
Is it of any importance? Fakt ist, das Problem existiert offensichtlich bei vielen Usern, nun liegt es Euch etwas zu tun. Ralf
Hallo Ralf, Ralf Corsepius wrote:
Am Mit, 2002-11-13 um 01.40 schrieb Philipp Thomas:
Thomas Hertweck <Thomas.Hertweck@gpi.uni-karlsruhe.de> [20021112 14:43]:
aus welchem Quellcode nun die einzelnen RPMs gebaut wurden.
Gebaut werden sie immer aus dem kernel-source RPM. Änderungen am Kernelquellcode bewirken also einen Neubau des kernel-source Pakets. Wenn hingegen einfach nur Änderungen in der Konfiguration des Kernels gemacht werden, betrifft dies nur die Binär-Pakete, sprich k_*.rpm.
Aber ich werde mal prüfen, ob man nicht evtl. irgendwo die Information unterbringen kann, die einen Bezug zwischen kernel-source und den binären Kernel-Pakete herstellt.
Steckt im RPM.
Nein ;-) OK, aus dem hier gequoteten Text ist die eigent- liche Problemstellung nicht mehr ersichtlich - das was Du meinst, ist nicht ganz die Loesung zum urspruenglichen Problem. Lies mal ein oder zwei Emails frueher in diesem Thread.
Oder kann man die Zusammenhaenge sonst irgendwie aufloesen?
rpm -qi -p <...>.rpm
rpm -q --queryformat "%{SOURCERPM}" -p <...>.rpm
Das gibt mir an, dass aus k_athlon-2.4.19-142.i586.rpm dem RPM k_athlon-2.4.19-142.src.rpm erstellt wurde - soweit so gut, das war aber nicht die Frage! Die Frage war, welcher Source-Code des Kernels zu Grunde liegt, ob das der im ueber- geordneten Verzeichnis ./mantel/next ist oder nicht? Und der traegt die Bezeichnung linux-2.4.19.SuSE-33.tar.bz2. Der Zu- sammenhang ist naemlich irgendwie nicht ersichtlich.... Aber ich denke, die Frage ist soweit durch Philipp geklaert. Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Am Mit, 2002-11-13 um 09.19 schrieb Thomas Hertweck:
Hallo Ralf,
Ralf Corsepius wrote:
Am Mit, 2002-11-13 um 01.40 schrieb Philipp Thomas:
Thomas Hertweck <Thomas.Hertweck@gpi.uni-karlsruhe.de> [20021112 14:43]:
aus welchem Quellcode nun die einzelnen RPMs gebaut wurden.
Gebaut werden sie immer aus dem kernel-source RPM. Änderungen am Kernelquellcode bewirken also einen Neubau des kernel-source Pakets. Wenn hingegen einfach nur Änderungen in der Konfiguration des Kernels gemacht werden, betrifft dies nur die Binär-Pakete, sprich k_*.rpm.
Aber ich werde mal prüfen, ob man nicht evtl. irgendwo die Information unterbringen kann, die einen Bezug zwischen kernel-source und den binären Kernel-Pakete herstellt.
Steckt im RPM.
Nein ;-) Sollte aber ...
Ralf
Hallo Philipp, On Mittwoch, 13. November 2002 01:40, Philipp Thomas wrote:
Das ist richtig, aber die werden sich, zumindest zum Teil, dann an die Kolleginnen/Kollegen vom Support wenden. Ich habe einfach keine Ahnung, wie viele Leute das Problem betroffen hat und das würde helfen, den Bedarf an einem SDB-Artikel abzuschätzen.
Mal direkt gefragt: ist Dir die Zukunft Deines Brötchengebers denn so egal? Tatsache ist, daß SuSE mit den Versionen 8.0 und 8.1 Distributionen verkauft hat, die für Leute mit 2 IDE-HDs im Rechner so wie sie aus der Verpackung kommen wertlos sind. Diese Konfiguration (2 x IDE-HD) kann man nun mit dem besten Willen nicht als exotisch oder selten bezeichen. Der Aufwand für eine Beseitigung dieses Problems ist je nach den Kenntnissen des Käufers beträchtlich bis unmöglich zu leisten. Damit und mit der Handhabung der Folgeproblemen hat SuSE bisher keine angemessene Reaktion im SInn von kundenfeundlich gezeigt. Wieviele der betroffenen Kunden werden sich nach 2 Fehlkäufen nochmals für SuSE entscheiden? MfG Arno Weber
Am Mittwoch, 13. November 2002 11:05 schrieb Arno Weber:
Tatsache ist, daß SuSE mit den Versionen 8.0 und 8.1 Distributionen verkauft hat, die für Leute mit 2 IDE-HDs im Rechner so wie sie aus der Verpackung kommen wertlos sind.
Sorry, ich habe den Thread nicht ganz verfolgt, aber was meinst du damit??? Bruno -- Linux is like an Indian tent... ...no Gates, no Windows and an Apache inside. mailto:bruno@schiele-rottum.de * ICQ: 65995978
On Mittwoch, 13. November 2002 11:22, Bruno Schiele wrote:
Sorry, ich habe den Thread nicht ganz verfolgt, aber was meinst du damit???
... das war meine Zwischenbilanz zum IDE-Kernel-Bug in SuSE 8.0 & 8.1 und meine Meinung zu den Zukunftsaussichten von SuSE als Linux-Distributor. MfG Arno Weber
Hallo, Am Mittwoch, 13. November 2002 11:22 schrieb Bruno Schiele:
Am Mittwoch, 13. November 2002 11:05 schrieb Arno Weber:
Tatsache ist, daß SuSE mit den Versionen 8.0 und 8.1 Distributionen verkauft hat, die für Leute mit 2 IDE-HDs im Rechner so wie sie aus der Verpackung kommen wertlos sind.
Sorry, ich habe den Thread nicht ganz verfolgt, aber was meinst du damit???
Er meint damit, dass bei Ihm bei Verwendung von zwei IDE-Platten der SuSE-Kernel von der 8.0 und der 8.1 die Grätsche macht. Aus den Tatsachen, dass a) dieses Problem bei ihm reproduzierbar ist und b) auch einige andere von diesem Problem berichtet haben folgert er (fälschlicherweise), dass dies auf alle oder zumindest die meisten Rechner mit 2 IDE-Platten zutrifft. Richtig ist, dass es nur bei sehr wenigen Leuten zu diesen Problemen (dessen Ursache oder auch nur die Voraussetzung für dessen Aufteten zumindest mir immer noch nicht klar ist) kommt. Wäre es tatsächlich ein ganz allgemeines Problem, dann gäbe es mit Sicherheit inzwischen eine Lösung - denn dann wäre es auch sehr einfach das Problem nachzustellen. Schöne Grüße aus Bremen hartmut
Hartmut Meyer wrote:
[...] Er meint damit, dass bei Ihm bei Verwendung von zwei IDE-Platten der SuSE-Kernel von der 8.0 und der 8.1 die Grätsche macht.
Aus den Tatsachen, dass
a) dieses Problem bei ihm reproduzierbar ist und b) auch einige andere von diesem Problem berichtet haben
folgert er (fälschlicherweise), dass dies auf alle oder zumindest die meisten Rechner mit 2 IDE-Platten zutrifft.
Richtig ist, dass es nur bei sehr wenigen Leuten zu diesen Problemen (dessen Ursache oder auch nur die Voraussetzung für dessen Aufteten zumindest mir immer noch nicht klar ist) kommt.
Einspruch, euer Ehren :-) Definiere bitte mal "sehr wenig"! Also, wenn ich mir hier auf suse-linux den Traffic der letzten Zeit an- schaue, wenn ich bedenke, dass wir hier alleine am Institut mehre- re PCs haben, die betroffen sind, und ich zahlreiche Bekannte ha- be, die ebenfalls unter dem Problem leiden, wenn ich vermute, dass viele Leute noch gar nichts vom Bug wissen und die staendigen Ab- stuerze auf irgendetwas schieben (nur nicht auf den Kernel - schliesslich liest nicht jeder suse-linux und in der SDB o.ae. findet man nichts zum Problem), dann kann die Menge der betroffenen PCs nicht soooo klein sein. Jetzt mag man natuerlich sagen, SuSE laeuft ja nicht nur auf i386 Architektur etc., und woanderst moegen die Probleme nicht auftreten, und insgesamt gesehen sind nur 5% der PCs betroffen (keine Ahnung, die Zahl ist einfach aus der Luft ge- griffen), aber das hilft den vielen Privatkunden (die mit ihrem PC genau unter diese 5% fallen) dann wenig.... Zwei IDE-HDDs im System ist nun wirklich nicht so selten anzutreffen, oder? Sicherlich koennen Fehler passieren. Aber nach der 8.0 auch in der 8.1? Und warum dann kein offizielles Statement dazu? Ich glaube, das nennt sich Informationspolitik - und die wird ja auch an ganz anderer Stelle gefordert ;-)
Wäre es tatsächlich ein ganz allgemeines Problem, dann gäbe es mit Sicherheit inzwischen eine Lösung - denn dann wäre es auch sehr einfach das Problem nachzustellen.
Es scheint ja inzwischen eine Loesung zu geben, seitdem Ph. Thomas ein wenig nachgehakt hat und bei SuSE wohl ein Kollege einen PC mit genau dem IDE-Problem zur Analyse mitbringen konnte. Gruesse, Thomson -- Thomas Hertweck, Dipl.-Geophys. Geophysikalisches Institut, Universitaet Karlsruhe (TH)
On Wednesday 13 November 2002 20:45, Hartmut Meyer wrote:
Am Mittwoch, 13. November 2002 11:22 schrieb Bruno Schiele:
Am Mittwoch, 13. November 2002 11:05 schrieb Arno Weber:
Tatsache ist, daß SuSE mit den Versionen 8.0 und 8.1 Distributionen verkauft hat, die für Leute mit 2 IDE-HDs im Rechner so wie sie aus der Verpackung kommen wertlos sind.
Sorry, ich habe den Thread nicht ganz verfolgt, aber was meinst du damit???
Er meint damit, dass bei Ihm bei Verwendung von zwei IDE-Platten der SuSE-Kernel von der 8.0 und der 8.1 die Grätsche macht.
Aus den Tatsachen, dass
a) dieses Problem bei ihm reproduzierbar ist und b) auch einige andere von diesem Problem berichtet haben
folgert er (fälschlicherweise), dass dies auf alle oder zumindest die meisten Rechner mit 2 IDE-Platten zutrifft.
Aber SuSE nimmt vielleicht (fälschlicherweise) an, dass dadurch das es hausintern nicht auftritt (wer weiss?), und auch nicht sehr oft beim Support gemeldet wird, dass es ein vernachlässigbares Problem ist. Das ist aber unter Umständen ebenso nicht ganz richtig, so vermute ich. Bei von meinen zu betreuenden ca 10 Rechern haben 4 zwei IDE-Platten und davon haben 2 den Fehler. Dies habe ich aber nie beim Support gemeldet, da ich die anderen Fälle kannte und mir den Support-Hinweis ersparen wollte der da lautet, dies ist kostenpflichtiger Support ... :-) Stattdessen habe ich die Platten einstweilen abgehängt und seitdem sind die Rechner schlichtweg nicht mehr abgestürzt. Gruß, Michael@Karbach.org
Am Mit, 2002-11-13 um 21.33 schrieb Michael Karbach:
On Wednesday 13 November 2002 20:45, Hartmut Meyer wrote:
Am Mittwoch, 13. November 2002 11:22 schrieb Bruno Schiele:
Am Mittwoch, 13. November 2002 11:05 schrieb Arno Weber:
Tatsache ist, daß SuSE mit den Versionen 8.0 und 8.1 Distributionen verkauft hat, die für Leute mit 2 IDE-HDs im Rechner so wie sie aus der Verpackung kommen wertlos sind.
Sorry, ich habe den Thread nicht ganz verfolgt, aber was meinst du damit???
Er meint damit, dass bei Ihm bei Verwendung von zwei IDE-Platten der SuSE-Kernel von der 8.0 und der 8.1 die Grätsche macht.
Aus den Tatsachen, dass
a) dieses Problem bei ihm reproduzierbar ist und b) auch einige andere von diesem Problem berichtet haben
folgert er (fälschlicherweise), dass dies auf alle oder zumindest die meisten Rechner mit 2 IDE-Platten zutrifft.
Aber SuSE nimmt vielleicht (fälschlicherweise) an, dass dadurch das es hausintern nicht auftritt (wer weiss?),
Laut Philipp T. war ein anderer SuSE-Mitarbeiter diesem Bug vor einigen Wochen selbst betroffen.
und auch nicht sehr oft beim Support gemeldet wird, dass es ein vernachlässigbares Problem ist. Das ist aber unter Umständen ebenso nicht ganz richtig, so vermute ich. Hubert Mantel persönlich kannte dieses Problem seit Mai - Er und SuSE haben einfach nichts unternommen. Erst als Philipp T. sich vor ca 3. Wochen der Sache annahm, tat sich was.
Bei von meinen zu betreuenden ca 10 Rechern haben 4 zwei IDE-Platten und davon haben 2 den Fehler. Dies habe ich aber nie beim Support gemeldet, da ich die anderen Fälle kannte und mir den Support-Hinweis ersparen wollte der da lautet, dies ist kostenpflichtiger Support ... :-) Stattdessen habe ich die Platten einstweilen abgehängt und seitdem sind die Rechner schlichtweg nicht mehr abgestürzt. Ich habe die mittlerweise (nicht nur aus diesem Grund) die Distribution gewechselt.
Ralf
Ralf Corsepius <corsepiu@faw.uni-ulm.de> [13 Nov 2002 22:17:34 +0100]:
Hubert Mantel persönlich kannte dieses Problem seit Mai - Er und SuSE haben einfach nichts unternommen. Erst als Philipp T. sich vor ca 3. Wochen der Sache annahm, tat sich was.
Das schmeichelt zwar, ist aber komplett falsch. Es war schlicht und ergreifend ein reiner Zufall. Wir hatten zum ersten Mal einen Rechner zur Hand, auf dem sich das Problem 100% reproduzieren liess. Die vermutete Quelle (sie waren es letztendlich nicht) waren bestimmte Patches gewesen, weshalb die Patches testweise heraus genommen wurden. Als es dann Testkernels geben sollte, habe ich dann nur gesagt, dass ich auch von externen Leuten wüsste, die an so einem Testkernel interessiert seien.
Dies habe ich aber nie beim Support gemeldet, da ich die anderen Fälle kannte und mir den Support-Hinweis ersparen wollte der da lautet, dies ist kostenpflichtiger Support ... :-)
Ich kann mir eigentlich nicht vorstellen, das ein nicht funktionierender Kernel nicht zum Support gehört, aber ich bin da nicht up-to-date. Auf jeden Fall brauchen wir das Feedback, entweder über den Suppport oder eben http://www.suse.de/feedback, um das Ausmass abschätzen zu können. Öffentliche Mailinglisten wie suse-linux sind kein Ersatz dafür, denn niemand liesst offiziell diese Liste. Auch ich habe schon mal über etliche Wochen oder Monate keine suse-linux gelesen, weil ich meine manchmal spärliche Freizeit mit anderen Dingen verbringen wollte. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
On Wednesday 13 November 2002 22:17, Ralf Corsepius wrote:
Am Mit, 2002-11-13 um 21.33 schrieb Michael Karbach:
On Wednesday 13 November 2002 20:45, Hartmut Meyer wrote:
Am Mittwoch, 13. November 2002 11:22 schrieb Bruno Schiele:
Am Mittwoch, 13. November 2002 11:05 schrieb Arno Weber:
Tatsache ist, daß SuSE mit den Versionen 8.0 und 8.1 Distributionen verkauft hat, die für Leute mit 2 IDE-HDs im Rechner so wie sie aus der Verpackung kommen wertlos sind.
Er meint damit, dass bei Ihm bei Verwendung von zwei IDE-Platten der SuSE-Kernel von der 8.0 und der 8.1 die Grätsche macht.
Aber SuSE nimmt vielleicht (fälschlicherweise) an, dass dadurch das es hausintern nicht auftritt (wer weiss?),
Laut Philipp T. war ein anderer SuSE-Mitarbeiter diesem Bug vor einigen Wochen selbst betroffen.
und auch nicht sehr oft beim Support gemeldet wird, dass es ein vernachlässigbares Problem ist. Das ist aber unter Umständen ebenso nicht ganz richtig, so vermute ich.
Bei von meinen zu betreuenden ca 10 Rechern haben 4 zwei IDE-Platten und davon haben 2 den Fehler. Dies habe ich aber nie beim Support gemeldet, da ich die anderen Fälle kannte und mir den Support-Hinweis ersparen wollte der da lautet, dies ist kostenpflichtiger Support ... :-) Stattdessen habe ich die Platten einstweilen abgehängt und seitdem sind die Rechner schlichtweg nicht mehr abgestürzt.
Ich habe die mittlerweise (nicht nur aus diesem Grund) die Distribution gewechselt.
Tja, einfacher gesagt als getan. Drei meiner Rechner sind in den USA und da bin ich nur einmal im Jahr und da wäre mir ein Umstieg zu riskant. 4 weitere Rechner sind in der UNI und da läuft alles unter SuSE und ein einzelner Umstieg einer Arbeitsgruppe wäre nicht gerne von den Hauptadministratoren gesehen. Blieben noch meine 4 Homerechner. Einer davon ist mein Firewall/Gateway (altes Notebook) das hat eine uptime von Monaten da ändere ich nix, warum auch:. Der Home-Server ist gleichzeitig der Desktop-Rechner meiner Frau, die ist seit Wochen nicht mehr ausgeloggt, und wenn ich da etwas dran mache gibt's Ärger:-), zudem läuft der Rechner absolut stabil. Bleibt noch der Spielerechner meiner Kinder, da könnte ich experimentieren, aber da sind soviele Spielevon Hand drauf installiert, dass das ebenso unsinnig wäre. Der einzige Rechner der übrig bleibt wäre mein Notebook. Da aber sowieso nur DEBIAN oder gar FreeBSD als Alternative in Frage kommen habe ich das auf die Zeit hinausgeschoben, wenn ich ein neues Notebook bekomme, denn es muss sichergestellt sein, dass ich weiter arbeiten kann, denn letzendlich ist das mein tägliches Arbeitsgerät. Michael
Hallo Hartmut, On Mittwoch, 13. November 2002 20:45, Hartmut Meyer wrote:
Aus den Tatsachen, dass
a) dieses Problem bei ihm reproduzierbar ist und b) auch einige andere von diesem Problem berichtet haben
folgert er (fälschlicherweise), dass dies auf alle oder zumindest die meisten Rechner mit 2 IDE-Platten zutrifft.
Bitte belege mir einige Fälle (NON-Standard-IDE-Controller sind geschenkt), wo der Original-SuSE 8.1-Kernel bei einem Rechner mit 2x IDE-HD den IDE-Bug nicht zeigt. Tatsächlich kann ich für meine Behauptung nur meine Erfahrung und die der betreffenden Postings in dieser ML anführen. Das sind allerdings nicht "sehr wenige". DIe Dunkelziffer dürfte schon deshalb sehr hoch sein, weil niemand so ein Problem in einer käuflichen Distribution erwarten würde.
Richtig ist, dass es nur bei sehr wenigen Leuten zu diesen Problemen (dessen Ursache oder auch nur die Voraussetzung für dessen Aufteten zumindest mir immer noch nicht klar ist) kommt.
Kannst Du im Archiv nachlesen: der Barrier-Patch, den SuSE einfügt.
Wäre es tatsächlich ein ganz allgemeines Problem, dann gäbe es mit Sicherheit inzwischen eine Lösung - denn dann wäre es auch sehr einfach das Problem nachzustellen.
Es gibt ja eine Lösung, nur nicht SuSE-offiziell! Und deshalb laufen immer wieder neue Leute mit diesem Problem ins offene Messer. Damit meine ich die Datenverluste, die so ein Kernelhänger sehr oft mit sich bringt. Also überleg Dir gut, welche Geschäftspolitik Du da rechtfertigst. MfG Arno Weber
Hallo, Am Mittwoch, 13. November 2002 21:41 schrieb Arno Weber:
On Mittwoch, 13. November 2002 20:45, Hartmut Meyer wrote:
Aus den Tatsachen, dass
a) dieses Problem bei ihm reproduzierbar ist und b) auch einige andere von diesem Problem berichtet haben
folgert er (fälschlicherweise), dass dies auf alle oder zumindest die meisten Rechner mit 2 IDE-Platten zutrifft.
Bitte belege mir einige Fälle (NON-Standard-IDE-Controller sind geschenkt), wo der Original-SuSE 8.1-Kernel bei einem Rechner mit 2x IDE-HD den IDE-Bug nicht zeigt.
Als konkretes Beispiel kann ich dir meinen Rechner nennen: felix:~ # hwinfo --disk 14: IDE 02.0: 10600 Disk [Created at ide.122] Unique ID: hY5p.C2H0_3rpT6E Hardware Class: disk Model: "IBM-DTLA-307045" Device: "IBM-DTLA-307045" Revision: "TX6OA60A" Serial ID: "YMEYMFH0767" Driver: "ide-disk" Device File: /dev/hdc Geometry (Physical): CHS 22075/16/255 Geometry (Logical): CHS 89355/16/63 Size: 90069840 sectors a 512 bytes Cache: 1916 kb Config Status: cfg=yes, avail=yes, need=no Attached to: #4 (IDE interface) 15: IDE 03.0: 10600 Disk [Created at ide.122] Unique ID: 8kLt.JmljC1+BE5C Hardware Class: disk Model: "Maxtor 4G120J6" Device: "Maxtor 4G120J6" Revision: "GAK819K0" Serial ID: "G6064XGE" Driver: "ide-disk" Device File: /dev/hdd Geometry (Physical): CHS 14946/255/63 Geometry (Logical): CHS 14946/255/63 Size: 240121728 sectors a 512 bytes Cache: 2048 kb Config Status: cfg=yes, avail=yes, need=no Attached to: #4 (IDE interface) felix:~ # cat /proc/version Linux version 2.4.19-4GB (root@Athlon.suse.de) (gcc version 3.2) #1 Fri Sep 13 3:19:15 UTC 2002 Das ist vermutlich nicht mehr der Original-Kernel der 8.1, aber ich schwöre, ich habe das Problem noch nie life gesehen (weder auf diesem Rechner noch auf irgendeinem anderen). Mit keinem Kernel.
Tatsächlich kann ich für meine Behauptung nur meine Erfahrung und die der betreffenden Postings in dieser ML anführen.
Bestreite ich ja auch nicht. Nur die Verallgemeinerung. Denn die ist falsch.
Das sind allerdings nicht "sehr wenige". DIe Dunkelziffer dürfte schon deshalb sehr hoch sein, weil niemand so ein Problem in einer käuflichen Distribution erwarten würde.
Die Begründung für die Dunkelziffer verstehe ich jetzt nciht, aber das macht auch nichts. Ich gehe umgekehrt davon aus, dass auf dieser Liste die Mehrzahl der Leute, die betroffen ist, sich auch melden, wenn sie dieses Problem bei sich haben. Mindestens eine "ich auch" Mail. Umgekehrt gehe ich davon aus, dass nur eine verschwindende Minderheit derer, die das Problem nicht haben (trotz zwei IDE-Platten, was ja tatsächlich nicht selten ist), sich melden und sagen - "bei mir sehe ich das Problem nicht". Das liegt in der Natur der Sache.
Richtig ist, dass es nur bei sehr wenigen Leuten zu diesen Problemen (dessen Ursache oder auch nur die Voraussetzung für dessen Aufteten zumindest mir immer noch nicht klar ist) kommt.
Kannst Du im Archiv nachlesen: der Barrier-Patch, den SuSE einfügt.
Um es ganz klar zu sagen: ich bin kein Kernel-Entwickler und will hier auch erst gar nicht behaupten in der Materie den großen Durchblick zu haben. Nimm es also mit Vorsicht. Der Barrier-Patch mag _eine_ Ursache sein. Bist du sicher, dass der Barrier Patch bereits im 8.0er Kernel war? Ich denke eher nicht (kann mich aber selbstverständlich täuschen). Was ich über die Problematik mit dem Barrier-Patch weiss bzw. glaube zu wissen ist, dass es mit einigen Samsung Platten zu Problemen kommt (wohlbemerkt durch eine kaputte Firmware der Platten). Wenn ich mich nicht täusche, gab es im IDE-Code aber eine ganze Reihe von Problemen, die zudem nicht alle SuSE-spezifisch sind. Es gab auf der Liste auch einige Leute die berichteten, dass bei ihnen das Problem beispielsweise auch nicht durch einen Vanilla-Kernel gelöst wurden. Wir brauchen eine umfassende Lösung (was ein umfassendes Veständnis für die Ursachen des Problem voraussetzt). Und das ist offensichtlich nicht trivial. Oder hältst du die SuSE-Entwickler für Idioten? Oder für Ignoranten?
Wäre es tatsächlich ein ganz allgemeines Problem, dann gäbe es mit Sicherheit inzwischen eine Lösung - denn dann wäre es auch sehr einfach das Problem nachzustellen.
Es gibt ja eine Lösung, nur nicht SuSE-offiziell!
Und, löst die auf allen betroffenen Rechnern das Problem? Du sprichst offensichtlich von den Kerneln im Verzeichnis von Hubert Mantel auf unserem FTP-Server. Die Kernel, die da unter "next" abgelegt sind, haben noch nicht den Status einer offiziellen Lösung. Sie sind noch nicht ausreichend getestet. Schließlich hilft es ja nichts, einen Kernel ofiziell zum Update anzubieten, der zwar (möglicherweise) ein bestimmtes Problem behebt, aber von dem nicht sicher ist, dass er nicht andere neue Probleme mit sich bringt.
Und deshalb laufen immer wieder neue Leute mit diesem Problem ins offene Messer. Damit meine ich die Datenverluste, die so ein Kernelhänger sehr oft mit sich bringt. Also überleg Dir gut, welche Geschäftspolitik Du da rechtfertigst.
Ich habe keine Probleme damit. Natürlich wünsche ich mir auch eine möglichst schnelle Behebung von Fehlern. Aber eine Lösung nach Salami-Technik (alle zwei Wochen ein neues offizielles Kernel-Update, weil es wieder für irgendwas eine Teillösung gibt) halte ich nicht für die bessere Lösung. Dir stellt sich die Situation vermutlich als eindeutig und vielleicht auch relativ übersichtlich dar. Ich denke, das ist sie nicht. Und ich bezweifle, dass viele den nötigen Hintergrund (Informationen + Wissen) haben, um dies tatsächlich zu beurteilen. Ich selbst gehöre zumindest mit Sicherheit nicht dazu. Da ich andererseits weiß, dass Hubert & Co weder Idioten noch Ignoranten sind (und ich zudem im Support sehe, dass wir trotz vielem rumprobieren mit unterschiedlichen Lösungen bei unseren Kunden bis heute keine allgeine Lösung gefunden haben) gehe ich davon aus, dass der Sachverhalt erheblich komplizieter ist. Schöne Grüße aus Bremen hartmut
Hallo Hartmut, On Mittwoch, 13. November 2002 22:54, Hartmut Meyer wrote:
Als konkretes Beispiel kann ich dir meinen Rechner nennen:
felix:~ # hwinfo --disk 14: IDE 02.0: 10600 Disk ...
Gut - dann muß ich mich korrigieren: Jeder SuSE 8.01-Käufer, der diese auf einem Rechner mit 2 IDE-HDs installiert, geht ein Risiko mit bisher unbekannter Wahrscheinlichkeit ein, daß er vom IDE-Kernel-Bug betroffen sein wird.
Dunkelziffer dürfte schon deshalb sehr hoch sein, weil niemand so ein Problem in einer käuflichen Distribution erwarten würde.
Die Begründung für die Dunkelziffer verstehe ich jetzt nciht, aber das macht auch nichts.
Ist doch naheliegend: wenn ich ein Produkt kaufe, rechne ich nicht mit totaler Funktionsunfähigkeit und suche den Fehler bei mir oder meiner Hardware. Je nach meinen Möglichkeiten geben ich früher oder später die Fehlersuche auf. Bei SuSE ist ja nichts dokumentiert. Die wenigsten Betroffenen werden dann den SuSE Support (nach einer Zwangsregistrierung, MS läßt grüßen) einschalten. Der Rest - und der ist mit Dunkelziffer angesprochen - geht auf eine stabile SuSE-Version zurück oder bleibt bei seiner NON-SuSE/MS-WIndows oder wechselt dorthin. Bitte doch mal nur die Betroffenen in der ML, sich per PM bei DIr zu melden und Du bekommst einen Vorgeschmack auf die Dunkelziffer
Ich gehe umgekehrt davon aus, dass auf dieser Liste die Mehrzahl der Leute, die betroffen ist, sich auch melden, wenn sie dieses Problem bei sich haben. Mindestens eine "ich auch" Mail.
... nur eine Minderheit der SuSE-Käufer liest diese Liste!!!
Wenn ich mich nicht täusche, gab es im IDE-Code aber eine ganze Reihe von Problemen, die zudem nicht alle SuSE-spezifisch sind. Es gab auf der Liste auch einige Leute die berichteten, dass bei ihnen das Problem beispielsweise auch nicht durch einen Vanilla-Kernel gelöst wurden.
So mußte ich es auch lösen, weil keine bereinigten Kernel-Sourcen verfügbar waren. Allerdings habe ich nirgendwo auch nur Anhaltspunkte dafür gefunden, daß der IDE-Kernel-Bug in einer anderen Distri vorkam. Das spricht dann doch sehr für "SuSE-spezifisch".
Wir brauchen eine umfassende Lösung (was ein umfassendes Veständnis für die Ursachen des Problem voraussetzt). Und das ist offensichtlich nicht trivial. Oder hältst du die SuSE-Entwickler für Idioten? Oder für Ignoranten?
Das ist wichtig und richtig. Nur: wo bleibt eine Warnung an die potentiell Betroffenen auf der SuSE-Website und über die Nachrichtendienste? Nochmal: wer in den Bug reinläuft, riskiert viel verlorene Zeit und Daten! Denk mal an Eure Geschäftskunden, die mit der 8.1 produktiv einsetzen. Wenn da der Bug die Produktion stoppt, fliegt SuSE komplett raus. Was die Autoindustrie schon vor einiger Zeit zähneknirschend gelernt hat, bleibt auch SuSE nicht erspart.
Es gibt ja eine Lösung, nur nicht SuSE-offiziell!
Und, löst die auf allen betroffenen Rechnern das Problem?
Die Frage darfst Du nicht an einen SuSE-Kunden richten. Ich will niemand eine Linux-Distribution verkaufen und stehe deshalb auch in keiner Pflicht. Allerdings habe ich mit dem Kauf Anspruch auf ein Produkt, daß bestimmungsgemäß funktioniert. SuSE scheint der Meinung zu sein, daß das Gewährleistungsrecht nur für die anderen gilt. Eine Mindestlösung wäre z.B. die o.g. öffenltiche Produktwarnung und ein Artikel mit den Alternativen in der SDB.
Und deshalb laufen immer wieder neue Leute mit diesem Problem ins offene Messer. Damit meine ich die Datenverluste, die so ein Kernelhänger sehr oft mit sich bringt. Also überleg Dir gut, welche Geschäftspolitik Du da rechtfertigst.
Ich habe keine Probleme damit. Natürlich wünsche ich mir auch eine möglichst schnelle Behebung von Fehlern. Aber eine Lösung nach Salami-Technik (alle zwei Wochen ein neues offizielles Kernel-Update, weil es wieder für irgendwas eine Teillösung gibt) halte ich nicht für die bessere Lösung.
Seltsam, daß auch Dir die Zukunft von SuSE gleichgültig ist. MfG Arno Weber
Hallo, Am Donnerstag, 14. November 2002 09:23 schrieb Arno Weber:
Hallo Hartmut,
On Mittwoch, 13. November 2002 22:54, Hartmut Meyer wrote:
Als konkretes Beispiel kann ich dir meinen Rechner nennen:
felix:~ # hwinfo --disk 14: IDE 02.0: 10600 Disk ...
Gut - dann muß ich mich korrigieren: Jeder SuSE 8.01-Käufer, der diese auf einem Rechner mit 2 IDE-HDs installiert, geht ein Risiko mit bisher unbekannter Wahrscheinlichkeit ein, daß er vom IDE-Kernel-Bug betroffen sein wird.
Dunkelziffer dürfte schon deshalb sehr hoch sein, weil niemand so ein Problem in einer käuflichen Distribution erwarten würde.
Die Begründung für die Dunkelziffer verstehe ich jetzt nciht, aber das macht auch nichts.
Ist doch naheliegend: wenn ich ein Produkt kaufe, rechne ich nicht mit totaler Funktionsunfähigkeit und suche den Fehler bei mir oder meiner Hardware. Je nach meinen Möglichkeiten geben ich früher oder später die Fehlersuche auf. Bei SuSE ist ja nichts dokumentiert. Die wenigsten Betroffenen werden dann den SuSE Support (nach einer Zwangsregistrierung, MS läßt grüßen)
Der Verleich mit Zwangsregistrierung/MS ist flach und falsch. Aber du kannst ja mal einen Vorschlag machen, wie wir zum einen kostenlosen Installations-Support anbieten, aber zum anderen sicherstellen, dass dieser (für uns alles andere als kostenlose) Service auch tatsächlich denen zugute kommt, die ihn finanzieren.
einschalten. Der Rest - und der ist mit Dunkelziffer angesprochen - geht auf eine stabile SuSE-Version zurück oder bleibt bei seiner NON-SuSE/MS-WIndows oder wechselt dorthin. Bitte doch mal nur die Betroffenen in der ML, sich per PM bei DIr zu melden und Du bekommst einen Vorgeschmack auf die Dunkelziffer
So sei es ;-) Ich bitte also alle Betroffenen um eine PM (Mail direkt an mich, nicht über die Liste). Bitte schickt mir die Ausgaben von hwinfo --storage_ctrl --disk cat /proc/version und eine kurze Beschreibung, wie und wann sich das Problem bei euch bemerkbar macht. Falls das Problem inzwischen beu euch behoben ist würde mich natürlich auch die Lösung interessieren. Nicht wundern, wenn ihr keine Reaktion bekommt: ich bin die nächsten zwei Wochen in Urlaub.
Ich gehe umgekehrt davon aus, dass auf dieser Liste die Mehrzahl der Leute, die betroffen ist, sich auch melden, wenn sie dieses Problem bei sich haben. Mindestens eine "ich auch" Mail.
... nur eine Minderheit der SuSE-Käufer liest diese Liste!!!
Klar, aber an der Relation ändert das nichts.
Es gibt ja eine Lösung, nur nicht SuSE-offiziell!
Und, löst die auf allen betroffenen Rechnern das Problem?
Die Frage darfst Du nicht an einen SuSE-Kunden richten. Ich will niemand eine Linux-Distribution verkaufen und stehe deshalb auch in keiner Pflicht. Allerdings habe ich mit dem Kauf Anspruch auf ein Produkt, daß bestimmungsgemäß funktioniert. SuSE scheint der Meinung zu sein, daß das Gewährleistungsrecht nur für die anderen gilt.
Bei allem Verständnis für deinen Standpunkt, aber mit Gewährleistungspflicht hat das nichts zu tun. Schöne Grüße aus Bremen hartmut
Hallo, Am Donnerstag, 14. November 2002 20:02 schrieb Hartmut Meyer:
Am Donnerstag, 14. November 2002 09:23 schrieb Arno Weber:
On Mittwoch, 13. November 2002 22:54, Hartmut Meyer wrote:
Dunkelziffer dürfte schon deshalb sehr hoch sein, weil niemand so ein Problem in einer käuflichen Distribution erwarten würde.
Die Begründung für die Dunkelziffer verstehe ich jetzt nciht, aber das macht auch nichts.
[...]
Bitte doch mal nur die Betroffenen in der ML, sich per PM bei DIr zu melden und Du bekommst einen Vorgeschmack auf die Dunkelziffer
So sei es ;-)
Ich bitte also alle Betroffenen um eine PM (Mail direkt an mich, nicht über die Liste). Bitte schickt mir die Ausgaben von
hwinfo --storage_ctrl --disk cat /proc/version
und eine kurze Beschreibung, wie und wann sich das Problem bei euch bemerkbar macht. Falls das Problem inzwischen beu euch behoben ist würde mich natürlich auch die Lösung interessieren.
Nicht wundern, wenn ihr keine Reaktion bekommt: ich bin die nächsten zwei Wochen in Urlaub.
Auf Nachfrage: Der Aufruf an Betroffene war/ist durchaus ernst gemeint. Aber ich will natürlich nicht die falsche Erwartung wecken, dass ihr von mir dann eine Lösung bekommt. Wenn es euch zu aufwändig ist, mir eine genauere Meldung zu machen, dann reicht mir ein einfaches "ich war betroffen" auch (anders ist es mir natürlich lieber. Ich werde dann nach meinem Urlaub mal das Ergebnis hier hin schicken (in diesem Thread). Schöne Grüße aus Bremen hartmut
Hallo, Am Donnerstag, 14. November 2002 22:04 schrieb Hartmut Meyer:
Hallo,
Am Donnerstag, 14. November 2002 20:02 schrieb Hartmut Meyer:
Am Donnerstag, 14. November 2002 09:23 schrieb Arno Weber:
On Mittwoch, 13. November 2002 22:54, Hartmut Meyer wrote:
Dunkelziffer dürfte schon deshalb sehr hoch sein, weil niemand so ein Problem in einer käuflichen Distribution erwarten würde.
Die Begründung für die Dunkelziffer verstehe ich jetzt nciht, aber das macht auch nichts.
[...]
Bitte doch mal nur die Betroffenen in der ML, sich per PM bei DIr zu melden und Du bekommst einen Vorgeschmack auf die Dunkelziffer
So sei es ;-)
Ich bitte also alle Betroffenen um eine PM (Mail direkt an mich, nicht über die Liste). Bitte schickt mir die Ausgaben von
hwinfo --storage_ctrl --disk cat /proc/version
und eine kurze Beschreibung, wie und wann sich das Problem bei euch bemerkbar macht. Falls das Problem inzwischen beu euch behoben ist würde mich natürlich auch die Lösung interessieren.
Nicht wundern, wenn ihr keine Reaktion bekommt: ich bin die nächsten zwei Wochen in Urlaub.
Auf Nachfrage:
Der Aufruf an Betroffene war/ist durchaus ernst gemeint. Aber ich will natürlich nicht die falsche Erwartung wecken, dass ihr von mir dann eine Lösung bekommt.
Wenn es euch zu aufwändig ist, mir eine genauere Meldung zu machen, dann reicht mir ein einfaches "ich war betroffen" auch (anders ist es mir natürlich lieber.
Ich werde dann nach meinem Urlaub mal das Ergebnis hier hin schicken (in diesem Thread).
Wie versprochen: es haben sich zwei Leute bei mir gemeldet (Ralf Ebeling und Thomas Hertweck). Der Rest der Betroffenen hat entweder nicht mitgelesen oder war zu faul (natürlich kein Vorwurf). Inzwischen gibt es aber den lange erwarteten Update Kernel: --- schnipp ----- kernel-source: Die Linux Kernel-Quellen (Kern des Linux Betriebssystems) ---------------------------------------------------------------------- Datei: kernel-source-2.4.19.SuSE-115.i586.rpm Patchrpm: kernel-source-2.4.19.SuSE-115.i586.patch.rpm Version: 2.4.19.SuSE Größe: 33780 kB Patchgröße: 5696 kB Datum: Mit 04 Dez 2002 17:29:16 CET Source: kernel-source-2.4.19.SuSE-115.nosrc.rpm Security: Ja ---------------------------------------------------------------------- Beschreibung: Dieses Kernel-Update behebt mehrere Probleme, die zu Abstuerzen oder anderen Fehlfunktionen führen können, insbesondere bei Einsatz von ICP Vortex RAID Controllern und bei Verwendung von mehreren IDE Festplatten im System. Dieses update-Paket (kernel-source) enthält nur die Quellen des SuSE kernels für Benutzer, die ihre eigenen Kernels kompilieren und installieren möchten. Wenn Sie von SuSE vorgefertigte kernels benutzen, dann brauchen Sie dieses update nicht. --- schnapp ----- sowie --- schnipp ----- k_deflt: der Standard Kernel ---------------------------------------------------------------------- Datei: k_deflt-2.4.19-174.i586.rpm Patchrpm: k_deflt-2.4.19-174.i586.patch.rpm Version: 2.4.19 Größe: 21380 kB Patchgröße: 13772 kB Datum: Mit 27 Nov 2002 03:25:58 CET Source: k_deflt-2.4.19-174.src.rpm Security: Nein ---------------------------------------------------------------------- Beschreibung: Dieses Kernel-Update behebt mehrere Probleme, die zu Abstuerzen oder anderen Fehlfunktionen führen können, insbesondere bei Einsatz von ICP Vortex RAID Controllern und bei Verwendung von mehreren IDE Festplatten im System. Nach Einspielen dieses Patches ist ein Reboot des Systemes nötig. --- schnapp k_smp und k_athlon gibts natürlich auch.
Arno Weber <arnoweber@epost.de> [13 Nov 2002 21:41:51 +0100]:
Kannst Du im Archiv nachlesen: der Barrier-Patch, den SuSE einfügt.
Das war der *vermutete* Auslöser, war er aber letztendlich nicht. Die Barrier-Patches waren letztlich nur Auslöser eines Bugs, der woanders sass. Noch einmal: hätte es wirklich massive Probleme gegeben, hätten wir wahrscheinlich früher versucht, eine Lösung zu finden. So aber kam es nur zu vereinzelten Meldungen, die wir nicht reproduzieren konnten und einen nicht reproduzierbaren Fehler zu beheben ist extrem schwierig. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
Hallo Philipp, On Donnerstag, 14. November 2002 02:03, Philipp Thomas wrote:
Noch einmal: hätte es wirklich massive Probleme gegeben, hätten wir wahrscheinlich früher versucht, eine Lösung zu finden. So aber kam es nur zu vereinzelten Meldungen, die wir nicht reproduzieren konnten und einen nicht reproduzierbaren Fehler zu beheben ist extrem schwierig.
Dein Einsatz ist unbestritten. So wie ich das sehe, hat die Gestaltung von Eurem Support unnötig zu dem Problem beigetragen. Ich wechsle nicht in die OpenSource-Welt, um mich dann doch beim SuSE-Support zwangsregistrieren zu lassen. Und feedback@suse ist zu unverbindlich für eine aktuelle Problemmeldung. Ihr müßt Euch mit dem Gedanken anfreunden, daß schon mehr als "sehr wenige" betroffen sind. Habt Ihr schon mal Eure Händler gefragt, wieviel Kunden die 8.1 wegen "läuft nicht" zurückgeben wollten? Eine öffentliche Produktwarnung zu dem IDE-Bug ist jedenfalls überfällig, auch wenn das nicht unbedingt den Aktienkurs hebt. Tut Ihr das nicht, verschlechtert sich neben Eurem Image auch die Rechtsposition in Bezug auf Folgeschäden. MfG Arno Weber
Hallo, Am Donnerstag, 14. November 2002 09:39 schrieb Arno Weber:
Eine öffentliche Produktwarnung zu dem IDE-Bug ist jedenfalls überfällig, auch wenn das nicht unbedingt den Aktienkurs hebt. Tut Ihr das nicht, verschlechtert sich neben Eurem Image auch die Rechtsposition in Bezug auf Folgeschäden.
Sorry, aber das ist (juristisch) einfach falsch. Wenn du es nicht glaubst: verklag uns auf Schadenersatz oder wegen Gewährleistungsansprüchen. Auf den Kosten der Klage wirst du sitzenbleiben. Das es keine "Produktwarnung" gibt hat weder etwas mit "Aktienkursen", noch etwas mit unserer "Rechtsposition in Bezug auf Folgeschäden" zu tun, sondern einfach damit, dass wir zumindest bis vor kurzem keine ausreichende Problemanalyse hatten. Über den aktuellen Stand bin ich nicht informiert - aber Philipp weiss da offensichtlich mehr. Und deine Aufregung wegen "Zwangsregistrierung" finde ich arm - um es vorsichtig auszudrücken. hartmut
Am Mit, 13 Nov 2002 schrieb Hartmut Meyer:
Am Mittwoch, 13. November 2002 11:22 schrieb Bruno Schiele:
Am Mittwoch, 13. November 2002 11:05 schrieb Arno Weber:
Tatsache ist, daß SuSE mit den Versionen 8.0 und 8.1 Distributionen verkauft hat, die für Leute mit 2 IDE-HDs im Rechner so wie sie aus der Verpackung kommen wertlos sind.
Sorry, ich habe den Thread nicht ganz verfolgt, aber was meinst du damit???
Er meint damit, dass bei Ihm bei Verwendung von zwei IDE-Platten der SuSE-Kernel von der 8.0 und der 8.1 die Grätsche macht.
Aus den Tatsachen, dass
a) dieses Problem bei ihm reproduzierbar ist und b) auch einige andere von diesem Problem berichtet haben
folgert er (fälschlicherweise), dass dies auf alle oder zumindest die meisten Rechner mit 2 IDE-Platten zutrifft.
Das das Problem im Kernel der 8.0 auftrat, war sicher ärgerlich, aber vielleicht nicht zu ändern - da SuSE ja aus mir nach wie vor unerfindlichen Gründen auf eine öffentliche Beta-Phase verzichtet (bei UnitedLinux ist es ja interessanterweise anders). Aber das Problem war danach bekannt, allein schon durch die zahlreichen Rückmeldungen auf dieser Liste, und dem hätte nachgegangen werden müssen, daß es in der 8.1 wieder auftauchte, stimmt mich sehr bedenklich (und bestärkt mich in meiner Praxis, grundsätzlich (sehr selektiv gepatchte) Vanilla-Kernel einzusetzen. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Hallo, On Mon, 11 Nov 2002, Philipp Thomas wrote:
David Haller <david@dhaller.de> [Sun, 10 Nov 2002 20:02:02 +0100]:
Ich tippe, das ist der IDE-Bug, den SuSE eingebaut hat...
Mit Verlaub, ich wage zu widersprechen. Das war kein IDE-Bug, den SuSE eingebaut hat, sondern ein Bug (genauer zwei Bugs) in den Barrier-Patches, dessen Auswirkungen unter IDE bemerkbar wurden und die mittlerweile analysiert und gefixt wurden.
Mit Verlaub, ich wage zu widersprechen. Wenn ihr einen buggy patch einbaut, dann baut ihr eben damit auch den Bug mit ein... Von wem der patch ist, ist dabei erstmal irrelevant, entscheidend ist, dass der Fehler im SuSE-Kernel gelandet ist. IMHO seid "ihr" (Hubert also wohl primaer?) fuer meinen Geschmack zu wenig "defensiv" was das anwenden von Kernel-Patches angeht... Aber es ist ja eigentlich Tradition, dass SuSE auch mal 'beta'-Patches einspielt (Ich erinnere an fruehe reiserfs-patches fuer 2.2.x) ;) -dnh -- / "Why is it that _really_ stupid ideas never actually die but just lie \ [ dormant in some conviently empty brain so that you have to prove again ] \ and again and again that they are _really_ stupid?" -- Geoff Lane /
participants (14)
-
Al Bogner -
Arno Weber -
Bruno Schiele -
Christoph Maurer -
David Haller -
Dieter Resnikschek -
Harald Huthmann -
Hartmut Meyer -
Jürgen Vollmer -
Maik Holtkamp -
Michael Karbach -
Philipp Thomas -
Ralf Corsepius -
Thomas Hertweck