On Thu, Mar 15, 2007 at 11:37:20AM +0900, Tejun Heo wrote:
...
> Also, the current implementation doesn't have any arch independent part.
I thnk you meant "arch dependent" here.
> It's wholly contained in arch independent PCI layer, but it might be
> beneficial to have arch dependent hooks (IR
[cc'ing Albert Lee. Hi!]
Vlad Codrea wrote:
>> Okay, now that you're on libata driver, it's easier for me to debug.
>> Can you apply the attached patch over 2.6.20 and report what the kernel
>> says? (the patch will apply with some noise, it's okay)
>
> I've applied your patch and recompiled the
Alan Cox wrote:
> - Use of cable_detect method
> - ata_pci_default_filter needed on PATA100 ops
> - Filter for UDMA 133 errata from vendor (not enabled in this diff but
> added ready)
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
>
>
> /**
> + * pdc2720x_mode_filter- mode selec
[cc'ing Andi, Hi!]
Hello,
Russell King wrote:
> On Wed, Mar 14, 2007 at 06:34:11PM -0400, Jeff Garzik wrote:
>> Russell King wrote:
>>> pci_enable_device() doesn't deal with this; in most PCI setups I've
>>> seen, there is no control at PCI level over whether a device generates
>>> an interrupt o
PATA_SCC depends on PPC_CELLEB. (not PPC_IBM_CELL_BLADE)
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Akira Iguchi <[EMAIL PROTECTED]>
---
diff -Nrpu -X linux-2.6.21-rc3/Documentation/dontdiff
linux-2.6.21-rc3/drivers/ata/Kconfig linux-2.6.21-rc3.mod/drivers/ata/Kconfig
--- lin
Stanislav Brabec wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
>>On Wednesday 14 March 2007, Stanislav Brabec wrote:
>>
>>>Albert Lee wrote:
>>>
Tejun Heo wrote:
>>>
>Hmmm... weird. Your drive bears the same model name as Stanislav's. I
>don't think the low level driver is causing the
YUP wrote:
> Hello,
>
> I have the folowing problem. I'm running kubuntu box with
> 2.6.20-10 kernel with ubuntu patches and my cdrom as well as dvd drive
> doesn't recognized at all. I've already reported this on kubuntu forum,
> but nobody can answer me. The link is here:
> http://kubuntuforums.
Andi Kleen wrote:
Tejun Heo <[EMAIL PROTECTED]> writes:
Let's assume there's a device which shares its INTX IRQ line with
another device and the other one is already initialized. During boot,
due to BIOS's fault, bad hardware design or sheer bad luck, the device
has got a pending IRQ.
This se
Stephen Hemminger wrote:
The problem is the BIOS is busted on these machines. How much effort
do we want to put into dealing with systems with broken BIOS?
I would rather have the root cause fixed than creating a bandaid that
has to be maintained for all the other architectures and platforms.
F
Fajun Chen wrote:
> On 3/14/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
>> Fajun Chen wrote:
>> > Since primary channel and secondary channel share the same IRQ, the
>> > ISR could be called to service one or both channels. So I would think
>> > it's normal to see "irq trap" traces when both cha
Mark Lord wrote:
Tejun Heo wrote:
Yeap, agreed but I think getting more info on the libata HSM violation
can help diagnosing ide problem too. Anyways, Stanislav, can you bisect
as Bartlomiej requested?
Tejun, do you have a Zip100 (ATAPI) drive to play with there?
Nope. Do you happen to h
On 3/14/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Fajun Chen wrote:
> Since primary channel and secondary channel share the same IRQ, the
> ISR could be called to service one or both channels. So I would think
> it's normal to see "irq trap" traces when both channels are in IO
> operation, corr
Russell King wrote:
In any case, relying on such a new control bit to implement this kind
of functionality would result in a very hit and miss result; Linux
How does Tejun's patch or thesis rely on this new control bit? He
explicitly mentions DISABLE_INTX variability...
Jeff
-
To
On Wed, Mar 14, 2007 at 06:34:11PM -0400, Jeff Garzik wrote:
> Russell King wrote:
> >pci_enable_device() doesn't deal with this; in most PCI setups I've
> >seen, there is no control at PCI level over whether a device generates
> >an interrupt on the bus. Certainly the memory and io command enable
Fajun Chen wrote:
Since primary channel and secondary channel share the same IRQ, the
ISR could be called to service one or both channels. So I would think
it's normal to see "irq trap" traces when both channels are in IO
operation, correct?
The irq trap code only occurs after a certain number
Since primary channel and secondary channel share the same IRQ, the
ISR could be called to service one or both channels. So I would think
it's normal to see "irq trap" traces when both channels are in IO
operation, correct?
I have another question in regard to ata_host_intr() function in
libata-
Russell King wrote:
pci_enable_device() doesn't deal with this; in most PCI setups I've
seen, there is no control at PCI level over whether a device generates
an interrupt on the bus. Certainly the memory and io command enables
PCI grew an interrupt enable while you weren't looking:
PCI_COMMA
Hello,
I have the folowing problem. I'm running kubuntu box with
2.6.20-10 kernel with ubuntu patches and my cdrom as well as dvd drive
doesn't recognized at all. I've already reported this on kubuntu forum,
but nobody can answer me. The link is here:
http://kubuntuforums.net/forums/index.php?top
On Thu, Mar 15, 2007 at 12:23:02AM +0900, Tejun Heo wrote:
> The problem is that a PCI device can be in any arbitrary when it gets
> enabled and the device has to be enabled for its driver to
> initialize/reset it. The most common case this causes headache is as
> follows.
>
> Let's assume there'
Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 14 March 2007, Stanislav Brabec wrote:
> > Albert Lee wrote:
> > > Tejun Heo wrote:
> >
> > > > Hmmm... weird. Your drive bears the same model name as Stanislav's. I
> > > > don't think the low level driver is causing the difference. They both
> >
Hello, I wrote:
Bartlomiej Zolnierkiewicz wrote:
[PATCH] sl82c105: add ->speedproc support
* add sl82c105_tunepio() wrapper for sl82c105_tune_drive()
(just to get the error value)
* add sl82c105_tune_chipset() (->speedproc method) for setting
transfer mode
Thanks for the patch!
Tejun Heo <[EMAIL PROTECTED]> writes:
>
> Let's assume there's a device which shares its INTX IRQ line with
> another device and the other one is already initialized. During boot,
> due to BIOS's fault, bad hardware design or sheer bad luck, the device
> has got a pending IRQ.
This seems to be a
Tejun Heo wrote:
Yeap, agreed but I think getting more info on the libata HSM violation
can help diagnosing ide problem too. Anyways, Stanislav, can you bisect
as Bartlomiej requested?
Tejun, do you have a Zip100 (ATAPI) drive to play with there?
Cheers
-
To unsubscribe from this list: s
Mark Lord wrote:
Tejun wrote:
If that's the case, libata should work too as long as the HSM problem is
fixed.
Really? I didn't notice when libata gained ATAPI-disk support.
ATAPI just passes through to SCSI. There is no limitation on the
peripheral device types supported, except in the SC
On Thu, 15 Mar 2007, Tejun Heo wrote:
> Hello, all.
>
> This patch started off from the following thread.
>
> http://thread.gmane.org/gmane.linux.ide/16899
>
> The problem is that a PCI device can be in any arbitrary when it gets
> enabled and the device has to be enabled for its driver to
>
On Thu, 15 Mar 2007 00:23:02 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello, all.
>
> This patch started off from the following thread.
>
> http://thread.gmane.org/gmane.linux.ide/16899
>
> The problem is that a PCI device can be in any arbitrary when it gets
> enabled and the device has
Vlad Codrea wrote:
Tejun Heo wrote:
Vlad Codrea wrote:
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: (BMDMA stat 0x25)
ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data
36 in
res 58/00:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM
violat
Ok, thanks for reporting back - I'm crossing out this item from my TODO. :-)
Bart
On Wednesday 14 March 2007, Uwe Bugla wrote:
> Hi Linus, Bart, Andrew, Alan,
>
> all ide-layer bugs I reported in connection with reinitialization oopses
> using a TEAC CDRW54 are gone in 2.6.21-rc3-git4.
> This
drivers/ide/mips/au1xxx-ide.c:684: warning: ISO C90 forbids mixed declarations
and code
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
diff --git a/drivers/ide/mips/au1xxx-ide.c b/drivers/ide/mips/au1xxx-ide.c
index b2dc028..d54d9fe 100644
--- a/drivers/ide/mips/au1xxx-ide.c
+++ b/drivers/ide/m
Tejun Heo wrote:
> Brian King wrote:
>> For SAS, the scsi_host pointer in the ata port is NULL today, since libata
>> is really not managing the scsi host, the LLDD is. I think the initialization
>> model we want for SAS is a little different than the one you are heading
>> towards on SATA. For SAS
Hello, all.
This patch started off from the following thread.
http://thread.gmane.org/gmane.linux.ide/16899
The problem is that a PCI device can be in any arbitrary when it gets
enabled and the device has to be enabled for its driver to
initialize/reset it. The most common case this causes he
Tejun Heo wrote:
Vlad Codrea wrote:
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: (BMDMA stat 0x25)
ata2.00: cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in
res 58/00:02:00:24:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
ata2: soft reset
Hi Linus, Bart, Andrew, Alan,
all ide-layer bugs I reported in connection with reinitialization oopses using
a TEAC CDRW54 are gone in 2.6.21-rc3-git4.
This is a good kernel, and at least I have not found any regressions in it.
To whoever fixed that: A thousand thanks! Very good work!
Yours sin
On Wed, Mar 14, 2007 at 11:07:40AM +0200, Faik Uygur wrote:
> In case of libata, discovery of ATAPI devices is the default behaviour.
>
> Signed-off-by: Faik Uygur <[EMAIL PROTECTED]>
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 856c8b1..96
On Wednesday 14 March 2007, Tejun Heo wrote:
> Several people have reported LITE-ON LTR-48246S detection failed
> because SETXFER fails. It seems the device raises IRQ too early after
> SETXFER. This is controller independent. The same problem has been
> reported for different controllers.
>
>
Bartlomiej Zolnierkiewicz wrote:
>> My drive is a slave on bus, where master is a modern Seagate ST3160812A.
>>
>> On my system I see two regressions:
>> - One between year 2002 kernels and SuSE Linux 10.0:
>> Delay with "packet command initiated yet DRQ isn't asserted" before
>> first read acc
Mark Lord wrote:
> Tejun wrote:
>> If that's the case, libata should work too as long as the HSM problem is
>> fixed.
>
> Really? I didn't notice when libata gained ATAPI-disk support.
>
> Are you *sure* about that??
Not sure sure but almost sure. :-) What ide-scsi does is borrowing
SCSI mid
On Wednesday 14 March 2007, Stanislav Brabec wrote:
> Albert Lee wrote:
> > Tejun Heo wrote:
>
> > > Hmmm... weird. Your drive bears the same model name as Stanislav's. I
> > > don't think the low level driver is causing the difference. They both
> > > use the standard libata HSM implementatio
Tejun wrote:
If that's the case, libata should work too as long as the HSM problem is
fixed.
Really? I didn't notice when libata gained ATAPI-disk support.
Are you *sure* about that??
Cool.
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [
Stanislav Brabec wrote:
> Looking at the syslog in Novell bug 232086 in detail, following line may
> indicate hardware failure:
> usb 5-1: string descriptor 0 read error: -22
I don't think usb 5-1 is related to ide-floppy problem.
> My drive is a slave on bus, where master is a modern Seagate ST3
Jeff Garzik wrote:
> Tejun Heo wrote:
>> There was a rare report where SB600 reported SERR_INTERNAL and SRST
>> couldn't get it out of the failure mode. Hardreset on SERR_INTERNAL.
>> As the problem is intermittent, whether this fixes the problem or not
>> hasn't been verified yet, but hardresetti
Tejun Heo a écrit :
> Hello,
>
>
> Due to blacklisting, NCQ
> won't be turned on your drive in future kernels.
>
>
Hello thanks.
I have found on Hitachi website the technical datasheets of my drive
model:
http://www.hitachigst.com/tech/techlib.nsf/techdocs/28DCCB17E0EEC5A086256F4E006E2F5B/$file/
Albert Lee wrote:
> Tejun Heo wrote:
> > Hmmm... weird. Your drive bears the same model name as Stanislav's. I
> > don't think the low level driver is causing the difference. They both
> > use the standard libata HSM implementation. Any ideas? Stanislav, can
> > you try to connect that zip dr
Tejun Heo wrote:
There was a rare report where SB600 reported SERR_INTERNAL and SRST
couldn't get it out of the failure mode. Hardreset on SERR_INTERNAL.
As the problem is intermittent, whether this fixes the problem or not
hasn't been verified yet, but hardresetting the channel on internal
erro
On Wed, 14 Mar 2007 05:06:11 -0400, Jeff Garzik wrote:
> > - tmp = readl(mmio);
> > - if (tmp & PDC_ERR_MASK) {
> > - qc->err_mask |= AC_ERR_DEV;
> > - pdc_reset_port(ap);
>
> AFAICS pdc_reset_port() will no longer be called, after this change.
>
> Since you are freezing t
Mikael Pettersson wrote:
This patch adds much needed error reason decoding and
reporting to sata_promise. It's simplistic but should
log all relevant error info the controller provides.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
---
drivers/ata/sata_promise.c | 64 ++
In case of libata, discovery of ATAPI devices is the default behaviour.
Signed-off-by: Faik Uygur <[EMAIL PROTECTED]>
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 856c8b1..96b6ec5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation
Tejun Heo wrote:
>
>
> Hmmm... weird. Your drive bears the same model name as Stanislav's. I
> don't think the low level driver is causing the difference. They both
> use the standard libata HSM implementation. Any ideas? Stanislav, can
> you try to connect that zip drive to another IDE con
This patch adds much needed error reason decoding and
reporting to sata_promise. It's simplistic but should
log all relevant error info the controller provides.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
---
drivers/ata/sata_promise.c | 64 ++---
Albert Lee wrote:
> Jeff Garzik wrote:
>> Tejun Heo wrote:
>>
>>> [libata]
>>> And, as the device requires custom high level driver, libata fails
>>> miserably. Would it be worth to try support these devices? Or are
>>> they just too outdated to put the effort in?
>>
>> What SCSI peripheral devic
Jeff Garzik wrote:
> Tejun Heo wrote:
>
>> [libata]
>> And, as the device requires custom high level driver, libata fails
>> miserably. Would it be worth to try support these devices? Or are
>> they just too outdated to put the effort in?
>
>
> What SCSI peripheral device type does it report,
51 matches
Mail list logo
