Re: ZFS vs ext3/NTFS/Veritas Storage Foundation
would be interesting if teher was also a document about XFS that is more suitable for some kind of use, and maybe reiserFS... > > Nice three documents with many numbers: > > http://blogs.sun.com/ontherecord/entry/now_available_three_new_solaris > > kloczek > -- > --- > *Ludzie nie maj± problemów, tylko sobie sami je stwarzaj±* > --- > Tomasz K³oczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS vs ext3/NTFS/Veritas Storage Foundation
would be interesting if teher was also a document about XFS that is more suitable for some kind of use, and maybe reiserFS... Nice three documents with many numbers: http://blogs.sun.com/ontherecord/entry/now_available_three_new_solaris kloczek -- --- *Ludzie nie maj± problemów, tylko sobie sami je stwarzaj±* --- Tomasz K³oczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: at mm/slab.c:777 __find_general_cachep()
While doing eavy I/O on a RAID1 logical volume with reiserfs with kernel
2.6.22-rc2 on Athlon64 3800+ X2, i got:
BUG: at mm/slab.c:777 __find_general_cachep()
Call Trace:
[] __kmalloc+0xfa/0x110
[] compat_core_sys_select+0xd1/0x250
[] compat_sys_select+0xe5/0x190
[] sys_read+0x53/0x90
[] ia32_sysret+0x0/0xa
linux 2.6.22-rc2 is copiled with gcc 4.2.0 (glibc 2.5).
system is:
DarkStar:{venom}:~>cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 43
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping: 1
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm
3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips: 2000.93
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 43
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping: 1
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings: 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm
3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips: 2000.93
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
has 2 GB RAM DR400
here is lspci:
arkStar:{root}:/home/venom>lspci -v
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
Subsystem: ASUSTeK Computer Inc. A8N-E Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [e0] HyperTransport: MSI Mapping
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard
Flags: 66MHz, fast devsel, IRQ 10
I/O ports at e400 [size=32]
I/O ports at 4c00 [size=64]
I/O ports at 4c40 [size=64]
Capabilities: [44] Power Management version 2
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
(prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21
Memory at d5004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
(prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20
Memory at d5005000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port
Capabilities: [80] Power Management version 2
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio
Controller (rev a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 8166
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
I/O ports at dc00 [size=256]
I/O ports at e000 [size=256]
Memory at d5003000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a
[Master SecP PriP])
Subsystem: Unknown device f043:815a
Flags: bus master, 66MHz, fast devsel, latency 0
[virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled]
[size=8]
[virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled]
[size=1]
[virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled]
[size=8]
[virtual] Memory at 0370 (type 3, non-prefetchable) [disabled]
[size=1]
I/O ports at f000 [size=16]
Capabilities: [44] Power Management version 2
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
(prog-if 85 [Master SecO PriO])
Subsystem: ASUSTeK Computer Inc. A8N-E Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
I/O ports at 09f0 [size=8]
I/O ports at 0bf0 [size=4]
I/O ports at 0970 [size=8]
I/O
BUG: at mm/slab.c:777 __find_general_cachep()
While doing eavy I/O on a RAID1 logical volume with reiserfs with kernel
2.6.22-rc2 on Athlon64 3800+ X2, i got:
BUG: at mm/slab.c:777 __find_general_cachep()
Call Trace:
[8027eeba] __kmalloc+0xfa/0x110
[802b60f1] compat_core_sys_select+0xd1/0x250
[802b7bf5] compat_sys_select+0xe5/0x190
[80285a83] sys_read+0x53/0x90
[8021f542] ia32_sysret+0x0/0xa
linux 2.6.22-rc2 is copiled with gcc 4.2.0 (glibc 2.5).
system is:
DarkStar:{venom}:~cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 43
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping: 1
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm
3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips: 2000.93
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 43
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping: 1
cpu MHz : 1000.000
cache size : 512 KB
physical id : 0
siblings: 2
core id : 1
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm
3dnowext 3dnow pni lahf_lm cmp_legacy
bogomips: 2000.93
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
has 2 GB RAM DR400
here is lspci:
arkStar:{root}:/home/venomlspci -v
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
Subsystem: ASUSTeK Computer Inc. A8N-E Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [e0] HyperTransport: MSI Mapping
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard
Flags: 66MHz, fast devsel, IRQ 10
I/O ports at e400 [size=32]
I/O ports at 4c00 [size=64]
I/O ports at 4c40 [size=64]
Capabilities: [44] Power Management version 2
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
(prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21
Memory at d5004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
(prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. K8N4-E or A8N-E Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20
Memory at d5005000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port
Capabilities: [80] Power Management version 2
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio
Controller (rev a2)
Subsystem: ASUSTeK Computer Inc. Unknown device 8166
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
I/O ports at dc00 [size=256]
I/O ports at e000 [size=256]
Memory at d5003000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a
[Master SecP PriP])
Subsystem: Unknown device f043:815a
Flags: bus master, 66MHz, fast devsel, latency 0
[virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled]
[size=8]
[virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled]
[size=1]
[virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled]
[size=8]
[virtual] Memory at 0370 (type 3, non-prefetchable) [disabled]
[size=1]
I/O ports at f000 [size=16]
Capabilities: [44] Power Management version 2
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
(prog-if 85 [Master SecO PriO])
Subsystem: ASUSTeK Computer Inc. A8N-E Mainboard
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
I/O ports at 09f0 [size=8]
[BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller.
Hi, since upgrading to kernel 2.6.20 my pata disk, using new pata driver, is initialized maximum in DMA33 mode (and obviously performances drop consequently), as you can see from: pata_amd :00:06.0: version 0.2.7 PCI: Setting latency timer of device :00:06.0 to 64 ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi4 : pata_amd ata5.00: ATA-7, max UDMA/100, 156368016 sectors: LBA48 ata5.00: ata5: dev 0 multi count 1 ata5.00: configured for UDMA/33 scsi5 : pata_amd ata6.00: ATAPI, max UDMA/33 ata6.00: configured for UDMA/33 scsi 4:0:0:0: Direct-Access ATA SAMSUNG SP0822N WA10 PQ: 0 ANSI: 5 SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sdc3 sd 4:0:0:0: Attached scsi disk sdc while with kernel 2.6.19.X it was initialized correctly in DMA100 mode: pata_amd :00:06.0: version 0.2.4 PCI: Setting latency timer of device :00:06.0 to 64 ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi4 : pata_amd ata5.00: ATA-7, max UDMA/100, 156368016 sectors: LBA48 ata5.00: ata5: dev 0 multi count 1 ata5.00: configured for UDMA/100 scsi5 : pata_amd ata6.00: ATAPI, max UDMA/33 ata6.00: configured for UDMA/33 scsi 4:0:0:0: Direct-Access ATA SAMSUNG SP0822N WA10 PQ: 0 ANSI: 5 SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sdc2 sdc3 sd 4:0:0:0: Attached scsi disk sdc I have other 2 sata disks on this system, and I have no problems with them. I Wonder if this is due to some controller/disk problem triggered just by 2.6.20 kernel (I saw there are a lot of changes into eh code), while 2.6.19.X and previous sees everything OK. Also forf the sata disks, in fact, I see this "doesn't support DPO or FUA" warning, but I have to admit I do not know which features it is referred to. This system is an Athlon64 X2 3800+ with an nvidia2 IDE controller here is the lspci -v 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: ASUSTeK Computer Inc. Unknown device 815a Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [e0] HyperTransport: MSI Mapping 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: 66MHz, fast devsel, IRQ 10 I/O ports at e400 [size=32] I/O ports at 4c00 [size=64] I/O ports at 4c40 [size=64] Capabilities: [44] Power Management version 2 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20 Memory at d4004000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 Memory at d4005000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] Debug port Capabilities: [80] Power Management version 2 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device 8166 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23 I/O ports at dc00 [size=256] I/O ports at e000 [size=256] Memory at d4003000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: Unknown device f043:815a Flags: bus master, 66MHz, fast devsel, latency 0 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170
[BUG?] ata disk running maximum at DMA33 with 2.6.20 and new pata driver, NV CK804 ide controller.
Hi, since upgrading to kernel 2.6.20 my pata disk, using new pata driver, is initialized maximum in DMA33 mode (and obviously performances drop consequently), as you can see from: pata_amd :00:06.0: version 0.2.7 PCI: Setting latency timer of device :00:06.0 to 64 ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi4 : pata_amd ata5.00: ATA-7, max UDMA/100, 156368016 sectors: LBA48 ata5.00: ata5: dev 0 multi count 1 ata5.00: configured for UDMA/33 scsi5 : pata_amd ata6.00: ATAPI, max UDMA/33 ata6.00: configured for UDMA/33 scsi 4:0:0:0: Direct-Access ATA SAMSUNG SP0822N WA10 PQ: 0 ANSI: 5 SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdc: sdc1 sdc2 sdc3 sd 4:0:0:0: Attached scsi disk sdc while with kernel 2.6.19.X it was initialized correctly in DMA100 mode: pata_amd :00:06.0: version 0.2.4 PCI: Setting latency timer of device :00:06.0 to 64 ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14 ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15 scsi4 : pata_amd ata5.00: ATA-7, max UDMA/100, 156368016 sectors: LBA48 ata5.00: ata5: dev 0 multi count 1 ata5.00: configured for UDMA/100 scsi5 : pata_amd ata6.00: ATAPI, max UDMA/33 ata6.00: configured for UDMA/33 scsi 4:0:0:0: Direct-Access ATA SAMSUNG SP0822N WA10 PQ: 0 ANSI: 5 SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 156368016 512-byte hdwr sectors (80060 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sdc2 sdc3 sd 4:0:0:0: Attached scsi disk sdc I have other 2 sata disks on this system, and I have no problems with them. I Wonder if this is due to some controller/disk problem triggered just by 2.6.20 kernel (I saw there are a lot of changes into eh code), while 2.6.19.X and previous sees everything OK. Also forf the sata disks, in fact, I see this doesn't support DPO or FUA warning, but I have to admit I do not know which features it is referred to. This system is an Athlon64 X2 3800+ with an nvidia2 IDE controller here is the lspci -v 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) Subsystem: ASUSTeK Computer Inc. Unknown device 815a Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [e0] HyperTransport: MSI Mapping 00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: 66MHz, fast devsel, IRQ 10 I/O ports at e400 [size=32] I/O ports at 4c00 [size=64] I/O ports at 4c40 [size=64] Capabilities: [44] Power Management version 2 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 20 Memory at d4004000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: ASUSTeK Computer Inc. K8N4-E Mainboard Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 Memory at d4005000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] Debug port Capabilities: [80] Power Management version 2 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) Subsystem: ASUSTeK Computer Inc. Unknown device 8166 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23 I/O ports at dc00 [size=256] I/O ports at e000 [size=256] Memory at d4003000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP]) Subsystem: Unknown device f043:815a Flags: bus master, 66MHz, fast devsel, latency 0 [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170
Re: HELP: unable to use I-MATE SP3 as USB (HTC) gprs modem
bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 3 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 which is, for what I understand (not to mutch to say the truth) really different. Obviously I will be happy to make all the test you will ask me. Luigi Genoni On Thursday 01 September 2005 19:32, Vojtech Pavlik wrote: > On Thu, Sep 01, 2005 at 07:22:04PM +0200, Oliver Neukum wrote: > > > I should use as an USB gprs modem. > > > > > > Since it is possible to configure it to be a (HTC) modem, using it's > > > menu, when I enable it to act as a modem on the usb port the content of > > > /proc/bus/usb/devices who refers to the phone changes to: I > > > > > > > > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 37 Spd=12 MxCh= 0 > > > D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > > > P: Vendor=0bb4 ProdID=00cf Rev= 0.90 > > > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA > > > I: If#= 0 Alt= 0 #EPs= 3 Cls=02(comm.) Sub=ff Prot=ff Driver=(none) > > > E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > > E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > > > E: Ad=86(I) Atr=03(Int.) MxPS= 16 Ivl=80ms > > > > > > The hotplug does not work anymore using the ipaq driver (as I > > > exspected), and the device is not attacched to ttyUSB0. > > > > > > I read Cls=02(comm.). I suppose there should be a way to use something > > > like cdc-acm driver. Unfortunatelly this driver does not seem to like > > > my phone. > > > All I get is a sad: > > > > > > usb 1-1: new full speed USB device using uhci_hcd and address 39 > > > > > > > > > Is there a way to solve this problem and to use I-mate SP3 smartphone > > > as gprs modem for linux or should I surrender? > > > > Is there just one interface? > > If so, looks like somebody tried to be clever and collapsed the control > > and the data interfaces of the acm specification. The ACM driver can be > > hacked to support that. > > That is, if the ACM command set actually works, otherwise it's a job for > usb-serial. > > > Can you confirm that there's just one interface and no extra descriptors? > > (lsusb -v) > > > > Regards > > Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP: unable to use I-MATE SP3 as USB (HTC) gprs modem
bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 3 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass255 Vendor Specific Subclass bInterfaceProtocol255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 which is, for what I understand (not to mutch to say the truth) really different. Obviously I will be happy to make all the test you will ask me. Luigi Genoni On Thursday 01 September 2005 19:32, Vojtech Pavlik wrote: On Thu, Sep 01, 2005 at 07:22:04PM +0200, Oliver Neukum wrote: I should use as an USB gprs modem. Since it is possible to configure it to be a (HTC) modem, using it's menu, when I enable it to act as a modem on the usb port the content of /proc/bus/usb/devices who refers to the phone changes to: I T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 37 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0bb4 ProdID=00cf Rev= 0.90 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=02(comm.) Sub=ff Prot=ff Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=86(I) Atr=03(Int.) MxPS= 16 Ivl=80ms The hotplug does not work anymore using the ipaq driver (as I exspected), and the device is not attacched to ttyUSB0. I read Cls=02(comm.). I suppose there should be a way to use something like cdc-acm driver. Unfortunatelly this driver does not seem to like my phone. All I get is a sad: usb 1-1: new full speed USB device using uhci_hcd and address 39 Is there a way to solve this problem and to use I-mate SP3 smartphone as gprs modem for linux or should I surrender? Is there just one interface? If so, looks like somebody tried to be clever and collapsed the control and the data interfaces of the acm specification. The ACM driver can be hacked to support that. That is, if the ACM command set actually works, otherwise it's a job for usb-serial. Can you confirm that there's just one interface and no extra descriptors? (lsusb -v) Regards Oliver - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is it possible to control C.O.P
HI, there is a way that the kernel could cope with CPU Overheating Protection? I am usng a Tyan MPX with Dual AthlonMP, but COP is configured to shutdown the system toot early, when the temparature is still low. lm_sensors 2.9.0 didn't help Thanx in advance Luigi Genoni - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Is it possible to control C.O.P
HI, there is a way that the kernel could cope with CPU Overheating Protection? I am usng a Tyan MPX with Dual AthlonMP, but COP is configured to shutdown the system toot early, when the temparature is still low. lm_sensors 2.9.0 didn't help Thanx in advance Luigi Genoni - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
On Sun, 1 Jul 2001, Justin Guyett wrote: > > Problem: I don't like company policy > Solution: Deal or get another job Not so easy in every country. For example in Italy the law called stauto dei lavoratori forbits workers to change so easily. > > > Peon: Help! I installed linux at work and got fired! > Oracle: You made a bad choice. > Not so easy for a company, at less in Italy. In fact the statuto dei lavoratori forbits a company to fire everyone for this kind of reasons. Also companies are forbitten to use any audio-visive way to monitor workers activities. The point is that your discussion does apply just to USA, at less for the terms you are using. Problems out of USA are different. I can install linux as i want, where i want, on sparc, on alpha, on ppc, to do all I want, but then M$ pre-sales have a good time to clean managers head, and to make managers belive M$ is the just one way to go. And managers and politician have power in companies, never technicians. If I would be regularly employed, (i do prefer my freedom), i could never be fired, of course, but anyway none would listen to me proposing linux, just because i am a technician. Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Uncle Sam Wants YOU!
On Sun, 1 Jul 2001, Justin Guyett wrote: Problem: I don't like company policy Solution: Deal or get another job Not so easy in every country. For example in Italy the law called stauto dei lavoratori forbits workers to change so easily. Peon: Help! I installed linux at work and got fired! Oracle: You made a bad choice. Not so easy for a company, at less in Italy. In fact the statuto dei lavoratori forbits a company to fire everyone for this kind of reasons. Also companies are forbitten to use any audio-visive way to monitor workers activities. The point is that your discussion does apply just to USA, at less for the terms you are using. Problems out of USA are different. I can install linux as i want, where i want, on sparc, on alpha, on ppc, to do all I want, but then M$ pre-sales have a good time to clean managers head, and to make managers belive M$ is the just one way to go. And managers and politician have power in companies, never technicians. If I would be regularly employed, (i do prefer my freedom), i could never be fired, of course, but anyway none would listen to me proposing linux, just because i am a technician. Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announcing Journaled File System (JFS) release 1.0.0 available
On Thu, 28 Jun 2001, james rich wrote: > On Fri, 29 Jun 2001, Luigi Genoni wrote: > > > On Fri, 29 Jun 2001, Yaacov Akiba Slama wrote: > > > > > So it seems that even if JFS is less complete than XFS (no ACL, quotas > > > for instance), and even if it is less robust (I don't know if it is, I > > It is not less complete nor less robust, it's a different technology and a > > totally different approach. > > Remember XFS was designed thinking to a kind of HW totally different from > > PC, and so was for jfs. But somehow JFS is a better choice if you > > do not have the last fastest CPU, and the last fastest scsi disk. > > This is simply not true. I run xfs on three systems - none of which have > anything close to the latest cpu. Each system runs faster after > installing xfs. Since linux-kernel is not the place for advocacy I > suggest a comparison be for your particular setup to determine which is > best for you. Please, I was not making any advocacy. I was saying that there are two different approach, and incidentally refered my own experience. Then, telling about jfs to be light, I was not saying XFS is slow! probably my english was not good enought to express my thought. Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announcing Journaled File System (JFS) release 1.0.0 available
On Fri, 29 Jun 2001, Yaacov Akiba Slama wrote: > Hi, > From what I understand from Linus's mail to lkml, there is a difference > between JFS and XFS: > JFS doesn't require any modifications to existing code, its only an > addition. > XFS on the contrary is far more intrusive. > So it seems that even if JFS is less complete than XFS (no ACL, quotas > for instance), and even if it is less robust (I don't know if it is, I It is not less complete nor less robust, it's a different technology and a totally different approach. Remember XFS was designed thinking to a kind of HW totally different from PC, and so was for jfs. But somehow JFS is a better choice if you do not have the last fastest CPU, and the last fastest scsi disk. > only used so far XFS and ext3 -with success), its inclusion in current > kernel is a lot easier and I don't see any (technical) reason for not > including it. I hope it will happen as soon. ReiserFS is a good FS, probably is the best journaled FS you could find out here, but how many memories with the old dear jfs! And I have some pentium classic for non critical use that would be so happy with it. > I don't think ext3 will have difficulties to be included in the kernel > because a) the guys working on it are lk veterans and b) Redhat (VA > also) is already including it in its kernels (rawhide AND 7.1 update). agree. > So I only hope that the smart guys at SGI find a way to prepare the > patches the way Linus loves because now the file > "patch-2.4.5-xfs-1.0.1-core" (which contains the modifs to the kernel > and not the new files) is about 174090 bytes which is a lot. mmm. I doubt it will be easy. I should check better, but i think it requires eavy changes to VFS. oh, by the way. On a 8 processor origin 2000, with a not so eavy I/O, I usually see 1 processor totally used just for journaling. (different HW, different Unix ) Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announcing Journaled File System (JFS) release 1.0.0 available
On Fri, 29 Jun 2001, Yaacov Akiba Slama wrote: Hi, From what I understand from Linus's mail to lkml, there is a difference between JFS and XFS: JFS doesn't require any modifications to existing code, its only an addition. XFS on the contrary is far more intrusive. So it seems that even if JFS is less complete than XFS (no ACL, quotas for instance), and even if it is less robust (I don't know if it is, I It is not less complete nor less robust, it's a different technology and a totally different approach. Remember XFS was designed thinking to a kind of HW totally different from PC, and so was for jfs. But somehow JFS is a better choice if you do not have the last fastest CPU, and the last fastest scsi disk. only used so far XFS and ext3 -with success), its inclusion in current kernel is a lot easier and I don't see any (technical) reason for not including it. I hope it will happen as soon. ReiserFS is a good FS, probably is the best journaled FS you could find out here, but how many memories with the old dear jfs! And I have some pentium classic for non critical use that would be so happy with it. I don't think ext3 will have difficulties to be included in the kernel because a) the guys working on it are lk veterans and b) Redhat (VA also) is already including it in its kernels (rawhide AND 7.1 update). agree. So I only hope that the smart guys at SGI find a way to prepare the patches the way Linus loves because now the file patch-2.4.5-xfs-1.0.1-core (which contains the modifs to the kernel and not the new files) is about 174090 bytes which is a lot. mmm. I doubt it will be easy. I should check better, but i think it requires eavy changes to VFS. oh, by the way. On a 8 processor origin 2000, with a not so eavy I/O, I usually see 1 processor totally used just for journaling. (different HW, different Unix ) Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announcing Journaled File System (JFS) release 1.0.0 available
On Thu, 28 Jun 2001, james rich wrote: On Fri, 29 Jun 2001, Luigi Genoni wrote: On Fri, 29 Jun 2001, Yaacov Akiba Slama wrote: So it seems that even if JFS is less complete than XFS (no ACL, quotas for instance), and even if it is less robust (I don't know if it is, I It is not less complete nor less robust, it's a different technology and a totally different approach. Remember XFS was designed thinking to a kind of HW totally different from PC, and so was for jfs. But somehow JFS is a better choice if you do not have the last fastest CPU, and the last fastest scsi disk. This is simply not true. I run xfs on three systems - none of which have anything close to the latest cpu. Each system runs faster after installing xfs. Since linux-kernel is not the place for advocacy I suggest a comparison be for your particular setup to determine which is best for you. Please, I was not making any advocacy. I was saying that there are two different approach, and incidentally refered my own experience. Then, telling about jfs to be light, I was not saying XFS is slow! probably my english was not good enought to express my thought. Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: AMD thunderbird oops
On Wed, 27 Jun 2001 [EMAIL PROTECTED] wrote: > Well considering the other night the power supply went dead, I think that is part of >the problem. It is brand new, and I am being sent another one (free of course). I would have bet that power supply was erogating elettricity with a discontinous intensity. I saw that RAM stability is the first think to be affected (together with L2 cache stability) in those cases. > > I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd, >Sound card, video, modem, NIC, scsi card) but my last tyan was fine with that load it >may be a kt7a thing. > > Several people said that random (keyword here) oopses are more often a hardware >thing. I wonder if the kt7a is going to be able to perform fully loaded.. > > is anyone running one fully loaded? 4 ide drives, 2 floppy, (5 pci and 1 isa) or >6pci, agp, 512MEG+ RAM? yes, 1.300 Mhz 1 agp 4 pci 1 isa (I love my sound blaster 16 on ISA, could not live without) 3 disks 1 floppy 1 zip 1 dvd 5 fans 350 watt power supply. Luigi > Joe > > Dave Jones <[EMAIL PROTECTED]> wrote: > > On Tue, 26 Jun 2001, Alan Cox wrote: > > My current speculation is that the sdram setup on some of these boards can't > > actually take the full CPU spec caused by these hand tuned routines. There is > > some evidence to support that as several other boards only work with Athlon > > optimisation if you set the BIOS options to 'conservative' not 'optimised' > > Interesting, and plausable theory. It would be more interesting to see > register dumps of the memory timing registers on both good and bad > systems, to see if this is the case. > > Unfortunatly afair the register level specs of all the affected chipsets > are not available. > > regards, > > Dave. > > -- > | Dave Jones.http://www.suse.de/~davej > | SuSE Labs > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2 Filesystem permissions (bug)?
On Wed, 27 Jun 2001, Kenneth Johansson wrote: > Interesting but I wonder how much this helps someone that not already know what it >is. Should not the ls manual also contain something that explains the meaning instead >of just the mapping from bits to symbol. > > Do linux even support the sticky bit (t) I can't see a reason to use it, why would I >want the file to be stored in the swap ?? > ?? if i have a sticky bit on a directory where every user has permission to write, and i write a file, that i will be the only one able to modify/delete my file. If there is no sticky bit on the directory, then every one is able to manipulate my file. How is this related to swap? usually the sticky bit is used for /tmp /var/tmp, where it has to be used for security reasons. Maybe you are making confusion because some other Unix use the /tmp partition with a special FS to use it also as a swap area (Slowlaris for expample, the old, old, old HP-UX pre 7.X versions and so on), and of course /tmp has the sticky be setted. If i am wrong with my supposition, excuse me. Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2 Filesystem permissions (bug)?
On Wed, 27 Jun 2001, Kenneth Johansson wrote: Interesting but I wonder how much this helps someone that not already know what it is. Should not the ls manual also contain something that explains the meaning instead of just the mapping from bits to symbol. Do linux even support the sticky bit (t) I can't see a reason to use it, why would I want the file to be stored in the swap ?? ?? if i have a sticky bit on a directory where every user has permission to write, and i write a file, that i will be the only one able to modify/delete my file. If there is no sticky bit on the directory, then every one is able to manipulate my file. How is this related to swap? usually the sticky bit is used for /tmp /var/tmp, where it has to be used for security reasons. Maybe you are making confusion because some other Unix use the /tmp partition with a special FS to use it also as a swap area (Slowlaris for expample, the old, old, old HP-UX pre 7.X versions and so on), and of course /tmp has the sticky be setted. If i am wrong with my supposition, excuse me. Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: AMD thunderbird oops
On Wed, 27 Jun 2001 [EMAIL PROTECTED] wrote: Well considering the other night the power supply went dead, I think that is part of the problem. It is brand new, and I am being sent another one (free of course). I would have bet that power supply was erogating elettricity with a discontinous intensity. I saw that RAM stability is the first think to be affected (together with L2 cache stability) in those cases. I also had my mb loaded at the time (scsi cd-rw, cdrom, internal zip, floppy, 1 hd, Sound card, video, modem, NIC, scsi card) but my last tyan was fine with that load it may be a kt7a thing. Several people said that random (keyword here) oopses are more often a hardware thing. I wonder if the kt7a is going to be able to perform fully loaded.. is anyone running one fully loaded? 4 ide drives, 2 floppy, (5 pci and 1 isa) or 6pci, agp, 512MEG+ RAM? yes, 1.300 Mhz 1 agp 4 pci 1 isa (I love my sound blaster 16 on ISA, could not live without) 3 disks 1 floppy 1 zip 1 dvd 5 fans 350 watt power supply. Luigi Joe Dave Jones [EMAIL PROTECTED] wrote: On Tue, 26 Jun 2001, Alan Cox wrote: My current speculation is that the sdram setup on some of these boards can't actually take the full CPU spec caused by these hand tuned routines. There is some evidence to support that as several other boards only work with Athlon optimisation if you set the BIOS options to 'conservative' not 'optimised' Interesting, and plausable theory. It would be more interesting to see register dumps of the memory timing registers on both good and bad systems, to see if this is the case. Unfortunatly afair the register level specs of all the affected chipsets are not available. regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: When the FUD is all around (sniff).
On Tue, 26 Jun 2001, Jordan Crouse wrote: > On Tuesday 26 June 2001 06:34, Alan Cox mentioned: > > > > I suppose they received some pression from M$, but if people read of a > > > FUD from a M$ employed, then they can guess what is going on, if it is a > > > newspaper usually telling facts in a correct way... > > > > It is common for newspaper staff to be corrupt, same with magazine people. > > Sometimes because people generally believe in a cause and are not impartial > > (which I've seen both pro and anti Linux btw) and sometimes because > > advertising revenue is a good thing. > > >From reading the article, the author showed that he understood the open > source world fairly well (better than my grandmother), even taking a crack at > Microsoft at one point: > > "il servizio Hotmail di Microsoft, che gestisce la posta per oltre 12 milioni > di utenti Internet, non "gira", come si dice nel gergo tecnico, su > piattaforma Microsoft, ma su di un aggregato di pacchetti Open Source." > > "Hotmail, from Microsoft, doesn't run on a Microsoft platform but rather a > collection of Open Source packages." > > He also discussed Perl, Python and other projects at length. Basically, from > his writing, I think that he was more missinformed that actually pushing real > FUD. I'll bet when he investigated the story, somebody close to him > mentioned that Linus had the final say on what went into the kernel, and he > probably saw a few e-mails on Google from people with rejected patches, and > he assumed that there was something rotten going on. Those informations came from an article printed on Linux just 6 days before the one on "affari e Finanza", written by A frined of mine, Felice Mainolfi. Nothing wrong to take informations from another article, (it takes also the same words), the final use of those true informations is deprecable (to title after a page "and also Us will be open" about M$ open source policy). > And it probably doesn't > help that we are always fighting amongst ourselves over architecture, > implementation and the such. An uneducated person reading over the archives > would probably assume that Alan and Linus are ready to start hunting each > other down, and the articles they write would probably reflect this. probable. > Luigi Genoni - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD thunderbird oops
I went trought 8 Athlon, (latest 1300 Mhz 200Mhz FSB). Usually those stability problems are related to power supply (it should be at less 300 Watt). If the power supply does not give enought Ampere, and the energy is fluttuant, the Athlon cpu really suffers. I usually do a little overvolt of the vcore to 3.4, and this makes things more stable. For what i know, the Athlon optimizzation does stress the memory I/O at best, and does use the Athlon FSB with all its power. Using the pentiumII/III stuff, you loose this memory performance boost. If a little overvolt of the VCORE does not solve the things, (someone also does a little overvolt of the CPU core to 1.78) then check if your power supply if working well, and the signal strenght setting inside of your bios (should be 2). This is just my experience with Athlon processors. Luigi On Tue, 26 Jun 2001, Thomas Foerster wrote: > Hi, > > > as i've said before - i have the same problem too > > Me too > > > the memory is OK! - have run memtest86 for hours ... - no errors ... - > > heatsink - CPU@45°C - Case @ 25°C > > > after changing the kernel compile to PentiumII (nearly) everything worked > > fine > > I HAD a Asus K7M with a 650 MHz Athlon, 256 MB RAM (Infineon, Ram is OK). > Using 2.4.2 AND 2.4.4 didn't work. > Whenever i started KDE2, the crashes startet, even oopses in ext2-code appeared. > > The strange thing is : If i startet KDE2 as root, the crashes didn't happen! > > I don't know why, my distribution is RedHat 7.1 > > Now i have a Epox 8kta3+ with an 1,333 MHz Athlon, FSB266, 256 MB RAM (Infineon) > and the crashes still appear. > > Changing the Kernel from Athlon to Pentium-II/III makes the system stable again. > > Thomas > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
When the FUD is all around (sniff).
HI, a couple of weeks ago, in Italy, on the review Affari e Finanza, that comes with the newspaper "La Repubblica" ([EMAIL PROTECTED]) one of the biggest newspapaer in Italy, there was an article with this title: "Also Linux goes in Tribunal" (http://www.repubblica.it/supplementi/af/.snapshot/nightly.1/2001/06/18/primopiano/010nuatta.html) In this article it's said that open source and Free Software (those terms are used as synonimous in the article, with a lot of confusion), are a good things, (also if there are bad episodes like Gracenote changing its licenze despite of the developers, from Open Source [GPL??] to a commercial one), but actually kernel developers are tired of Linux and so, while Microsoft could soon put an end to its trouble with american joustice "The big enemy Torvalds could be called to tribunal because of his big power and monopolistic tendencies". Please note, from the Title and the tone any reader would understand that Some of big kernel hackers are going to sue Linus. (Alan, some of my readers thinked to you). In 3 days i recevived about 50 letters from Linux readers (the review i write for), asking if it were true. I wrote them, of course, not, and many of them wrote to "la Repubblica", asking the reason of this FUD. As an answert they received "read some kernel mail list archive". simply they took some letter from some troll proposing a fork, and so... The funny thing is that on the next page there was another article, with the tittle "And als Us will be a little open". The president of MicroSoft Italia was telling that M$ is really open source because of (nahh, i cannot even write those lies). After a couple of mail to "la Repubblica" i received as an answert that they would have soon published a correction of the article. I am reading now the "revision" "It is true that kernel hackers dislike Linus attitute, but in tribunal they took Gracenote" Again, I guess that Gracenote developers have troubles with Gracenote commercial choice, but how is this related to Linus, or to any of the people writing on this mail list? If, let's say, some oracle developers working of the db version for winNT go to the chart with Oracle, then a newspaper could ever write a title like: "And Bill Gates goes to tribunal"? Obviously, no. here is a case when the fUD comes, not from M$, but from a newspaper that should write facts. I suppose they received some pression from M$, but if people read of a FUD from a M$ employed, then they can guess what is going on, if it is a newspaper usually telling facts in a correct way... The situation is going to be sad Luigi Genoni - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
When the FUD is all around (sniff).
HI, a couple of weeks ago, in Italy, on the review Affari e Finanza, that comes with the newspaper La Repubblica ([EMAIL PROTECTED]) one of the biggest newspapaer in Italy, there was an article with this title: Also Linux goes in Tribunal (http://www.repubblica.it/supplementi/af/.snapshot/nightly.1/2001/06/18/primopiano/010nuatta.html) In this article it's said that open source and Free Software (those terms are used as synonimous in the article, with a lot of confusion), are a good things, (also if there are bad episodes like Gracenote changing its licenze despite of the developers, from Open Source [GPL??] to a commercial one), but actually kernel developers are tired of Linux and so, while Microsoft could soon put an end to its trouble with american joustice The big enemy Torvalds could be called to tribunal because of his big power and monopolistic tendencies. Please note, from the Title and the tone any reader would understand that Some of big kernel hackers are going to sue Linus. (Alan, some of my readers thinked to you). In 3 days i recevived about 50 letters from LinuxC readers (the review i write for), asking if it were true. I wrote them, of course, not, and many of them wrote to la Repubblica, asking the reason of this FUD. As an answert they received read some kernel mail list archive. simply they took some letter from some troll proposing a fork, and so... The funny thing is that on the next page there was another article, with the tittle And als Us will be a little open. The president of MicroSoft Italia was telling that M$ is really open source because of (nahh, i cannot even write those lies). After a couple of mail to la Repubblica i received as an answert that they would have soon published a correction of the article. I am reading now the revision It is true that kernel hackers dislike Linus attitute, but in tribunal they took Gracenote Again, I guess that Gracenote developers have troubles with Gracenote commercial choice, but how is this related to Linus, or to any of the people writing on this mail list? If, let's say, some oracle developers working of the db version for winNT go to the chart with Oracle, then a newspaper could ever write a title like: And Bill Gates goes to tribunal? Obviously, no. here is a case when the fUD comes, not from M$, but from a newspaper that should write facts. I suppose they received some pression from M$, but if people read of a FUD from a M$ employed, then they can guess what is going on, if it is a newspaper usually telling facts in a correct way... The situation is going to be sad Luigi Genoni - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD thunderbird oops
I went trought 8 Athlon, (latest 1300 Mhz 200Mhz FSB). Usually those stability problems are related to power supply (it should be at less 300 Watt). If the power supply does not give enought Ampere, and the energy is fluttuant, the Athlon cpu really suffers. I usually do a little overvolt of the vcore to 3.4, and this makes things more stable. For what i know, the Athlon optimizzation does stress the memory I/O at best, and does use the Athlon FSB with all its power. Using the pentiumII/III stuff, you loose this memory performance boost. If a little overvolt of the VCORE does not solve the things, (someone also does a little overvolt of the CPU core to 1.78) then check if your power supply if working well, and the signal strenght setting inside of your bios (should be 2). This is just my experience with Athlon processors. Luigi On Tue, 26 Jun 2001, Thomas Foerster wrote: Hi, as i've said before - i have the same problem too Me too the memory is OK! - have run memtest86 for hours ... - no errors ... - heatsink - CPU@45°C - Case @ 25°C after changing the kernel compile to PentiumII (nearly) everything worked fine I HAD a Asus K7M with a 650 MHz Athlon, 256 MB RAM (Infineon, Ram is OK). Using 2.4.2 AND 2.4.4 didn't work. Whenever i started KDE2, the crashes startet, even oopses in ext2-code appeared. The strange thing is : If i startet KDE2 as root, the crashes didn't happen! I don't know why, my distribution is RedHat 7.1 Now i have a Epox 8kta3+ with an 1,333 MHz Athlon, FSB266, 256 MB RAM (Infineon) and the crashes still appear. Changing the Kernel from Athlon to Pentium-II/III makes the system stable again. Thomas - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: When the FUD is all around (sniff).
On Tue, 26 Jun 2001, Jordan Crouse wrote: On Tuesday 26 June 2001 06:34, Alan Cox mentioned: I suppose they received some pression from M$, but if people read of a FUD from a M$ employed, then they can guess what is going on, if it is a newspaper usually telling facts in a correct way... It is common for newspaper staff to be corrupt, same with magazine people. Sometimes because people generally believe in a cause and are not impartial (which I've seen both pro and anti Linux btw) and sometimes because advertising revenue is a good thing. From reading the article, the author showed that he understood the open source world fairly well (better than my grandmother), even taking a crack at Microsoft at one point: il servizio Hotmail di Microsoft, che gestisce la posta per oltre 12 milioni di utenti Internet, non gira, come si dice nel gergo tecnico, su piattaforma Microsoft, ma su di un aggregato di pacchetti Open Source. Hotmail, from Microsoft, doesn't run on a Microsoft platform but rather a collection of Open Source packages. He also discussed Perl, Python and other projects at length. Basically, from his writing, I think that he was more missinformed that actually pushing real FUD. I'll bet when he investigated the story, somebody close to him mentioned that Linus had the final say on what went into the kernel, and he probably saw a few e-mails on Google from people with rejected patches, and he assumed that there was something rotten going on. Those informations came from an article printed on LinuxC just 6 days before the one on affari e Finanza, written by A frined of mine, Felice Mainolfi. Nothing wrong to take informations from another article, (it takes also the same words), the final use of those true informations is deprecable (to title after a page and also Us will be open about M$ open source policy). And it probably doesn't help that we are always fighting amongst ourselves over architecture, implementation and the such. An uneducated person reading over the archives would probably assume that Alan and Linus are ready to start hunting each other down, and the articles they write would probably reflect this. probable. Luigi Genoni - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2 Filesystem permissions (bug)?
Those are normal unix permissions, and you can use them on every kind of Unix FS, (at less i saw them on jfs, hfs, vxfs, xfs, reiserfs, ext2, ufs). S is suid and sgid without execution bit. T is stiky bit without any execution bit. (I hope my english is correct) Luigi On Mon, 25 Jun 2001, Shawn Starr wrote: > > Is this a bug or something thats undocumented somewhere? > > dT > and > drwSrwSrwT > > are these special bits? I'm not aware of +S and +T > > Shawn. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: AMD thunderbird oops
Have you considered to change your dimm at all? If they are bugged they should be under warranty. Luigi On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote: > Thanks, > I have a heat sink and it is huge about 2 inches, plus fan. Plus another 4" fan >in the case. (real nice case). > > I think it is the memory, as yesterday my gcc was bombing with 'internel >compiler error', which is usually a good mem tester. So I started setting mem=64m >and things worked better and the install went all the way through. I think I need to >slow my drams down a bit or add some delay in the bios settings. > >The oops says something like 'kernel null pointer at address 0x00'. How do I >'catch' the output of an oops when the filesystem goes and I get ext2fs errors and am >forced to reboot and manually run e2fsck? > > Lastly with the mem=64M or mem=128M when I do a make dep, I get an error message >that says Error 'missing seperator'. What does that mean? It stops in the >drivers/net dir when I get this message? > > Thanks > Joe > > Alan Cox <[EMAIL PROTECTED]> wrote: > > > I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) >processor / 512Meg of RAM, and an Asus kt7a motherboard. > > > It is oppsing left and right. I recompiled the kernel with Athelon as the CPU but >keep getting these oopses.. > > > > I also get these same problems while trying to install RH 7.1 > > > > Anyone know is this a supported processor / MB and has anyone had these problems? > > Random oopses normally indicate faulty board cpu or ram (and the fault may > even just be overheating or dimms not in the sockets cleanly). I doubt its > the board design or model that is the problem, you probably jut have a faulty > component somewhere if its oopsing randomly even during installs and stuff > > memtest86, and heatsink compound may be your best friends > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The Joy of Forking
On Mon, 25 Jun 2001, Rick Hohensee wrote: > > > > > rtlinux by default > > > no SMP > > > SMP doesn't scale. If this fork comes, the smart maintainer > > > will take the non-SMP fork. > > > > Depends on platform and bus. From reports, it seems to scale just fine on > > non-intel systems. > > Big expensive systems. Non-desktop systems. Non-end-user systems. And > clustering will eat its lunch eventually anyway. biprocessor are starting to be also end-user systems. About clustering, actually it is very usefull, the most of times is a cost effective solution to avoid to buy an unusefull 64 processor system, but basically, in front of the computational needs you could have, it can be used for different things in front of SMP systems. It happens to me to have a cluster composed by 4 dual processor systems, because i need a cluster, and i need the single nodes to be dual processor. With an 8 nodes cluster composed by uniprocessor I wuld give a mutch less efficient service to my users computational needs. > > > > > > x86 only (and similar, e.g. Crusoe) > > > > Again, Linux is the only system that CAN run on anything from PDA thorough > > supercomputer clusters. > > > > NetBSD claims 24 platforms. Forths run on everything you've never heard of > below a PDA. yes, but to run on every kind of processor is a BIG strenght for Linux. I don't think it is necessary to explain why. > > > > > mimimal VM cacheing > > > So you can red-switch the box without journalling with > > > reasonable damage, which for an end-user is a file or two. > > > Having done a lot of very wrong things with Linux, I'm > > > impressed that ext2 doesn't self-destruct under abuse. > > > > Not if you want some speed out of it. > > Again, throughput is a server thing. not true. Desktops have to be very responsive to users. If a users run an application (read click on icon application), let's say mozilla, and it will not start in about one second, he will feel the desktop is slow. You need the best throughtput and speed efficiency with disks on desktops. Desktop users will never pay atention if the system is efficient, but if it is fast in a way they can feel fastness. That means, fast to bring up an application the same second the command is runned. > > > > > > > > >What about GUI's, and "desktops" and such? They're nice. They are > > >secondary, however. The free unix world doesn't often enough make the > > >point that GUI's are much more important when the underlying OS sucks, > > >which it doesn't in Linux. > > > > If you only use a compute/disk server. Otherwise you are saying "no desktop > > publishing, word processing, or image analysis". > > > > Are you still using DOS only? > > > > I haven't started X in about a year. I read pdf's as jpegs, I have Xaos > running in SVGA, and so on. Not-unix != Dos . I don't dislike X > particularly, but I live in what I ship, and for maintenance I can't keep > up with console, considering that I'm doing a bit more than just bundling > things up. ??? I do not understand the point. I would say that is not a point. > > > >In short, an open source OS for end-users should be very serious about > > >simplicity, and not just pay lip-service to it. There is evidence of the > > >value of this in the marketplace. What doesn't exist is an OS where > > >simplicity is systemic. This is why end-user issues pertain to the kernel > > >at all. This is how open source should be. Simple, or at least clear, > > >through and through. Linux has lost a lot of simplicity since I got into > > >it in '96, and that is a loss. > > > > For the most part, the base Linux appears simple to the user. There are no > > Which distro appears simple to the user? I write for a review in Italy, we usually include distro's cd every month. I have readers feed back. You would never say. Newbies, who never saw a linux before, mandrake, red hat, newbies coming from some Unix experience as users, slackware, someone debian. They write back to the redation, telling us how fonderfully easy it was, and that they could not figure it was so easy. > > > > desktops to worry about. Desktops are an application, not part of Linux at all > > It is becoming better for the administrator. As better desktops are developed, > > it is becoming for "user friendly". > > Thanks for replying civilly to something you clearly don't agree with. > Basically, your reply says to me that kernel hackers can't imagine unix as > an end-user OS. Your points are all "that will suck as a server". Of > course. A solid true multi-user open source operating system is a solid > base for a variety of things. I would say that users needs top feel the system to be fast. That is true for desktop even more than for servers. anyway, many of changes someone push to bring linux on the desktop will make it slower, and that way users will never use it. No desktop user will way 2 minutes to bring up an office suite. Linux has a
Re: AMD thunderbird oops
Works well for me, Athlon 1300 (200Mhz FSB). Did you check your ram? Luigi On Sun, 24 Jun 2001 [EMAIL PROTECTED] wrote: > I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) >processor / 512Meg of RAM, and an Asus kt7a motherboard. > > It is oppsing left and right. I recompiled the kernel with Athelon as the CPU but >keep getting these oopses.. > > I also get these same problems while trying to install RH 7.1 > > Anyone know is this a supported processor / MB and has anyone had these problems? > > Joe please cc me as I am not on this list. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Some experience of linux on a Laptop
On Mon, 25 Jun 2001, Dieter Nützel wrote: > > > > 8: A way to change kernel without rebooting. I have no diskdrive or > > > cddrive in my laptop so I often do drastic things when I install a new > > > distribution. > > > > Thats actually an incredibly hard problem to solve. The only people who do > > this level of stuff are some of the telephony folks, and the expensive > > tandem non-stop boxes. > > SUN Enterprise I have an E1, and it cannot do it, i just can make a bring up of domains, and then boot different OS version for each domain. (I had also a little linux domain :) > IBM S/390 (zSeries) don't know about this. I was prone to think to a domain login as for Origin and SUN E1 Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Some experience of linux on a Laptop
On Mon, 25 Jun 2001, Dieter Nützel wrote: 8: A way to change kernel without rebooting. I have no diskdrive or cddrive in my laptop so I often do drastic things when I install a new distribution. Thats actually an incredibly hard problem to solve. The only people who do this level of stuff are some of the telephony folks, and the expensive tandem non-stop boxes. SUN Enterprise I have an E1, and it cannot do it, i just can make a bring up of domains, and then boot different OS version for each domain. (I had also a little linux domain :) IBM S/390 (zSeries) don't know about this. I was prone to think to a domain login as for Origin and SUN E1 Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD thunderbird oops
Works well for me, Athlon 1300 (200Mhz FSB). Did you check your ram? Luigi On Sun, 24 Jun 2001 [EMAIL PROTECTED] wrote: I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) processor / 512Meg of RAM, and an Asus kt7a motherboard. It is oppsing left and right. I recompiled the kernel with Athelon as the CPU but keep getting these oopses.. I also get these same problems while trying to install RH 7.1 Anyone know is this a supported processor / MB and has anyone had these problems? Joe please cc me as I am not on this list. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The Joy of Forking
On Mon, 25 Jun 2001, Rick Hohensee wrote: rtlinux by default no SMP SMP doesn't scale. If this fork comes, the smart maintainer will take the non-SMP fork. Depends on platform and bus. From reports, it seems to scale just fine on non-intel systems. Big expensive systems. Non-desktop systems. Non-end-user systems. And clustering will eat its lunch eventually anyway. biprocessor are starting to be also end-user systems. About clustering, actually it is very usefull, the most of times is a cost effective solution to avoid to buy an unusefull 64 processor system, but basically, in front of the computational needs you could have, it can be used for different things in front of SMP systems. It happens to me to have a cluster composed by 4 dual processor systems, because i need a cluster, and i need the single nodes to be dual processor. With an 8 nodes cluster composed by uniprocessor I wuld give a mutch less efficient service to my users computational needs. x86 only (and similar, e.g. Crusoe) Again, Linux is the only system that CAN run on anything from PDA thorough supercomputer clusters. NetBSD claims 24 platforms. Forths run on everything you've never heard of below a PDA. yes, but to run on every kind of processor is a BIG strenght for Linux. I don't think it is necessary to explain why. mimimal VM cacheing So you can red-switch the box without journalling with reasonable damage, which for an end-user is a file or two. Having done a lot of very wrong things with Linux, I'm impressed that ext2 doesn't self-destruct under abuse. Not if you want some speed out of it. Again, throughput is a server thing. not true. Desktops have to be very responsive to users. If a users run an application (read click on icon application), let's say mozilla, and it will not start in about one second, he will feel the desktop is slow. You need the best throughtput and speed efficiency with disks on desktops. Desktop users will never pay atention if the system is efficient, but if it is fast in a way they can feel fastness. That means, fast to bring up an application the same second the command is runned. What about GUI's, and desktops and such? They're nice. They are secondary, however. The free unix world doesn't often enough make the point that GUI's are much more important when the underlying OS sucks, which it doesn't in Linux. If you only use a compute/disk server. Otherwise you are saying no desktop publishing, word processing, or image analysis. Are you still using DOS only? I haven't started X in about a year. I read pdf's as jpegs, I have Xaos running in SVGA, and so on. Not-unix != Dos . I don't dislike X particularly, but I live in what I ship, and for maintenance I can't keep up with console, considering that I'm doing a bit more than just bundling things up. ??? I do not understand the point. I would say that is not a point. In short, an open source OS for end-users should be very serious about simplicity, and not just pay lip-service to it. There is evidence of the value of this in the marketplace. What doesn't exist is an OS where simplicity is systemic. This is why end-user issues pertain to the kernel at all. This is how open source should be. Simple, or at least clear, through and through. Linux has lost a lot of simplicity since I got into it in '96, and that is a loss. For the most part, the base Linux appears simple to the user. There are no Which distro appears simple to the user? I write for a review in Italy, we usually include distro's cd every month. I have readers feed back. You would never say. Newbies, who never saw a linux before, mandrake, red hat, newbies coming from some Unix experience as users, slackware, someone debian. They write back to the redation, telling us how fonderfully easy it was, and that they could not figure it was so easy. desktops to worry about. Desktops are an application, not part of Linux at all It is becoming better for the administrator. As better desktops are developed, it is becoming for user friendly. Thanks for replying civilly to something you clearly don't agree with. Basically, your reply says to me that kernel hackers can't imagine unix as an end-user OS. Your points are all that will suck as a server. Of course. A solid true multi-user open source operating system is a solid base for a variety of things. I would say that users needs top feel the system to be fast. That is true for desktop even more than for servers. anyway, many of changes someone push to bring linux on the desktop will make it slower, and that way users will never use it. No desktop user will way 2 minutes to bring up an office suite. Linux has a tradition it has to refer to, and inside of this tradition Linux can find the way also for the desktop. There is nothing wrong if you separe the OS from
Re: Re: AMD thunderbird oops
Have you considered to change your dimm at all? If they are bugged they should be under warranty. Luigi On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote: Thanks, I have a heat sink and it is huge about 2 inches, plus fan. Plus another 4 fan in the case. (real nice case). I think it is the memory, as yesterday my gcc was bombing with 'internel compiler error', which is usually a good mem tester. So I started setting mem=64m and things worked better and the install went all the way through. I think I need to slow my drams down a bit or add some delay in the bios settings. The oops says something like 'kernel null pointer at address 0x00'. How do I 'catch' the output of an oops when the filesystem goes and I get ext2fs errors and am forced to reboot and manually run e2fsck? Lastly with the mem=64M or mem=128M when I do a make dep, I get an error message that says Error 'missing seperator'. What does that mean? It stops in the drivers/net dir when I get this message? Thanks Joe Alan Cox [EMAIL PROTECTED] wrote: I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) processor / 512Meg of RAM, and an Asus kt7a motherboard. It is oppsing left and right. I recompiled the kernel with Athelon as the CPU but keep getting these oopses.. I also get these same problems while trying to install RH 7.1 Anyone know is this a supported processor / MB and has anyone had these problems? Random oopses normally indicate faulty board cpu or ram (and the fault may even just be overheating or dimms not in the sockets cleanly). I doubt its the board design or model that is the problem, you probably jut have a faulty component somewhere if its oopsing randomly even during installs and stuff memtest86, and heatsink compound may be your best friends - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2 Filesystem permissions (bug)?
Those are normal unix permissions, and you can use them on every kind of Unix FS, (at less i saw them on jfs, hfs, vxfs, xfs, reiserfs, ext2, ufs). S is suid and sgid without execution bit. T is stiky bit without any execution bit. (I hope my english is correct) Luigi On Mon, 25 Jun 2001, Shawn Starr wrote: Is this a bug or something thats undocumented somewhere? dT and drwSrwSrwT are these special bits? I'm not aware of +S and +T Shawn. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GCC3.0 Produce REALLY slower code!
On Sun, 24 Jun 2001, Rik van Riel wrote: > On Mon, 25 Jun 2001, Alexander V. Bilichenko wrote: > > > Some tests that I have recently check out. kernel compiled with > > 3.0 (2.4.5) function call: 100 iteration. 3% slower than > > 2.95. test example - hash table add/remove - 4% slower (compiled > > both with -O2 -march=i686). > > > Why have this version been released? > > It would be better to ask that to the GCC people, but I > suspect it was released because it was (almost) stable > and the only way to do the last small tweaks to the code > would be to have it tested in the field ? > Actually I think the just one very good reason to use gcc 3.0 is if you are programming using C++. It's a kind of paradise for C++ programmers. So I had to install it on my servers used by C++ programmers, they were so happy... To use C, it's better to avoid gcc 3.0, it's just slower. All bench i did, it's slower about 3/5% depending on the kind of code. It is faster just on some floating point with really small code, (I used optimizzations for athlon CPU). Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Some experience of linux on a Laptop
John Nilson wrote: > 2: Compile time optimization options in Make menuconfig I do not understand the point. > 3: Lilo/grub config in make menuconfig Unusefull and dangerous. > 4: make bzImage && make modules && make modules install && cp > arch/i386/boot/bzImage /boot/'uname -r' something inside make menuconfig To compile a kernel someone should be able to run correctly make. Don't you think so? Also my girlfriend, who never saw a Unix system before, after a couple days spended reading during free time some documentation and help files (4 hours in two days I think) has been able to compile and install a new kernel. > 6: Wouldn't it be easier for svgalib/framebuffer/GGI/X11 and others if the > graphiccard drivers where kernel modules? This is an old discussion. I hope it will never be. (just my own 2 cents). > 8: A way to change kernel without rebooting. I have no diskdrive or cddrive > in my laptop so I often do drastic things when I install a new distribution. Is it possible at all?? Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: The Joy of Forking
> > no SMP > > x86 only (and similar, e.g. Crusoe) > Is this a joke? I hope it is. Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
Yes, but i followed its development till now, and those file are still present, belive me, when i do compile latest versions. I am doing beta test of it when i have time, and i think i tried all versions from 2.7 times, sometimes sending bug reports. On Sun, 24 Jun 2001, Alan Cox wrote: > > The point was that Stimits says that on its Red Hat 7.1 he has no > > ldscripts directory, and so no files like elf_i386.x and so on. > > I was just surprised, since i know thay are all necessary to /usr/bin/ld > > to work. > > > two libc > > /lib/libc.so.6 and /lib/i686/libc.so.6, one is tripped and the other > > contains debug symbols. > > > Ok that I dont know. The dynamic linker has changed a fair bit over time and > I don't know enough about it to help > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: The Joy of Forking
no SMP x86 only (and similar, e.g. Crusoe) Is this a joke? I hope it is. Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Some experience of linux on a Laptop
John Nilson wrote: 2: Compile time optimization options in Make menuconfig I do not understand the point. 3: Lilo/grub config in make menuconfig Unusefull and dangerous. 4: make bzImage make modules make modules install cp arch/i386/boot/bzImage /boot/'uname -r' something inside make menuconfig To compile a kernel someone should be able to run correctly make. Don't you think so? Also my girlfriend, who never saw a Unix system before, after a couple days spended reading during free time some documentation and help files (4 hours in two days I think) has been able to compile and install a new kernel. 6: Wouldn't it be easier for svgalib/framebuffer/GGI/X11 and others if the graphiccard drivers where kernel modules? This is an old discussion. I hope it will never be. (just my own 2 cents). 8: A way to change kernel without rebooting. I have no diskdrive or cddrive in my laptop so I often do drastic things when I install a new distribution. Is it possible at all?? Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GCC3.0 Produce REALLY slower code!
On Sun, 24 Jun 2001, Rik van Riel wrote: On Mon, 25 Jun 2001, Alexander V. Bilichenko wrote: Some tests that I have recently check out. kernel compiled with 3.0 (2.4.5) function call: 100 iteration. 3% slower than 2.95. test example - hash table add/remove - 4% slower (compiled both with -O2 -march=i686). Why have this version been released? It would be better to ask that to the GCC people, but I suspect it was released because it was (almost) stable and the only way to do the last small tweaks to the code would be to have it tested in the field ? Actually I think the just one very good reason to use gcc 3.0 is if you are programming using C++. It's a kind of paradise for C++ programmers. So I had to install it on my servers used by C++ programmers, they were so happy... To use C, it's better to avoid gcc 3.0, it's just slower. All bench i did, it's slower about 3/5% depending on the kind of code. It is faster just on some floating point with really small code, (I used optimizzations for athlon CPU). Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
Yes, but i followed its development till now, and those file are still present, belive me, when i do compile latest versions. I am doing beta test of it when i have time, and i think i tried all versions from 2.7 times, sometimes sending bug reports. On Sun, 24 Jun 2001, Alan Cox wrote: The point was that Stimits says that on its Red Hat 7.1 he has no ldscripts directory, and so no files like elf_i386.x and so on. I was just surprised, since i know thay are all necessary to /usr/bin/ld to work. two libc /lib/libc.so.6 and /lib/i686/libc.so.6, one is tripped and the other contains debug symbols. Ok that I dont know. The dynamic linker has changed a fair bit over time and I don't know enough about it to help - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
The point was that Stimits says that on its Red Hat 7.1 he has no ldscripts directory, and so no files like elf_i386.x and so on. I was just surprised, since i know thay are all necessary to /usr/bin/ld to work. Then he was alo wondering why he has two libc /lib/libc.so.6 and /lib/i686/libc.so.6, one is tripped and the other contains debug symbols. I can figure why, but he adfirms that /lib/i686 is not included in /etc/ld.so.conf, there is no preload configured, but this is the directory used by the loader to find the libc to load. I have to red hat installed, so i was trying to figure out how things are working on new releases (my last red hat was 6.2 when i was working at red hat Italy). Bests Luigi On Sun, 24 Jun 2001, Alan Cox wrote: > > glad to know this, i do wonder how does /usr/bin/ld work for red hat. > > to my old mentality this seems red hat is going out of any resonable > > standard. > > It works like /usr/bin/ld on any other platform I know of > > > if the same libc stripped would not run library, and they HAVE to mantein > > a libc.so.6 linside of /lib, otherway this would be too mutch against > > a resonable standard. > > bash-2.04$ ls -l /lib/libc.so.6 > lrwxrwxrwx1 root root 13 May 14 16:46 /lib/libc.so.6 -> >libc-2.2.2.so > > I don't follow the discussion here. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
On Sat, 23 Jun 2001, D. Stimits wrote:
> > > The RH 7.1 comes with:
> > > :~# ld --version
> > > GNU ld 2.10.91
> > > Copyright 2001 Free Software Foundation, Inc.
> > > This program is free software; you may redistribute it under the terms
> > > of
> > > the GNU General Public License. This program has absolutely no
> > > warranty.
> > > Supported emulations:
> > >elf_i386
> > >i386linux
> > >elf_i386_glibc21
> > Ok, this is the linker for compilation time, it
> > is not related to the loader for shared libraries. You can even remove
> > /usr/bin/ld, and the system will run anyway binaries, but you will not be
> > able to link compiled objects.
> > try a find for the directory ldscripts or for those files,
>
> It appears that Redhat has eliminated much of this. If I run updatedb,
> then locate, I find there is no instance of "ldscripts". Nor is there an
> instance of "i386linux" or "i386coff" that can be seen by locate. So I
> made it a wider locate, and tried for any instance of just "86linux" or
> "86coff", these also do not exist. Apparently Redhat has completely
> changed linking (looking at a backup of an older RH 6.2, these do exist,
> so I suspect the change at around 7.0).
glad to know this, i do wonder how does /usr/bin/ld work for red hat.
to my old mentality this seems red hat is going out of any resonable
standard.
>
> > >
> > > There is *no* /usr/i386-xxx except for:
> > > /usr/i386-glibc21-linux/
> > name could be different, just could you e-mail the output for
> > the command tree inside of /usr?
>
> The entire tree would be quite large. Are you looking only for
> directories (this would be a much smaller listing)? It might even
> challenge the maximum size an ISP allows before filtering it:
> 16632 directories, 258120 files
It is my own curiosity. yes if you could send me the direcotory tree of
your /usr. Just to see. Actually i know none using red hat 7.X to whom i
could ask to check, they are all slackware addicted.
>
>
> No ldscripts on the system. Through locate and awk, I can guarantee
> there is also only one ld on the system, /usr/bin/ld. It sounds like
> they did compile all other binaries from scratch, passing /lib/i686/
> explicitly.
mmm!
Again I am confused. how can the linker work?
>
>
> As far as this particular problem goes, I am trying to help the author
> of some general boot disk utilities find a good way to automatically
> detect (through perl scripts) the correct libc configuration. Telling
> users of the software that Redhat 7.1 is not supported is not an option,
> regardless of why it is a problem. What it will probably end up becoming
> is a mechanical script to test for the existence of /lib/{uname -a}/,
> and if it exists, adding it to the boot disk ld.so.conf
I would not be so scared, if you set a LD_PRELOAD_LIBRARY to
/lib/libc.so.6, you willse any binary will run anyway, because it would be
too mutch
if the same libc stripped would not run library, and they HAVE to mantein
a libc.so.6 linside of /lib, otherway this would be too mutch against
a resonable standard.
I would be happy if some guy from red hat could explain what is going on.
Luigi Genoni
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
On Fri, 22 Jun 2001, D. Stimits wrote:
> Luigi Genoni wrote:
> >
> > Again i am confused.
> >
> > /usr/bin/ld is linker at compilation time, at it works how i told in
> > second part
> > of my mail, (just try to compile it, it comes with binutils,
> > ftp.kernel.org/pub/linux/devel/binutils).
> >
> > /lib/d-2.2.X.so is what you are talking about.
> > So should i think os an hack to ld-2.2.3.so ??
>
> The RH 7.1 comes with:
> :~# ld --version
> GNU ld 2.10.91
> Copyright 2001 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms
> of
> the GNU General Public License. This program has absolutely no
> warranty.
> Supported emulations:
>elf_i386
>i386linux
>elf_i386_glibc21
Ok, this is the linker for compilation time, it
is not related to the loader for shared libraries. You can even remove
/usr/bin/ld, and the system will run anyway binaries, but you will not be
able to link compiled objects.
try a find for the directory ldscripts or for those files,
elf_i386.xelf_i386.xs i386coff.xn i386linux.xbn
elf_i386.xbn elf_i386.xu i386coff.xr i386linux.xn
elf_i386.xn i386coff.xi386coff.xu i386linux.xr
elf_i386.xr i386coff.xbn i386linux.x i386linux.xu
you could not find the *coff* ones
those are the configuration file (unproper definition, i ask
excuse for my english), for /usr/bin/ld you are running
doing ld --version.
>
> The glibc rpm is version 2.2.2-10.
>
> >
> > to see how it works loock at /usr/bin/ldd, it's an interesting script.
> >
> > I can understand why old glibc 2.1 is not isered in the directories
> > where ldconfig has to loock to create its db for loader, but there should
> > be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
> > subdirectories)
> > for glibc 2.2, since it is necessary at compilation
> > time.
>
> There is *no* /usr/i386-xxx except for:
> /usr/i386-glibc21-linux/
name could be different, just could you e-mail the output for
the command tree inside of /usr?
>
> No glibc22 version exists.
>
> > This do not change the problem which is related to /lib/ld-2.2.X.so.
> > doing a strings /lib/ld-2.XXX
> > you will find also
> >
> > info[19]->d_un.d_val == sizeof (Elf32_Rel)
> > info[20]->d_un.d_val == 17
> > /lib/
> > /usr/lib/
> > {ORIGIN}
> > {PLATFORM}
> > expand_dynamic_string_token
> > dl-load.c
>
> "i686" is visible on a line by itself, but so are i386, i486, and i586.
this is another thing...
> The full path of /lib/i686/ is not mentioned anywhere. So it looks like
> strings of /lib/ld-2* does not offer any hints as to how the i686
> subdirectory is being chosen without it being specified anywhere else. I
> think this will end up just being one of those mysteries, and the boot
> software coder will have to find some non-trivial workaround. It sounds
> like the /lib/i686/ path was hardcoded in the linker when it was
> compiled, which means there are no simple config file checks.
and then they compiled ALL other binaries from scratch with new linker,
passing /lib/i686/libc.so.6 explivitally, or changing the script
/usr/lib/libc.so?
boh! I do not know, and I am not thinking I am going to install a Red Hat
right now (simply it is not suitable for my needs, it is a great
distribution, of course, but it is not what my users need).
want my suggestion?
upgrade to glibc 2.2.3 and to binutils 2.11.90.0.19 building
them from sources against 2.4.X kernel includes. And you wil see if it
works how you would expect.
Luigi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
On Fri, 22 Jun 2001, D. Stimits wrote:
Luigi Genoni wrote:
Again i am confused.
/usr/bin/ld is linker at compilation time, at it works how i told in
second part
of my mail, (just try to compile it, it comes with binutils,
ftp.kernel.org/pub/linux/devel/binutils).
/lib/d-2.2.X.so is what you are talking about.
So should i think os an hack to ld-2.2.3.so ??
The RH 7.1 comes with:
:~# ld --version
GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
Supported emulations:
elf_i386
i386linux
elf_i386_glibc21
Ok, this is the linker for compilation time, it
is not related to the loader for shared libraries. You can even remove
/usr/bin/ld, and the system will run anyway binaries, but you will not be
able to link compiled objects.
try a find for the directory ldscripts or for those files,
elf_i386.xelf_i386.xs i386coff.xn i386linux.xbn
elf_i386.xbn elf_i386.xu i386coff.xr i386linux.xn
elf_i386.xn i386coff.xi386coff.xu i386linux.xr
elf_i386.xr i386coff.xbn i386linux.x i386linux.xu
you could not find the *coff* ones
those are the configuration file (unproper definition, i ask
excuse for my english), for /usr/bin/ld you are running
doing ld --version.
The glibc rpm is version 2.2.2-10.
to see how it works loock at /usr/bin/ldd, it's an interesting script.
I can understand why old glibc 2.1 is not isered in the directories
where ldconfig has to loock to create its db for loader, but there should
be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
subdirectories)
for glibc 2.2, since it is necessary at compilation
time.
There is *no* /usr/i386-xxx except for:
/usr/i386-glibc21-linux/
name could be different, just could you e-mail the output for
the command tree inside of /usr?
No glibc22 version exists.
This do not change the problem which is related to /lib/ld-2.2.X.so.
doing a strings /lib/ld-2.XXX
you will find also
info[19]-d_un.d_val == sizeof (Elf32_Rel)
info[20]-d_un.d_val == 17
/lib/
/usr/lib/
{ORIGIN}
{PLATFORM}
expand_dynamic_string_token
dl-load.c
i686 is visible on a line by itself, but so are i386, i486, and i586.
this is another thing...
The full path of /lib/i686/ is not mentioned anywhere. So it looks like
strings of /lib/ld-2* does not offer any hints as to how the i686
subdirectory is being chosen without it being specified anywhere else. I
think this will end up just being one of those mysteries, and the boot
software coder will have to find some non-trivial workaround. It sounds
like the /lib/i686/ path was hardcoded in the linker when it was
compiled, which means there are no simple config file checks.
and then they compiled ALL other binaries from scratch with new linker,
passing /lib/i686/libc.so.6 explivitally, or changing the script
/usr/lib/libc.so?
boh! I do not know, and I am not thinking I am going to install a Red Hat
right now (simply it is not suitable for my needs, it is a great
distribution, of course, but it is not what my users need).
want my suggestion?
upgrade to glibc 2.2.3 and to binutils 2.11.90.0.19 building
them from sources against 2.4.X kernel includes. And you wil see if it
works how you would expect.
Luigi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
On Sat, 23 Jun 2001, D. Stimits wrote:
The RH 7.1 comes with:
:~# ld --version
GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
Supported emulations:
elf_i386
i386linux
elf_i386_glibc21
Ok, this is the linker for compilation time, it
is not related to the loader for shared libraries. You can even remove
/usr/bin/ld, and the system will run anyway binaries, but you will not be
able to link compiled objects.
try a find for the directory ldscripts or for those files,
It appears that Redhat has eliminated much of this. If I run updatedb,
then locate, I find there is no instance of ldscripts. Nor is there an
instance of i386linux or i386coff that can be seen by locate. So I
made it a wider locate, and tried for any instance of just 86linux or
86coff, these also do not exist. Apparently Redhat has completely
changed linking (looking at a backup of an older RH 6.2, these do exist,
so I suspect the change at around 7.0).
glad to know this, i do wonder how does /usr/bin/ld work for red hat.
to my old mentality this seems red hat is going out of any resonable
standard.
There is *no* /usr/i386-xxx except for:
/usr/i386-glibc21-linux/
name could be different, just could you e-mail the output for
the command tree inside of /usr?
The entire tree would be quite large. Are you looking only for
directories (this would be a much smaller listing)? It might even
challenge the maximum size an ISP allows before filtering it:
16632 directories, 258120 files
It is my own curiosity. yes if you could send me the direcotory tree of
your /usr. Just to see. Actually i know none using red hat 7.X to whom i
could ask to check, they are all slackware addicted.
No ldscripts on the system. Through locate and awk, I can guarantee
there is also only one ld on the system, /usr/bin/ld. It sounds like
they did compile all other binaries from scratch, passing /lib/i686/
explicitly.
mmm!
Again I am confused. how can the linker work?
As far as this particular problem goes, I am trying to help the author
of some general boot disk utilities find a good way to automatically
detect (through perl scripts) the correct libc configuration. Telling
users of the software that Redhat 7.1 is not supported is not an option,
regardless of why it is a problem. What it will probably end up becoming
is a mechanical script to test for the existence of /lib/{uname -a}/,
and if it exists, adding it to the boot disk ld.so.conf
I would not be so scared, if you set a LD_PRELOAD_LIBRARY to
/lib/libc.so.6, you willse any binary will run anyway, because it would be
too mutch
if the same libc stripped would not run library, and they HAVE to mantein
a libc.so.6 linside of /lib, otherway this would be too mutch against
a resonable standard.
I would be happy if some guy from red hat could explain what is going on.
Luigi Genoni
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
The point was that Stimits says that on its Red Hat 7.1 he has no ldscripts directory, and so no files like elf_i386.x and so on. I was just surprised, since i know thay are all necessary to /usr/bin/ld to work. Then he was alo wondering why he has two libc /lib/libc.so.6 and /lib/i686/libc.so.6, one is tripped and the other contains debug symbols. I can figure why, but he adfirms that /lib/i686 is not included in /etc/ld.so.conf, there is no preload configured, but this is the directory used by the loader to find the libc to load. I have to red hat installed, so i was trying to figure out how things are working on new releases (my last red hat was 6.2 when i was working at red hat Italy). Bests Luigi On Sun, 24 Jun 2001, Alan Cox wrote: glad to know this, i do wonder how does /usr/bin/ld work for red hat. to my old mentality this seems red hat is going out of any resonable standard. It works like /usr/bin/ld on any other platform I know of if the same libc stripped would not run library, and they HAVE to mantein a libc.so.6 linside of /lib, otherway this would be too mutch against a resonable standard. bash-2.04$ ls -l /lib/libc.so.6 lrwxrwxrwx1 root root 13 May 14 16:46 /lib/libc.so.6 - libc-2.2.2.so I don't follow the discussion here. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
Again i am confused.
/usr/bin/ld is linker at compilation time, at it works how i told in
second part
of my mail, (just try to compile it, it comes with binutils,
ftp.kernel.org/pub/linux/devel/binutils).
/lib/d-2.2.X.so is what you are talking about.
So should i think os an hack to ld-2.2.3.so ??
to see how it works loock at /usr/bin/ldd, it's an interesting script.
I can understand why old glibc 2.1 is not isered in the directories
where ldconfig has to loock to create its db for loader, but there should
be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
subdirectories)
for glibc 2.2, since it is necessary at compilation
time.
This do not change the problem which is related to /lib/ld-2.2.X.so.
doing a strings /lib/ld-2.XXX
you will find also
info[19]->d_un.d_val == sizeof (Elf32_Rel)
info[20]->d_un.d_val == 17
/lib/
/usr/lib/
{ORIGIN}
{PLATFORM}
expand_dynamic_string_token
dl-load.c
this is the interesting section of the output. This way you can check for
an hack to the loader, but I think to something else instead of an hack.
I do not have a red hat here around, since i do prefer another style for
my linux systems, so i cannot check by person.
Luigi Genoni
On Fri, 22 Jun 2001, D. Stimits wrote:
> Luigi Genoni wrote:
> >
> > I do not know if this is a new filesystem hierarchy, it should not be,
> > at less untill lsb finishes all discussion (anyway it is similar to lsb
> > standard). Your mail is a little confusing for me. Let's see if i can
> > clarify my ideas.
> >
> > On Thu, 21 Jun 2001, D. Stimits wrote:
> >
> > > I found on my newer Redhat 7.1 distribution that glibc is being placed
> > > differently than just /lib/. Here is the structure I found:
> > >
> > > /lib/ has:
> > > libc-2.2.2.so (hard link)
> > > libc.so.6 (sym link to above)
> > >
> > > A new directory appears, /lib/i686/ (uname -m is i686):
> > > libc-2.2.2.so (a full hard link copy of /lib/ version)
> > > libc.so.6 (sym link to hard link in this directory)
> > >
> > > The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
> > > /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
> > > while the 1.2 MB version is stripped.
> > >
> > > Here is the peculiar part that I need to find out about. My
> > > /lib/ld.so.conf does not contain the i686 directory in its path. Nor do
> > > any local LD environment variables. Even so, "ldconfig -p" lists *only*
> > > the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
> > > the i686 subdirectory, not the /lib/ directory. How is it possible that
> > > the i686 directory is being checked if it is not listed in ld.so.conf
> > > and not part of any LD path variable? I am using a non-Redhat kernel
> > > (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
> > > kernel itself. My ld version:
> > excuse, but if you do something like,
> > ldd /bin/ls
> >
> > what do you get, which libc is loaded?
>
> :~# ldd /bin/ls
> libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002a000)
> libc.so.6 => /lib/i686/libc.so.6 (0x4002e000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
>
> The i686 subdirectory version is visible to the linker. I don't know
> how.
>
> >
> > have you got a file like /etc/ld.so.preload??
>
> No. Nor are any preload or LD environment variables set. Something
> Redhat has done is making the i686 subdirectory visible. Maybe ld
> searches recursively?
>
> > basically you can use the stripped glibc (faster), but then,
> > if you have troubles and you need to debug, just set the preload file,
> > or use LD_PRELOAD variable to use
> > the non stripped library. In princip it is not a stupid idea,
> > not that i like it, but it is not stupid.
>
> Without any preload, it appears the linker is by default choosing the
> debug version in the i686 subdirectory. Redhat must have mucked with it,
> otherwise I don't see how it could be searching the i686 subdirectory
> without any configuration customization (no preload, no LD environment
> variables). But this is what I want to verify...where the "mucking" has
> occurred, it is important to find out for some software that is used to
> create custom and/or rescue disks. (alternately, to find out if there is
> a predictable scheme, such as knowning ld is searching recursively, or
> searches for /lib/{uname -m})
>
> >
> > > ~# ld --version
> > > GNU ld 2.10.91
> > > Copyright 2001 Free Software Foundation, Inc.
> > > This program is free software; you may redistri
Re: Is this part of newer filesystem hierarchy?
I do not know if this is a new filesystem hierarchy, it should not be, at less untill lsb finishes all discussion (anyway it is similar to lsb standard). Your mail is a little confusing for me. Let's see if i can clarify my ideas. On Thu, 21 Jun 2001, D. Stimits wrote: > I found on my newer Redhat 7.1 distribution that glibc is being placed > differently than just /lib/. Here is the structure I found: > > /lib/ has: > libc-2.2.2.so (hard link) > libc.so.6 (sym link to above) > > A new directory appears, /lib/i686/ (uname -m is i686): > libc-2.2.2.so (a full hard link copy of /lib/ version) > libc.so.6 (sym link to hard link in this directory) > > The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of > /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols, > while the 1.2 MB version is stripped. > > Here is the peculiar part that I need to find out about. My > /lib/ld.so.conf does not contain the i686 directory in its path. Nor do > any local LD environment variables. Even so, "ldconfig -p" lists *only* > the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for > the i686 subdirectory, not the /lib/ directory. How is it possible that > the i686 directory is being checked if it is not listed in ld.so.conf > and not part of any LD path variable? I am using a non-Redhat kernel > (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the > kernel itself. My ld version: excuse, but if you do something like, ldd /bin/ls what do you get, which libc is loaded? have you got a file like /etc/ld.so.preload?? basically you can use the stripped glibc (faster), but then, if you have troubles and you need to debug, just set the preload file, or use LD_PRELOAD variable to use the non stripped library. In princip it is not a stupid idea, not that i like it, but it is not stupid. > ~# ld --version > GNU ld 2.10.91 > Copyright 2001 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms > of > the GNU General Public License. This program has absolutely no > warranty. > Supported emulations: >elf_i386 >i386linux >elf_i386_glibc21 > > Possibly Redhat altered ld? According to the man page, this directory > should not be found since it is not part of ld.so.conf, and also the > /lib/ version *should* be found (but isn't). What has changed, is it a > standard for filesystem hierarchy, or is it something distribution > specific? (I need to pass the answer along to someone working on > customized boot software that is currently being confused by this > distinction; there is a need to find a proper means to detect libc and > linker information) ld links dynamic libraries if the final extension is .so (usually a link), and uses the soname (usually a link too, created by ldconfig), for the binaries it generates, otherway it will use .a library archives. /usr/lib/libc.so (the file used by ld to link glibc), is a script. There are good reason for that, with libc5 it was a link to /lib/libc.so.5 (soname). ld loocks for .so files as is configured inside of the files in /usr//lib/ldscripts please note that usually for klibraries inside of /lib, the .so link is in /usr/lib, or at less it should. syntax is like: SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); \ SEARCH_DIR(/usr/i386-slackware-linux/lib); (that is why you need to pass -L/usr/X11R6/lib to link X11 apps at runtime) anyway to load shared libraries is managed by /lib/ld-2.XXX.so, using the db created by ldconfig that uses /etc/ld.so.conf as its configuration file. Luigi Genoni - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
I do not know if this is a new filesystem hierarchy, it should not be, at less untill lsb finishes all discussion (anyway it is similar to lsb standard). Your mail is a little confusing for me. Let's see if i can clarify my ideas. On Thu, 21 Jun 2001, D. Stimits wrote: I found on my newer Redhat 7.1 distribution that glibc is being placed differently than just /lib/. Here is the structure I found: /lib/ has: libc-2.2.2.so (hard link) libc.so.6 (sym link to above) A new directory appears, /lib/i686/ (uname -m is i686): libc-2.2.2.so (a full hard link copy of /lib/ version) libc.so.6 (sym link to hard link in this directory) The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of /lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols, while the 1.2 MB version is stripped. Here is the peculiar part that I need to find out about. My /lib/ld.so.conf does not contain the i686 directory in its path. Nor do any local LD environment variables. Even so, ldconfig -p lists *only* the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for the i686 subdirectory, not the /lib/ directory. How is it possible that the i686 directory is being checked if it is not listed in ld.so.conf and not part of any LD path variable? I am using a non-Redhat kernel (patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the kernel itself. My ld version: excuse, but if you do something like, ldd /bin/ls what do you get, which libc is loaded? have you got a file like /etc/ld.so.preload?? basically you can use the stripped glibc (faster), but then, if you have troubles and you need to debug, just set the preload file, or use LD_PRELOAD variable to use the non stripped library. In princip it is not a stupid idea, not that i like it, but it is not stupid. ~# ld --version GNU ld 2.10.91 Copyright 2001 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Supported emulations: elf_i386 i386linux elf_i386_glibc21 Possibly Redhat altered ld? According to the man page, this directory should not be found since it is not part of ld.so.conf, and also the /lib/ version *should* be found (but isn't). What has changed, is it a standard for filesystem hierarchy, or is it something distribution specific? (I need to pass the answer along to someone working on customized boot software that is currently being confused by this distinction; there is a need to find a proper means to detect libc and linker information) ld links dynamic libraries if the final extension is .so (usually a link), and uses the soname (usually a link too, created by ldconfig), for the binaries it generates, otherway it will use .a library archives. /usr/lib/libc.so (the file used by ld to link glibc), is a script. There are good reason for that, with libc5 it was a link to /lib/libc.so.5 (soname). ld loocks for .so files as is configured inside of the files in /usr/arch/host name/lib/ldscripts please note that usually for klibraries inside of /lib, the .so link is in /usr/lib, or at less it should. syntax is like: SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/local/lib); \ SEARCH_DIR(/usr/i386-slackware-linux/lib); (that is why you need to pass -L/usr/X11R6/lib to link X11 apps at runtime) anyway to load shared libraries is managed by /lib/ld-2.XXX.so, using the db created by ldconfig that uses /etc/ld.so.conf as its configuration file. Luigi Genoni - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is this part of newer filesystem hierarchy?
Again i am confused.
/usr/bin/ld is linker at compilation time, at it works how i told in
second part
of my mail, (just try to compile it, it comes with binutils,
ftp.kernel.org/pub/linux/devel/binutils).
/lib/d-2.2.X.so is what you are talking about.
So should i think os an hack to ld-2.2.3.so ??
to see how it works loock at /usr/bin/ldd, it's an interesting script.
I can understand why old glibc 2.1 is not isered in the directories
where ldconfig has to loock to create its db for loader, but there should
be a corrispective /usr/i386-(redhat/glibc2.2???)-linux/ (with its
subdirectories)
for glibc 2.2, since it is necessary at compilation
time.
This do not change the problem which is related to /lib/ld-2.2.X.so.
doing a strings /lib/ld-2.XXX
you will find also
info[19]-d_un.d_val == sizeof (Elf32_Rel)
info[20]-d_un.d_val == 17
/lib/
/usr/lib/
{ORIGIN}
{PLATFORM}
expand_dynamic_string_token
dl-load.c
this is the interesting section of the output. This way you can check for
an hack to the loader, but I think to something else instead of an hack.
I do not have a red hat here around, since i do prefer another style for
my linux systems, so i cannot check by person.
Luigi Genoni
On Fri, 22 Jun 2001, D. Stimits wrote:
Luigi Genoni wrote:
I do not know if this is a new filesystem hierarchy, it should not be,
at less untill lsb finishes all discussion (anyway it is similar to lsb
standard). Your mail is a little confusing for me. Let's see if i can
clarify my ideas.
On Thu, 21 Jun 2001, D. Stimits wrote:
I found on my newer Redhat 7.1 distribution that glibc is being placed
differently than just /lib/. Here is the structure I found:
/lib/ has:
libc-2.2.2.so (hard link)
libc.so.6 (sym link to above)
A new directory appears, /lib/i686/ (uname -m is i686):
libc-2.2.2.so (a full hard link copy of /lib/ version)
libc.so.6 (sym link to hard link in this directory)
The file size of /lib/libc-2.2.2.so is around 1.2 MB, while the size of
/lib/i686/libc-2.2.2.so is over 5 MB. The 5 MB version has symbols,
while the 1.2 MB version is stripped.
Here is the peculiar part that I need to find out about. My
/lib/ld.so.conf does not contain the i686 directory in its path. Nor do
any local LD environment variables. Even so, ldconfig -p lists *only*
the libc.so.6 sym link, not the libc-2.2.2.so, and the one listed is for
the i686 subdirectory, not the /lib/ directory. How is it possible that
the i686 directory is being checked if it is not listed in ld.so.conf
and not part of any LD path variable? I am using a non-Redhat kernel
(patched 2.4.6-pre1), so I know it isn't a Redhat-ism related to the
kernel itself. My ld version:
excuse, but if you do something like,
ldd /bin/ls
what do you get, which libc is loaded?
:~# ldd /bin/ls
libtermcap.so.2 = /lib/libtermcap.so.2 (0x4002a000)
libc.so.6 = /lib/i686/libc.so.6 (0x4002e000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
The i686 subdirectory version is visible to the linker. I don't know
how.
have you got a file like /etc/ld.so.preload??
No. Nor are any preload or LD environment variables set. Something
Redhat has done is making the i686 subdirectory visible. Maybe ld
searches recursively?
basically you can use the stripped glibc (faster), but then,
if you have troubles and you need to debug, just set the preload file,
or use LD_PRELOAD variable to use
the non stripped library. In princip it is not a stupid idea,
not that i like it, but it is not stupid.
Without any preload, it appears the linker is by default choosing the
debug version in the i686 subdirectory. Redhat must have mucked with it,
otherwise I don't see how it could be searching the i686 subdirectory
without any configuration customization (no preload, no LD environment
variables). But this is what I want to verify...where the mucking has
occurred, it is important to find out for some software that is used to
create custom and/or rescue disks. (alternately, to find out if there is
a predictable scheme, such as knowning ld is searching recursively, or
searches for /lib/{uname -m})
~# ld --version
GNU ld 2.10.91
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of
the GNU General Public License. This program has absolutely no
warranty.
Supported emulations:
elf_i386
i386linux
elf_i386_glibc21
Possibly Redhat altered ld? According to the man page, this directory
should not be found since it is not part of ld.so.conf, and also the
/lib/ version *should* be found (but isn't). What has changed, is it a
standard for filesystem hierarchy, or is it something distribution
specific? (I need to pass the answer along to someone working on
customized boot software that is currently being confused by this
distinction; there is a need
Re: Linux 2.2.20-pre4
Tried this too, but i have the feeling the kernel compiled with this gcc 3.0 is somehow slower. context switch is slower no benchs (no time to make them) to sustain my feeling, just a feeling... On Wed, 20 Jun 2001, Eric Lammerts wrote: > > On Tue, 19 Jun 2001, Alan Cox wrote: > > > Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ? > > > If not what must be fixed/chenged to be ready ? > > > > It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can > > insert calls to 'memcpy' > > I tried it, but didn't run into problems (apart from the volatile > xtime thing) > > Linux version 2.2.18 (eric@andredvb) (gcc version 3.0 (Debian)) > #1 Wed Jun 20 23:15:46 CEST 2001 > > (Tons of warnings, though) > > Eric > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.20-pre4
Tried this too, but i have the feeling the kernel compiled with this gcc 3.0 is somehow slower. context switch is slower no benchs (no time to make them) to sustain my feeling, just a feeling... On Wed, 20 Jun 2001, Eric Lammerts wrote: On Tue, 19 Jun 2001, Alan Cox wrote: Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ? If not what must be fixed/chenged to be ready ? It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can insert calls to 'memcpy' I tried it, but didn't run into problems (apart from the volatile xtime thing) Linux version 2.2.18 (eric@andredvb) (gcc version 3.0 (Debian)) #1 Wed Jun 20 23:15:46 CEST 2001 (Tons of warnings, though) Eric - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ip_tables/ipchains
try to delete those two modules, and repit depmod -a then try to load the modules. ipchain and ipfwadm modules do have symbols inside that are confusing depmode/modprobe dor dependency of actual netfilter modules. On Wed, 20 Jun 2001, Ted Gervais wrote: > On Wed, 20 Jun 2001, Luigi Genoni wrote: > > > Have you also compiled modules for ipchains and ipfwadm support?? > > > Yes. Is this a mistake?? > > > > > > > On Wed, 20 Jun 2001, Ted Gervais wrote: > > > > > Wondering something.. > > > I ran insmod to bring up ip_tables.o and I received the following error: > > > > > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > > > symbol nf_unregister_sockopt > > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > > > symbol nf_register_sockopt > > > > > > This is with kernel 2.4.5 and Slackware 7.1 is the distribution. > > > Does anyone know what these unresolved symbols are about?? > > > > > > --- > > > Doubt is not a pleasant condition, but certainty is absurd. > > > -- Voltaire > > > > > > Ted Gervais <[EMAIL PROTECTED]> > > > 44.135.34.201 linux.ve1drg.ampr.org > > > > > > > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > --- > Doubt is not a pleasant condition, but certainty is absurd. > -- Voltaire > > Ted Gervais <[EMAIL PROTECTED]> > 44.135.34.201 linux.ve1drg.ampr.org > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ip_tables/ipchains
Have you also compiled modules for ipchains and ipfwadm support?? On Wed, 20 Jun 2001, Ted Gervais wrote: > Wondering something.. > I ran insmod to bring up ip_tables.o and I received the following error: > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > symbol nf_unregister_sockopt > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > symbol nf_register_sockopt > > This is with kernel 2.4.5 and Slackware 7.1 is the distribution. > Does anyone know what these unresolved symbols are about?? > > --- > Doubt is not a pleasant condition, but certainty is absurd. > -- Voltaire > > Ted Gervais <[EMAIL PROTECTED]> > 44.135.34.201 linux.ve1drg.ampr.org > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ip_tables/ipchains
Have you also compiled modules for ipchains and ipfwadm support?? On Wed, 20 Jun 2001, Ted Gervais wrote: Wondering something.. I ran insmod to bring up ip_tables.o and I received the following error: /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved symbol nf_unregister_sockopt /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved symbol nf_register_sockopt This is with kernel 2.4.5 and Slackware 7.1 is the distribution. Does anyone know what these unresolved symbols are about?? --- Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire Ted Gervais [EMAIL PROTECTED] 44.135.34.201 linux.ve1drg.ampr.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ip_tables/ipchains
try to delete those two modules, and repit depmod -a then try to load the modules. ipchain and ipfwadm modules do have symbols inside that are confusing depmode/modprobe dor dependency of actual netfilter modules. On Wed, 20 Jun 2001, Ted Gervais wrote: On Wed, 20 Jun 2001, Luigi Genoni wrote: Have you also compiled modules for ipchains and ipfwadm support?? Yes. Is this a mistake?? On Wed, 20 Jun 2001, Ted Gervais wrote: Wondering something.. I ran insmod to bring up ip_tables.o and I received the following error: /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved symbol nf_unregister_sockopt /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved symbol nf_register_sockopt This is with kernel 2.4.5 and Slackware 7.1 is the distribution. Does anyone know what these unresolved symbols are about?? --- Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire Ted Gervais [EMAIL PROTECTED] 44.135.34.201 linux.ve1drg.ampr.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ --- Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire Ted Gervais [EMAIL PROTECTED] 44.135.34.201 linux.ve1drg.ampr.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange behaviour of swap under 2.4.5-ac15
On Mon, 18 Jun 2001, German Gomez Garcia wrote: > On Mon, 18 Jun 2001, Andrea Arcangeli wrote: > > > On Mon, Jun 18, 2001 at 12:14:01PM +0200, German Gomez Garcia wrote: > > > Hello, > > > > > > I've running 2.4.5-ac15 for almost a day (22 hours) and I found > > > some strange behaviour of the kswap, at least it was not present in > > > 2.4.5-ac9. The swap memory increase with time as the cache dedicated > > > memory also increase, that is swapping process at a very fast rate, even > > > when no program is getting more memory. Is that the expected behaviour? > > > An example, with no process running (just the usual daemons and > > > none of them getting extra memory) the command: > > > > > > free ; sleep 60; free > > > > > > total used free sharedbuffers cached > > > Mem:513416 393184 120232364 63276 254576 > > > -/+ buffers/cache: 75332 438084 > > > Swap: 530104 14228 515876 > > > > > > total used free sharedbuffers cached > > > Mem:513416 393192 120224364 63276 258412 > > > -/+ buffers/cache: 71504 441912 > > > Swap: 530104 18064 512040 > > > > > > Any idea? > > > > either apply this patch to 2.4.5ac15: > > > > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.5aa3/00_fix-unusable-vm-on-alpha-1 > > > > (note it is not an alpha specific bug, it's just that I was triggering > > all the time on alpha so I called the patch that way) > > It doesn't fix it, swapped memory and cache memory increase at a > rate of about 40K/s, swapping process very fast, even the "agetty" > processes get 64 out of 68 K swapped one or two minutes after booting. > This rate gets lower as nothing but the essential (4K of "agetty", etc) is > left in the physical memory. > I was having similar problems with a sun 3500 with 4 GB of RAM running 2.4.5 (no problems of this kind with 2.4.4), and this patch fixed my problems under eavy stress. I was having the most of memory free and a lot of swap allocated, and system swapping to dead. Now it works, with other problems, but when i have time and permission to try to debug them. :). Maybe there could be some HW related reason because of which it fixed for my sun and not for you... Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange behaviour of swap under 2.4.5-ac15
On Mon, 18 Jun 2001, German Gomez Garcia wrote: On Mon, 18 Jun 2001, Andrea Arcangeli wrote: On Mon, Jun 18, 2001 at 12:14:01PM +0200, German Gomez Garcia wrote: Hello, I've running 2.4.5-ac15 for almost a day (22 hours) and I found some strange behaviour of the kswap, at least it was not present in 2.4.5-ac9. The swap memory increase with time as the cache dedicated memory also increase, that is swapping process at a very fast rate, even when no program is getting more memory. Is that the expected behaviour? An example, with no process running (just the usual daemons and none of them getting extra memory) the command: free ; sleep 60; free total used free sharedbuffers cached Mem:513416 393184 120232364 63276 254576 -/+ buffers/cache: 75332 438084 Swap: 530104 14228 515876 total used free sharedbuffers cached Mem:513416 393192 120224364 63276 258412 -/+ buffers/cache: 71504 441912 Swap: 530104 18064 512040 Any idea? either apply this patch to 2.4.5ac15: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.5aa3/00_fix-unusable-vm-on-alpha-1 (note it is not an alpha specific bug, it's just that I was triggering all the time on alpha so I called the patch that way) It doesn't fix it, swapped memory and cache memory increase at a rate of about 40K/s, swapping process very fast, even the agetty processes get 64 out of 68 K swapped one or two minutes after booting. This rate gets lower as nothing but the essential (4K of agetty, etc) is left in the physical memory. I was having similar problems with a sun 3500 with 4 GB of RAM running 2.4.5 (no problems of this kind with 2.4.4), and this patch fixed my problems under eavy stress. I was having the most of memory free and a lot of swap allocated, and system swapping to dead. Now it works, with other problems, but when i have time and permission to try to debug them. :). Maybe there could be some HW related reason because of which it fixed for my sun and not for you... Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2FS problems & 2.2.19 & 3ware RAID
On Thu, 14 Jun 2001, Udo Wolter wrote: > Hi ! > > I'm hosting a server with 120 GB disk space. This disk space consists of > a RAID10 via a 3ware Escalade 6800 controller. As you can see, the disks are > IDE disks (4 x 60 GB) but the controller maps it as scsi-devices to > the system. It runs fine but from time to time I get those errors: > > kernel: EXT2-fs warning (device sd(8,6)): ext2_free_inode: bit already cleared for >inode 885312 > kernel: EXT2-fs warning (device sd(8,6)): ext2_free_inode: bit already cleared for >inode 885258 > when i saw something similar, with a configuration really similar to your, but on scsi disks, it was because a disc was near to break. I had to change the disk and everything went ok. It also happened to me after a crash on a disk due to eathing problems, last august. Same messages, and thanx God the disk was not really damnaged, so low level formatted the disk, rebuilt partition table, then I rebuilt the fs to restore my backup and everything went ok. So my suggestion is to loock for HW problems. > etc. > > The messages are coming almost once a week. As long as those messages are not > harming the filesystem, I had no problems with them (in fact, they say, they > are warnings and no errors). But the last times I tried to do a du over the > full partition, I got 2 or 3 files and directories which say that that they > can't be accessed -> I/O-Error. Neither I can't delete them nor I can > access them in any way, not even list. > > After using debugfs (read only mode during the mount) I can see the files > in the listing but even here they are not accessible. > > I shut the machine down for 2 hours to do a fsck and the errors had been > gone but after some days the errors came back (different files and directories, > not the same). At this time it's not possible to shut it down because > more than 5000 users use it at the moment. Anyway before doing a fsck again > I'd like to solve the problem so that the system couldn't get corrupted again. > exactly, that what I saw myself on the soon to get broken disk. bests Luigi Genoni - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
On Wed, 13 Jun 2001, Daniel wrote: > So without further ado here're the features I want to get rid of: > > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. Please, I have a lot of 486 that I use for many secondary things and a 386, why I should not be able to run the latest kernel on them? In princip, linux have to support all old hardware out there. > > math-emu > If support for i386 and i486 is going away, then so should math emulation. > Every intel processor since the 486DX has an FPU unit built in. In fact > shouldn't FPU support be a userspace responsibility anyway? see previuos > > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting devices for > these buses. Again, a lot of modern MB comes out with at less one isa slot, and anyway isa bus is present also without the slot on all MB since it has to be there. how many users are happy with their old sound blaster 16 on ISA, or with their old isa modem and would never change it? they should never be forced. > > MFM/RLL/XT/ESDI hard drive support > Does anyone still *have* an RLL drive that works? At the very least get rid > of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, > CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) see previous > > parallel/serial/game ports > More controversial to remove this, since they are *still* in pretty wide > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. see previous > > a.out > Who needs it anymore. I love ELF. and how many are happy to play doom with a.out svgalibs?? > my 2 cents Luigi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
On Wed, 13 Jun 2001, Daniel wrote: So without further ado here're the features I want to get rid of: i386, i486 The Pentium processor has been around since 1995. Support for these older processors should go so we can focus on optimizations for the pentium and better processors. Please, I have a lot of 486 that I use for many secondary things and a 386, why I should not be able to run the latest kernel on them? In princip, linux have to support all old hardware out there. math-emu If support for i386 and i486 is going away, then so should math emulation. Every intel processor since the 486DX has an FPU unit built in. In fact shouldn't FPU support be a userspace responsibility anyway? see previuos ISA, MCA, EISA device drivers If support for the buses is gone, there's no point in supporting devices for these buses. Again, a lot of modern MB comes out with at less one isa slot, and anyway isa bus is present also without the slot on all MB since it has to be there. how many users are happy with their old sound blaster 16 on ISA, or with their old isa modem and would never change it? they should never be forced. MFM/RLL/XT/ESDI hard drive support Does anyone still *have* an RLL drive that works? At the very least get rid of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) see previous parallel/serial/game ports More controversial to remove this, since they are *still* in pretty wide use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. see previous a.out Who needs it anymore. I love ELF. and how many are happy to play doom with a.out svgalibs?? my 2 cents Luigi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2FS problems 2.2.19 3ware RAID
On Thu, 14 Jun 2001, Udo Wolter wrote: Hi ! I'm hosting a server with 120 GB disk space. This disk space consists of a RAID10 via a 3ware Escalade 6800 controller. As you can see, the disks are IDE disks (4 x 60 GB) but the controller maps it as scsi-devices to the system. It runs fine but from time to time I get those errors: kernel: EXT2-fs warning (device sd(8,6)): ext2_free_inode: bit already cleared for inode 885312 kernel: EXT2-fs warning (device sd(8,6)): ext2_free_inode: bit already cleared for inode 885258 when i saw something similar, with a configuration really similar to your, but on scsi disks, it was because a disc was near to break. I had to change the disk and everything went ok. It also happened to me after a crash on a disk due to eathing problems, last august. Same messages, and thanx God the disk was not really damnaged, so low level formatted the disk, rebuilt partition table, then I rebuilt the fs to restore my backup and everything went ok. So my suggestion is to loock for HW problems. etc. The messages are coming almost once a week. As long as those messages are not harming the filesystem, I had no problems with them (in fact, they say, they are warnings and no errors). But the last times I tried to do a du over the full partition, I got 2 or 3 files and directories which say that that they can't be accessed - I/O-Error. Neither I can't delete them nor I can access them in any way, not even list. After using debugfs (read only mode during the mount) I can see the files in the listing but even here they are not accessible. I shut the machine down for 2 hours to do a fsck and the errors had been gone but after some days the errors came back (different files and directories, not the same). At this time it's not possible to shut it down because more than 5000 users use it at the moment. Anyway before doing a fsck again I'd like to solve the problem so that the system couldn't get corrupted again. exactly, that what I saw myself on the soon to get broken disk. bests Luigi Genoni - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hour long timeout to ssh/telnet/ftp to down host?
On Tue, 12 Jun 2001, Ben Greear wrote: > Rob Landley wrote: > > > > I have scripts that ssh into large numbers of boxes, which are sometimes > > down. The timeout for figuring out the box is down is over an hour. This is > > just insane. > > > > Telnet and ftp behave similarly, or at least tthey lasted the 5 minutes I was > > willing to wait, anyway. Basically anything that calls connect(). If the > > box doesn't respond in 15 seconds, I want to give up. > > > > Is this a problem with the kernel or with glibc? If it's the kernel, I'd > > expect a /proc entry where I can set this, but I can't seem to find one. Is > > there one? What would be involved in writing one? > > > > You can tune things by setting the tcp-timeout probably..I don't > know exactly where to set this.. /proc/sys/net/ipv4/tcp_fin_timeout default is 60. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
I have the sound blaster 16 card on one of my athlon (on PIII i have es1731), that has one isa slot on its MB. It works well, but i do not use isapnp nor any pnp support is enabled inside of the kernel. running 2.4.5/2.4.6-pre2 Luigi On Tue, 12 Jun 2001, Colonel wrote: > From: Colonel <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: ISA Soundblaster problem > Reply-to: [EMAIL PROTECTED] > > > The Maintainers list does not contain anyone for 2.4 Soundblaster > modules, so perhaps some one on the mailing list is aware of a > solution. My ISA Soundblaster 16waveffects worked fine in kernel 2.2 > with XMMS. But I have never been successful in a varity of 2.4 > kernels, the latest being 2.4.5-ac12. This is what I know: > > [DMESG] > isapnp: Scanning for PnP cards... > isapnp: Calling quirk for 01:00 > isapnp: SB audio device quirk - increasing port range > isapnp: Card 'Creative SB16 PnP' > isapnp: 1 Plug & Play card detected total > > }modprobe sb > /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device > /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be caused >by incorrect module parameters, including invalid IO or IRQ parameters > /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod >/lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed > /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed > > > [/etc/modules.conf] > options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330 > > > [DMESG} > Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 > sb: No ISAPnP cards found, trying standard ones... > sb: dsp reset failed. > > > So it seems that PnP finds the card, but the connections (or even the > forced values) to the sb module fail. Back when this was a single > processor machine, but still running 2.4 kernel, a windoze > installation found the SB at the listed interface parameters. > > > Anyone have a solution? > > Same problem without modules.conf settings, valid version of mod > utilities, a web search did not help,... > > > > TIA > > > please CC: [EMAIL PROTECTED], not currently on the mailing list. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: your mail
I have the sound blaster 16 card on one of my athlon (on PIII i have es1731), that has one isa slot on its MB. It works well, but i do not use isapnp nor any pnp support is enabled inside of the kernel. running 2.4.5/2.4.6-pre2 Luigi On Tue, 12 Jun 2001, Colonel wrote: From: Colonel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: ISA Soundblaster problem Reply-to: [EMAIL PROTECTED] The Maintainers list does not contain anyone for 2.4 Soundblaster modules, so perhaps some one on the mailing list is aware of a solution. My ISA Soundblaster 16waveffects worked fine in kernel 2.2 with XMMS. But I have never been successful in a varity of 2.4 kernels, the latest being 2.4.5-ac12. This is what I know: [DMESG] isapnp: Scanning for PnP cards... isapnp: Calling quirk for 01:00 isapnp: SB audio device quirk - increasing port range isapnp: Card 'Creative SB16 PnP' isapnp: 1 Plug Play card detected total }modprobe sb /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: init_module: No such device /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o failed /lib/modules/2.4.5-ac12/kernel/drivers/sound/sb.o: insmod sb failed [/etc/modules.conf] options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330 [DMESG} Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 sb: No ISAPnP cards found, trying standard ones... sb: dsp reset failed. So it seems that PnP finds the card, but the connections (or even the forced values) to the sb module fail. Back when this was a single processor machine, but still running 2.4 kernel, a windoze installation found the SB at the listed interface parameters. Anyone have a solution? Same problem without modules.conf settings, valid version of mod utilities, a web search did not help,... TIA please CC: [EMAIL PROTECTED], not currently on the mailing list. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hour long timeout to ssh/telnet/ftp to down host?
On Tue, 12 Jun 2001, Ben Greear wrote: Rob Landley wrote: I have scripts that ssh into large numbers of boxes, which are sometimes down. The timeout for figuring out the box is down is over an hour. This is just insane. Telnet and ftp behave similarly, or at least tthey lasted the 5 minutes I was willing to wait, anyway. Basically anything that calls connect(). If the box doesn't respond in 15 seconds, I want to give up. Is this a problem with the kernel or with glibc? If it's the kernel, I'd expect a /proc entry where I can set this, but I can't seem to find one. Is there one? What would be involved in writing one? You can tune things by setting the tcp-timeout probably..I don't know exactly where to set this.. /proc/sys/net/ipv4/tcp_fin_timeout default is 60. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: es1371 and recent kernels
It does work very well for me with 2.4.5 and 2.4.6-pre2, both with or without devfs, both if sound support has been statically linked or compiled as module. On 12 Jun 2001, Pierfrancesco Caci wrote: > > [please be kind and Cc when replying] > > Has someone been able to get es1371 to actually produce anything > audible with latest kernels? The last version I could use was 2.4.0. > Then I had some trouble but I attributed them to devfs. Now I've > removed devfs and still I'm not able to play anything. > > .config is available at http://mirror.seabone.net/paperino.config > > pieffe@paperino:/proc $ cat devices > Character devices: > 1 mem > 2 pty > 3 ttyp > 4 ttyS > 5 cua > 6 lp > 7 vcs > 10 misc > 14 sound > 29 fb > 89 i2c > 128 ptm > 129 ptm > 136 pts > 137 pts > 162 raw > > Block devices: > 2 fd > 3 ide0 > 22 ide1 > Character devices: 1 mem 2 pty 3 ttyp 4 vc/0 5 ptmx 7 vcs 10 misc 14 sound 21 sg 29 fb 36 netlink 81 video_capture 90 mtd 128 ptm 136 pts 162 raw 180 usb 202 cpu/msr 203 cpu/cpuid Block devices: 3 ide0 22 ide1 31 mtdblock > pieffe@paperino:/proc $ cat es1371 > Creative ES137x Debug Dump-o-matic > AC97 CODEC state > reg:0x00 val:0x1990 > reg:0x02 val:0x0303 > reg:0x04 val:0x1515 > reg:0x06 val:0x0017 > reg:0x08 val:0x > reg:0x0a val:0x000a > reg:0x0c val:0x0006 > reg:0x0e val:0x > reg:0x10 val:0x0b0b > reg:0x12 val:0x0b0b > reg:0x14 val:0x0b0b > reg:0x16 val:0x0b0b > reg:0x18 val:0x0b0b > reg:0x1a val:0x0404 > reg:0x1c val:0x0a0a > reg:0x1e val:0x > reg:0x20 val:0x > reg:0x22 val:0x > reg:0x24 val:0x > reg:0x26 val:0x800f > reg:0x28 val:0x0200 > reg:0x2a val:0x > reg:0x2c val:0xbb80 > reg:0x2e val:0x > reg:0x30 val:0x > reg:0x32 val:0xbb80 > reg:0x34 val:0x > reg:0x36 val:0x > reg:0x38 val:0x > reg:0x3a val:0x > reg:0x3c val:0x > reg:0x3e val:0x > reg:0x40 val:0x > reg:0x42 val:0x > reg:0x44 val:0x > reg:0x46 val:0x > reg:0x48 val:0x > reg:0x4a val:0x > reg:0x4c val:0x > reg:0x4e val:0x > reg:0x50 val:0x > reg:0x52 val:0x > reg:0x54 val:0x > reg:0x56 val:0x > reg:0x58 val:0x > reg:0x5a val:0x0302 > reg:0x5c val:0x > reg:0x5e val:0x0080 > reg:0x60 val:0x0022 > reg:0x62 val:0x > reg:0x64 val:0x > reg:0x66 val:0x > reg:0x68 val:0x > reg:0x6a val:0x > reg:0x6c val:0x > reg:0x6e val:0x > reg:0x70 val:0x > reg:0x72 val:0x > reg:0x74 val:0x > reg:0x76 val:0x > reg:0x78 val:0x003f > reg:0x7a val:0x > reg:0x7c val:0x4352 > reg:0x7e val:0x5913 > Creative ES137x Debug Dump-o-matic AC97 CODEC state reg:0x00 val:0x1990 reg:0x02 val:0x1717 reg:0x04 val:0x1515 reg:0x06 val:0x0017 reg:0x08 val:0x reg:0x0a val:0x000a reg:0x0c val:0x000b reg:0x0e val:0x000b reg:0x10 val:0x0b0b reg:0x12 val:0x0b0b reg:0x14 val:0x0b0b reg:0x16 val:0x0b0b reg:0x18 val:0x0b0b reg:0x1a val:0x0404 reg:0x1c val:0x0a0a reg:0x1e val:0x reg:0x20 val:0x reg:0x22 val:0x reg:0x24 val:0x reg:0x26 val:0x800f reg:0x28 val:0x0200 reg:0x2a val:0x reg:0x2c val:0xbb80 reg:0x2e val:0x reg:0x30 val:0x reg:0x32 val:0xbb80 reg:0x34 val:0x reg:0x36 val:0x reg:0x38 val:0x reg:0x3a val:0x reg:0x3c val:0x reg:0x3e val:0x reg:0x40 val:0x reg:0x42 val:0x reg:0x44 val:0x reg:0x46 val:0x reg:0x48 val:0x reg:0x4a val:0x reg:0x4c val:0x reg:0x4e val:0x reg:0x50 val:0x reg:0x52 val:0x reg:0x54 val:0x reg:0x56 val:0x reg:0x58 val:0x reg:0x5a val:0x0302 reg:0x5c val:0x reg:0x5e val:0x0080 reg:0x60 val:0x0022 reg:0x62 val:0x reg:0x64 val:0x reg:0x66 val:0x reg:0x68 val:0x reg:0x6a val:0x reg:0x6c val:0x reg:0x6e val:0x reg:0x70 val:0x reg:0x72 val:0x reg:0x74 val:0x reg:0x76 val:0x reg:0x78 val:0x0071 reg:0x7a val:0x reg:0x7c val:0x4352 reg:0x7e val:0x5913 > pieffe@paperino:/proc $ cat interrupts >CPU0 > 0: 122894 XT-PIC timer > 1: 5051 XT-PIC keyboard > 2: 0 XT-PIC cascade > 5: 3225 XT-PIC eth0 > 8: 1 XT-PIC rtc > 10: 38969 XT-PIC es1371 > 12: 28771 XT-PIC PS/2 Mouse > 14: 8790 XT-PIC ide0 > 15:112 XT-PIC ide1 > NMI: 0 > ERR: 0 > CPU0 0: 51784328 XT-PIC timer 1: 142458 XT-PIC keyboard 2: 0 XT-PIC cascade 11: 11021305 XT-PIC es1371, usb-uhci, eth0 12:1374347 XT-PIC PS/2 Mouse 14:1085963 XT-PIC ide0 15: 3 XT-PIC ide1 NMI: 0 ERR: 0 > pieffe@paperino:/proc $ cat iomem > -0009fbff : System RAM >
Re: es1371 and recent kernels
0010-03fe : System RAM 0010-0021aee3 : Kernel code 0021aee4-0027df2b : Kernel data 03ff-03ff2fff : ACPI Non-volatile Storage 03ff3000-03ff : ACPI Tables e000-e3ff : PCI Bus #01 e000-e0ff : ATI Technologies Inc 3D Rage Pro AGP 1X/2X e200-e2000fff : ATI Technologies Inc 3D Rage Pro AGP 1X/2X e400-e5ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge e700-e77f : 3Com Corporation 3c905B-Combo [Deluxe Etherlink XL 10/100] - : reserved -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000c8000-000c97ff : Extension ROM 000e-000e : Extension ROM 000f-000f : System ROM 0010-07ff : System RAM 0010-0020638d : Kernel code 0020638e-00265f7f : Kernel data 4000-408f : PCI Bus #01 4000-407f : Matrox Graphics, Inc. MGA G200 AGP 4080-40803fff : Matrox Graphics, Inc. MGA G200 AGP 4080-40803fff : matroxfb MMIO 4090-409f : Intel Corporation 82557 [Ethernet Pro 100] 40a0-40a00fff : Intel Corporation 82557 [Ethernet Pro 100] 40a0-40a00fff : eepro100 4100-41ff : PCI Bus #01 4100-41ff : Matrox Graphics, Inc. MGA G200 AGP 4100-41ff : matroxfb FB 4400-47ff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge fffc- : reserved pieffe@paperino:/proc $ cat ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(auto) 0376-0376 : ide1 0378-037a : parport0 037b-037f : parport0 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0778-077a : parport0 0cf8-0cff : PCI conf1 4000-403f : Intel Corporation 82371AB PIIX4 ACPI 5000-501f : Intel Corporation 82371AB PIIX4 ACPI d000-dfff : PCI Bus #01 d000-d0ff : ATI Technologies Inc 3D Rage Pro AGP 1X/2X e000-e01f : Intel Corporation 82371AB PIIX4 USB e400-e47f : 3Com Corporation 3c905B-Combo [Deluxe Etherlink XL 10/100] e400-e47f : eth0 e800-e83f : Ensoniq ES1371 [AudioPCI-97] e800-e83f : es1371 f000-f00f : Intel Corporation 82371AB PIIX4 IDE f000-f007 : ide0 f008-f00f : ide1 0cf8-0cff : PCI conf1 1000-103f : Intel Corporation 82557 [Ethernet Pro 100] 1000-103f : eepro100 1040-107f : Ensoniq ES1371 [AudioPCI-97] 1040-107f : es1371 1080-109f : Intel Corporation 82371AB PIIX4 USB 1080-109f : usb-uhci 10a0-10af : Intel Corporation 82371AB PIIX4 IDE 10a0-10a7 : ide0 10a8-10af : ide1 f800-f83f : Intel Corporation 82371AB PIIX4 ACPI fc00-fc1f : Intel Corporation 82371AB PIIX4 ACPI pieffe@paperino:/proc $ cat modules es1371 25680 0 (autoclean) ac97_codec 8576 0 (autoclean) [es1371] parport_pc 23248 1 (autoclean) lp 5552 1 (autoclean) parport25664 1 (autoclean) [parport_pc lp] binfmt_misc 3264 0 soundcore 3792 4 (autoclean) [es1371] #lspci -vv 00:0c.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06) Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort+ MAbort+ SERR- PERR- Latency: 32 (3000ns min, 32000ns max) Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at e800 [size=64] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0+,D1-,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:0f.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 08) Subsystem: Compaq Computer Corporation ES1371, ES1373 AudioPCI Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort+ MAbort+ SERR- PERR- Latency: 64 (3000ns min, 32000ns max) Interrupt: pin A routed to IRQ 11 Region 0: I/O ports at 1040 [size=64] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Luigi Genoni Unix System Manager Scuola Normale Superiore di Pisa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
