Re: AHCI + ST3160023AS + NCQ problems
On 10/30/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote: > On 10/30/07, Michael Tokarev <[EMAIL PROTECTED]> wrote: > > Eric D. Mudama wrote: > > > On 10/30/07, Michael Tokarev <[EMAIL PROTECTED]> wrote: > > >> By the way, did you forget to remove a jumper on the drive > > >> (the only jumper installed by default) that limits drive > > >> usage to SATAI? > > > ... > > >> ..etc. Try again without the jumper? Note that NCQ is NOT supported > > >> in SATAI mode, or there were some pre-standard implementations of it. > > >> In SATAII, NCQ is standard (well... more or less anyway ;) > > > > > > Huh? > > > > > > To my knowledge, the jumper should only limit the bus rate to > > > 1.5Gbit/s, for compatibility with one or more chipsets. It shouldn't > > > affect the command set supported by the device. > > > > The thing is that I don't know. I had some other probs with seagate > > sata drives when the jumper was there. So I learned a lesson - > > always remove the jumper before using their drives. I don't want > > to test which other restrictions this and other drive families > > apply when jumpered... ;) > > > > /mjt > > > > Indeed removing the jumper of sdb made it be recognised as SATA2. But > sdc, what the problem is really about, is neither SATA2, not has any > jumper whatsoever. but both the manufacturer and libata claim it > supports NCQ. > Anything i could do to help debug this? or perhaps it makes more sense to just blacklist NCQ for this particular drive? - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: question about sata-error on boot.
> On Fri, 2 Nov 2007 19:34:20 +0100 "Hemmann, Volker Armin" <[EMAIL PROTECTED]> > wrote: > Hi, (cc linux-ide) > for some time (and I can't say for how long, but the board is less than a > month old) I get this error on boot: > > [ 42.116273] ahci :00:0a.0: version 2.2 > [ 42.116482] ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23 > [ 42.116653] ACPI: PCI Interrupt :00:0a.0[A] -> Link [LSA0] -> GSI 23 > (level, low) -> IRQ 23 > [ 43.119478] ahci :00:0a.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf > impl IDE mode > [ 43.119778] ahci :00:0a.0: flags: 64bit led clo pmp pio > [ 43.119943] PCI: Setting latency timer of device :00:0a.0 to 64 > [ 43.120149] scsi0 : ahci > [ 43.120365] scsi1 : ahci > [ 43.120556] scsi2 : ahci > [ 43.120741] scsi3 : ahci > [ 43.120927] ata1: SATA max UDMA/133 cmd 0xc2014100 ctl > 0x bmdma 0x irq 315 > [ 43.121227] ata2: SATA max UDMA/133 cmd 0xc2014180 ctl > 0x bmdma 0x irq 315 > [ 43.121526] ata3: SATA max UDMA/133 cmd 0xc2014200 ctl > 0x bmdma 0x irq 315 > [ 43.121826] ata4: SATA max UDMA/133 cmd 0xc2014280 ctl > 0x bmdma 0x irq 315 > [ 43.934296] ata1: softreset failed (1st FIS failed) > [ 43.934461] ata1: reset failed (errno=-5), retrying in 10 secs > [ 53.885194] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 53.885890] ata1.00: ATA-7: WDC WD1600JS-00MHB1, 10.02E01, max UDMA/133 > [ 53.886056] ata1.00: 312581808 sectors, multi 16: LBA48 > [ 53.886804] ata1.00: configured for UDMA/133 > [ 54.201147] ata2: SATA link down (SStatus 0 SControl 300) > [ 54.517101] ata3: SATA link down (SStatus 0 SControl 300) > [ 54.833055] ata4: SATA link down (SStatus 0 SControl 300) > > The board has four ports and I use the first one. After that, the computer > boots and works fine. Harddisk-speed is normal. Kernel is 2.6.22.9 with > cfs&reiser4 patches. > > Is this something to worry about? > > Following is lspci -v and dmesg, config is attached. > lspci -v > 00:00.0 RAM memory: nVidia Corporation MCP65 Memory Controller (rev a1) > Subsystem: ASRock Incorporation Unknown device 0444 > Flags: bus master, 66MHz, fast devsel, latency 0 > Capabilities: [44] HyperTransport: Slave or Primary Interface > Capabilities: [dc] HyperTransport: MSI Mapping Enable+ Fixed- > > 00:01.0 ISA bridge: nVidia Corporation MCP65 LPC Bridge (rev a2) > Subsystem: ASRock Incorporation Unknown device 0441 > Flags: bus master, 66MHz, fast devsel, latency 0 > I/O ports at 2f00 [size=256] > > 00:01.1 SMBus: nVidia Corporation MCP65 SMBus (rev a1) > Subsystem: ASRock Incorporation Unknown device 0446 > Flags: 66MHz, fast devsel, IRQ 11 > I/O ports at ac00 [size=64] > I/O ports at 2d00 [size=64] > I/O ports at 2e00 [size=64] > Capabilities: [44] Power Management version 2 > > 00:01.2 RAM memory: nVidia Corporation MCP65 Memory Controller (rev a1) > Subsystem: ASRock Incorporation Unknown device 0446 > Flags: 66MHz, fast devsel > > 00:02.0 USB Controller: nVidia Corporation MCP65 USB Controller (rev a1) > (prog-if 10 [OHCI]) > Subsystem: ASRock Incorporation Unknown device 0454 > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 21 > Memory at f9dff000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [44] Power Management version 2 > > 00:02.1 USB Controller: nVidia Corporation MCP65 USB Controller (rev a1) > (prog-if 20 [EHCI]) > Subsystem: ASRock Incorporation Unknown device 0455 > Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22 > Memory at f9dfec00 (32-bit, non-prefetchable) [size=256] > Capabilities: [44] Debug port > Capabilities: [80] Power Management version 2 > > 00:08.0 PCI bridge: nVidia Corporation MCP65 PCI bridge (rev a1) (prog-if 01 > [Subtractive decode]) > Flags: bus master, 66MHz, fast devsel, latency 0 > Bus: primary=00, secondary=02, subordinate=02, sec-latency=128 > I/O behind bridge: c000-dfff > Memory behind bridge: f9f0-f9ff > Prefetchable memory behind bridge: 8800-880f > Capabilities: [b8] Subsystem: ASRock Incorporation Unknown device 0449 > Capabilities: [8c] HyperTransport: MSI Mapping Enable- Fixed- > > 00:09.0 IDE interface: nVidia Corporation MCP65 IDE (rev a1) (prog-if 8a > [Master SecP PriP]) > Subsystem: ASRock Incorporation Unknown device 0448 > 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
Re: SC1200 failure in 2.6.23 and 2.6.24-rc1-git10
> On Thu, 1 Nov 2007 23:30:13 +0200 "Denys" <[EMAIL PROTECTED]> wrote:
> Finally i got full DMESG with 1GB card till end. Seems not readable too.
>
> Linux version 2.6.24-rc1-git10-embedded ([EMAIL PROTECTED]) (gcc
> version 4.1.2 (Gentoo 4.1.2 p1.0.1)) #1 Thu Nov 1 23:12:53 EET 2007
> BIOS-provided physical RAM map:
> BIOS-e801: - 0009f000 (usable)
> BIOS-e801: 0010 - 0400 (usable)
> 64MB LOWMEM available.
> Zone PFN ranges:
> DMA 0 -> 4096
> Normal 4096 ->16384
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0:0 ->16384
> DMI not present or invalid.
> Allocating PCI resources starting at 1000 (gap: 0400:fc00)
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
> Kernel command line: console=ttyS0,38400n8
> Initializing CPU#0
> PID hash table entries: 256 (order: 8, 1024 bytes)
> Detected 266.627 MHz processor.
> Console: colour dummy device 80x25
> console [ttyS0] enabled
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 62836k/65536k available (1020k kernel code, 2292k reserved, 317k
> data, 112k init, 0k highmem)
> virtual kernel memory layout:
> fixmap : 0xb000 - 0xf000 ( 16 kB)
> vmalloc : 0xc480 - 0x9000 ( 951 MB)
> lowmem : 0xc000 - 0xc400 ( 64 MB)
> .init : 0xc0252000 - 0xc026e000 ( 112 kB)
> .data : 0xc01ff111 - 0xc024e6f4 ( 317 kB)
> .text : 0xc010 - 0xc01ff111 (1020 kB)
> Checking if this processor honours the WP bit even in supervisor mode... Ok.
> SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
> Calibrating delay using timer specific routine.. 534.41 BogoMIPS (lpj=1068836)
> Mount-cache hash table entries: 512
> Compat vDSO mapped to e000.
> CPU: NSC Unknown stepping 01
> Checking 'hlt' instruction... OK.
> Freeing SMP alternatives: 0k freed
> net_namespace: 64 bytes
> NET: Registered protocol family 16
> PCI: PCI BIOS revision 2.10 entry at 0xfc3ad, last bus=0
> PCI: Using configuration type 1
> Setting up standard PCI resources
> SCSI subsystem initialized
> PCI: Probing PCI hardware
> PCI: Device :00:12.5 not found by BIOS
> Time: tsc clocksource has been installed.
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 2048 (order: 2, 16384 bytes)
> TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
> TCP: Hash tables configured (established 2048 bind 2048)
> TCP reno registered
> scx200: NatSemi SCx200 Driver
> scx200: GPIO base 0xf400
> scx200: Configuration Block base 0x9000
> io scheduler noop registered (default)
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
> serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
> natsemi dp8381x driver, version 2.1, Sept 11, 2006
> originally by Donald Becker <[EMAIL PROTECTED]>
> 2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
> natsemi eth0: NatSemi DP8381[56] at 0x8000 (:00:0e.0),
> 00:0d:b9:00:8a:30, IRQ 10, port TP.
> scsi0 : sc1200
> scsi1 : sc1200
> ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0xfc00 irq 14
> ata2: DUMMY
> ata1.00: CFA: SanDisk SDCFH-1024, HDX 3.07, max MWDMA2
> ata1.00: 2001888 sectors, multi 0: LBA
> ata1.00: configured for MWDMA2
> scsi 0:0:0:0: Direct-Access ATA SanDisk SDCFH-10 HDX PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 2001888 512-byte hardware sectors (1025 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> sd 0:0:0:0: [sda] 2001888 512-byte hardware sectors (1025 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> sda:<4>Clocksource tsc unstable (delta = -334501841 ns)
> Time: pit clocksource has been installed.
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA2
> ata1: EH complete
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1.00: configured for MWDMA2
> ata1: EH complete
> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> ata1.00: status: { DRDY }
>
Re: [PATCH] SCSI: Add the SGPIO support for sata_nv.c
On Nov 7, 2006 1:55 AM, Peer Chen <[EMAIL PROTECTED]> wrote: > Modified and resent out the patch as attachment. > Description about the patch: > Add SGPIO support in sata_nv.c. > SGPIO (Serial General Purpose Input Output) is a sideband serial 4-wire > interface that a storage controller uses to communicate with a storage > enclosure management controller, primarily to control activity and > status LEDs that are located within drive bays or on a storage > backplane. SGPIO is defined by [SFF8485]. > In this patch,we drive the LEDs to blink when read/write operation > happen on SATA drives connect the corresponding ports on MCP55 board. > == > The patch will be applied to kernel 2.6.19-rc4-git9. do you have one that can apply to 2.6.24-rc2 or current linus git tree. YH - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ata_piix: add SATELLITE PRO U200 to broken suspend list
From: Yann Chachkoff <[EMAIL PROTECTED]>
Please warmly welcome the PRO variant of Satellite U200 to the broken
suspend list.
Original patch is from Yann Chachkoff. Patch reformatted and
forwarded by Tejun Heo.
Signed-off-by: Yann Chachkoff <[EMAIL PROTECTED]>
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
ata_piix.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index f08cca2..328ce8a 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -960,6 +960,13 @@ static int piix_broken_suspend(void)
},
},
{
+ .ident = "Satellite Pro U200",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "SATELLITE PRO
U200"),
+ },
+ },
+ {
.ident = "Satellite U205",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] libata: xfer_mask is unsigned int not unsigned long
Jeff Garzik wrote: >> Jeff, are you okay with u32 or 64? > > unsigned long is IMO the best choice for bitmaps. > > * it is a machine int on all(?) architectures I don't really see much point in this. What's the advantage of a machine int for xfer mask? > * it is 32-bit on 32-bit architectures The problem I see for using native integral types for flags or mask is that it's not fixed in size, so you can only use the smallest of all the supported architectures. We know for all archs we support, both unsigned int and unsigned long are at least 32bits long but to me making the assumption about expected number of bits using u32 or u64 is much more important than other considerations. > * it is consistent with test_bit(), set_bit() and lib/bitmap.c interfaces > > * conversion to test_bit() and lib/bitmap.c interfaces as a future step > is trivial I don't think it's likely that we'll need those heavy machineries for xfermask and the correct approach is to convert when the need actually arises. > * your structs inflate on 64-bit due to pointers anyway, so I see little > real consequence to using the lower 32 bits of an unsigned long as a > portable meme. I'm not trying to optimize performance or size. I'm trying to make programming assumptions clear. I think it's silly to optimize anything for xfermask. It just has to work and be clear to people working with it. An optimal but overkill solution would be using fast_u32 or fast_u64 types such that the compiler can choose as necessary but as we don't have that yet && xfermask handling is a very very cold path, I think we should be aiming for clarity. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hitachi SATA HSM violation (Was: Re: Adding SATA disk with broken NCQ)
Reading other similar reports on this issue, I attach a dmesg that shows
the HSM violations/NCQ being disabled.
In addition,
# hdparm -i /dev/sda
/dev/sda:
Model=HITACHI HTS541616J9SA00 , FwRev=SB4IC7UP,
SerialNo=...
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=7516kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
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=yes: disabled (255) 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
Simos
On Tue, 2007-11-06 at 01:50 +, Simos Xenitellis wrote:
> Hi,
> I'ld like to add another disk in the blacklist regarding NCQ
> (libata-core.c).
>
> It is the disk model "HITACHI HTS541616J9SA00" with rev "SB4IC7UP".
>
> Currently there is a similar description,
> { "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
> Notice the difference between SB4IC7UP and SB4OC70P.
>
> I have verified that the model name and rev are "HITACHI
> HTS541616J9SA00" and "SB4IC7UP" by adding printks in the kernel. The
> word HITACHI is all caps.
> Blacklisting does eliminate NCQ-related disk errors.
>
> Simos
>
[ 51.294197] ata1.00: exception Emask 0x2 SAct 0x785 SErr 0x0 action 0x2
frozen
[ 51.294208] ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x785
FIS=005040a1:0010)
[ 51.294219] ata1.00: cmd 60/08:00:49:64:9f/00:00:06:00:00/40 tag 0 cdb 0x0
data 4096 in
[ 51.294222] res 50/00:08:f9:5b:5a/00:00:06:00:00/40 Emask 0x2 (HSM
violation)
[ 51.294232] ata1.00: cmd 60/08:10:f9:5b:5a/00:00:06:00:00/40 tag 2 cdb 0x0
data 4096 in
[ 51.294235] res 50/00:08:f9:5b:5a/00:00:06:00:00/40 Emask 0x2 (HSM
violation)
[ 51.294244] ata1.00: cmd 60/08:38:51:64:9f/00:00:06:00:00/40 tag 7 cdb 0x0
data 4096 in
[ 51.294247] res 50/00:08:f9:5b:5a/00:00:06:00:00/40 Emask 0x2 (HSM
violation)
[ 51.294256] ata1.00: cmd 60/08:40:59:64:9f/00:00:06:00:00/40 tag 8 cdb 0x0
data 4096 in
[ 51.294259] res 50/00:08:f9:5b:5a/00:00:06:00:00/40 Emask 0x2 (HSM
violation)
[ 51.294268] ata1.00: cmd 60/08:48:a9:2a:56/00:00:06:00:00/40 tag 9 cdb 0x0
data 4096 in
[ 51.294271] res 50/00:08:f9:5b:5a/00:00:06:00:00/40 Emask 0x2 (HSM
violation)
[ 51.294281] ata1.00: cmd 60/08:50:61:64:9f/00:00:06:00:00/40 tag 10 cdb 0x0
data 4096 in
[ 51.294283] res 50/00:08:f9:5b:5a/00:00:06:00:00/40 Emask 0x2 (HSM
violation)
[ 51.325202] ata1: soft resetting port
[ 51.330258] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 51.331248] ata1.00: configured for UDMA/100
[ 51.331279] ata1: EH complete
[ 51.331463] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB)
[ 51.331494] sd 0:0:0:0: [sda] Write Protect is off
[ 51.331498] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 51.331575] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[23679.735640] ata1.00: exception Emask 0x2 SAct 0x3fc SErr 0x0 action 0x2
frozen
[23679.735651] ata1.00: (spurious completions during NCQ issue=0x0 SAct=0x3fc
FIS=005040a1:0002)
[23679.735662] ata1.00: cmd 61/30:10:cc:be:5e/00:00:0a:00:00/40 tag 2 cdb 0x0
data 24576 out
[23679.735665] res 50/00:08:bc:bf:61/00:00:0a:00:00/40 Emask 0x2 (HSM
violation)
[23679.735676] ata1.00: cmd 61/08:18:64:c3:5e/00:00:0a:00:00/40 tag 3 cdb 0x0
data 4096 out
[23679.735679] res 50/00:08:bc:bf:61/00:00:0a:00:00/40 Emask 0x2 (HSM
violation)
[23679.735689] ata1.00: cmd 61/10:20:fc:55:5f/00:00:0a:00:00/40 tag 4 cdb 0x0
data 8192 out
[23679.735692] res 50/00:08:bc:bf:61/00:00:0a:00:00/40 Emask 0x2 (HSM
violation)
[23679.735701] ata1.00: cmd 61/08:28:fc:56:5f/00:00:0a:00:00/40 tag 5 cdb 0x0
data 4096 out
[23679.735704] res 50/00:08:bc:bf:61/00:00:0a:00:00/40 Emask 0x2 (HSM
violation)
[23679.735714] ata1.00: cmd 61/48:30:0c:57:5f/00:00:0a:00:00/40 tag 6 cdb 0x0
data 36864 out
[23679.735717] res 50/00:08:bc:bf:61/00:00:0a:00:00/40 Emask 0x2 (HSM
violation)
[23679.735727] ata1.00: cmd 61/08:38:74:57:5f/00:00:0a:00:00/40 tag 7 cdb 0x0
data 4096 out
[23679.735730] res 50/00:08:bc:bf:61/00:00:0a:00:00/40 Emask 0x2 (HSM
violation)
[23679.735740] ata1.00: cmd 61/10:40:7c:57:5f/00:00:0a:00:00/40 tag 8 cdb 0x0
data 8192 out
[23679.735743] res 50/00:08:bc:bf:61/00:00:0a:00:00/40 Emask 0x2 (HSM
violation)
[23679.735752] ata1.00: cmd 61/08:48:bc:bf:61/00:00:0a:00:00/40 tag 9 cdb 0x0
data 4096 out
[23679.735755] res 50/00:08:bc:bf:61/00:00:0a:00:00/40 Emask 0x2 (HSM
violation)
[23679.833152] ata1: soft resetting port
[23679.883781] ata1: SATA link up 1.5 Gbps (SStatu
only one drive in a port multiplier system is being recognized
I have a LYCeSATA-4x pci card that is port multiplier compatible (it works fine under win xp) that is only showing one of 5 attached drives when attached to a Redhat 5 computer, with both 2.6.18-8.1.15.el5 and 2.6.23.1. The SATA link shows as up for the one recognized drive, the other four drives show the link down. Any sugguestions as to what may be the problem? A subset of what I consider the relavant portion of dmesg for the 2.6.18-8.1.15.el5 kernel is: ahci :00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x2f impl SATA mode ahci :00:1f.2: flags: 64bit ncq pm led clo pmp pio slum part ata1: SATA max UDMA/133 cmd 0xF882C100 ctl 0x0 bmdma 0x0 irq 233 ata2: SATA max UDMA/133 cmd 0xF882C180 ctl 0x0 bmdma 0x0 irq 233 ata3: SATA max UDMA/133 cmd 0xF882C200 ctl 0x0 bmdma 0x0 irq 233 ata4: SATA max UDMA/133 cmd 0xF882C280 ctl 0x0 bmdma 0x0 irq 233 ata5: SATA max UDMA/133 cmd 0xF882C300 ctl 0x0 bmdma 0x0 irq 233 ata6: SATA max UDMA/133 cmd 0xF882C380 ctl 0x0 bmdma 0x0 irq 233 scsi0 : ahci usb 1-1: new low speed USB device using uhci_hcd and address 3 usb 1-1: configuration #1 chosen from 1 choice input: Dell Dell USB Mouse as /class/input/input1 input: USB HID v1.10 Mouse [Dell Dell USB Mouse] on usb-:00:1a.0-1 usb 1-2: new full speed USB device using uhci_hcd and address 4 ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: ATA-7, max UDMA/133, 488281250 sectors: LBA48 NCQ (depth 31/32) ata1.00: ata1: dev 0 multi count 0 ata1.00: configured for UDMA/133 scsi1 : ahci usb 1-2: configuration #1 chosen from 1 choice input: Dell Dell Smart Card Reader Keyboard as /class/input/input2 input: USB HID v1.11 Keyboard [Dell Dell Smart Card Reader Keyboard] on usb-:00:1a.0-2 ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: ATA-7, max UDMA/133, 488281250 sectors: LBA48 NCQ (depth 31/32) ata2.00: ata2: dev 0 multi count 0 ata2.00: configured for UDMA/133 scsi2 : ahci ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: ATAPI, max UDMA/100 ata3.00: configured for UDMA/100 scsi3 : ahci ata4: SATA link down (SStatus 4 SControl 300) scsi4 : ahci ata5: SATA link down (SStatus 0 SControl 0) scsi5 : ahci ata6: SATA link down (SStatus 4 SControl 300) Vendor: ATA Model: Hitachi HDT72502 Rev: V5DO Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 488281250 512-byte hdwr sectors (25 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 488281250 512-byte hdwr sectors (25 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sd 0:0:0:0: Attached scsi disk sda Vendor: ATA Model: Hitachi HDT72502 Rev: V5DO Type: Direct-Access ANSI SCSI revision: 05 SCSI device sdb: 488281250 512-byte hdwr sectors (25 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back SCSI device sdb: 488281250 512-byte hdwr sectors (25 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: drive cache: write back sdb: sdb1 sd 1:0:0:0: Attached scsi disk sdb Vendor: PBDS Model: DVD+-RW DH-16W1S Rev: 2D14 Type: CD-ROM ANSI SCSI revision: 05 sata_sil24 :03:02.0: version 0.3 ACPI: PCI Interrupt :03:02.0[A] -> GSI 18 (level, low) -> IRQ 217 ata7: SATA max UDMA/100 cmd 0xF884 ctl 0x0 bmdma 0x0 irq 217 ata8: SATA max UDMA/100 cmd 0xF8842000 ctl 0x0 bmdma 0x0 irq 217 ata9: SATA max UDMA/100 cmd 0xF8844000 ctl 0x0 bmdma 0x0 irq 217 ata10: SATA max UDMA/100 cmd 0xF8846000 ctl 0x0 bmdma 0x0 irq 217 scsi6 : sata_sil24 ata7: SATA link down (SStatus 0 SControl 300) scsi7 : sata_sil24 ata8: SATA link down (SStatus 0 SControl 300) scsi8 : sata_sil24 ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata9.00: ATA-7, max UDMA/133, 1953525168 sectors: LBA48 NCQ (depth 31/32) ata9.00: ata9: dev 0 multi count 16 ata9.00: configured for UDMA/100 scsi9 : sata_sil24 ata10: SATA link down (SStatus 0 SControl 300) Vendor: ATA Model: Hitachi HDS72101 Rev: GKAO Type: Direct-Access ANSI SCSI revision: 05 SCSI device sdc: 1953525168 512-byte hdwr sectors (1000205 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back SCSI device sdc: 1953525168 512-byte hdwr sectors (1000205 MB) sdc: Write Protect is off sdc: Mode Sense: 00 3a 00 00 SCSI device sdc: drive cache: write back sdc: sdc1 sd 8:0:0:0: Attached scsi disk sdc [EMAIL PROTECTED] ~]# fdisk -l Disk /dev/sda: 250.0 GB, 2500 bytes 255 heads, 63 sectors/track, 30394 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 30394 244139773+ 83 Linux Disk /dev/sdb: 250.0 GB, 2500 bytes 255 heads, 63 sectors/track, 30394 cylinders Units = cylinders of 16065 * 512 =
Re: Strange freezes (seems like SATA related)
Andrew Morton wrote: > On Mon, 29 Oct 2007 09:54:27 -0700 > Max Krasnyansky <[EMAIL PROTECTED]> wrote: > >> A couple of HP xw9300 machines (dual Opterons) started freezing up. >> We're running on 2.6.22.1 on them. Freezes a somewhere weird. VGA console is >> alive >> (I can switch vts, etc) but everything else is dead (network, etc). >> Unfortunately SYSRQ was not enabled and I could not get backtraces and stuff. >> >> Hooked up serial console and the only error that shows up is this. >> >> ata1: EH in ADMA mode, notifier 0x1 notifier_error 0x0 gen_ctl 0x1581000 >> status 0x1540 next cpb count 0x0 next cpb idx 0x0 >> ata1: CPB 0: ctl_flags 0xd, resp_flags 0x1 >> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen >> ata1.00: cmd ca/00:08:57:00:80/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 out >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) >> Descriptor sense data with sense descriptors (in hex): >> end_request: I/O error, dev sda, sector 8388695 >> Buffer I/O error on device sda1, logical block 1048579 >> lost page write due to I/O error on sda1 >> sd 0:0:0:0: [sda] Write Protect is off >> >> I see a bunch of those and then the box just sits there spewing this >> periodically >> >> ata1: EH in ADMA mode, notifier 0x1 notifier_error 0x0 gen_ctl 0x1581000 >> status 0x1540 next cpb count 0x0 next cpb idx 0x0 >> ata1: CPB 0: ctl_flags 0xd, resp_flags 0x1 >> ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen >> ata1.00: cmd ca/00:08:4f:00:f8/00:00:00:00:00/e1 tag 0 cdb 0x0 data 4096 out >> res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) >> >> SMART selftest on the drive passed without errors. >> >> Here is how this machine looks like >> >> ... > > So this happens on more than one machine? Yep. > The kernel shouldn't freeze, so even if both machines have magically > identical hardware faults, there's a kernel bug there somewhere. > > I guess it would be useful to test a 2.6.23 kernel if poss. We've seen a > very large number of reports like this one in recent months (many of which > have not been responded to, btw) and perhaps someone has done something > about them. I may not be able to run identical workload on 2.6.23. Will try to give it a shot sometime next week. Also I've upgraded to 2.6.22.10 last week. There are a few fixes in there that may potentially affect those boxes. Max - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/15] ide: remove atapi_ireason_t
Bartlomiej Zolnierkiewicz wrote: Thanks! [ Heh, after "take 2" I had a feeling that something still may be not right so I deferred committing of this patch series to the official tree... :) ] [PATCH] ide: remove atapi_ireason_t (take 3) Remove atapi_ireason_t. While at it: * replace 'HWIF(drive)' by 'drive->hwif' (or just 'hwif' where possible) v2: * v1 had CD and IO bits reversed in many places. * Use CD and IO defines from . v3: * Fix incorrect "(ireason & IO) == test_bit()". (Noticed by Sergei) Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] libata: xfer_mask is unsigned int not unsigned long
Tejun Heo wrote: Alan Cox wrote: On Tue, 6 Nov 2007 14:39:03 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: xfer_mask is unsigned int not unsigned long. Change ->mode_filter to take and return unsigned int. While at it, rename @adev of ata_pci_default_filter() to @dev for consistency. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> The filter type was purposefully unsigned long to allow for expansion (eg for SWDMA) without breaking drivers. No problem with it changing but I'd say "unsigned int" was the worst possible choice - its now shorter (no room for expansion) and size dependant on arch. u32 would be shorter and consistent across all platforms, ulong would have more room for expansion. I agree it should be one of u* types and am happy to convert. This patch is primarily for consistency as in libata-core, xfer_mask is unsigned int. My first proposal was u32 too but Jeff vetoed it. IIRC, Jeff has affection for machine-independent integral types. :-) Anyways, I think ulong is worse than uint because ulong differs in size between 32 and 64 archs. What's the good of extra 32bits in flags space if it's not there on 32bit archs? Also, we currently only use 20bits of xfermask, 12 extra bits seem enough for the time, especially as everything is moving over to SATA where xfermode doesn't really matter, no? Jeff, are you okay with u32 or 64? unsigned long is IMO the best choice for bitmaps. * it is a machine int on all(?) architectures * it is 32-bit on 32-bit architectures * it is consistent with test_bit(), set_bit() and lib/bitmap.c interfaces * conversion to test_bit() and lib/bitmap.c interfaces as a future step is trivial * your structs inflate on 64-bit due to pointers anyway, so I see little real consequence to using the lower 32 bits of an unsigned long as a portable meme. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Maxtor 6L200M0 sata irq timeouts
On 01/10/2007, Michal Suchanek <[EMAIL PROTECTED]> wrote: > Hello > > (please CC me when replying) > > I got a replacement drive which is also a 6L200M0 but the fw rev is now BACE1G10. Both the irq errors and the smart checksum errors are gone. I guess these were cause by old and buggy drive firmware in my case. Thanks Michal - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/18] pdc202xx_new: move PIO programming code to pdcnew_set_pio_mode()
Bartlomiej Zolnierkiewicz wrote: * Move PIO programming code from pdcnew_set_mode() to pdcnew_set_pio_mode(). * Rename pdcnew_set_mode() to pdcnew_set_dma_mode(). There should be no functionality changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_hpt37x: Fix outstanding bug reports on the HPT374 and 37x cable detect
> > + if (chip_table == &hpt374) {
> > + freq = hpt374_read_freq(dev);
> > + if (freq == 0)
> > + return -ENODEV;
>
> Not sure whether this check is necessary...
If the device is hot unplugged we can get a zero return error case. It
seems cleaner to catch the error case rather than attempt to prove it
does no harm later.
pre_reset one fixed in my tree and will check and push.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_hpt37x: Fix outstanding bug reports on the HPT374 and 37x cable detect
Alan Cox wrote:
- Read frequency correctly
- Correct cable detect handling
I'm still not sure it's correct...
- Fix wrong filter test
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.24-rc1/drivers/ata/pata_hpt37x.c
linux-2.6.24-rc1/drivers/ata/pata_hpt37x.c
--- linux.vanilla-2.6.24-rc1/drivers/ata/pata_hpt37x.c 2007-11-01
11:41:54.0 +
+++ linux-2.6.24-rc1/drivers/ata/pata_hpt37x.c 2007-11-05 22:21:31.0
+
@@ -295,7 +295,7 @@
static unsigned long hpt370a_filter(struct ata_device *adev, unsigned long mask)
{
- if (adev->class != ATA_DEV_ATA) {
+ if (adev->class == ATA_DEV_ATA) {
if (hpt_dma_blacklisted(adev, "UDMA100", bad_ata100_5))
mask &= ~ (0x1F << ATA_SHIFT_UDMA);
}
@@ -359,28 +359,25 @@
{ 0x50, 1, 0x04, 0x04 },
{ 0x54, 1, 0x04, 0x04 }
};
- u16 mcr3, mcr6;
+ u16 mcr3;
u8 ata66;
struct ata_port *ap = link->ap;
struct pci_dev *pdev = to_pci_dev(ap->host->dev);
+ unsigned int mcrbase = 0x50 + 4 * ap->port_no;
if (!pci_test_config_bits(pdev, &hpt37x_enable_bits[ap->port_no]))
return -ENOENT;
/* Do the extra channel work */
- pci_read_config_word(pdev, 0x52, &mcr3);
- pci_read_config_word(pdev, 0x56, &mcr6);
+ pci_read_config_word(pdev, mcrbase + 2, &mcr3);
/* Set bit 15 of 0x52 to enable TCBLID as input
- Set bit 15 of 0x56 to enable FCBLID as input
*/
- pci_write_config_word(pdev, 0x52, mcr3 | 0x8000);
- pci_write_config_word(pdev, 0x56, mcr6 | 0x8000);
+ pci_write_config_word(pdev, mcrbase + 2, mcr3 | 0x8000);
pci_read_config_byte(pdev, 0x5A, &ata66);
/* Reset TCBLID/FCBLID to output */
pci_write_config_word(pdev, 0x52, mcr3);
- pci_write_config_word(pdev, 0x56, mcr6);
- if (ata66 & (1 << ap->port_no))
+ if (ata66 & (2 >> ap->port_no))
But has the same issue with hpt37x_pre_reset() been corrected? I don't
see this in the current driver.
ap->cbl = ATA_CBL_PATA40;
else
ap->cbl = ATA_CBL_PATA80;
@@ -844,6 +841,25 @@
/* Never went stable */
return 0;
}
+
+static u32 hpt374_read_freq(struct pci_dev *pdev)
+{
+ u32 freq;
+ unsigned long io_base = pci_resource_start(pdev, 4);
No new line after declaration block...
+ if (PCI_FUNC(pdev->devfn) & 1) {
+ struct pci_dev *pdev_0 = pci_get_slot(pdev->bus, pdev->devfn -
1);
+ /* Someone hot plugged the controller on us ? */
+ if (pdev_0 == NULL)
+ return 0;
+ io_base = pci_resource_start(pdev_0, 4);
+ freq = inl(io_base + 0x90);
+ pci_dev_put(pdev_0);
+ }
+ else
+ freq = inl(io_base + 0x90);
+ return freq;
+}
+
/**
* hpt37x_init_one - Initialise an HPT37X/302
* @dev: PCI device
@@ -902,7 +918,7 @@
.flags = ATA_FLAG_SLAVE_POSS,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
- .udma_mask = 0x0f,
+ .udma_mask = ATA_UDMA5,
.port_ops = &hpt370_port_ops
};
/* HPT370A - UDMA100 */
@@ -911,7 +927,7 @@
.flags = ATA_FLAG_SLAVE_POSS,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
- .udma_mask = 0x0f,
+ .udma_mask = ATA_UDMA5,
.port_ops = &hpt370a_port_ops
};
/* HPT371, 372 and friends - UDMA133 */
@@ -1047,9 +1063,16 @@
outb(0x0e, iobase + 0x9c);
/* Some devices do not let this value be accessed via PCI space
- according to the old driver */
+ according to the old driver. In addition we must use the value
+ from FN 0 on the HPT374 */
+
+ if (chip_table == &hpt374) {
+ freq = hpt374_read_freq(dev);
+ if (freq == 0)
+ return -ENODEV;
Not sure whether this check is necessary...
+ } else
+ freq = inl(iobase + 0x90);
- freq = inl(iobase + 0x90);
if ((freq >> 12) != 0xABCDE) {
int i;
u8 sr;
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Fix ATAPI transfer lengths" causes CD writing regression
> Just to make sure I'm not misunderstanding it. So, PDC202xx will lock > up if you transfer allocation size, reset and then try to drain, but > it's okay to keep draining as part of continued PIO transfer, right? The following hang mine: PIO transfer Reset state machine Read data register DMA transfer in progress Read data register And this does not PIO transfer Keep reading data register while checking DRQ - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] sl82c105: remove no longer needed ->selectproc method
Bartlomiej Zolnierkiewicz wrote: * Program register 0x40 in sl82c105_resetproc(). * Remove no longer needed sl82c105_selectproc() and pci_set_drvdata() calls. Cc: Sergei Shtylyov <[EMAIL PROTECTED]> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] sl82c105: program DMA/PIO timings in ->dma_start/->ide_dma_end
Bartlomiej Zolnierkiewicz wrote:
* Program DMA timings in sl82c105_dma_start() (->dma_start method)
before starting DMA transfer.
* Add sl82c105_dma_end() (->ide_dma_end method) to switch back to
PIO timings when DMA transfer is complete.
* In sl82c105_set_pio_mode() program timings regardless of ->using_dma
setting and in sl82c105_set_dma_mode() only cache the new timings.
* Remove no longer needed sl82c105_{ide_dma_on,off_quietly}().
Well, the right fix would have been to merge PIO/DMA timings -- but I
must admit that I have nearly forgotten about my existing but unfinished
version by now. :-|
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/18] ide: remove redundant DMA blacklist check from __ide_dma_on()
Bartlomiej Zolnierkiewicz wrote: ->ide_dma_on method is called only after successful ide_dma_check() call (ide_dma_check()->ide_tune_dma() checks DMA blacklist) or if drive->using_dma has been previously enabled for a given device (->ide_dma_on is the only place which sets drive->using_dma to '1'). There should be no functionality changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/18] ide: remove redundant ->ide_dma_on call from set_using_dma()
Bartlomiej Zolnierkiewicz wrote: ide_set_dma() calls ->ide_dma_on method itself and returns zero only if ->ide_dma_on call succeeded. There should be no functionality changes caused by this patch. Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/18] ide: don't BUG() on unsupported transfer modes
Bartlomiej Zolnierkiewicz wrote: Fix ide-cris, cs5530, sc1200 and sis5513 host drivers to just return instead of OOPS-ing for unsupported modes in ->set_dma_mode methods. Wait... weren't you going to make all the other drivers oops in this case? Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/18] ide: make 'extra' field in struct ide_port_info u8
Bartlomiej Zolnierkiewicz wrote: The maximum value used currently for 'extra' field in struct ide_port_info is 240. It just can't exceed 240 (256 - 16). Make 'extra' u8 so it packs nicely together with enablebits[] and 'chipset' fields (ide_pci_enablebit_t is 3 bytes and hwif_chipset_t is 1 byte). Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/18] ide: add missing HOB bit clearing to ide_dump_ata_status()
Bartlomiej Zolnierkiewicz wrote: Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/18] ide: move ide_fixstring() documentation to ide-iops.c from ide.h
Bartlomiej Zolnierkiewicz wrote: Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/18] ide: add missing #ifdef/#endif CONFIG_IDE_TASK_IOCTL
Bartlomiej Zolnierkiewicz wrote: Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/18] ide-pmac: skip conservative PIO "downgrade"
Bartlomiej Zolnierkiewicz wrote: We can skip conservative PIO "downgrade" (PIO3 becomes PIO2 etc.) on PMAC. Problem reported by Mikael. Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/18] ide: fix ide_find_dma_mode() to print human-readable info
Bartlomiej Zolnierkiewicz wrote: Problem reported by Mikael. Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] libata: add ATA_CBL_PATA_IGN
On Tue, 06 Nov 2007 20:02:28 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Alan Cox wrote: > >> This patch adds ATA_CBL_PATA_IGN which tells libata to ignore the > >> cable type completely and just let the LLD determine the transfer mode > >> via host transfer mode masks and ->mode_filter(). > >> > >> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > >> Cc: Alan Cox <[EMAIL PROTECTED]> > > > > Acked-by: Alan Cox <[EMAIL PROTECTED]> > > > > I think this can be applied to pata_acpi too as we don't have any idea > about actual cable there. Agreed entirely - and its beginning to look like pata_via is also a candidate as some boards have real issues. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/12] libata: kill ata_id_to_dma_mode()
Alan Cox wrote: > On Tue, 6 Nov 2007 14:39:02 +0900 > Tejun Heo <[EMAIL PROTECTED]> wrote: > >> ata_id_to_dma_mode() isn't quite generic. The function is basically >> privately implemented ata_id_xfermask() combined with hardcoded mode >> printing and configuration which are specific to ata_generic. > > I anticpiated other users. This seems a backward move - we end up > exporting lots of low level detail into the drivers which should be none > of their business. Those functions need to be exported anyway for pata_amd and I think it's natural to export them as xfer mode and mask handling is pretty fundamental and having those helpers around is handy when implementing LLD-specific mode selection. ata_id_to_dma_mode() just seemed a bit too specific to me. Sans ata_id_xfermask() part, printing configured mode and using "DMA" when there's no applicable DMA mode don't seem too useful as generic xfer mode/mask helper. I agree that the latter part of the function can be factored tho (setting xfer_mode, shift and clearing PIO flag according to determined xfer_mask). But since ata_generic() is currently the only user, factoring that part out seems an overkill. Well, I guess this is a matter of taste after all. How about letting Jeff determine it? I'm okay as long as generic ata_id_xfermask() is used there. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/12] libata: implement ata_timing_cycle2mode() and use it in libata-acpi and pata_acpi
Alan Cox wrote: >> +/* PIO */ >> +mode = ata_timing_cycle2mode(ATA_SHIFT_PIO, gtm->drive[unit].pio); >> +xfer_mask |= ata_xfer_mode2mask(mode); > > No check v 0xFF > >> + * ata_timing_cycle2mode - find xfer mode for the specified cycle duration >> + * @xfer_shift: ATA_SHIFT_* value for transfer type to examine. >> + * @cycle: cycle duration in ns >> + * >> + * Return matching xfer mode for @cycle. The returned mode is of >> + * the transfer type specified by @xfer_shift. If @cycle is too >> + * slow for @xfer_shift, 0xff is returned. If @cycle is faster >> + * than the fastest known mode, the fasted m > > Can return 0xFF The check is implicit in ata_xfer_mode2mask(), 0xff translates to xfermask 0, vice-versa. 0xff is internally a valid value indicating no mode. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] libata: add ATA_CBL_PATA_IGN
Alan Cox wrote: >> This patch adds ATA_CBL_PATA_IGN which tells libata to ignore the >> cable type completely and just let the LLD determine the transfer mode >> via host transfer mode masks and ->mode_filter(). >> >> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> >> Cc: Alan Cox <[EMAIL PROTECTED]> > > Acked-by: Alan Cox <[EMAIL PROTECTED]> > I think this can be applied to pata_acpi too as we don't have any idea about actual cable there. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/12] libata: separate out ata_acpi_gtm_xfermask() from pacpi_discover_modes()
Alan Cox wrote:
>> +/* Welcome to ACPI, bring a bucket */
>> +const unsigned int ata_acpi_pio_cycle[7] = {
>> +600, 383, 240, 180, 120, 100, 80
>> +};
>> +EXPORT_SYMBOL_GPL(ata_acpi_pio_cycle);
>> +
>> +const unsigned int ata_acpi_mwdma_cycle[5] = {
>> +480, 150, 120, 100, 80
>> +};
>> +EXPORT_SYMBOL_GPL(ata_acpi_mwdma_cycle);
>> +
>> +const unsigned int ata_acpi_udma_cycle[7] = {
>> +120, 80, 60, 45, 30, 20, 15
>> +};
>> +EXPORT_SYMBOL_GPL(ata_acpi_udma_cycle);
>
> Do we really need to keep exporting all these things. So far this patch
> set has exported a set of very specific ACPI arrays and a load of
> internal functions. That to me says the splitting up is wrong.
>
> One option would be to make those tables private and simply make the
> pata_acpi driver use the ata_timing functions
This is mid-step of merging ACPI timing handling into the standard
ata_timing mechanism. These will go away in later patch.
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] libata: add ATA_CBL_PATA_IGN
> This patch adds ATA_CBL_PATA_IGN which tells libata to ignore the > cable type completely and just let the LLD determine the transfer mode > via host transfer mode masks and ->mode_filter(). > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > Cc: Alan Cox <[EMAIL PROTECTED]> Acked-by: Alan Cox <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] libata: xfer_mask is unsigned int not unsigned long
Alan Cox wrote: > On Tue, 6 Nov 2007 14:39:03 +0900 > Tejun Heo <[EMAIL PROTECTED]> wrote: > >> xfer_mask is unsigned int not unsigned long. Change ->mode_filter to >> take and return unsigned int. >> >> While at it, rename @adev of ata_pci_default_filter() to @dev for >> consistency. >> >> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > > The filter type was purposefully unsigned long to allow for expansion (eg > for SWDMA) without breaking drivers. No problem with it changing but I'd > say "unsigned int" was the worst possible choice - its now shorter (no > room for expansion) and size dependant on arch. u32 would be shorter and > consistent across all platforms, ulong would have more room for expansion. I agree it should be one of u* types and am happy to convert. This patch is primarily for consistency as in libata-core, xfer_mask is unsigned int. My first proposal was u32 too but Jeff vetoed it. IIRC, Jeff has affection for machine-independent integral types. :-) Anyways, I think ulong is worse than uint because ulong differs in size between 32 and 64 archs. What's the good of extra 32bits in flags space if it's not there on 32bit archs? Also, we currently only use 20bits of xfermask, 12 extra bits seem enough for the time, especially as everything is moving over to SATA where xfermode doesn't really matter, no? Jeff, are you okay with u32 or 64? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/12] libata: implement ata_timing_cycle2mode() and use it in libata-acpi and pata_acpi
On Tue, 6 Nov 2007 14:39:06 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > libata-acpi is using separate timing tables for transfer modes > although libata-core has the complete ata_timing table. Implement > ata_timing_cycle2mode() to look for matching mode given transfer type > and cycle duration and use it in libata-acpi and pata_acpi to replace > private timing tables. Ok that makes sense having now seen the second chunk of patches. Just one problem: > + /* PIO */ > + mode = ata_timing_cycle2mode(ATA_SHIFT_PIO, gtm->drive[unit].pio); > + xfer_mask |= ata_xfer_mode2mask(mode); No check v 0xFF > + * ata_timing_cycle2mode - find xfer mode for the specified cycle duration > + * @xfer_shift: ATA_SHIFT_* value for transfer type to examine. > + * @cycle: cycle duration in ns > + * > + * Return matching xfer mode for @cycle. The returned mode is of > + * the transfer type specified by @xfer_shift. If @cycle is too > + * slow for @xfer_shift, 0xff is returned. If @cycle is faster > + * than the fastest known mode, the fasted m Can return 0xFF - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/12] pata_amd: update mode selection for NV PATAs
Looks good to me Acked-by: Alan Cox <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] libata: fix ata_acpi_gtm_xfermask()
On Tue, 6 Nov 2007 14:39:05 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > ata_acpi_gtm_xfermask() as separated out from pacpi_discover_modes() > has various bugs. Fix them. > > * The wrong comparison operator is used when finding for matching > cycle resulting totally bogus result. > > * With the comparion operator fixed, boundary condtion handling is > clumsy. > > * Setting of any DMA mask bit set all bits in PIO mask. > > * MWDMA and UDMA blocks are swapped. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > Cc: Alan Cox <[EMAIL PROTECTED]> > --- Looks good to me - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/12] libata: separate out ata_acpi_gtm_xfermask() from pacpi_discover_modes()
> +/* Welcome to ACPI, bring a bucket */
> +const unsigned int ata_acpi_pio_cycle[7] = {
> + 600, 383, 240, 180, 120, 100, 80
> +};
> +EXPORT_SYMBOL_GPL(ata_acpi_pio_cycle);
> +
> +const unsigned int ata_acpi_mwdma_cycle[5] = {
> + 480, 150, 120, 100, 80
> +};
> +EXPORT_SYMBOL_GPL(ata_acpi_mwdma_cycle);
> +
> +const unsigned int ata_acpi_udma_cycle[7] = {
> + 120, 80, 60, 45, 30, 20, 15
> +};
> +EXPORT_SYMBOL_GPL(ata_acpi_udma_cycle);
Do we really need to keep exporting all these things. So far this patch
set has exported a set of very specific ACPI arrays and a load of
internal functions. That to me says the splitting up is wrong.
One option would be to make those tables private and simply make the
pata_acpi driver use the ata_timing functions
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] libata: xfer_mask is unsigned int not unsigned long
On Tue, 6 Nov 2007 14:39:03 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > xfer_mask is unsigned int not unsigned long. Change ->mode_filter to > take and return unsigned int. > > While at it, rename @adev of ata_pci_default_filter() to @dev for > consistency. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> The filter type was purposefully unsigned long to allow for expansion (eg for SWDMA) without breaking drivers. No problem with it changing but I'd say "unsigned int" was the worst possible choice - its now shorter (no room for expansion) and size dependant on arch. u32 would be shorter and consistent across all platforms, ulong would have more room for expansion. Alan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/12] libata: kill ata_id_to_dma_mode()
On Tue, 6 Nov 2007 14:39:02 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > ata_id_to_dma_mode() isn't quite generic. The function is basically > privately implemented ata_id_xfermask() combined with hardcoded mode > printing and configuration which are specific to ata_generic. I anticpiated other users. This seems a backward move - we end up exporting lots of low level detail into the drivers which should be none of their business. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_hpt37x: Fix outstanding bug reports on the HPT374 and 37x cable detect
> hm, pci_resource_start() returns a resource_size_t and I guess this (and a > heck of a lot of other) code is bust on (whatever machine we added that for). inl takes an unsigned long. pci_resource_start historically was 32bit and became 64bit so we should have no problems. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "Fix ATAPI transfer lengths" causes CD writing regression
Alan Cox wrote: > On Mon, 05 Nov 2007 09:05:48 +0900 > Tejun Heo <[EMAIL PROTECTED]> wrote: > >> Alan Cox wrote: Maybe we could set a limit here. If the ATAPI device keeps DRQ=1 and exceeds the limit, we consider it as HSM violation and have EH handle it. >>> On a DMA transfer its basically out of our control (and a PIO drain will >>> lock some controllers solid until power cycle), >> Do such controllers lock up on PIO draining after PIO transfers too? >> Can you tell which are those controllers? > > Promise PDC202xx will lock on a PIO drain of a DMA transfer or (if you > reset it before you drain) on a PIO drain of a PIO transfer. Just to make sure I'm not misunderstanding it. So, PDC202xx will lock up if you transfer allocation size, reset and then try to drain, but it's okay to keep draining as part of continued PIO transfer, right? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
All these are caused by smartd. Updating should fix the problem. Okay, but there is no newer smartd than what I'm using. (5.37) Bruce? Original thread can be read from... http://thread.gmane.org/gmane.linux.kernel/588972 The fixes were added in smartmontools CVS, but there hasn't been a release since then. I think we'll do a new smartmontools release fairly soon. Cheers, Bruce - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
