Re: ZFS vs ext3/NTFS/Veritas Storage Foundation

2007-06-15 Thread Luigi Genoni
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

2007-06-15 Thread Luigi Genoni
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()

2007-05-22 Thread Luigi Genoni
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()

2007-05-22 Thread Luigi Genoni
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.

2007-02-06 Thread Luigi Genoni
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.

2007-02-06 Thread Luigi Genoni
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

2005-09-01 Thread Luigi Genoni
  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

2005-09-01 Thread Luigi Genoni
  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

2005-08-11 Thread Luigi Genoni
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

2005-08-11 Thread Luigi Genoni
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!

2001-07-02 Thread Luigi Genoni



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!

2001-07-02 Thread Luigi Genoni



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

2001-06-28 Thread Luigi Genoni



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

2001-06-28 Thread Luigi Genoni



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

2001-06-28 Thread Luigi Genoni



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

2001-06-28 Thread Luigi Genoni



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

2001-06-27 Thread Luigi Genoni



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

2001-06-27 Thread Luigi Genoni



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

2001-06-27 Thread Luigi Genoni



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

2001-06-27 Thread Luigi Genoni



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

2001-06-26 Thread Luigi Genoni



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

2001-06-26 Thread Luigi Genoni

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

2001-06-26 Thread Luigi Genoni


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

2001-06-26 Thread Luigi Genoni


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

2001-06-26 Thread Luigi Genoni

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

2001-06-26 Thread Luigi Genoni



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

2001-06-25 Thread Luigi Genoni

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

2001-06-25 Thread Luigi Genoni


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

2001-06-25 Thread Luigi Genoni



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

2001-06-25 Thread Luigi Genoni

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

2001-06-25 Thread Luigi Genoni



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

2001-06-25 Thread Luigi Genoni



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

2001-06-25 Thread Luigi Genoni

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

2001-06-25 Thread Luigi Genoni



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

2001-06-25 Thread Luigi Genoni


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

2001-06-25 Thread Luigi Genoni

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!

2001-06-24 Thread Luigi Genoni



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

2001-06-24 Thread Luigi Genoni



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

2001-06-24 Thread Luigi Genoni



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

2001-06-24 Thread Luigi Genoni


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

2001-06-24 Thread Luigi Genoni



  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

2001-06-24 Thread Luigi Genoni



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!

2001-06-24 Thread Luigi Genoni



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?

2001-06-24 Thread Luigi Genoni


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?

2001-06-23 Thread Luigi Genoni

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?

2001-06-23 Thread Luigi Genoni



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?

2001-06-23 Thread Luigi Genoni



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?

2001-06-23 Thread Luigi Genoni



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?

2001-06-23 Thread Luigi Genoni



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?

2001-06-23 Thread Luigi Genoni

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?

2001-06-22 Thread Luigi Genoni


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?

2001-06-22 Thread Luigi Genoni

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?

2001-06-22 Thread Luigi Genoni

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?

2001-06-22 Thread Luigi Genoni


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

2001-06-21 Thread Luigi Genoni

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

2001-06-21 Thread Luigi Genoni

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

2001-06-20 Thread Luigi Genoni

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

2001-06-20 Thread Luigi Genoni

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

2001-06-20 Thread Luigi Genoni

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

2001-06-20 Thread Luigi Genoni

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

2001-06-18 Thread Luigi Genoni



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

2001-06-18 Thread Luigi Genoni



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

2001-06-14 Thread Luigi Genoni



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

2001-06-14 Thread Luigi Genoni



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

2001-06-14 Thread Luigi Genoni



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

2001-06-14 Thread Luigi Genoni



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?

2001-06-13 Thread Luigi Genoni



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

2001-06-13 Thread Luigi Genoni

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

2001-06-13 Thread Luigi Genoni

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?

2001-06-13 Thread Luigi Genoni



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

2001-06-12 Thread Luigi Genoni


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

2001-06-12 Thread Luigi Genoni
 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/