There are machines out there which share legacy PCI IDE IRQs w/ other
devices. libata SFF interrupt/HSM code is ready for shared IRQ and
has been setting IRQF_SHARED for devices in native PCI mode. Device
in legacy mode is still a PCI device and thus supposedly uses
active-low level triggered IRQ
Mark Lord wrote:
Tejun Heo wrote:
Note that ->freeze() handler is always called under ap->lock held and
irq disabled. Even if CTL manipulation causes stuck IRQ, it's cleared
immediately. This should be safe (enough) even in SMP environment.
More correct solution is to mask the IRQ from IRQ co
Tejun Heo wrote:
Note that ->freeze() handler is always called under ap->lock held and
irq disabled. Even if CTL manipulation causes stuck IRQ, it's cleared
immediately. This should be safe (enough) even in SMP environment.
More correct solution is to mask the IRQ from IRQ controller but that
Now that BMDMA status is recorded in irq handler. ata_bmdma_freeze()
is free to manipulate host status. Under certain circumstances, some
controllers (ICH7 in enhanced mode w/ IRQ shared) raise IRQ when CTL
register is written to and ATA_NIEN doesn't mask it.
This patch makes ata_bmdma_freeze()
Now that BMDMA status is recorded in irq handler. ata_bmdma_freeze()
is free to manipulate host status. Under certain circumstances, some
controllers (ICH7 in enhanced mode w/ IRQ shared) raise IRQ when CTL
register is written to and ATA_NIEN doesn't mask it.
This patch makes ata_bmdma_freeze()
For certain errors, interrupt handler alter BMDMA host status before
entering EH (clears active and intr). Thus altered BMDMA host status
value is recorded by BMDMA EH and reported to user. Move BMDMA host
status recording from EH to interrupt handler.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]
HSM_ST_UNKNOWN is not used anywhere. Its value is zero and supposed
to serve sanity check purpose but HSM_ST_IDLE is used for that
purpose. This unused state causes confusion. After a port is
initialized but before the first command is executed, the idle hsm
state is UNKNOWN. However, once a co
On Thu, 16 Nov 2006 23:12:19 +0100
Sylvain Munaut <[EMAIL PROTECTED]> wrote:
> * The manual states we should check for the TIP bit before all
> PIO transaction. That's not really supported by libata and requires
> reimplementing almost all the hooks. But after talking to Freescale,
> it turnsout i
Hi,
When booting a fresh 2.6.19-rc5-mm2, I get a lof of traces like this:
WARNING at drivers/ata/sata_nv.c:762 nv_adma_bmdma_setup()
Call Trace:
[] show_trace+0x34/0x47
[] dump_stack+0x12/0x17
[] :libata:ata_qc_issue_prot+0x1ec/0x24c
[] :libata:ata_qc_issue+0x400/0x45d
[] :libata:ata_scsi_
This is the first attempt at a libata driver for this controller.
The two main issues :
* The manual states we should check for the TIP bit before all
PIO transaction. That's not really supported by libata and requires
reimplementing almost all the hooks. But after talking to Freescale,
it turnsou
On Thu, 16 Nov 2006 13:52:28 +
"Andrew Lyon" <[EMAIL PROTECTED]> wrote:
>
> Comparing the first 32k of the 4 disks under 2.6.18.2 and 2.6.19-rc5
> there is no difference, so I decided to compare the bootup dmesg, the
> following text is not output with 2.6.19-rc5:
>
> md: md driver 0.90.3 MA
On 15/11/06 23:10 -0600, Ben Gardner wrote:
> On 11/15/06, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> >I am embarrassed to say that I have yet to try out the
> >CS5535 PATA driver.
>
> So which driver is used with the OLPC?
> Or does that not use IDE devices?
OLPC uses USB and NAND. I'll leave i
G'day all,
Rehash of an old problem. I've done a bit of homework and found this only occurs on the last 2 ports
of the card. If I take the drives from ports 3&4 and put them on a SIL3112 I've got lying around,
then the system works perfectly.
Diving deeper, the below problem only surfaces whe
On Wed, Nov 15 2006, Marek Podmaka wrote:
> Hello,
>
> I have server with Intel 5000V motherboard with integrated AHCI SATA
> controller. It works well with kernel 2.6.18.2. But I have problem
> with little entropy available and I'm not sure if one of the reasons
> is that AHCI driver does
Andrew Morton wrote:
On Thu, 16 Nov 2006 09:52:27 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
ATAPI devices transfer fixed number of bytes for CDBs (12 or 16).
Some ATAPI devices choke when shorter CDB is used and the left bytes
contain garbage. Block SG_IO cleared left bytes but SCSI SG_IO
did
On 11/15/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Wed, 15 Nov 2006 14:45:27 +
"Andrew Lyon" <[EMAIL PROTECTED]> wrote:
> Andrew,
>
> You asked me to test if the issues I reported (Re: JMicron 20360/20363
> AHCI Controller much slower with 2.6.18 / Re: SATA CD/DVDRW Support in
> 2.6.18
> To further assist anyone wishing to hack on sata_promise.c, I just
> uploaded the long-since-GPL'd vendor drivers for Generation-I and
> Generation-II chipsets to
> http://gkernel.sourceforge.net/specs/promise/
>
> This should help with isolating the proper initialization
> sequence for a gi
On Thu, 16 Nov 2006 09:52:27 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> ATAPI devices transfer fixed number of bytes for CDBs (12 or 16).
> Some ATAPI devices choke when shorter CDB is used and the left bytes
> contain garbage. Block SG_IO cleared left bytes but SCSI SG_IO
> didn't. This patch
Tejun Heo wrote:
> Vasily Averin wrote:
>> Alan Cox wrote:
>>> Ar Gwe, 2006-10-27 am 17:17 +0400, ysgrifennodd Vasily Averin:
Could somebody please help me to troubleshoot this issue? I've seen this
issue
on the customer nodes and would like to know how I can work-around this
19 matches
Mail list logo
