Re: 2.6.20-rc3 IRQ race upon resume? => killing SATA IRQ

2007-01-04 Thread Alan
> (correctly probably). Question is, where is the irq coming from then.
> 
> Obviously this is a horribly wrong fix, since if the interrupt is shared, we 
> will shadow the other interrupt so it never gets run (and corrupt our own 
> BM DMA operations).

I wonder if it's left over from the resume I/O completing or the chip
coming back up in a stupid state. What occurs if the bit is cleared
during the early resume before IRQs are turned back on ?
-
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


IRQ anomaly

2007-01-04 Thread Valentijn Sessink
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

We had a problem with a server running Ubuntu Dapper kernel 2.6.15
(Ubuntu version 2.6.15-27-686) and Intel 82801GB/GR/GH with sw-raid on
two Seagate disks. Suddenly, the IRQ servicing the disks got disabled.
The sequence of events seemed just too typical to not mention them here.
What happened (summary):

00:53:46 a SCSI (libata) command timeout, "Scsi parity error"
01:01:00 raid disk failure ("continuing on 1 devices")
01:01:00++ continueing "Aborted Command" messages
[...]
01:30:32 APIC error on CPU0: 00(60)
[...]
01:32:59 the last of a sequence of sda "Aborted Command" messages

Until now, no serious problem; a working (yet degraded) array and a
functional server. Then a few days later we find out, and I issue a
"fdisk -l /dev/sda" just to see what will happen.

This shows another two "aborted command" messages and then, suddenly:
irq 185: nobody cared (try booting with the "irqpoll" option)
[...]
Disabling IRQ #185

... which had the additional result of disabling sdb (the second disk),
hence no further logs and an emergency visit to the machine itself :-(

This is probably just noisy busses or other HW related stuff, but the
fact that (not being able to) reading one SATA disk disables the IRQ
that is (also) used by another SATA disk seemed just too specific too
not mention it on this list. Let's say that I did care about irq 185 :)

The full kernel logs (including the messages after the restart) and an
lspci -v can be found at
http://valentijn.sessink.nl/temp/shja.tgz (20Kb)

If this is just HW related or too obscure, please feel free to ignore
this message; we've only seen this once (and I hope to not see it again).

Best regards,

Valentijn
- --
http://www.openoffice.nl/   Open Office - Linux Office Solutions
Valentijn Sessink  [EMAIL PROTECTED]  +31(0)20-4214059
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFnNSITRf3oaxjt6kRAq1xAJ4tiZ0izxgB6zL7w2RDZmEmA8pcGwCghCM/
fX7j5viCHAZ8LgMxzZ62CLI=
=JMu7
-END PGP SIGNATURE-
-
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: IRQ anomaly

2007-01-04 Thread Alan
On Thu, 04 Jan 2007 11:18:49 +0100
Valentijn Sessink <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi,
> 
> We had a problem with a server running Ubuntu Dapper kernel 2.6.15
> (Ubuntu version 2.6.15-27-686) and Intel 82801GB/GR/GH with sw-raid on

2.6.15 is a very very old libata and lots of problems have been fixed
since then, including some that do sound rather like your description.

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] add delay around sl82c105_reset_engine calls

2007-01-04 Thread Alan
On Thu, 4 Jan 2007 07:42:54 +0100
Olaf Hering <[EMAIL PROTECTED]> wrote:

> On Mon, Dec 04, Alan wrote:
> 
> > On Mon, 4 Dec 2006 13:40:26 +0100 (MET)
> > Olaf Hering <[EMAIL PROTECTED]> wrote:
> > 
> > > 
> > > 
> > > the hald media changed polling does really confuse things.
> > > noone knows why the delays are needed, but they give us access to
> > > the CD.
> > 
> > Can you tell me what happens if you completely pull the reset out of the
> > dma_end function. Do you still need delays then.
> 
> An udelay(50) will give reliable access to the drive, but there is still
> one (or more) EH reset. The drive works without EH resets with udelay(100).
> 
> Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>

Acked-by: Alan Cox <[EMAIL PROTECTED]>

This wants revisiting some day to understand the interaction better but
for now it gets us up and running properly.

-
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] SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

2007-01-04 Thread Jens Axboe
On Wed, Jan 03 2007, James Bottomley wrote:
> Er, well, as you know, I've never been a fan of this static list.  I
> thought Jens was going to put us all out of our misery by making the
> list settable per device by root and thus shovel the problem off onto
> the distros?

The code is there, just haven't had the guts to merge it yet.

http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=bf5f922d167a5c5cf57132bbcaa1e0ddfd5c45f7

-- 
Jens Axboe

-
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] SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

2007-01-04 Thread Mark Lord

Jens Axboe wrote:

On Wed, Jan 03 2007, James Bottomley wrote:

Er, well, as you know, I've never been a fan of this static list.  I
thought Jens was going to put us all out of our misery by making the
list settable per device by root and thus shovel the problem off onto
the distros?


The code is there, just haven't had the guts to merge it yet.

http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=bf5f922d167a5c5cf57132bbcaa1e0ddfd5c45f7



That's nice, but doesn't help with the case of trying to do ATA passthru
to ATAPI devices, the subject of the original patch here.

Cheers!
-
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] SCSI, libata: add support for ATA_16 commands to libata ATAPI devices

2007-01-04 Thread Jens Axboe
On Thu, Jan 04 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Wed, Jan 03 2007, James Bottomley wrote:
> >>Er, well, as you know, I've never been a fan of this static list.  I
> >>thought Jens was going to put us all out of our misery by making the
> >>list settable per device by root and thus shovel the problem off onto
> >>the distros?
> >
> >The code is there, just haven't had the guts to merge it yet.
> >
> >http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=bf5f922d167a5c5cf57132bbcaa1e0ddfd5c45f7
> >
> 
> That's nice, but doesn't help with the case of trying to do ATA passthru
> to ATAPI devices, the subject of the original patch here.

James brought up the filtering issue, my reply pertains to that alone.
Hence the snipping of unrelated contents in the original mail :-)

-- 
Jens Axboe

-
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: What is the correct way to indicate an unassigned PCI resource ?

2007-01-04 Thread Olaf Hering
On Wed, Dec 06, Benjamin Herrenschmidt wrote:

> On Tue, 2006-12-05 at 09:15 +0100, Olaf Hering wrote:
> > On Tue, Dec 05, Benjamin Herrenschmidt wrote:
> > 
> > > Olaf, can you give me a dump of /proc/ioports ? What is sitting at 0 on
> > > that PCI bus ?
> > 
> > with IDE=y
> > 
> > ==> /proc/ioports <==
> > -001f : dma1
> 
> So it's indeed colliding with the cruft above.
> 
> I reckon it's a bug in the firmware of this machine.
> 
> Add to pseries/pci.c a quirk for that chipset (don't forget to test for
> machine_is(pseries) in the quirk as they get called for all platforms in
> a combo kernel. The quirk shall check if resource 6 has a 0 base and
> clear the size as Alan suggested (possibly setting the UNSET flag as
> well).

I will test this change tomorrow:

+++ linux-2.6/arch/powerpc/platforms/pseries/pci.c
@@ -98,6 +98,10 @@ static void fixup_winbond_82c105(struct
if (dev->resource[i].flags & IORESOURCE_IO
&& dev->bus->number == 0 && dev->devfn == 0x81)
dev->resource[i].flags &= ~IORESOURCE_IO;
+   if (dev->resource[i].start == 0) {
+   printk("disable IO resource %d on W82c105 IDE 
controller\n", i);
+   dev->resource[i].flags = IORESOURCE_DISABLED;
+   }
}
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_WINBOND, PCI_DEVICE_ID_WINBOND_82C105,



Or did you mean 'if (dev->resource[5].start == 0)' ?
-
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: What is the correct way to indicate an unassigned PCI resource ?

2007-01-04 Thread Benjamin Herrenschmidt

> > Add to pseries/pci.c a quirk for that chipset (don't forget to test for
> > machine_is(pseries) in the quirk as they get called for all platforms in
> > a combo kernel. The quirk shall check if resource 6 has a 0 base and
> > clear the size as Alan suggested (possibly setting the UNSET flag as
> > well).
> 
> I will test this change tomorrow:
> 
> +++ linux-2.6/arch/powerpc/platforms/pseries/pci.c
> @@ -98,6 +98,10 @@ static void fixup_winbond_82c105(struct
> if (dev->resource[i].flags & IORESOURCE_IO
> && dev->bus->number == 0 && dev->devfn == 0x81)
> dev->resource[i].flags &= ~IORESOURCE_IO;
> +   if (dev->resource[i].start == 0) {
> +   printk("disable IO resource %d on W82c105 IDE 
> controller\n", i);
> +   dev->resource[i].flags = IORESOURCE_DISABLED;
> +   }
> }
>  }
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_WINBOND, PCI_DEVICE_ID_WINBOND_82C105,
> 
> 
> 
> Or did you mean 'if (dev->resource[5].start == 0)' ?

Nah, but also set resource->end = 0 too and or-in IORESOURCE_UNSET for
flags not (=) (or just set it to 0, I have no problem with completely
clearing the resource, that will keep it out of the way)

-
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: problem with pata_hpt37x ...

2007-01-04 Thread Brad Campbell

Alan wrote:

On Tue, 2 Jan 2007 08:01:45 +0100
Herbert Poetzl <[EMAIL PROTECTED]> wrote:


if you are interested in investigating this, please
let me know what kind of data you would like to see
and/or what kind of tests would be appreciated.


I reviewed the 374 code a bit further to see what might be causing this
and found the slave channel end of DMA handling was using the wrong port
I think.


This now passes all my stress tests Alan. No more "Interrupt disabled" or dmesg 
storms.
I put the HPT Rocketraid 1540 (HPT374) back in a box and connected 4 200GB ata drives to it using 
SATA-PATA bridgeboards as before. It looks to be rock solid now.


Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
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: problem with pata_hpt37x ...

2007-01-04 Thread Herbert Poetzl
On Thu, Jan 04, 2007 at 08:09:56PM +0400, Brad Campbell wrote:
> Alan wrote:
> >On Tue, 2 Jan 2007 08:01:45 +0100
> >Herbert Poetzl <[EMAIL PROTECTED]> wrote:
> >
> >>if you are interested in investigating this, please
> >>let me know what kind of data you would like to see
> >>and/or what kind of tests would be appreciated.
> >
> >I reviewed the 374 code a bit further to see what might be causing this
> >and found the slave channel end of DMA handling was using the wrong port
> >I think.
> 
> This now passes all my stress tests Alan. No more "Interrupt disabled"
> or dmesg storms. I put the HPT Rocketraid 1540 (HPT374) back in a box
> and connected 4 200GB ata drives to it using SATA-PATA bridgeboards as
> before. It looks to be rock solid now.

sounds great! where can I get that version?
should it be in 2.6.20-rc* or is there a separate
patch available somewhere?

TIA,
Herbert

> Brad
> -- 
> "Human beings, who are almost unique in having the ability
> to learn from the experience of others, are also remarkable
> for their apparent disinclination to do so." -- Douglas Adams
-
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: problem with pata_hpt37x ...

2007-01-04 Thread Brad Campbell

Herbert Poetzl wrote:


sounds great! where can I get that version?
should it be in 2.6.20-rc* or is there a separate
patch available somewhere?


The patch was contained in the message from Alan to you that I replied to. I just applied it to a 
vanilla 2.6.20-rc3 tree and fired it up.


(I've pasted it inline here for you but I'm using thunderbird and it's likely the resulting mess may 
not apply - not hard to manually change the required lines however)


--- linux.vanilla-2.6.20-rc3/drivers/ata/pata_hpt37x.c  2007-01-01 
21:43:27.0 +
+++ linux-2.6.20-rc3/drivers/ata/pata_hpt37x.c  2007-01-02 14:30:18.122801920 
+
@@ -25,7 +25,7 @@
 #include 

 #define DRV_NAME   "pata_hpt37x"
-#define DRV_VERSION"0.5.1"
+#define DRV_VERSION"0.5.2"

 struct hpt_clock {
u8  xfer_speed;
@@ -749,7 +749,7 @@
 {
struct ata_port *ap = qc->ap;
struct pci_dev *pdev = to_pci_dev(ap->host->dev);
-   int mscreg = 0x50 + 2 * ap->port_no;
+   int mscreg = 0x50 + 4 * ap->port_no;
u8 bwsr_stat, msc_stat;

pci_read_config_byte(pdev, 0x6A, &bwsr_stat);




Brad
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams
-
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: Initial Promise SX4 hw docs opened

2007-01-04 Thread Dan Williams

On 1/3/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:

The first open hardware docs for the Promise SX4 (sata_sx4) series are
now available:
http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-dimm-1.6.pdf.bz2
http://gkernel.sourceforge.net/specs/promise/pdc20621-pguide-pll-ata-timing-1.2.pdf.bz2

These are only small, ancillary guides; the main hardware doc should be
opened soon.

However, I would like to take this opportunity to point hackers looking
for a project at this hardware.  The Promise SX4 is pretty neat, and it
needs more attention than I can give, to reach its full potential.

Here's a braindump:

* It's an older chipset/board, probably not actively sold anymore

* ATA programming interface very close to sata_promise (PDC2037x)

* Contains on-board DIMM, to be used for any purpose the driver desires

* Contains on-board RAID5 XOR, also fully programmable

A key problem is that, under Linux, sata_sx4 cannot fully exploit the
RAID-centric power of this hardware by driving the hardware in "dumb ATA
mode" as it does.

A better driver would notice when a RAID1 or RAID5 array contains
multiple components attached to the SX4, and send only a single copy of
the data to the card (saving PCI bus bandwidth tremendously).
Similarly, a better driver would take advantage of the RAID5 XOR offload
capabilities, to offload the entire RAID5 read or write transaction to
the card.

All this is difficult within either the MD or DM RAID frameworks,
because optimizing each RAID transaction requires intimate knowledge of
the hardware.  We have the knowledge...  but I don't have good ideas --
aside from an SX4-specific RAID 0/1/5/6 driver -- on how to exploit this
knowledge.


Can the XOR engines on the card access host memory or do they only
operate on the card's local memory?  And are there DMA (copy) engines?


Traditionally the vendor has distributed a SCSI driver that implements
the necessary RAID stack pieces entirely in the hardware driver itself.
  That sort of approach definitely works, but is traditionally rejected
by upstream maintainers because it essentially requires a third (if h/w
specific) RAID stack.


[ brainstorming ]
For the RAID5 case: With the hardware acceleration patches the part of
MD that actually operates on the stripe cache is factored out of
handle_stripe5.  So MD can be used to handle all of the cache state
information and then use a SX4 specific operations routine to handle
the data transfers.  However this assumes that all the members of the
array are behind the SX4 (which is the same assumption the vendor
driver makes so maybe its not so bad).

The part I am lost at it is how do you tell libata and the lldd that
data for a transaction is coming from or headed to device local memory
and not host memory?  It seems there would need to be changes to the
dma api to handle this distinction?


Jeff



Dan
-
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: [RFC,PATCHSET] Managed device resources

2007-01-04 Thread Jeff Garzik

Greg KH wrote:

Hm, but I guess without the follow-up patches for libata, it will not
really get tested much.  Jeff, if I accept this, what's your feelings of
letting libata be the "test bed" for it?



It would be easiest for me to merge this through my 
libata-dev.git#upstream tree.  That will auto-propagate it to -mm, and 
ensure that both base and libata bits are sent in one batch.


Just shout if you see NAK-able bits...

Work for you?

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: [RFC,PATCHSET] Managed device resources

2007-01-04 Thread Greg KH
On Thu, Jan 04, 2007 at 05:26:43PM -0500, Jeff Garzik wrote:
> Greg KH wrote:
> >Hm, but I guess without the follow-up patches for libata, it will not
> >really get tested much.  Jeff, if I accept this, what's your feelings of
> >letting libata be the "test bed" for it?
> 
> 
> It would be easiest for me to merge this through my 
> libata-dev.git#upstream tree.  That will auto-propagate it to -mm, and 
> ensure that both base and libata bits are sent in one batch.
> 
> Just shout if you see NAK-able bits...
> 
> Work for you?

That works for me.

The only question I have is on the EXPORT_SYMBOL() stuff for the new
driver/base/ functions.  Tejun, traditionally the driver core has all
exported symbols marked with EXPORT_SYMBOL_GPL().  So, any objection to
marking the new ones (becides the "mirror" functions) in this manner?

thanks,

greg k-h
-
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: [RFC,PATCHSET] Managed device resources

2007-01-04 Thread Greg KH
On Wed, Dec 27, 2006 at 12:18:33AM +0900, Tejun Heo wrote:
> Hello, all.
> 
> This patchset implements managed device resources, in short, devres.



I like this.  It feels a bit awkward, and creating a bunch of duplicate
functions is "messy", but I can't think of any other way to achive this.

Your writeup in this message is also quite good, care to add it to the
Documentation/ directory in the kernel?

> ## Patchset
> 
> This patchset contains the following 12 patches and is against the
> current 2.6.20-rc2 (3bf8ba38f38d3647368e4edcf7d019f9f8d9184a).
> 
> 01: implement devres core
> 02-06 : implement managed resource interface for IO region, IRQ, DMA,
> PCI and iomap

Unless anyone objects, I'll add the first 6 patches here to my tree for
testing in -mm for a bit.

Hm, but I guess without the follow-up patches for libata, it will not
really get tested much.  Jeff, if I accept this, what's your feelings of
letting libata be the "test bed" for it?

thanks,

greg k-h
-
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


Norco DS-1220 (sil3726+sil3124) / libata-tj bug report

2007-01-04 Thread Brad Fitzpatrick
Tejun, et al,

Hardware:
   Norco DS-1220 SATA enclosure (sil2134 card w/ 4 PMP/direct ports,
   enclosure is 2x sil3726 (5 disks each), and then 2 direct SATA ports.

   (also have 2x SATA internal, on ata_piix, md raid1, that's working fine...
those are sd[ab], ata[12].nn, scsi[01])

Kernel:
   2.6.18.6 + libata-tj-2.6.18.1-20061020.

Issue:

Disks in DS-1220 show up, kinda, but don't work.  Errors reading /
writing blocks.  Tried a single disk in both a PMP port and a direct
(non-sil3726) port.

Full dmesg:
  http://bradfitz.com/temp/libata-norco-timeout-dmesg.txt

.config:
  http://bradfitz.com/temp/libata-norco-config.txt

Snippet of dmesg:


18:29:45 ata3.15: exception Emask 0x100 SAct 0x0 SErr 0x0 action 0x1
18:29:45 ata3.15: (irq_stat 0x08000800, SDB notify)
18:29:45 ata3.01: exception Emask 0x10 SAct 0x0 SErr 0x405 action 0x43
18:29:46 ata3.01: waiting for device to spin up (8 secs)
18:29:53 ata3.01: hard resetting port
18:29:54 ata3.01: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
18:29:54 ata3.01: ATA-6, max UDMA/100, 488397168 sectors: LBA48
18:29:54 ata3.01: ata3: dev 0 multi count 0
18:29:54 ata3.01: applying bridge limits
18:29:54 ata3.01: configured for UDMA/100
18:29:54 ata3: EH complete
18:29:55   Vendor: ATA   Model: WDC WD2500JD-00G  Rev: 02.0
18:29:55   Type:   Direct-Access  ANSI SCSI revision: 05
18:29:55 SCSI device sdd: 488397168 512-byte hdwr sectors (250059 MB)
18:29:55 sdd: Write Protect is off
18:29:55 sdd: Mode Sense: 00 3a 00 00
18:29:55 SCSI device sdd: drive cache: write back
18:29:55 SCSI device sdd: 488397168 512-byte hdwr sectors (250059 MB)
18:29:55 sdd: Write Protect is off
18:29:55 sdd: Mode Sense: 00 3a 00 00
18:29:55 SCSI device sdd: drive cache: write back
18:29:55  sdd:<3>ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
18:29:55 ata3.01: (irq_stat 0x00020002, device error via D2H FIS)
18:29:55 ata3.01: tag 0 cmd 0xc8 Emask 0x1 stat 0x50 err 0x0 (device error)
18:29:55 ata3: EH complete
18:29:55 ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
18:29:55 ata3.01: (irq_stat 0x00060002, device error via D2H FIS)
18:29:55 ata3.01: tag 0 cmd 0xc8 Emask 0x1 stat 0x50 err 0x0 (device error)
18:29:55 ata3: EH complete
18:29:55 ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
18:29:55 ata3.01: (irq_stat 0x00060002, device error via D2H FIS)
18:29:55 ata3.01: tag 0 cmd 0xc8 Emask 0x1 stat 0x50 err 0x0 (device error)
18:29:55 ata3: EH complete
18:29:55 ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
18:29:55 ata3.01: (irq_stat 0x00060002, device error via D2H FIS)
18:29:55 ata3.01: tag 0 cmd 0xc8 Emask 0x1 stat 0x50 err 0x0 (device error)
18:29:55 ata3: EH complete
18:29:56 ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
18:29:56 ata3.01: (irq_stat 0x00060002, device error via D2H FIS)
18:29:56 ata3.01: tag 0 cmd 0xc8 Emask 0x1 stat 0x50 err 0x0 (device error)
18:29:56 ata3: EH complete
18:29:56 ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
18:29:56 ata3.01: (irq_stat 0x00060002, device error via D2H FIS)
18:29:56 ata3.01: tag 0 cmd 0xc8 Emask 0x1 stat 0x50 err 0x0 (device error)
18:29:56 sd 2:0:1:0: SCSI error: return code = 0x0802
18:29:56 sdd: Current: sense key: Aborted Command
18:29:56 Additional sense: No additional sense information
18:29:56 end_request: I/O error, dev sdd, sector 0
18:29:56 Buffer I/O error on device sdd, logical block 0
18:29:56 ata3: EH complete
18:29:56 ata3.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
18:29:56 ata3.01: (irq_stat 0x00060002, device error via D2H FIS)


lspci:

:03:01.0 Mass storage controller: Silicon Image, Inc. SiI 3124 PCI-X Serial 
ATA Controller (rev 01)
Subsystem: Silicon Image, Inc. SiI 3124 PCI-X Serial ATA Controller
Flags: bus master, stepping, 66MHz, medium devsel, latency 32, IRQ 21
Memory at ff9ffc00 (64-bit, non-prefetchable) [size=128]
Memory at ff9f (64-bit, non-prefetchable) [size=32K]
I/O ports at bc00 [size=16]
Expansion ROM at f6a0 [disabled] [size=512K]
Capabilities: [64] Power Management version 2
Capabilities: [40] PCI-X non-bridge device.
Capabilities: [54] Message Signalled Interrupts: 64bit+ Queue=0/0 
Enable-

:00:00.0 Host bridge: Intel Corporation 82865G/PE/P DRAM 
Controller/Host-Hub Interface (rev 02)
:00:01.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to AGP Controller 
(rev 02)
:00:03.0 PCI bridge: Intel Corporation 82865G/PE/P PCI to CSA Bridge (rev 
02)
:00:1d.0 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI 
Controller #1 (rev 02)
:00:1d.1 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI 
Controller #2 (rev 02)
:00:1d.2 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI 
Controller #3 (rev 02)
:00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI 
Controller #4 (rev 02)
:00:1d.7 USB Contro

Re: Norco DS-1220 (sil3726+sil3124) / libata-tj bug report

2007-01-04 Thread Jim Paris
Hi Brad,

> Hardware:
>Norco DS-1220 SATA enclosure (sil2134 card w/ 4 PMP/direct ports,
>enclosure is 2x sil3726 (5 disks each), and then 2 direct SATA ports.
> 
>(also have 2x SATA internal, on ata_piix, md raid1, that's working fine...
> those are sd[ab], ata[12].nn, scsi[01])
> 
> Kernel:
>2.6.18.6 + libata-tj-2.6.18.1-20061020.
> 
> Issue:
> 
> Disks in DS-1220 show up, kinda, but don't work.  Errors reading /
> writing blocks.  Tried a single disk in both a PMP port and a direct
> (non-sil3726) port.

Just FYI:

I am using the same enclosure and card with no problems at all on
2.6.17.4 + libata-tj-2.6.17.4-20060710.  The card is plugged into a
PCI slot, not PCI-X.  My disks are Seagate ST3300822AS in all 12 bays.

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


2.6.20-rc3: known unfixed regressions (v3)

2007-01-04 Thread Adrian Bunk
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject: BUG: scheduling while atomic: hald-addon-stor/...
 cdrom_{open,release,ioctl} in trace
References : http://lkml.org/lkml/2006/12/26/105
 http://lkml.org/lkml/2006/12/29/22
 http://lkml.org/lkml/2006/12/31/133
Submitter  : Jon Smirl <[EMAIL PROTECTED]>
 Damien Wyart <[EMAIL PROTECTED]>
 Aaron Sethman <[EMAIL PROTECTED]>
Status : unknown


Subject: Acer Extensa 3002 WLMi: 'shutdown -h now' reboots the system
References : http://lkml.org/lkml/2006/12/25/40
Submitter  : Berthold Cogel <[EMAIL PROTECTED]>
Status : unknown


Subject: USB keyboard unresponsive after some time
References : http://lkml.org/lkml/2006/12/25/35
 http://lkml.org/lkml/2006/12/26/106
Submitter  : Florin Iucha <[EMAIL PROTECTED]>
Status : unknown


Subject: SPARC64: Can't mount /  (CONFIG_SCSI_SCAN_ASYNC=y ?)
References : http://lkml.org/lkml/2006/12/13/181
 http://lkml.org/lkml/2007/01/04/75
Submitter  : Horst H. von Brand <[EMAIL PROTECTED]>
Status : unknown


Subject: ftp: get or put stops during file-transfer
References : http://lkml.org/lkml/2006/12/16/174
Submitter  : Komuro <[EMAIL PROTECTED]>
Caused-By  : YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
 commit cfb6eeb4c860592edd123fdea908d23c6ad1c7dc
Handled-By : YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Status : problem is being debugged


Subject: x86_64 boot failure: "IO-APIC + timer doesn't work"
References : http://lkml.org/lkml/2006/12/16/101
 http://lkml.org/lkml/2007/1/3/9
Submitter  : Tobias Diedrich <[EMAIL PROTECTED]>
Caused-By  : Andi Kleen <[EMAIL PROTECTED]>
 commit b026872601976f666bae77b609dc490d1834bf77
Handled-By : Yinghai Lu <[EMAIL PROTECTED]>
 Eric W. Biederman <[EMAIL PROTECTED]>
Status : patches are being discussed
-
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