The 2.5.69 kernel kicks butt -- Debian is now releasing a version in sid
and it runs stable on my vpr matrix 205A laptop. What works: nfs, samba,
v4l, the nVidia driver (patched), everything I've tested so far. And sound
-- the ALSA sound is great (headphone jack still dead). ACPI now detects
my battery, and I'm working on software suspend.
The ALI chipset (1671 northbridge, 1533 ISA bridge, 5229 IDE interface,
7101 bridge) gives me
DMA 33 with 2.4.20:
hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=4864/255/63, UDMA(33)
but no dma with 2.5.69. Timing buffered disk reads now come in at
3.17MB/s -- in 2.4.20 I get 19.88 MB/sec. hdparm gives part number
IC25N040ATCS04-0, a Travelstar 40GN, which I believe supports a 100MHz
bus. The "idebus=66" never made a difference afaict.
Aside from the slower harddrive (see details below), I've had no issues
with this kernel.
Is there a workaround for the dma, or something I'm missing? Incidentally,
it would be handy to have a bit more information in dmesg, along the lines
of the 2.4 kernel -- chipset, dma and bus speed per drive.
Cheers,
Peter
dmesg 2.5.69:
Kernel command line: root=/dev/hda5 ro hdc=scsi idebus=66 resume=/dev/hda6
ide_setup: hdc=scsi
ide_setup: idebus=66
No local APIC present or hardware disabled
PCI: PCI BIOS revision 2.10 entry at 0xfd88e, last bus=1
PCI: Using configuration type 1
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 66MHz system bus speed for PIO modes
hda: IC25N040ATCS04-0, ATA DISK drive
hdc: MATSHITACD-RW CW-8121, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: host protected area => 1
hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=77520/16/63
hda: hda1 hda2 < hda5 hda6 hda7 > hda3 hda4
ide-cd: passing drive hdc to ide-scsi emulation.
hdparm -i claims to be using dma5:
hdparm -i /dev/hda
/dev/hda:
Model=IC25N040ATCS04-0, FwRev=CA4OA71A, SerialNo=CSH405DCLW5UVB
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=1768kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78140160
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 3: 2 3 4 5
In contrast, hdparm /dev/hda claims dma is off:
# hdparm /dev/hda
/dev/hda:
multcount = 0 (off)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 11984/16/63, sectors = 78140160, start = 0
The disk read speed in 2.5.69 indicates dma is off:
# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.46 seconds =280.74 MB/sec
Timing buffered disk reads: 64 MB in 20.18 seconds = 3.17 MB/sec
# cat kernel-2.5.69.config | grep DMA
CONFIG_GENERIC_ISA_DMA=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
CONFIG_BLK_DEV_ADMA=y
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
Here's what 2.4.20 produces:
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 66MHz system bus speed for PIO modes
ALI15X3: IDE controller on PCI bus 00 dev 80
PCI: No IRQ known for interrupt pin A of device 00:10.0.
ALI15X3: chipset revision 196
ALI15X3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:pio, hdd:pio
hda: IC25N040ATCS04-0, ATA DISK drive
hdc: MATSHITACD-RW CW-8121, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c0335ee4, I/O limit 4095Mb (mask 0xffffffff)
hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=4864/255/63, UDMA(33)
Disk information under 2.4.20 -- claims to be using dma2:
Model=IC25N040ATCS04-0, FwRev=CA4OA71A, SerialNo=CSH405DCLW5UVB
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=1768kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78140160
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 3: 2 3 4 5
This fits with the disk read speed:
Timing buffer-cache reads: 128 MB in 0.44 seconds =290.91 MB/sec
Timing buffered disk reads: 64 MB in 3.22 seconds = 19.88 MB/sec
cat kernel-2.4.20-5-5.config | grep DMA
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
# CONFIG_SOUND_DMAP is not set
It seems you forgot to compile in support for ALI chipset.
Make sure you have CONFIG_BLK_DEV_ALI15X3=y in your config.
If it doesn't help let me know.
Please also read below...
On Thu, 22 May 2003, Peter wrote:
> The 2.5.69 kernel kicks butt -- Debian is now releasing a version in sid
> and it runs stable on my vpr matrix 205A laptop. What works: nfs, samba,
> v4l, the nVidia driver (patched), everything I've tested so far. And sound
> -- the ALSA sound is great (headphone jack still dead). ACPI now detects
> my battery, and I'm working on software suspend.
>
> The ALI chipset (1671 northbridge, 1533 ISA bridge, 5229 IDE interface,
> 7101 bridge) gives me
> DMA 33 with 2.4.20:
>
> hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=4864/255/63, UDMA(33)
>
> but no dma with 2.5.69. Timing buffered disk reads now come in at
> 3.17MB/s -- in 2.4.20 I get 19.88 MB/sec. hdparm gives part number
> IC25N040ATCS04-0, a Travelstar 40GN, which I believe supports a 100MHz
> bus. The "idebus=66" never made a difference afaict.
>
> Aside from the slower harddrive (see details below), I've had no issues
> with this kernel.
>
> Is there a workaround for the dma, or something I'm missing? Incidentally,
> it would be handy to have a bit more information in dmesg, along the lines
> of the 2.4 kernel -- chipset, dma and bus speed per drive.
>
> Cheers,
> Peter
>
>
>
>
> dmesg 2.5.69:
>
> Kernel command line: root=/dev/hda5 ro hdc=scsi idebus=66 resume=/dev/hda6
> ide_setup: hdc=scsi
> ide_setup: idebus=66
> No local APIC present or hardware disabled
>
> PCI: PCI BIOS revision 2.10 entry at 0xfd88e, last bus=1
> PCI: Using configuration type 1
>
> PCI: Using ACPI for IRQ routing
> PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
>
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 66MHz system bus speed for PIO modes
> hda: IC25N040ATCS04-0, ATA DISK drive
> hdc: MATSHITACD-RW CW-8121, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: host protected area => 1
> hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=77520/16/63
> hda: hda1 hda2 < hda5 hda6 hda7 > hda3 hda4
> ide-cd: passing drive hdc to ide-scsi emulation.
Interfaces were taken by generic code, no ALI driver here.
> hdparm -i claims to be using dma5:
>
> hdparm -i /dev/hda
>
> /dev/hda:
>
> Model=IC25N040ATCS04-0, FwRev=CA4OA71A, SerialNo=CSH405DCLW5UVB
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
> BuffType=DualPortCache, BuffSize=1768kB, MaxMultSect=16, MultSect=off
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78140160
> IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2
> UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
> AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
> Drive conforms to: ATA/ATAPI-5 T13 1321D revision 3: 2 3 4 5
>
> In contrast, hdparm /dev/hda claims dma is off:
>
> # hdparm /dev/hda
>
> /dev/hda:
> multcount = 0 (off)
> IO_support = 0 (default 16-bit)
> unmaskirq = 0 (off)
> using_dma = 0 (off)
> keepsettings = 0 (off)
> readonly = 0 (off)
> readahead = 256 (on)
> geometry = 11984/16/63, sectors = 78140160, start = 0
>
> The disk read speed in 2.5.69 indicates dma is off:
>
> # hdparm -tT /dev/hda
>
> /dev/hda:
> Timing buffer-cache reads: 128 MB in 0.46 seconds =280.74 MB/sec
> Timing buffered disk reads: 64 MB in 20.18 seconds = 3.17 MB/sec
>
> # cat kernel-2.5.69.config | grep DMA
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> # CONFIG_BLK_DEV_IDEDMA_FORCED is not set
> CONFIG_IDEDMA_PCI_AUTO=y
> # CONFIG_IDEDMA_ONLYDISK is not set
> CONFIG_BLK_DEV_IDEDMA=y
> # CONFIG_IDEDMA_PCI_WIP is not set
> CONFIG_BLK_DEV_ADMA=y
> CONFIG_IDEDMA_AUTO=y
> # CONFIG_IDEDMA_IVB is not set
> # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
>
> Here's what 2.4.20 produces:
>
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 66MHz system bus speed for PIO modes
> ALI15X3: IDE controller on PCI bus 00 dev 80
> PCI: No IRQ known for interrupt pin A of device 00:10.0.
> ALI15X3: chipset revision 196
> ALI15X3: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:pio, hdd:pio
> hda: IC25N040ATCS04-0, ATA DISK drive
> hdc: MATSHITACD-RW CW-8121, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> blk: queue c0335ee4, I/O limit 4095Mb (mask 0xffffffff)
> hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=4864/255/63, UDMA(33)
ALI driver compiled in.
> Disk information under 2.4.20 -- claims to be using dma2:
>
> Model=IC25N040ATCS04-0, FwRev=CA4OA71A, SerialNo=CSH405DCLW5UVB
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
> BuffType=DualPortCache, BuffSize=1768kB, MaxMultSect=16, MultSect=16
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78140160
> IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2
> UDMA modes: udma0 udma1 *udma2 udma3 udma4 udma5
> AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
> Drive conforms to: ATA/ATAPI-5 T13 1321D revision 3: 2 3 4 5
>
> This fits with the disk read speed:
>
> Timing buffer-cache reads: 128 MB in 0.44 seconds =290.91 MB/sec
> Timing buffered disk reads: 64 MB in 3.22 seconds = 19.88 MB/sec
>
> cat kernel-2.4.20-5-5.config | grep DMA
'grep DMA' is really not sufficient,
you need driver for your IDE chipset first.
Regards,
--
Bartlomiej
> CONFIG_BLK_DEV_IDEDMA_PCI=y
> # CONFIG_BLK_DEV_IDEDMA_FORCED is not set
> CONFIG_IDEDMA_PCI_AUTO=y
> # CONFIG_IDEDMA_ONLYDISK is not set
> CONFIG_BLK_DEV_IDEDMA=y
> # CONFIG_IDEDMA_PCI_WIP is not set
> # CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set
> # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
> CONFIG_BLK_DEV_ADMA=y
> # CONFIG_HPT34X_AUTODMA is not set
> CONFIG_IDEDMA_AUTO=y
> # CONFIG_IDEDMA_IVB is not set
> # CONFIG_DMA_NONPCI is not set
> # CONFIG_SCSI_EATA_DMA is not set
> # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
> # CONFIG_SOUND_DMAP is not set
I had included kernel support for the ALI 15X3 chipset, but as a module --
and it obviously didn't load. If I include the module in /etc/modules, it
loads too late (details below). I'm assuming this means "make menuconfig"
mistakenly provides the module option? I've recompiled it into the kernel
and got DMA back (although only dma2, as before) -- thanks for the quick
feedback!
Cheers,
Peter
Details on what happens when you compile ALI 15X3 as a module -- I'm
guessing this should not be an option?
A. Should the module have loaded automatically? I had
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
B. I then included the module in /etc/modules and got this in dmesg:
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 66MHz system bus speed for PIO modes
hda: IC25N040ATCS04-0, ATA DISK drive
hdc: MATSHITACD-RW CW-8121, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: host protected area => 1
hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=77520/16/63
-- that is to say, no change in first pass detection. Then this:
ALI15X3: IDE controller at PCI slot 00:10.0
ACPI: No IRQ known for interrupt pin A of device 00:10.0
ALI15X3: chipset revision 196
ALI15X3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1840-0x1847, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:pio, hdd:pio
ide0: I/O resource 0x1F0-0x1F0 not free.
I guess it was too late.
So no performance improvement:
# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.46 seconds =275.90 MB/sec
Timing buffered disk reads: 64 MB in 19.69 seconds = 3.25 MB/sec
lsmod:
alim15x3 7052 1 [unsafe]
On Thu, 22 May 2003, Peter wrote:
> I had included kernel support for the ALI 15X3 chipset, but as a module --
> and it obviously didn't load. If I include the module in /etc/modules, it
> loads too late (details below). I'm assuming this means "make menuconfig"
> mistakenly provides the module option? I've recompiled it into the kernel
Module support for IDE chipsets is currently unfinished/broken.
Lot of things need fixing before we will have _correct_ module support.
If we won't manage to do it for 2.6, option for compiling them as
modules will backed out.
> and got DMA back (although only dma2, as before) -- thanks for the quick
> feedback!
>
> Cheers,
> Peter
Cheers,
--
Bartlomiej
The kernel compiled with no errors. On booting, I got this:
ACPI: Subsystem revision 20030619
ACPI breakpoint: Executed AML Breakpoint opcode
If I just wanted to boot, which option should I disable?
This is a vpr matrix 200a5 laptop with an ALi M1671 chipset and various
ACPI options enabled, including CONFIG_X86_P4_CLOCKMOD=m. Details below.
2.5.69 has been running fine for a long time now, but there are some new
ACPI options.
Cheers,
Peter
System:
00:00.0 Host bridge: ALi Corporation M1671 Super P4 Northbridge [AGP4X,PCI and SDR/DDR] (rev 02)
00:01.0 PCI bridge: ALi Corporation PCI to AGP Controller
00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02)
00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV]
00:09.0 Network controller: Harris Semiconductor Prism 2.5 Wavelan chipset (rev 01)
00:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)
00:0b.0 USB Controller: VIA Technologies, Inc. USB (rev 50)
00:0b.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
00:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
00:11.0 Bridge: ALi Corporation M7101 PMU
00:12.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go 32M] (rev a3)
Configuration:
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
#
# ACPI Support
#
CONFIG_ACPI=y
# CONFIG_ACPI_HT_ONLY is not set
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
# CONFIG_APM is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
# CONFIG_CPU_FREQ_PROC_INTF is not set
CONFIG_CPU_FREQ_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_24_API is not set
CONFIG_CPU_FREQ_TABLE=y
#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
CONFIG_X86_P4_CLOCKMOD=m
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
> The point of the test versions is to make more people realize that they
> need testing
Are all the known security issues in 2.4 now fixed in 2.6.0-test1?
This has been the only major reason for keeping of most of my
production machines running 2.4 for quite a while. If not, can we get
the fixes in at the earliest opportunity?
John.
On Llu, 2003-07-14 at 12:01, John Bradford wrote:
> > The point of the test versions is to make more people realize that they
> > need testing
>
> Are all the known security issues in 2.4 now fixed in 2.6.0-test1?
No, and several more have been added in 2.6-test only.
> This has been the only major reason for keeping of most of my
> production machines running 2.4 for quite a while. If not, can we get
> the fixes in at the earliest opportunity?
Sure.. send the fixes to Linus
> > > The point of the test versions is to make more people realize that they
> > > need testing
> >
> > Are all the known security issues in 2.4 now fixed in 2.6.0-test1?
>
> No, and several more have been added in 2.6-test only.
As far as I know, they are only information disclosure ones, not
directly exploitable vulnerabilities, or am I wrong?
> > This has been the only major reason for keeping of most of my
> > production machines running 2.4 for quite a while. If not, can we get
> > the fixes in at the earliest opportunity?
>
> Sure.. send the fixes to Linus
Is anybody even keeping track of this, though? Picking thorough LKML
to see what did and didn't go in doesn't seem particularly exciting to
me.
John.
On Llu, 2003-07-14 at 12:39, John Bradford wrote:
> > > > The point of the test versions is to make more people realize that they
> > > > need testing
> > >
> > > Are all the known security issues in 2.4 now fixed in 2.6.0-test1?
> >
> > No, and several more have been added in 2.6-test only.
>
> As far as I know, they are only information disclosure ones, not
> directly exploitable vulnerabilities, or am I wrong?
Last time I checked there were remote DoS attacks and local root attacks
present in 2.5.7x
> > > This has been the only major reason for keeping of most of my
> > > production machines running 2.4 for quite a while. If not, can we get
> > > the fixes in at the earliest opportunity?
> >
> > Sure.. send the fixes to Linus
>
> Is anybody even keeping track of this, though? Picking thorough LKML
> to see what did and didn't go in doesn't seem particularly exciting to
> me.
Then you'll just have to wait a few months
> Then you'll just have to wait a few months
Oh well, it just seems strange to be asking people to test
2.6.0-root-my-box, without making the consequences a bit clearer.
John.
On Mon, Jul 14, 2003 at 12:50:40PM +0100, John Bradford wrote:
> > Then you'll just have to wait a few months
>
> Oh well, it just seems strange to be asking people to test
> 2.6.0-root-my-box, without making the consequences a bit clearer.
>From http://www.codemonkey.org.uk/post-halloween-2.5.txt
------ 8< 8< 8< 8< ------
Security concerns.
~~~~~~~~~~~~~~~~~~
Several security issues solved in 2.4 may not yet be forward ported
to 2.5. For this reason 2.5.x kernels should not be tested on
untrusted systems. Testing known 2.4 exploits and reporting results
is useful.
------ 8< 8< 8< 8< ------
If you don't have the time/energy to trawl linux-kernel, testing the
many zillions of `sploits out there to see what works and what doesn't
may be more fun. (Although most if not all should be failing, so it
may also get boring very quickly). It'd be nice if someone like osdl
could add such testing to nightly regression tests. Some of them may
even be candidates for LTP perhaps ?
Dave
On Mon, Jul 14, 2003 at 12:50:40PM +0100, John Bradford wrote:
>> Oh well, it just seems strange to be asking people to test
>> 2.6.0-root-my-box, without making the consequences a bit clearer.
On Mon, Jul 14, 2003 at 12:53:13PM +0100, Dave Jones wrote:
> If you don't have the time/energy to trawl linux-kernel, testing the
> many zillions of `sploits out there to see what works and what doesn't
> may be more fun. (Although most if not all should be failing, so it
> may also get boring very quickly). It'd be nice if someone like osdl
> could add such testing to nightly regression tests. Some of them may
> even be candidates for LTP perhaps ?
Some work has been done here, though I'm not sure how much; I'll try to
get the IBM people involved with it to chime in.
-- wli
On Llu, 2003-07-14 at 13:00, William Lee Irwin III wrote:
> Some work has been done here, though I'm not sure how much; I'll try to
> get the IBM people involved with it to chime in.
The IBM india folks (being outside the DMCA zone) went through a long list of
fixes and propogated them but there are lots of others some pretty critical such
as the fs/exec stuff and proc leaks
On Llu, 2003-07-14 at 13:00, William Lee Irwin III wrote:
>> Some work has been done here, though I'm not sure how much; I'll try to
>> get the IBM people involved with it to chime in.
On Mon, Jul 14, 2003 at 01:39:44PM +0100, Alan Cox wrote:
> The IBM india folks (being outside the DMCA zone) went through a long list of
> fixes and propogated them but there are lots of others some pretty critical such
> as the fs/exec stuff and proc leaks
Well, that should cover it. Odd that I've not heard of those two.
-- wli
On Llu, 2003-07-14 at 12:50, John Bradford wrote:
> > Then you'll just have to wait a few months
>
> Oh well, it just seems strange to be asking people to test
> 2.6.0-root-my-box, without making the consequences a bit clearer.
Its 2.6.0 locally root my box, not remotely root my box, although remote
crash bugs exist in at least one situation
On Llu, 2003-07-14 at 13:47, William Lee Irwin III wrote:
> Well, that should cover it. Odd that I've not heard of those two.
They've had publically discussed fixes, patch files, CAN vulnerability
identifiers and mail to bugtraq. The information is out there but the
2.5 people have been too busy on more fundamental stuff I guess
this one was posted on full-disclosure a while ago
i think this is what alan cox means with
fs/exec stuff
:)
---------- Forwarded Message ----------
From: Paul Starzetz <[email protected]>
To: [email protected],
vendor-sec <[email protected]>,
[email protected]
Date: Thu, 26 Jun 2003 19:24:23 +0200
Hi people,
again it is time to discover a funny bug inside the Linux execve()
system call.
Details:
- ---------
While looking at the execve() code I've found the following piece of
code (from fs/binfmt_elf.c):
static int load_elf_binary(struct linux_binprm * bprm, struct pt_regs *
regs)
{
struct file *interpreter = NULL; /* to shut gcc up */
[...]
retval = kernel_read(bprm->file, elf_ex.e_phoff, (char *)
elf_phdata, size);
if (retval < 0)
goto out_free_ph;
retval = get_unused_fd();
if (retval < 0)
goto out_free_ph;
get_file(bprm->file);
fd_install(elf_exec_fileno = retval, bprm->file);
So, during the execution of new binary, the opened file descriptor to
the executable is put into the file table of the current (the caller of
execve()) process. This can be exploited creating a file sharing
parent/child pair by means of the clone() syscall and reading the file
descriptor from one of them.
Further, the check for shared files structure (in compute_creds() from
exec.c) is made to late, so even the parent can successfully exit after
playing games on that file descriptor and the child (if setuid) is
executed under full privileges. I wrote a simple setuid binary dump
utility so far, but further implications (due to the complexity of the
execve() syscall) may be possible...
Lets illustrate the vulnerability:
paul@buggy:~> ls -l /bin/ping
- -rws--x--x 1 root root 29680 Oct 25 2001 /bin/ping
so the setuid ping binary can be only executed by anyone, but not read.
Now we start the suid dumper (while playing with the disk on another
console like cat /usr/bin/* >/dev/null) :
paul@buggy:~> while true ; do ./suiddmp /bin/ping -c 1 127.0.0.1 ; if
test $? -eq 1 ; then exit 1 ; fi; done 2>/dev/null | grep -A5 suc
and after few seconds:
Parent success stating:
uid 0 gid 0 mode 104711 inode 9788 size 29680
PING 127.0.0.1 (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=94 usec
- --- 127.0.0.1 ping statistics ---
paul@buggy:~> ls -l
total 7132
- -rwxr-xr-x 1 paul users 29680 Jun 26 19:17 suid.dump
[...]
paul@buggy:~> ./suid.dump
Usage: ping [-LRUbdfnqrvVaA] [-c count] [-i interval] [-w deadline]
[-p pattern] [-s packetsize] [-t ttl] [-I interface or address]
[-M mtu discovery hint] [-S sndbuf]
[ -T timestamp option ] [ -Q tos ] [hop1 ...] destination
Obviously the setuid binary has been duplicated :-) (but with no setuid
flag of course).
Source also available at:
http://www.starzetz.com/paul/suiddmp.c
/ih
-------------------------------------------------------
On Mon, 14 Jul 2003, Alan Cox wrote:
> On Llu, 2003-07-14 at 12:39, John Bradford wrote:
> > > > > The point of the test versions is to make more people realize that they
> > > > > need testing
> > > >
> > > > Are all the known security issues in 2.4 now fixed in 2.6.0-test1?
> > >
> > > No, and several more have been added in 2.6-test only.
> >
> > As far as I know, they are only information disclosure ones, not
> > directly exploitable vulnerabilities, or am I wrong?
>
> Last time I checked there were remote DoS attacks and local root attacks
> present in 2.5.7x
>
> > > > This has been the only major reason for keeping of most of my
> > > > production machines running 2.4 for quite a while. If not, can we get
> > > > the fixes in at the earliest opportunity?
> > >
> > > Sure.. send the fixes to Linus
> >
> > Is anybody even keeping track of this, though? Picking thorough LKML
> > to see what did and didn't go in doesn't seem particularly exciting to
> > me.
>
> Then you'll just have to wait a few months
I will start looking at 2.4 security fixes which are not applied in 2.6.
If someone is already doing that, please tell me.
On Llu, 2003-07-14 at 14:56, Marcelo Tosatti wrote:
> > Then you'll just have to wait a few months
>
> I will start looking at 2.4 security fixes which are not applied in 2.6.
>
> If someone is already doing that, please tell me.
I'm working on the recent exec and proc stuff. strncpy needs people who can
do their native asm though.
On Mon, 14 Jul 2003, Alan Cox wrote:
> On Llu, 2003-07-14 at 14:56, Marcelo Tosatti wrote:
> > > Then you'll just have to wait a few months
> >
> > I will start looking at 2.4 security fixes which are not applied in 2.6.
> >
> > If someone is already doing that, please tell me.
>
> I'm working on the recent exec and proc stuff. strncpy needs people who can
> do their native asm though.
Right. I'll look at any other possible (misc) security problem which is
fixed in 2.4.
Quoth John Bradford:
> > Then you'll just have to wait a few months
>
> Oh well, it just seems strange to be asking people to test
> 2.6.0-root-my-box, without making the consequences a bit clearer.
And it seems equally odd actually to put an unstable kernel on a
production system.
Kurt
--
He had occasional flashes of silence that made his conversation
perfectly delightful.
-- Sydney Smith
This is on the ALim15x3 with the 2.5.69 kernel on a vpr matrix 200a5
laptop -- I just did this to get DMA5:
* set ide0=ata66 in lilo to get the 100MHz bus and DMA5
* add "hdparm -c 1 -m 16 -S 242 -k 1 /dev/hda" to /etc/init.d/bootmisc.sh
Nice results:
hda: 78140160 sectors (40008 MB) w/1768KiB Cache, CHS=77520/16/63, UDMA(100)
# hdparm -i /dev/hda
/dev/hda:
Model=IC25N040ATCS04-0, FwRev=CA4OA71A, SerialNo=CSH405DCLW5UVB
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=1768kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78140160
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
Drive conforms to: ATA/ATAPI-5 T13 1321D revision 3: 2 3 4 5
# hdparm -tT /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.45 seconds =283.23 MB/sec
Timing buffered disk reads: 64 MB in 3.23 seconds = 19.79 MB/sec
# hdparm /dev/hda
/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 1 (on)
readonly = 0 (off)
readahead = 256 (on)
geometry = 11984/16/63, sectors = 78140160, start = 0
Cheers,
Peter
Hello!
Using devfs, there are neither device-nodes for the ZIP-drive using
ide-floppy nor for cpuid or msr. Are there any patches i can try (i
didn't find patches for ide-floppy).
Best regards,
--
/"\
Dirk Meul \ / ASCII Ribbon Campaign
[email protected] X Against HTML Mail
/ \
Hi,
Can you try this patch? It seems
--- alim15x3.c.orig 2003-04-20 04:49:10.000000000 +0200
+++ alim15x3.c 2003-07-16 00:39:15.351639072 +0200
@@ -753,7 +753,8 @@
return;
}
- hwif->atapi_dma = 1;
+ if (m5229_revision <= 0x20)
+ hwif->atapi_dma = 1;
if (m5229_revision > 0x20)
hwif->ultra_mask = 0x3f;
On Wed, 16 Jul 2003, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> Can you try this patch? It seems
It seems it won't help.
What was the last kernel which worked without "ide=nodma"?
Regards,
--
Bartlomiej
On Wed, Jul 16, 2003 at 12:58:53AM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> Can you try this patch? It seems
>
You're messages seems to have been cut. I should have sent the following
along with my initial posting:
$ lspci -v
00:00.0 Host bridge: ALi Corporation M1531 [Aladdin IV] (rev b3)
Subsystem: ALi Corporation M1531 [Aladdin IV]
Flags: bus master, slow devsel, latency 32
00:02.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV] (rev b4)
Flags: bus master, medium devsel, latency 0
00:05.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01) (prog-if 00 [VGA])
Subsystem: S3 Inc. ViRGE/DX
Flags: bus master, medium devsel, latency 64
Memory at ec000000 (32-bit, non-prefetchable) [size=64M]
Expansion ROM at ebff0000 [disabled] [size=64K]
00:06.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
Subsystem: D-Link System Inc DFE-530TX+ 10/100 Ethernet Adapter
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at ec00 [size=256]
Memory at ebfeff00 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
00:0b.0 IDE interface: ALi Corporation M5229 IDE (rev 20) (prog-if fa)
Flags: bus master, medium devsel, latency 32
I/O ports at ffa0 [size=16]
$
If I'm reading the lspci output correctly the patch won't have any effect
on my machine because the m5229 interface is at rev 0x20, so the test in
the if block will succeed and the atapi_dma variable is set to 1 just
like it is currently. I'll still recompile and try if you like; let me
know.
> --- alim15x3.c.orig 2003-04-20 04:49:10.000000000 +0200
> +++ alim15x3.c 2003-07-16 00:39:15.351639072 +0200
> @@ -753,7 +753,8 @@
> return;
> }
>
> - hwif->atapi_dma = 1;
> + if (m5229_revision <= 0x20)
> + hwif->atapi_dma = 1;
>
> if (m5229_revision > 0x20)
> hwif->ultra_mask = 0x3f;
>
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
On Wed, Jul 16, 2003 at 01:12:09AM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> It seems it won't help.
>
> What was the last kernel which worked without "ide=nodma"?
>
I've been using the 2.5 series for a long time now, but I have vague
memories of not needing to use 'ide=nodma' before this patch was added:
===== setup-pci.c 1.5 vs 1.6 =====
--- 1.5/drivers/ide/setup-pci.c Sat Sep 21 07:59:59 2002
+++ 1.6/drivers/ide/setup-pci.c Tue Sep 24 09:24:57 2002
@@ -250,6 +250,7 @@
switch(dev->device) {
case PCI_DEVICE_ID_AL_M5219:
+ case PCI_DEVICE_ID_AL_M5229:
case PCI_DEVICE_ID_AMD_VIPER_7409:
case PCI_DEVICE_ID_CMD_643:
case PCI_DEVICE_ID_SERVERWORKS_CSB5IDE:
I don't recall which kernel brought this change, and I can't swear that
this recollection is correct.
I'd received mail from another person stating that the ALi DMA is broken
from many old chips, but that it is only the UDMA stuff that is broken,
and the MW_DMA stuff works. Also the notes about the 2.6 transition
indicate ali15x3 and DMA don't always play nicely together. Still,
if the MW_DMA stuff works, some hdparm trickery like ...
# hdparm -d1 -X34 /dev/hda
... would supposedly activate working DMA. I really screwed up my
machine once by fooling around with hdparm so I'm very hesitant to go in
and start trying hdparm commands without some expert guidance.
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
On Tue, 2003-07-15 at 09:52, Dirk Meul wrote:
> Hello!
>
> Using devfs, there are neither device-nodes for the ZIP-drive using
> ide-floppy nor for cpuid or msr. Are there any patches i can try (i
> didn't find patches for ide-floppy).
>
Check here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105810954902637&w=2
--
Martin Schlemmer
On Tue, Jul 15, 2003 at 06:32:02PM -0500, Art Haas wrote:
> I've been using the 2.5 series for a long time now, but I have vague
> memories of not needing to use 'ide=nodma' before this patch was added:
>
> ===== setup-pci.c 1.5 vs 1.6 =====
> --- 1.5/drivers/ide/setup-pci.c Sat Sep 21 07:59:59 2002
> +++ 1.6/drivers/ide/setup-pci.c Tue Sep 24 09:24:57 2002
> @@ -250,6 +250,7 @@
>
> switch(dev->device) {
> case PCI_DEVICE_ID_AL_M5219:
> + case PCI_DEVICE_ID_AL_M5229:
> case PCI_DEVICE_ID_AMD_VIPER_7409:
> case PCI_DEVICE_ID_CMD_643:
> case PCI_DEVICE_ID_SERVERWORKS_CSB5IDE:
Hmm, interesting. This line has been added at early stage of IDE rewrite
to work around some unrelated bug, IIRC. I strongly suspect that it's
not needed anymore (will verify it later today), and it also might explain
weird DMA breakage with older ALi chips.
BTW, have you tried recent 2.4 kernels? Looks like this line should be
removed in 2.4 as well.
Ivan.
On Mer, 2003-07-16 at 00:32, Art Haas wrote:
> I'd received mail from another person stating that the ALi DMA is broken
> from many old chips, but that it is only the UDMA stuff that is broken,
The older chips dont do UDMA. Then a lot of the next range of chips do
UDMA but not 48bit command so you can end up in PIO mode. Possibly our
logic for this needs tightening now we use lba28 commands whenever
possible, so an LBA48 capable disk under LBA48 limit size is drivable
entirely in LBA28 safely.
> and the MW_DMA stuff works. Also the notes about the 2.6 transition
> indicate ali15x3 and DMA don't always play nicely together. Still,
> if the MW_DMA stuff works, some hdparm trickery like ...
Simplex DMA needs some fixing for one. That should only bite you if you
have a set up something like
hda -> unused
hdb -> unused
hdc -> DISK
hdd -> unused
in which case we assign the DMA engine to hda/hdb!
On Wed, Jul 16, 2003 at 02:20:36AM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> > I've been using the 2.5 series for a long time now, but I have vague
> > memories of not needing to use 'ide=nodma' before this patch was added:
>
> I don't think so, but you can safely revert this chunk and check.
>
> > ===== setup-pci.c 1.5 vs 1.6 =====
> > --- 1.5/drivers/ide/setup-pci.c Sat Sep 21 07:59:59 2002
> > +++ 1.6/drivers/ide/setup-pci.c Tue Sep 24 09:24:57 2002
> > @@ -250,6 +250,7 @@
> >
> > switch(dev->device) {
> > case PCI_DEVICE_ID_AL_M5219:
> > + case PCI_DEVICE_ID_AL_M5229:
> > case PCI_DEVICE_ID_AMD_VIPER_7409:
> > case PCI_DEVICE_ID_CMD_643:
> > case PCI_DEVICE_ID_SERVERWORKS_CSB5IDE:
> >
I built a new kernel with this line commented out and booted up this new
kernel. Sadly the problem remained. Trying this kernel with the
'ide0=autotune' was also unsuccessful. For the curious, the kernel gets
to the point where the drive partitions are examined and then things go
splat. A sample of the messages ...
hda: dma_timer_expiry: dma_status == 0x20
hda: (__ide_dma_test_irq) called while not waiting
hda: drive not ready for command
hda: lost interrupt
Things limp along as the partitions on the hda drive are gradually
printed out, but there is one change in the kernel messages
hda: dma_timer_expiry: dma_status == 0x21
I'll try modifing the ali15x3 driver with the patch you sent and see how
that goes.
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
On Wed, Jul 16, 2003 at 02:20:36AM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> I spotted following difference between old (<=2.4.20) and new
> (>=2.4.21 and 2.6) code. Just a guess...
>
> --- alim15x3.c.orig 2003-04-20 04:49:10.000000000 +0200
> +++ alim15x3.c 2003-07-16 02:09:05.411225464 +0200
> @@ -595,6 +595,26 @@
>
> local_irq_save(flags);
>
> + /*
> + * CD_ROM DMA on (m5229, 0x53, bit0)
> + * Enable this bit even if we want to use PIO
> + * PIO FIFO off (m5229, 0x53, bit1)
> + * The hardware will use 0x54h and 0x55h to control PIO FIFO
> + * (Not on later devices it seems)
> + *
> + * 0x53 changes meaning on later revs - we must no touch
> + * bit 1 on them. Need to check if 0x20 is the right break
> + */
> +
> + pci_read_config_byte(dev, 0x53, &tmpbyte);
> +
> + if (m5229_revision <= 0x20)
> + tmpbyte = (tmpbyte & (~0x02)) | 0x01;
> + else
> + tmpbyte |= 0x01;
> +
> + pci_write_config_byte(dev, 0x53, tmpbyte);
> +
> if (m5229_revision < 0xC2) {
> /*
> * revision 0x20 (1543-E, 1543-F)
> @@ -706,26 +726,6 @@
> chip_is_1543c_e = ((tmpbyte & 0x1e) == 0x12) ? 1: 0;
> }
>
> - /*
> - * CD_ROM DMA on (m5229, 0x53, bit0)
> - * Enable this bit even if we want to use PIO
> - * PIO FIFO off (m5229, 0x53, bit1)
> - * The hardware will use 0x54h and 0x55h to control PIO FIFO
> - * (Not on later devices it seems)
> - *
> - * 0x53 changes meaning on later revs - we must no touch
> - * bit 1 on them. Need to check if 0x20 is the right break
> - */
> -
> - pci_read_config_byte(dev, 0x53, &tmpbyte);
> -
> - if(m5229_revision <= 0x20)
> - tmpbyte = (tmpbyte & (~0x02)) | 0x01;
> - else
> - tmpbyte |= 0x01;
> -
> - pci_write_config_byte(dev, 0x53, tmpbyte);
> -
> local_irq_restore(flags);
>
> return(ata66);
>
Apply this patch and rebooting with this new kernel made no difference.
I tried a few more things as well:
Disconnect CD-ROM: Same problem as before.
Boot with 'ide0=autotune': Same problem as before
I was e-mailed a suggestion to try booting with 'noapic', and that
didn't help either. I'm currently running the patched kernel booted with
the 'ide=nodma' argument.
As things just go to pieces when reading the hard drive, maybe someone
knows if this hard drive model has known DMA issues. When starting the
machine the screens before my lilo prompt print out that the hard drive
should do UDMA. The hard drive on the ide1 channel seems to present no
problem to the ALi controller. Here is agin the hdparm info on my
troublesome drive:
$ hdparm -I /dev/hda
/dev/hda:
ATA device, with non-removable media
Model Number: ST33232A
Serial Number: GH593339
Firmware Revision: 3.02
Standards:
Supported: 2 1
Likely used: 4
Configuration:
Logical max current
cylinders 6253 6253
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 6303024
LBA user addressable sectors: 6303024
device size with M = 1024*1024: 3077 MBytes
device size with M = 1000*1000: 3227 MBytes (3 GB)
Capabilities:
LBA, IORDY(can be disabled)
Buffer size: 128.0kB bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Vendor
R/W multiple sector transfer: Max = 16 Current = 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=383ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
Power Management feature set
SMART feature set
This hard drive is from 1996/1997; it is the original hard drive I built
this machine with. The 'Standards' line above looks odd - a clue
perhaps?
The second hard drive I added about 3 years ago. Here is info on it:
$ hdparm -I /dev/hdc
/dev/hdc:
ATA device, with non-removable media
Model Number: FUJITSU MPD3084AT
Serial Number: 05043987
Firmware Revision: DD-03-47
Standards:
Supported: 4 3 2 1
Likely used: 4
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 16514064
device size with M = 1024*1024: 8063 MBytes
device size with M = 1000*1000: 8455 MBytes (8 GB)
Capabilities:
LBA, IORDY(cannot be disabled)
Buffer size: 512.0kB bytes avail on r/w long: 4 Queue depth: 1
Standby timer values: spec'd by Vendor
R/W multiple sector transfer: Max = 16 Current = ?
Advanced power management level: unknown setting (0x0000)
DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
READ BUFFER cmd
WRITE BUFFER cmd
Host Protected Area feature set
* Look-ahead
* Write cache
Power Management feature set
Security Mode feature set
* SMART feature set
Advanced Power Management feature set
Security:
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
24min for SECURITY ERASE UNIT.
If the hard drives seem to be alright, maybe there is some sort of BIOS
thing I should try? I've poked around in the BIOS setup numerous times
but never found anything that I could change and make things work.
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822