Hello,
Robert Hancock wrote:
[--correct summary snipped--]
Given the above, what I'm proposing to do is:
-Remove the blacklisting of Maxtor BANC1G10 firmware for FUA. If we need
to FUA-blacklist any drives this should likely be added to the existing
"horkage" mechanism we now have. However, a
Le Samedi 10 Février 2007 15:45, Tejun Heo a écrit :
> [cc'ing Alan and Jean, Hi!]
>
> Leopold Palomo Avellaneda wrote:
> > A Divendres 09 Febrer 2007 18:13, Leopold Palomo Avellaneda va escriure:
> >> A Divendres 09 Febrer 2007 10:46, Tejun Heo va escriure:
> >>> Leopold Palomo Avellaneda wrote:
>
[cc'ing Pavel, Hi!]
Robert Hancock wrote:
I'm seeing BUGs like these on all libata-driven controllers when
suspending to disk on 2.6.20-git6:
sata_nv :00:07.0: resuming
BUG: at drivers/pci/pci.c:817 pcim_enable_device()
Call Trace:
[] pcim_enable_device+0x8a/0xa5
[] :libata:ata_pci_devi
Jean Delvare wrote:
I've read the whole thread, the source code (quickly) and the patches to
ahci.c and sata_via.c, and here are some comments:
It looks like support for the VT8251 was added to the ahci driver in kernel
2.6.18, and was then updated in 2.6.20. The code is different from the
pa
Zhang, Yanmin wrote:
Hi,
I am using Fedora Core 7 Test1 on my ia64 box and run into an issue
about my cd drive. FC6 works well on my machine, but FC7Test1 couldn't
recognise the cd drive.
Just an FYI for everyone on linux-ide ... F7 (not FC anymore ;) )
maps upstream. I think there is a b
O> 0x 0x03ff 0x0200
> 0x 0x 0x
>
> The 5th bar is incorrect. BIOS initiates ide controllers.
You appear to have a 5th BAR allocated at address 0 with a length of
0x400.
> failure, but ide-cd/piix is smarter
A Dilluns 12 Febrer 2007 10:11, Jean Delvare va escriure:
> Le Samedi 10 Février 2007 15:45, Tejun Heo a écrit :
> > [cc'ing Alan and Jean, Hi!]
> >
> > Leopold Palomo Avellaneda wrote:
> > > A Divendres 09 Febrer 2007 18:13, Leopold Palomo Avellaneda va escriure:
> > >> A Divendres 09 Febrer 2007
> Your platform code or BIOS is buggy. PPC people had a similar problem.
> Zero is not currently taken as "unallocated" by the PCI layer and, while
> Linus suggested it could be, Dave Woodhouse and others pointed out there
> are systems which legitimately use address 0 on the PCI in this way.
The
If many other BIOS writers believe the same thing as ours, then maybe
it might be worth fixing ... otherwise it looks like we'll need a quirk
(this machine is old, there isn't much liklihood of an updated BIOS release
for just this issue).
Tony,
As Alan suggested I think Yanmin should pu
> Which sounds sort of plausible ... but perhaps that's because I have
> not idea what a "Class code programming model" is. Does that make
> any sense?
I think they are talking about BAR0 to 3 which are special, not BAR5
which the ia64 kernel code has somehow ended up assigned at I/O address
zero
A Dilluns 12 Febrer 2007 10:11, Jean Delvare va escriure:
> Le Samedi 10 Février 2007 15:45, Tejun Heo a écrit :
> > [cc'ing Alan and Jean, Hi!]
> >
> > Leopold Palomo Avellaneda wrote:
> > > A Divendres 09 Febrer 2007 18:13, Leopold Palomo Avellaneda va escriure:
> > >> A Divendres 09 Febrer 2007
Conversion to resource-managed iomap was buggy causing init failures
on both vt6420 and 6421 - BAR5 wasn't mapped for both controllers
while on vt6420 sata_via tried to map BAR0-4 twice. Fix it.
DO NOT APPLY YET.
---
Markus, does this fix your problem?
diff --git a/drivers/ata/sata_via.c b/driv
On Mon, Feb 12, 2007 at 10:51:44AM -0800, Tejun Heo wrote:
> Conversion to resource-managed iomap was buggy causing init failures
> on both vt6420 and 6421 - BAR5 wasn't mapped for both controllers
> while on vt6420 sata_via tried to map BAR0-4 twice. Fix it.
>
> DO NOT APPLY YET.
> ---
> Markus,
Markus Trippelsdorf wrote:
On Mon, Feb 12, 2007 at 10:51:44AM -0800, Tejun Heo wrote:
Conversion to resource-managed iomap was buggy causing init failures
on both vt6420 and 6421 - BAR5 wasn't mapped for both controllers
while on vt6420 sata_via tried to map BAR0-4 twice. Fix it.
Great, can a
Hi!
> >I'm seeing BUGs like these on all libata-driven controllers when
> >suspending to disk on 2.6.20-git6:
> >
> >sata_nv :00:07.0: resuming
> >BUG: at drivers/pci/pci.c:817 pcim_enable_device()
> >
> >Call Trace:
> > [] pcim_enable_device+0x8a/0xa5
> > [] :libata:ata_pci_device_do_resume+
The READ/WRITE LONG commands are theoretically obsolete,
but most (all?) drives to date still implement them.
Of these, WRITE_LONG and WRITE_LONG_ONCE are of particular
interest for fault injection testing -- eg. creating "media errors"
at specific locations on a disk.
The fussy bit is that thes
Tejun Heo wrote:
-Add a new port flag ATA_FLAG_NO_FUA to indicate that a controller
can't handle FUA commands, and add that flag to sata_sil. Force FUA
off on any drive connected to a controller with this bit set.
There was some talk that sata_mv might have this problem, but I
believe the con
17 matches
Mail list logo
