Hi!
Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
it spins down the disk correctly. Does emergency unload count increase
after each power down? Also, please post the result of 'dmidecode'.
I know that my Compaq X1000-series laptop does do some kind of ACPI
Hi!
firmwarekit-discuss [EMAIL PROTECTED] (added to CC list)
see: http://linuxfirmwarekit.org/
But if I understand this problem right, this won't be easy.
The ACPI tables are just parsed with system (iasl ...) and syntactical
errors/warnings are printed out.
I also thought about a
On Thu, 2007-08-09 at 15:16 +, Pavel Machek wrote:
Hi!
firmwarekit-discuss [EMAIL PROTECTED] (added to CC list)
see: http://linuxfirmwarekit.org/
But if I understand this problem right, this won't be easy.
The ACPI tables are just parsed with system (iasl ...) and
I'm trying to figure out what could cause the following error
messages. This is on a PPC host using a ULI 1575 southbridge:
- k
ata5: PATA max UDMA/133 cmd 0xfdfee300 ctl 0xfdfee30a bmdma
0xfdfee320 irq 6
ata6: PATA max UDMA/133 cmd 0xfdfee310 ctl 0xfdfee31a bmdma
0xfdfee328 irq 6
On Wed, 1 Aug 2007 14:16:51 -0700
Kristen Carlson Accardi [EMAIL PROTECTED] wrote:
I was able to duplicate Tejun's problem on an ATAPI device I had here.
this updated patch fixed my problem. These devices are just setting
PhyReady (N) and CommWake (W) in Serror on power state changes,
On Thu, Aug 09, 2007 at 02:53:36PM +0100, Alan Cox wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8424 - patch review
This one is on Alan.
I think not - something horrible is happening in dma_alloc_coherent when
called from dmam_* with a non PCI device
Seems to be some kind of
Seems to be some kind of AMD64 specific DMA mapping bug ?
I think it's dev-dma_mask == NULL. Clearly you're passing a non DMA
able device to dma_alloc_coherent(). Which seems like a caller bug.
Ok - other archs seem to just return NULL in this case. If its your view
that
On Aug 9, 2007, at 12:17 PM, Alan Cox wrote:
On Thu, 9 Aug 2007 10:59:12 -0500
Kumar Gala [EMAIL PROTECTED] wrote:
I'm trying to figure out what could cause the following error
messages. This is on a PPC host using a ULI 1575 southbridge:
I'm still chasing problems with ATAPI DMA on some
On Thu, Aug 09, 2007 at 06:21:01PM +0100, Alan Cox wrote:
Seems to be some kind of AMD64 specific DMA mapping bug ?
I think it's dev-dma_mask == NULL. Clearly you're passing a non DMA
able device to dma_alloc_coherent(). Which seems like a caller bug.
Ok - other archs seem to just
Someone must ask that caller library to DMA to/from that device
in the first place. Whoever it is it is wrong.
No I disagree.
Or perhaps you got the wrong device here? For ISA devices we
traditionally used NULL. Or if you set up your own ISA devices
(which I can't see a reason for but
On Thursday, 9 August 2007 17:06, Pavel Machek wrote:
Hi!
Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether
it spins down the disk correctly. Does emergency unload count increase
after each power down? Also, please post the result of 'dmidecode'.
I know
On Thu, Aug 09, 2007 at 06:53:10PM +0100, Alan Cox wrote:
Or perhaps you got the wrong device here? For ISA devices we
traditionally used NULL. Or if you set up your own ISA devices
(which I can't see a reason for but there might be one I'm missing)
at least give them a dma mask. Then it
Some host drivers depend on CONFIG_IDE_GENERIC to do the probing but their
config options lack explicit dependencies on IDE_GENERIC. In the long-term
these host drivers should be fixed to do the probing themselves but for now
fix them by making their config options select CONFIG_IDE_GENERIC.
Don't force PIO4 when programming UDMA mode (suggested by Sergei).
Cc: Sergei Shtylyov [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/it8213.c |9 -
drivers/ide/pci/piix.c | 11 +--
drivers/ide/pci/slc90e66.c | 10
Clear prefetch and postwrite for ATAPI devices instead of depending on BIOS.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/sis5513.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
Index: b/drivers/ide/pci/sis5513.c
This belongs to user-space (and only if really needed).
textdata bss dec hex filename
7129 404 875411d75 drivers/ide/pci/sis5513.o.before
3916 404 1432110e1 drivers/ide/pci/sis5513.o.after
Additionaly to being bloat the code contained
On Thu, 2007-08-09 at 18:53 +0100, Alan Cox wrote:
Someone must ask that caller library to DMA to/from that device
in the first place. Whoever it is it is wrong.
No I disagree.
I'm with Andi here ... you're fortunate that parisc has no working
IDE/SATA interface (or rather we have so few
While at it:
On Sunday 05 August 2007, Sergei Shtylyov wrote:
Index: linux-2.6/drivers/ata/pata_hpt37x.c
===
--- linux-2.6.orig/drivers/ata/pata_hpt37x.c
+++ linux-2.6/drivers/ata/pata_hpt37x.c
@@ -8,12 +8,10 @@
this driver
Support the use of '*' in model_num and model_rev entries
in ata_device_blacklist[].
Signed-off-by: Alan Cox [EMAIL PROTECTED]
Signed-off-by: David Milburn [EMAIL PROTECTED]
---
libata-core.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git
Hello,
I'm using a Promise SATA300 TX4 with SAMSUNG HD501LJ harddisks on kernel 2.6.21.
On high disk load sometimes warning/error messages are printed out:
...
ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata4.00: cmd c8/00:08:8f:7f:85/00:00:00:00:00/ef tag 0 cdb 0x0 data 4096 in
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):
* Fix the problem by adding missing struct ata_port_info to artop_init_one().
* Use the right naming (s/626/628/).
* Bump driver version.
Fixes IDE-libata regression, problem was never
Hello,
Here are some updated ALPM patches. These patches are different from the
last version in that they now use the error handler to enable link power
management. Please review and let me know what you think.
Kristen
--
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
Use a stored value for which interrupts to enable. Changing this allows
us to selectively turn off certain interrupts later and have them
stay off.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-git/drivers/ata/ahci.c
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Index: 2.6-git/include/linux/libata.h
===
--- 2.6-git.orig/include/linux/libata.h
+++ 2.6-git/include/linux/libata.h
@@ -139,7 +139,7 @@ enum {
ATA_DFLAG_FLUSH_EXT
libata drivers can define a function (enable_pm) that will
perform hardware specific actions to enable whatever power
management policy the user set up from the scsi sysfs
interface if the driver supports it. This power management
policy will be activated after all disks have been
enumerated
This patch will set the correct bits to turn on Aggressive
Link Power Management (ALPM) for the ahci driver. This
will cause the controller and disk to negotiate a lower
power state for the link when there is no activity (see
the AHCI 1.x spec for details). This feature is mutually
exclusive
On Wednesday, 8 August 2007 14:24, Rafael J. Wysocki wrote:
On Wednesday, 8 August 2007 04:56, Tejun Heo wrote:
Rafael J. Wysocki wrote:
Well, on my box (nx6325) with the appended (experimental) patch applied
on top of 2.6.23-rc1 with the patchset from
Where does the device come from? What device is it?
At the higher level someone passed us a device and some mappings and
function methods and said this is an IDE controller
Is that known already?
The core code has no idea or interest in where it came from.
But at least on x86-64 the device
You cannot allocate a dma_coherent buffer without passing in the correct
underlying device ... on parisc we'd explode trying to find the iommu to
map through (some of our hw has more than one).
We do pass the correct underlying device. Then dma_alloc_coherent oopses
on x86_64 if you pass some
On Thu, 9 Aug 2007 23:19:34 +0200
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):
* Fix the problem by adding missing struct ata_port_info to artop_init_one().
* Use the right
On Thu, 2007-08-09 at 23:37 +0100, Alan Cox wrote:
You cannot allocate a dma_coherent buffer without passing in the correct
underlying device ... on parisc we'd explode trying to find the iommu to
map through (some of our hw has more than one).
We do pass the correct underlying device.
On Thu, Aug 09, 2007 at 11:34:58PM +0100, Alan Cox wrote:
Where does the device come from? What device is it?
At the higher level someone passed us a device and some mappings and
function methods and said this is an IDE controller
Ok you're stabbing in the dark. I guess more debugging is
* This driver is heavily based upon:
*
* linux/drivers/ide/pci/hpt366.c Version 0.36April 25, 2003
*
reference to hpt366 version should also be updated (or removed)
Disagree - its not based on the newer hpt366 driver. Its based on the old
one. Actually by now it bears
On Fri, 2007-08-10 at 00:17 +0100, Alan Cox wrote:
If the device you're passing has a NULL dma_mask pointer that means the
platform hasn't set it up correctly for dma ... and that's the
Well it may not do DMA.
Unfortunately, I don't think we've considered that possibility in the
BTW unless I'm misreading the i386 code it'll not fail here, but
allocate memory. Surely that will cause failures later if you
rely on it failing? If you don't rely on it then changing x86-64
will also not help you.
Eww that'll do strange things.
Ok so we do in fact need some kind of proper
On Fri, 10 Aug 2007 01:09:13 +0200 (MEST)
Mikael Pettersson [EMAIL PROTECTED] wrote:
On Wed, 8 Aug 2007 14:33:20 +0100, Alan Cox wrote:
Set the MWDMA timing by updating the correct registers. Split the PIO
path as this is mostly shared code. Wants testing.
Works fine on my CMD646 SPARC
On Wed, 8 Aug 2007 14:33:20 +0100, Alan Cox wrote:
Set the MWDMA timing by updating the correct registers. Split the PIO
path as this is mostly shared code. Wants testing.
Works fine on my CMD646 SPARC Ultra5.
/Mikael
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the
I'll submit a patch to check this in my next batch.
But as James pointed out you'll likely need similar patches on other
architectures.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Friday 10 August 2007, Alan Cox wrote:
On Thu, 9 Aug 2007 23:19:34 +0200
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
Maximum supported UDMA mode for AEC6280[R] is UDMA5 (not UDMA4)
and for AEC6880[R] it is UDMA6 (not UDMA5):
* Fix the problem by adding missing struct
BTW unless I'm misreading the i386 code it'll not fail here, but
allocate memory. Surely that will cause failures later if you
rely on it failing? If you don't rely on it then changing x86-64
will also not help you.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
40 matches
Mail list logo
