[Kernel-packages] [Bug 1011225] Re: Again limited to UDMA/33 due to 40-wire cable
In case anyone is interested I may have figured out why this is
happening. The problem is related to a BIOS setting and the SATA port
the hard drive is connected to on the motherboard. In your BIOS
settings you will find a setting called sata ide combined mode. If it
is enabled it causes SATA ports 4 and 5 (and possibly 6) to act like
PATA compatible ports for SATA optical drives. So if you have an SATA
optical drive then keep the setting enabled and move your hard drives to
SATA ports 1, 2, or 3 and optical drive to 4 or 5. Anyway, this solved
it for me so hopefully someone else can try it out.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1011225
Title:
Again limited to UDMA/33 due to 40-wire cable
Status in “linux” package in Ubuntu:
Expired
Bug description:
I just made clean install on my new box for NAS routing and etc.
It is : Ubuntu 3.2.0-23.36-generic-pae 3.2.14 (ubuntu-12.04-server-i386)
My hardware is HP 5730 Thin Client
Sempron 2100+ ( 1 GHz )
HP Logic Board with SB600 and ATI RS690 with Radeon X1250 Series
512 MB RAM ( waiting for Memory 2GB)
HD SSD 120 GB SAMSUNG via PATASATA connector
I'm usung 80 wire cable with HD SSD with PATASATA connector, but also for
test I was connected few different 2,5 PATA drives directly, with all cases
the problem is ata1.00: limited to UDMA/33 due to 40-wire cable
In my other box ( ATV gen 1 with Crystalbuntu) all the disk work perfectly on
UDMA 5
I also tried with IDECF adapter putted direct to board with SanDisk UDMA133,
with the same results.
I tried to use some method from
http://www.pixca.net/bits-and-bytes/limited-to-udma33-due-to-40-wire-cable/
without success.
I also made some google research, and it seems that problem occurs in
PC with embedded AMD IDE Controller with many computers with different
cases etc. It's because probably that BIOS or IDE controller doesn't
provide proper information about 80-pin cable.
I will be glad to get some solution with this problem, maybe some
prompt about edit pata_atiixp.c to force 80-wire and compile.
Here is hdparm -i output:
/dev/sda:
Model=SAMSUNG SSD PB22-JS3 FDE 2.5 128GB, FwRev=VBM9LD1Q,
SerialNo=YFBB100947SY947A6641
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=250069680
IORDY=on/off, tPIO={min:120,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=no WriteCache=enabled
Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2,3,4,5,6,7
* signifies the current active mode
Here is dmesg output:
[0.135688] SCSI subsystem initialized
[0.135818] libata version 3.00 loaded.
[0.135939] usbcore: registered new interface driver usbfs
[0.135976] usbcore: registered new interface driver hub
[0.136062] usbcore: registered new device driver usb
[0.136307] PCI: Using ACPI for IRQ routing
[0.147472] PCI: pci_cache_line_size set to 64 bytes
[0.147584] reserve RAM buffer: 0009fc00 - 0009
[0.147591] reserve RAM buffer: 1dfe - 1fff
[0.147839] NetLabel: Initializing
[0.147850] NetLabel: domain hash size = 128
[0.147857] NetLabel: protocols = UNLABELED CIPSOv4
[0.147888] NetLabel: unlabeled traffic allowed by default
[0.165707] AppArmor: AppArmor Filesystem Enabled
[0.165795] pnp: PnP ACPI init
[0.165839] ACPI: bus type pnp registered
[0.166086] pnp 00:00: [bus 00-ff]
[0.166093] pnp 00:00: [io 0x0cf8-0x0cff]
[0.166099] pnp 00:00: [io 0x-0x0cf7 window]
[0.166104] pnp 00:00: [io 0x0d00-0x window]
[0.166110] pnp 00:00: [mem 0x000a-0x000b window]
[0.166116] pnp 00:00: [mem 0x000c-0x000d window]
[0.166122] pnp 00:00: [mem 0xe000-0x window]
[0.166224] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
[0.166381] pnp 00:01: [io 0x4100-0x411f]
[0.166387] pnp 00:01: [io 0x0228-0x022f]
[0.166392] pnp 00:01: [io 0x040b]
[0.166396] pnp 00:01: [io 0x04d6]
[0.166401] pnp 00:01: [io 0x0c00-0x0c01]
[0.166405] pnp 00:01: [io 0x0c14]
[0.166410] pnp 00:01: [io 0x0c50-0x0c52]
[0.166415] pnp 00:01: [io 0x0c6c-0x0c6d]
[0.166419] pnp 00:01: [io 0x0c6f]
[0.166430] pnp 00:01: [io 0x0cd0-0x0cd1]
[0.166434] pnp 00:01: [io 0x0cd2-0x0cd3]
[0.166439] pnp 00:01: [io 0x0cd4-0x0cdf]
[0.166444] pnp 00:01: [io 0x4000-0x40fe]
[0.166448] pnp 00:01: [io 0x4210-0x4217]
[0.166453] pnp 00:01: [io 0x0b10-0x0b1f]
[0.166459] pnp 00:01: [mem
[Kernel-packages] [Bug 1011225] Re: Again limited to UDMA/33 due to 40-wire cable
[Expired for linux (Ubuntu) because there has been no activity for 60
days.]
** Changed in: linux (Ubuntu)
Status: Incomplete = Expired
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1011225
Title:
Again limited to UDMA/33 due to 40-wire cable
Status in “linux” package in Ubuntu:
Expired
Bug description:
I just made clean install on my new box for NAS routing and etc.
It is : Ubuntu 3.2.0-23.36-generic-pae 3.2.14 (ubuntu-12.04-server-i386)
My hardware is HP 5730 Thin Client
Sempron 2100+ ( 1 GHz )
HP Logic Board with SB600 and ATI RS690 with Radeon X1250 Series
512 MB RAM ( waiting for Memory 2GB)
HD SSD 120 GB SAMSUNG via PATASATA connector
I'm usung 80 wire cable with HD SSD with PATASATA connector, but also for
test I was connected few different 2,5 PATA drives directly, with all cases
the problem is ata1.00: limited to UDMA/33 due to 40-wire cable
In my other box ( ATV gen 1 with Crystalbuntu) all the disk work perfectly on
UDMA 5
I also tried with IDECF adapter putted direct to board with SanDisk UDMA133,
with the same results.
I tried to use some method from
http://www.pixca.net/bits-and-bytes/limited-to-udma33-due-to-40-wire-cable/
without success.
I also made some google research, and it seems that problem occurs in
PC with embedded AMD IDE Controller with many computers with different
cases etc. It's because probably that BIOS or IDE controller doesn't
provide proper information about 80-pin cable.
I will be glad to get some solution with this problem, maybe some
prompt about edit pata_atiixp.c to force 80-wire and compile.
Here is hdparm -i output:
/dev/sda:
Model=SAMSUNG SSD PB22-JS3 FDE 2.5 128GB, FwRev=VBM9LD1Q,
SerialNo=YFBB100947SY947A6641
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=250069680
IORDY=on/off, tPIO={min:120,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=no WriteCache=enabled
Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2,3,4,5,6,7
* signifies the current active mode
Here is dmesg output:
[0.135688] SCSI subsystem initialized
[0.135818] libata version 3.00 loaded.
[0.135939] usbcore: registered new interface driver usbfs
[0.135976] usbcore: registered new interface driver hub
[0.136062] usbcore: registered new device driver usb
[0.136307] PCI: Using ACPI for IRQ routing
[0.147472] PCI: pci_cache_line_size set to 64 bytes
[0.147584] reserve RAM buffer: 0009fc00 - 0009
[0.147591] reserve RAM buffer: 1dfe - 1fff
[0.147839] NetLabel: Initializing
[0.147850] NetLabel: domain hash size = 128
[0.147857] NetLabel: protocols = UNLABELED CIPSOv4
[0.147888] NetLabel: unlabeled traffic allowed by default
[0.165707] AppArmor: AppArmor Filesystem Enabled
[0.165795] pnp: PnP ACPI init
[0.165839] ACPI: bus type pnp registered
[0.166086] pnp 00:00: [bus 00-ff]
[0.166093] pnp 00:00: [io 0x0cf8-0x0cff]
[0.166099] pnp 00:00: [io 0x-0x0cf7 window]
[0.166104] pnp 00:00: [io 0x0d00-0x window]
[0.166110] pnp 00:00: [mem 0x000a-0x000b window]
[0.166116] pnp 00:00: [mem 0x000c-0x000d window]
[0.166122] pnp 00:00: [mem 0xe000-0x window]
[0.166224] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
[0.166381] pnp 00:01: [io 0x4100-0x411f]
[0.166387] pnp 00:01: [io 0x0228-0x022f]
[0.166392] pnp 00:01: [io 0x040b]
[0.166396] pnp 00:01: [io 0x04d6]
[0.166401] pnp 00:01: [io 0x0c00-0x0c01]
[0.166405] pnp 00:01: [io 0x0c14]
[0.166410] pnp 00:01: [io 0x0c50-0x0c52]
[0.166415] pnp 00:01: [io 0x0c6c-0x0c6d]
[0.166419] pnp 00:01: [io 0x0c6f]
[0.166430] pnp 00:01: [io 0x0cd0-0x0cd1]
[0.166434] pnp 00:01: [io 0x0cd2-0x0cd3]
[0.166439] pnp 00:01: [io 0x0cd4-0x0cdf]
[0.166444] pnp 00:01: [io 0x4000-0x40fe]
[0.166448] pnp 00:01: [io 0x4210-0x4217]
[0.166453] pnp 00:01: [io 0x0b10-0x0b1f]
[0.166459] pnp 00:01: [mem 0x-0x0fff window]
[0.166465] pnp 00:01: [mem 0xfee00400-0xfee00fff window]
[0.166603] system 00:01: [io 0x4100-0x411f] has been reserved
[0.166618] system 00:01: [io 0x0228-0x022f] has been reserved
[0.166629] system 00:01: [io 0x040b] has been reserved
[0.166641] system 00:01: [io 0x04d6] has been reserved
[0.166652] system 00:01: [io 0x0c00-0x0c01] has been reserved
[0.14] system 00:01: [io 0x0c14] has
[Kernel-packages] [Bug 1011225] Re: Again limited to UDMA/33 due to 40-wire cable
Ziemowit Marcinkowski, this bug was reported a while ago and there
hasn't been any activity in it recently. We were wondering if this is
still an issue? If so, could you please test for this with the latest
development release of Ubuntu? ISO images are available from
http://cdimage.ubuntu.com/daily-live/current/ .
If it remains an issue, could you please run the following command in
the development release from a Terminal
(Applications-Accessories-Terminal), as it will automatically gather
and attach updated debug information to this report:
apport-collect -p linux replace-with-bug-number
Also, could you please test the latest upstream kernel available following
https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional
upstream developers to examine the issue. Please do not test the daily folder,
but the one all the way at the bottom. Once you've tested the upstream kernel,
please comment on which kernel version specifically you tested. If this bug is
fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER
where VERSION-NUMBER is the version number of the kernel you tested. For
example:
kernel-fixed-upstream-v3.11-rc5
This can be done by clicking on the yellow circle with a black pencil icon next
to the word Tags located at the bottom of the bug description. As well, please
remove the tag:
needs-upstream-testing
If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER
As well, please remove the tag:
needs-upstream-testing
Once testing of the upstream kernel is complete, please mark this bug's
Status as Confirmed. Please let us know your results. Thank you for your
understanding.
** Tags added: needs-kernel-logs needs-upstream-testing
** Changed in: linux (Ubuntu)
Status: Confirmed = Incomplete
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1011225
Title:
Again limited to UDMA/33 due to 40-wire cable
Status in “linux” package in Ubuntu:
Incomplete
Bug description:
I just made clean install on my new box for NAS routing and etc.
It is : Ubuntu 3.2.0-23.36-generic-pae 3.2.14 (ubuntu-12.04-server-i386)
My hardware is HP 5730 Thin Client
Sempron 2100+ ( 1 GHz )
HP Logic Board with SB600 and ATI RS690 with Radeon X1250 Series
512 MB RAM ( waiting for Memory 2GB)
HD SSD 120 GB SAMSUNG via PATASATA connector
I'm usung 80 wire cable with HD SSD with PATASATA connector, but also for
test I was connected few different 2,5 PATA drives directly, with all cases
the problem is ata1.00: limited to UDMA/33 due to 40-wire cable
In my other box ( ATV gen 1 with Crystalbuntu) all the disk work perfectly on
UDMA 5
I also tried with IDECF adapter putted direct to board with SanDisk UDMA133,
with the same results.
I tried to use some method from
http://www.pixca.net/bits-and-bytes/limited-to-udma33-due-to-40-wire-cable/
without success.
I also made some google research, and it seems that problem occurs in
PC with embedded AMD IDE Controller with many computers with different
cases etc. It's because probably that BIOS or IDE controller doesn't
provide proper information about 80-pin cable.
I will be glad to get some solution with this problem, maybe some
prompt about edit pata_atiixp.c to force 80-wire and compile.
Here is hdparm -i output:
/dev/sda:
Model=SAMSUNG SSD PB22-JS3 FDE 2.5 128GB, FwRev=VBM9LD1Q,
SerialNo=YFBB100947SY947A6641
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=1
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=250069680
IORDY=on/off, tPIO={min:120,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=no WriteCache=enabled
Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2,3,4,5,6,7
* signifies the current active mode
Here is dmesg output:
[0.135688] SCSI subsystem initialized
[0.135818] libata version 3.00 loaded.
[0.135939] usbcore: registered new interface driver usbfs
[0.135976] usbcore: registered new interface driver hub
[0.136062] usbcore: registered new device driver usb
[0.136307] PCI: Using ACPI for IRQ routing
[0.147472] PCI: pci_cache_line_size set to 64 bytes
[0.147584] reserve RAM buffer: 0009fc00 - 0009
[0.147591] reserve RAM buffer: 1dfe - 1fff
[0.147839] NetLabel: Initializing
[0.147850] NetLabel: domain hash size = 128
[0.147857] NetLabel: protocols = UNLABELED CIPSOv4
[0.147888] NetLabel: unlabeled traffic allowed by default
[0.165707]
