Re: [Bugme-new] [Bug 9901] New: kernel panic in stex modules (?)
On Wed, 06 Feb 2008 12:26:39 -0600
James Bottomley <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-02-06 at 10:15 -0800, Andrew Morton wrote:
> > On Wed, 6 Feb 2008 09:40:15 -0800 (PST) [EMAIL PROTECTED] wrote:
> >
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9901
> > >
> > >Summary: kernel panic in stex modules (?)
> > >Product: IO/Storage
> > >Version: 2.5
> > > KernelVersion: 2.6.24
> > > Platform: All
> > > OS/Version: Linux
> > > Tree: Mainline
> > > Status: NEW
> > > Severity: normal
> > > Priority: P1
> > > Component: Serial ATA
> > > AssignedTo: [EMAIL PROTECTED]
> > > ReportedBy: [EMAIL PROTECTED]
> > >
> > >
> > > Latest working kernel version: 2.6.23-r6
> > > Earliest failing kernel version: 2.6.24
> > > Distribution: Gentoo
> > > Hardware Environment: Core2D E6600, Asus p5B Dlx, 2G DDR2 667, Promise ST
> > > EX4350
> > > Software Environment: GCC 4.2.3/4.1.2, CFLAGS="-O2"
> > >
> > > Problem Description:
> > > The problem is frequent kernel panics within the same module. Can't say
> > > what it
> > > is, but looks like it is related to dma and promise driver.
> > > The first culprit, the memory, is ok, 8 hours of memtest passed without
> > > errors.
> > > Before, kernel 2.6.23-gentoo-r6, compiled with GCC 4.1.2 worked just
> > > fine, then
> > > after upgrade to 4.2.2 th bug appeared. Upgrade to 2.6.24 didn't solve the
> > > problem. Switching back to GCC 4.1.2 made things better for a moment,
> > > crashes
> > > became less frequent and I thought compiler was the cause. But today
> > > system
> > > crashed again with same symptoms.
> > > Sorry, but I can't save crash log, so I'll provide screen "shot":
> > > http://img238.imageshack.us/my.php?image=p2030030ki1.jpg
> > >
> > > Steps to reproduce:
> > > Boot, start FTP-server, load RAID with heavy input, in some hours it will
> > > crash. With pure reads system can run several days, heavy write load
> > > kills it
> > > much too easier.
> > >
> >
> > The supertrak driver has regressed in 2.6.24. And
> >
> > commit 9cb83c7529d929c00f37d821daed1942a1b20602
> > Author: FUJITA Tomonori <[EMAIL PROTECTED]>
> > Date: Tue Oct 16 11:24:32 2007 +0200
> >
> > [SCSI] add use_sg_chaining option to scsi_host_template
> >
> > looks a likely candidate.
> >
> > And this:
> >
> > commit d3f46f39b7092594b498abc12f0c73b0b9913bde
> > Author: James Bottomley <[EMAIL PROTECTED]>
> > Date: Tue Jan 15 11:11:46 2008 -0600
> >
> > [SCSI] remove use_sg_chaining
> >
> > from 2.6.25 looks to be a likely fix for it. Should it be backported?
>
> If the patch you identify is the culprit, mine can't be the fix ... and
> it should also be present in git head.
>
> The BUG_ON is here: isn't it?
>
> static inline void
> dma_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
>int direction)
> {
> BUG_ON(!valid_dma_direction(direction));
> ^^^
> dma_ops->unmap_sg(hwdev, sg, nents, direction);
> }
>
> stex only does scsi_dma_unmap(), so something looks to have tampered
> with the cmnd->sc_data_direction somehow ... and I can't see how.
Surely, someone changes the cmnd->sc_data_direction, or else we should
be hit by dma_map_sg before dma_unmap_sg:
static inline int
dma_map_sg(struct device *hwdev, struct scatterlist *sg, int nents, int
direction)
{
BUG_ON(!valid_dma_direction(direction));
return dma_ops->map_sg(hwdev, sg, nents, direction);
}
-
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 #upstream-fixes] pata_via: fix SATA cable detection on cx700
On Thu, 07 Feb 2008 10:18:53 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > The first port of cx700 is SATA. Fix cable detection. That should be set anyway by the drive detect but it does no harm and fixes stuff if there is no drive. Acked-by: Alan Cox <[EMAIL PROTECTED]> - 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 #upstream-fixes] libata: ignore deverr on SETXFER if mode is configured
On Thu, 07 Feb 2008 10:34:08 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Some controllers (VIA CX700) raise device error on SETXFER even after > mode configuration succeeded. Update ata_dev_set_mode() such that > device error is ignored if transfer mode is configured correctly. To > implement this, device is revalidated even after device error on > SETXFER. > > This fixes kernel bugzilla bug 8563. Tidy Acked-by: Alan Cox <[EMAIL PROTECTED]> - 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
[PATCH #upstream-fixes] libata: ignore deverr on SETXFER if mode is configured
Some controllers (VIA CX700) raise device error on SETXFER even after
mode configuration succeeded. Update ata_dev_set_mode() such that
device error is ignored if transfer mode is configured correctly. To
implement this, device is revalidated even after device error on
SETXFER.
This fixes kernel bugzilla bug 8563.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c | 48 +++---
1 file changed, 33 insertions(+), 15 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index bdbd55a..bcd2860 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3048,6 +3048,8 @@ int ata_down_xfermask_limit(struct ata_device *dev,
unsigned int sel)
static int ata_dev_set_mode(struct ata_device *dev)
{
struct ata_eh_context *ehc = &dev->link->eh_context;
+ const char *dev_err_whine = "";
+ int ign_dev_err = 0;
unsigned int err_mask;
int rc;
@@ -3057,41 +3059,57 @@ static int ata_dev_set_mode(struct ata_device *dev)
err_mask = ata_dev_set_xfermode(dev);
+ if (err_mask & ~AC_ERR_DEV)
+ goto fail;
+
+ /* revalidate */
+ ehc->i.flags |= ATA_EHI_POST_SETMODE;
+ rc = ata_dev_revalidate(dev, ATA_DEV_UNKNOWN, 0);
+ ehc->i.flags &= ~ATA_EHI_POST_SETMODE;
+ if (rc)
+ return rc;
+
/* Old CFA may refuse this command, which is just fine */
if (dev->xfer_shift == ATA_SHIFT_PIO && ata_id_is_cfa(dev->id))
- err_mask &= ~AC_ERR_DEV;
+ ign_dev_err = 1;
/* Some very old devices and some bad newer ones fail any kind of
SET_XFERMODE request but support PIO0-2 timings and no IORDY */
if (dev->xfer_shift == ATA_SHIFT_PIO && !ata_id_has_iordy(dev->id) &&
dev->pio_mode <= XFER_PIO_2)
- err_mask &= ~AC_ERR_DEV;
+ ign_dev_err = 1;
/* Early MWDMA devices do DMA but don't allow DMA mode setting.
Don't fail an MWDMA0 set IFF the device indicates it is in MWDMA0 */
if (dev->xfer_shift == ATA_SHIFT_MWDMA &&
dev->dma_mode == XFER_MW_DMA_0 &&
(dev->id[63] >> 8) & 1)
- err_mask &= ~AC_ERR_DEV;
+ ign_dev_err = 1;
- if (err_mask) {
- ata_dev_printk(dev, KERN_ERR, "failed to set xfermode "
- "(err_mask=0x%x)\n", err_mask);
- return -EIO;
- }
+ /* if the device is actually configured correctly, ignore dev err */
+ if (dev->xfer_mode == ata_xfer_mask2mode(ata_id_xfermask(dev->id)))
+ ign_dev_err = 1;
- ehc->i.flags |= ATA_EHI_POST_SETMODE;
- rc = ata_dev_revalidate(dev, ATA_DEV_UNKNOWN, 0);
- ehc->i.flags &= ~ATA_EHI_POST_SETMODE;
- if (rc)
- return rc;
+ if (err_mask & AC_ERR_DEV) {
+ if (!ign_dev_err)
+ goto fail;
+ else
+ dev_err_whine = " (device error ignored)";
+ }
DPRINTK("xfer_shift=%u, xfer_mode=0x%x\n",
dev->xfer_shift, (int)dev->xfer_mode);
- ata_dev_printk(dev, KERN_INFO, "configured for %s\n",
- ata_mode_string(ata_xfer_mode2mask(dev->xfer_mode)));
+ ata_dev_printk(dev, KERN_INFO, "configured for %s%s\n",
+ ata_mode_string(ata_xfer_mode2mask(dev->xfer_mode)),
+ dev_err_whine);
+
return 0;
+
+ fail:
+ ata_dev_printk(dev, KERN_ERR, "failed to set xfermode "
+ "(err_mask=0x%x)\n", err_mask);
+ return -EIO;
}
/**
-
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
[PATCH #upstream-fixes] pata_via: fix SATA cable detection on cx700
The first port of cx700 is SATA. Fix cable detection.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/ata/pata_via.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/pata_via.c b/drivers/ata/pata_via.c
index 39627ab..d119a68 100644
--- a/drivers/ata/pata_via.c
+++ b/drivers/ata/pata_via.c
@@ -84,6 +84,7 @@ enum {
VIA_BAD_ID = 0x100, /* Has wrong vendor ID (0x1107) */
VIA_BAD_AST = 0x200, /* Don't touch Address Setup Timing */
VIA_NO_ENABLES = 0x400, /* Has no enablebits */
+ VIA_SATA_PATA = 0x800, /* SATA/PATA combined configuration */
};
/*
@@ -100,7 +101,7 @@ static const struct via_isa_bridge {
{ "vx800", PCI_DEVICE_ID_VIA_VX800,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8237s",PCI_DEVICE_ID_VIA_8237S,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8251", PCI_DEVICE_ID_VIA_8251, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
- { "cx700", PCI_DEVICE_ID_VIA_CX700,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
+ { "cx700", PCI_DEVICE_ID_VIA_CX700,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST | VIA_SATA_PATA },
{ "vt6410", PCI_DEVICE_ID_VIA_6410, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST | VIA_NO_ENABLES},
{ "vt8237a",PCI_DEVICE_ID_VIA_8237A,0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
{ "vt8237", PCI_DEVICE_ID_VIA_8237, 0x00, 0x2f, VIA_UDMA_133 |
VIA_BAD_AST },
@@ -172,6 +173,9 @@ static int via_cable_detect(struct ata_port *ap) {
if (via_cable_override(pdev))
return ATA_CBL_PATA40_SHORT;
+ if ((config->flags & VIA_SATA_PATA) && ap->port_no == 0)
+ return ATA_CBL_SATA;
+
/* Early chips are 40 wire */
if ((config->flags & VIA_UDMA) < VIA_UDMA_66)
return ATA_CBL_PATA40;
-
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 2/4] libata: update ATAPI overflow draining
Tejun Heo wrote: For misc ATAPI commands which transfer variable length data to the host, overflow can occur due to application or hardware bug. Such overflows can be ignored safely as long as overflow data is properly drained. libata HSM implementation has this implemented in __atapi_pio_bytes() and recently updated for 2.6.24-rc but it requires further improvements. Improve drain logic such that... * Report overflow errors using ehi desc mechanism instead of printing directly. * Properly calculate the number of bytes to be drained considering actual number of consumed bytes for partial draining. * Add and use ata_drain_page for draining. This change fixes the problem where LLDs which do 32bit IOs consumes 4 bytes on each 2 byte draining resulting in draining twice more data than requested. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Acked-by: Albert Lee <[EMAIL PROTECTED]> --- drivers/ata/libata-core.c | 104 +++-- 1 files changed, 53 insertions(+), 51 deletions(-) (updating status on an old patch) dropped, due to your current work - 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 3/4] libata: implement ATAPI drain buffer
Tejun Heo wrote: Misc ATAPI commands may try to transfer more bytes than requested. For PIO which is performed by libata HSM, this is worked around by draining extra bytes from __atapi_pio_bytes(). This patch implements drain buffer to perform draining for DMA and PIO-over-DMA cases. One page is allocated w/ GFP_DMA32 during libata core layer initialization. On host registration, this drain page is DMA mapped and ATAPI_MAX_DRAIN_PAGES sg entries are reserved. ata_sg_setup_extra() uses these extra sg entries to map the drain page ATAPI_MAX_DRAIN_PAGES times, extending sg list by ATAPI_MAX_DRAIN bytes. This allows both DMA and PIO-over-DMA misc ATAPI commands to overflow by ATAPI_MAX_DRAIN bytes just like PIO commands. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/libata-core.c | 116 - drivers/ata/libata-scsi.c | 14 -- include/linux/libata.h|4 +- 3 files changed, 116 insertions(+), 18 deletions(-) (updating status on an old patch) dropped, due to your current work - 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: [PATCHSET #upstream] block/libata: update and use block layer padding and draining
Tejun Heo wrote: This patchset updates block layer padding and draining support and make libata use it. It's based on James Bottomley's initial work and, of the five, the last two patches are from James with some modifications. Please read the following thread for more info. http://thread.gmane.org/gmane.linux.scsi/37185 This patchset is on top of upstream (a6af42fc9a12165136d82206ad52f18c5955ce87) + kill-n_iter-and-fix-fsl patch [1] ACK patchset... lets definitely get these fixes upstream. Once Jens is happy, I would prefer the merge the lot upstream, if that is OK with everyone involved? 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: [PATCHSET #upstream] block/libata: update and use block layer padding and draining
On Tue, 2008-02-05 at 16:53 +0900, Tejun Heo wrote: > This patchset updates block layer padding and draining support and > make libata use it. It's based on James Bottomley's initial work and, > of the five, the last two patches are from James with some > modifications. > > Please read the following thread for more info. > > http://thread.gmane.org/gmane.linux.scsi/37185 > > This patchset is on top of > > upstream (a6af42fc9a12165136d82206ad52f18c5955ce87) > + kill-n_iter-and-fix-fsl patch [1] This certainly fixes the SATAPI panic on aic94xx (finally got the machine with it plugged into the expanders to boot). James - 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] ide-core: remove conditional compiling with MODULE in ide-core.c
Hi,
On Saturday 02 February 2008, Denis Cheng wrote:
> use module_init/module_exit to replace the original cond-compiling, these
> macros were well designed to deal module/built-in compiling.
>
> the original __setup with null string was invalid and not executed,
> __setup("", ide_setup);
Seems to work fine for me with the latest git tree (just tried
"idebus=35" with IDE built-in and it works as expected).
[ "" - has always been a special way (or rather a special ugly hack)
for handling "hdx=" and "idex=" kernel parameters ]
> however, with the current module_param mechanics, module parameters also can
> be input on the kernel command line, with this style:
>
> ide-core.options="ide=nodma hdd=cdrom idebus=..."
>
> so Documentation/kernel-parameters.txt also updated.
If we are going to change the currently working kernel parameters (which we
should do anyway because of other reasons, like need for handling warm-plugged
devices) we may as well use the occasion to rework it completely - making more
usage of parameter handling infrastructure present in kernel and getting rid
of passing everything through IDE core code (by moving the majority of these
parameters to where they should belong in the first place - IDE host drivers).
The sketch of how it is supposed to look like:
* Mark the rest of parameters for enabling probing of legacy VLB chipsets
as obsoleted ("ide0=ali14xx", "ide0=umc8672", "ide0=dtc2278", "ide0=qd65xx",
"ide0=cmd640_vlb" and "ide0=ht6560b" - the per host driver parameters have
been available for a long time). This should be as simple as replacing
few "goto done;"-s by "goto obsolete_option;"-s.
* Mark "hdx=scsi" and "hdx=driver_name" as obsoleted (device-driver binding
can be changed at runtime nowadays through sysfs + can be dealt with using
per device driver parameters).
* Mark "hdx=remap" and "hdx=remap63" as obsoleted (they are layering violation
and should be dealt with in the same way as done by libata - device-mapper
should be used instead).
* Add ".pci_clock=" or ".vlb_clock=" parameter to 11 host drivers that
use system_bus_clock(). Then obsolete "idebus=".
* Remove obsoleted "idex=nodma".
* "idex=base[,ctl[,irq]]" is going to be removed by a soon-to-posted
patch series which adds warm-plug support (heh, it was ready two weeks
ago but because of the "merge storm" I has been unable to _document_ it).
* Enable PIO auto-tuning in few drivers that still miss it and remove
obsoleted "hdx=autotune"/"hdx=noautotune" parameters.
* Add "ide-4drives" host driver (I have a patch for this, needs refresh)
and remove obsoleted "ide0=four" parameter.
* Remove obsoleted "idex=serialize" parameter.
* Remove obsoleted "idex=reset" parameter together with hwif->reset flag
handling from ide-probe.c.
* Remove all other obsoleted "hdx="/"idex=" parameters.
* This would leave us with "idex=noprobe", "idex=ata66", "hdx=none/noprobe",
"hdx=nowerr", "hdx=cdrom", "hdx=nodma", "hdx=noflush" and "hdx=c,h,s"
parameters which should be passed through host drivers, i.e. for "hdc=nodma"
and piix host driver - "piix.nodma=hdc" or even "piix.nodma=1.0" should be
used instead. I have some old draft patch partially implementing this
(I will send it to you in PM as soon as I find it).
* The rest of parameters (== 5 "ide=" parameters) can be finally converted to
use "ide_core.". :-)
[ The above plan may look like a lot of work but it really isn't - all
changes are easy or even trivial to convey. It should be also really
worth to do it because together with removing __setup("", ...) hack
it should remove 300-400 LOC from ide.c. ]
Thanks,
Bart
> Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
> ---
> Documentation/kernel-parameters.txt | 11 +--
> drivers/ide/ide.c | 55 ++
> 2 files changed, 25 insertions(+), 41 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index cf38689..c94730c 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -759,15 +759,8 @@ and is between 256 and 4096 characters. It is defined in
> the file
> icn=[HW,ISDN]
> Format: [,[,[,]]]
>
> - ide=[HW] (E)IDE subsystem
> - Format: ide=nodma or ide=doubler or ide=reverse
> - See Documentation/ide.txt.
> -
> - ide?= [HW] (E)IDE subsystem
> - Format: ide?=noprobe or chipset specific parameters.
> - See Documentation/ide.txt.
> -
> - idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
> + ide-core.options= [HW] (E)IDE subsystem
> + Format: ide-core.options="ide=nodma hdd=cdrom
> idebus=..."
> See Documentation/ide.txt.
>
> idle= [X86]
> diff --git a/drivers/ide/ide.c b/drivers/ide/i
[Bug 9904] New: ASUS DVD-E616A - drive side 80-wire cable detection failed
http://bugzilla.kernel.org/show_bug.cgi?id=9904 Summary: ASUS DVD-E616A - drive side 80-wire cable detection failed Product: IO/Storage Version: 2.5 KernelVersion: 2.6.24 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: IDE AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Latest working kernel version: none Earliest failing kernel version: 2.6.21 Distribution: Gentoo (with vanilla kernel on x86_64) or Slackware (on i386). Hardware Environment: Mainboard: 939Dual-VSTA, BIOS P1.30 DVD-ROM drive: ASUS DVD-E616A (UDMA100 capable). # dmesg Linux version 2.6.24 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2)) #5 SMP Tue Jan 29 19:07:57 CET 2008 Command line: root=/dev/hda5 ro notsc BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - 7ffb (usable) BIOS-e820: 7ffb - 7ffc (ACPI data) BIOS-e820: 7ffc - 7fff (ACPI NVS) BIOS-e820: 7fff - 8000 (reserved) BIOS-e820: ff38 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 524208) 1 entries of 256 used end_pfn_map = 1048576 DMI present. ACPI: RSDP 000FA900, 0014 (r0 ACPIAM) ACPI: RSDT 7FFB, 0038 (r1 A M I OEMRSDT 9000625 MSFT 97) ACPI: FACP 7FFB0200, 0084 (r2 A M I OEMFACP 9000625 MSFT 97) ACPI: DSDT 7FFB0440, 496C (r1 939DV 939DV122 122 INTL 20051117) ACPI: FACS 7FFC, 0040 ACPI: APIC 7FFB0390, 0068 (r1 A M I OEMAPIC 9000625 MSFT 97) ACPI: MCFG 7FFB0400, 003C (r1 A M I OEMMCFG 9000625 MSFT 97) ACPI: OEMB 7FFC0040, 005C (r1 A M I AMI_OEM 9000625 MSFT 97) ACPI: HPET 7FFB4DB0, 0038 (r1 A M I OEMHPET 9000625 MSFT 97) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 524208) 1 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 Movable zone start PFN for each node early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 524208 On node 0 totalpages: 524111 DMA zone: 56 pages used for memmap DMA zone: 1761 pages reserved DMA zone: 2182 pages, LIFO batch:0 DMA32 zone: 7110 pages used for memmap DMA32 zone: 513002 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: IOAPIC (id[0x03] address[0xfec1] gsi_base[24]) IOAPIC[1]: apic_id 3, address 0xfec1, GSI 24-39 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to flat ACPI: HPET id: 0x10b9a201 base: 0xfed0 Using ACPI (MADT) for SMP configuration information swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000e8000 swsusp: Registered nosave memory region: 000e8000 - 0010 Allocating PCI resources starting at 8800 (gap: 8000:7f38) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 29664 bytes of per cpu data Built 1 zonelists in Zone order, mobility grouping on. Total pages: 515184 Kernel command line: root=/dev/hda5 ro notsc Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) hpet clockevent registered TSC calibrated against HPET Marking TSC unstable due to TSCs unsynchronized time.c: Detected 2200.078 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Checking aperture... CPU 0: aperture @ c000 size 256 MB Memory: 2056944k/2096832k available (4067k kernel code, 39208k reserved, 1888k data, 268k init) Calibrating delay using timer specific routine.. 4402.66 BogoMIPS (lpj=8805336) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code ACPI: Core revision 20070126 Using local APIC t
Re: [PATCH] ide: another possible ide panic fix for blk-end-request
On Monday 04 February 2008, Kiyoshi Ueda wrote: > Hi Jens, Bart, Boris, > > I have reviewed all blk-end-request patches again to confirm whether > there are any similar problems with the last week's ide-cd panic: > http://lkml.org/lkml/2008/1/29/140 > > And I found a possible similar bug in ide-io change: > ide_end_drive_cmd() could be called for blk_pc_request() which could > have bios. To complete such requests correctly, we need to pass > the actual size of the request. > Otherwise, __blk_end_request() returns 1 because the request still has > bios, and the system will BUG() unnecessarily. > > The following patch fixes the bug and should be applied on top of > Linus' git. > Please review and apply. > > > Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> > Cc: Borislav Petkov <[EMAIL PROTECTED]> > Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]> > Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]> applied, thanks - 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 2/5] ide: remove redundant BUG_ON() from [atapi_]reset_pollfunc()
On Wednesday 06 February 2008, Sergei Shtylyov wrote: > Bartlomiej Zolnierkiewicz wrote: > > > Same BUG_ON() is present inside ide_set_handler(). > > There is no BUG_ON there -- __ide_set_handler() has a check for the same > condition and a printk(KERN_CRIT)... myabe it should be replaced with > BUG_ON()... Yeah, you're right - care to make a patch? > > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> > > Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> > > MBR, Sergei - 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: 2.6.26-git0: IDE oops during boot
Hi, On Wednesday 06 February 2008, Pavel Machek wrote: > On Wed 2008-02-06 11:53:34, Pavel Machek wrote: > > Hi! > > > > Trying to boot 2.6.25-git0 (few days old), I get > > > > BUG: unable to handle kernel paging request at ..ffb0 > > IP at init_irq+0x42e init_irq? hmm... > > Call trace: > > ide_device_add_all this comes from ide-generic (Generic IDE host driver) > > ide_generic_init > > kernel_init > > child_rip > > vgacon_cursor > > kernel_init > > child_rip > > > > Excerpt from config: > > > > CONFIG_IDE=y > > CONFIG_BLK_DEV_IDE=y > > Disabling CONFIG_IDE made my machine boot, as it was using libata > anyway. Kamalesh/Pavel: Could you try latest git and see if the OOPS is still there? [ Yeah, I'm unable to reproduce it. :( ] Thanks, Bart - 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: [Bugme-new] [Bug 9901] New: kernel panic in stex modules (?)
On Wed, 2008-02-06 at 10:15 -0800, Andrew Morton wrote:
> On Wed, 6 Feb 2008 09:40:15 -0800 (PST) [EMAIL PROTECTED] wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=9901
> >
> >Summary: kernel panic in stex modules (?)
> >Product: IO/Storage
> >Version: 2.5
> > KernelVersion: 2.6.24
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: Serial ATA
> > AssignedTo: [EMAIL PROTECTED]
> > ReportedBy: [EMAIL PROTECTED]
> >
> >
> > Latest working kernel version: 2.6.23-r6
> > Earliest failing kernel version: 2.6.24
> > Distribution: Gentoo
> > Hardware Environment: Core2D E6600, Asus p5B Dlx, 2G DDR2 667, Promise ST
> > EX4350
> > Software Environment: GCC 4.2.3/4.1.2, CFLAGS="-O2"
> >
> > Problem Description:
> > The problem is frequent kernel panics within the same module. Can't say
> > what it
> > is, but looks like it is related to dma and promise driver.
> > The first culprit, the memory, is ok, 8 hours of memtest passed without
> > errors.
> > Before, kernel 2.6.23-gentoo-r6, compiled with GCC 4.1.2 worked just fine,
> > then
> > after upgrade to 4.2.2 th bug appeared. Upgrade to 2.6.24 didn't solve the
> > problem. Switching back to GCC 4.1.2 made things better for a moment,
> > crashes
> > became less frequent and I thought compiler was the cause. But today system
> > crashed again with same symptoms.
> > Sorry, but I can't save crash log, so I'll provide screen "shot":
> > http://img238.imageshack.us/my.php?image=p2030030ki1.jpg
> >
> > Steps to reproduce:
> > Boot, start FTP-server, load RAID with heavy input, in some hours it will
> > crash. With pure reads system can run several days, heavy write load kills
> > it
> > much too easier.
> >
>
> The supertrak driver has regressed in 2.6.24. And
>
> commit 9cb83c7529d929c00f37d821daed1942a1b20602
> Author: FUJITA Tomonori <[EMAIL PROTECTED]>
> Date: Tue Oct 16 11:24:32 2007 +0200
>
> [SCSI] add use_sg_chaining option to scsi_host_template
>
> looks a likely candidate.
>
> And this:
>
> commit d3f46f39b7092594b498abc12f0c73b0b9913bde
> Author: James Bottomley <[EMAIL PROTECTED]>
> Date: Tue Jan 15 11:11:46 2008 -0600
>
> [SCSI] remove use_sg_chaining
>
> from 2.6.25 looks to be a likely fix for it. Should it be backported?
If the patch you identify is the culprit, mine can't be the fix ... and
it should also be present in git head.
The BUG_ON is here: isn't it?
static inline void
dma_unmap_sg(struct device *hwdev, struct scatterlist *sg, int nents,
int direction)
{
BUG_ON(!valid_dma_direction(direction));
^^^
dma_ops->unmap_sg(hwdev, sg, nents, direction);
}
stex only does scsi_dma_unmap(), so something looks to have tampered
with the cmnd->sc_data_direction somehow ... and I can't see how.
James
-
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: [Bugme-new] [Bug 9901] New: kernel panic in stex modules (?)
On Wed, 6 Feb 2008 09:40:15 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9901 > >Summary: kernel panic in stex modules (?) >Product: IO/Storage >Version: 2.5 > KernelVersion: 2.6.24 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Serial ATA > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Latest working kernel version: 2.6.23-r6 > Earliest failing kernel version: 2.6.24 > Distribution: Gentoo > Hardware Environment: Core2D E6600, Asus p5B Dlx, 2G DDR2 667, Promise ST > EX4350 > Software Environment: GCC 4.2.3/4.1.2, CFLAGS="-O2" > > Problem Description: > The problem is frequent kernel panics within the same module. Can't say what > it > is, but looks like it is related to dma and promise driver. > The first culprit, the memory, is ok, 8 hours of memtest passed without > errors. > Before, kernel 2.6.23-gentoo-r6, compiled with GCC 4.1.2 worked just fine, > then > after upgrade to 4.2.2 th bug appeared. Upgrade to 2.6.24 didn't solve the > problem. Switching back to GCC 4.1.2 made things better for a moment, crashes > became less frequent and I thought compiler was the cause. But today system > crashed again with same symptoms. > Sorry, but I can't save crash log, so I'll provide screen "shot": > http://img238.imageshack.us/my.php?image=p2030030ki1.jpg > > Steps to reproduce: > Boot, start FTP-server, load RAID with heavy input, in some hours it will > crash. With pure reads system can run several days, heavy write load kills it > much too easier. > The supertrak driver has regressed in 2.6.24. And commit 9cb83c7529d929c00f37d821daed1942a1b20602 Author: FUJITA Tomonori <[EMAIL PROTECTED]> Date: Tue Oct 16 11:24:32 2007 +0200 [SCSI] add use_sg_chaining option to scsi_host_template looks a likely candidate. And this: commit d3f46f39b7092594b498abc12f0c73b0b9913bde Author: James Bottomley <[EMAIL PROTECTED]> Date: Tue Jan 15 11:11:46 2008 -0600 [SCSI] remove use_sg_chaining from 2.6.25 looks to be a likely fix for it. Should it be backported? - 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 2/5] ide: remove redundant BUG_ON() from [atapi_]reset_pollfunc()
Bartlomiej Zolnierkiewicz wrote: Same BUG_ON() is present inside ide_set_handler(). There is no BUG_ON there -- __ide_set_handler() has a check for the same condition and a printk(KERN_CRIT)... myabe it should be replaced with BUG_ON()... Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> MBR, Sergei - 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 2/3 2.6.24-git] ARM/RPC: Use HAVE_PATA_PLATFORM to select pata platform driver
On Wed, Feb 06, 2008 at 06:58:17AM -0500, Jeff Garzik wrote: > ACK patch series... would it be ok to send via the ARM maintainer? > > I would prefer to add this at the same time as its user... I've only seen the one patch, and I suspect that it depends on patches to other architectures (to convert other architectures to use the new variable.) - 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
[git patches] libata updates
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
arch/arm/mach-rpc/riscpc.c|2 +-
arch/blackfin/mach-bf527/boards/ezkit.c |2 +-
arch/blackfin/mach-bf533/boards/H8606.c |2 +-
arch/blackfin/mach-bf533/boards/cm_bf533.c|2 +-
arch/blackfin/mach-bf533/boards/ezkit.c |2 +-
arch/blackfin/mach-bf533/boards/stamp.c |2 +-
arch/blackfin/mach-bf537/boards/cm_bf537.c|2 +-
arch/blackfin/mach-bf537/boards/generic_board.c |2 +-
arch/blackfin/mach-bf537/boards/minotaur.c|2 +-
arch/blackfin/mach-bf537/boards/stamp.c |2 +-
arch/blackfin/mach-bf561/boards/cm_bf561.c|2 +-
arch/blackfin/mach-bf561/boards/ezkit.c |2 +-
arch/sh/boards/landisk/setup.c|2 +-
arch/sh/boards/lboxre2/setup.c|2 +-
arch/sh/boards/renesas/r7780rp/setup.c|2 +-
arch/sh/boards/renesas/rts7751r2d/setup.c |2 +-
arch/sh/boards/renesas/sdk7780/setup.c|2 +-
arch/sh/boards/se/7722/setup.c|2 +-
drivers/ata/ahci.c| 35 +-
drivers/ata/ata_piix.c|3 +-
drivers/ata/libata-core.c |2 -
drivers/ata/pata_of_platform.c|2 +-
drivers/ata/pata_platform.c |2 +-
drivers/ata/sata_fsl.c|4 +-
drivers/ata/sata_mv.c | 366 ++---
drivers/ata/sata_nv.c | 78 -
drivers/ata/sata_via.c|2 -
drivers/ide/legacy/ide_platform.c |2 +-
include/linux/{pata_platform.h => ata_platform.h} | 13 +-
include/linux/libata.h|2 -
30 files changed, 440 insertions(+), 107 deletions(-)
rename include/linux/{pata_platform.h => ata_platform.h} (75%)
Adrian Bunk (1):
ata_piix.c:piix_init_one() must be __devinit
Alejandro Riveira Fernández (1):
sata_via.c: Remove missleading comment.
Andrew Morton (1):
ata: drivers/ata/sata_mv.c needs dmapool.h
David Milburn (1):
libata-core: unblacklist HITACHI drives
James Bottomley (1):
libata: kill now unused n_iter and fix sata_fsl
Jeff Garzik (1):
Rename: linux/pata_platform.h to linux/ata_platform.h
Robert Hancock (1):
sata_nv: fix ATAPI issues with memory over 4GB (v7)
Saeed Bishara (1):
sata_mv: Support SoC controllers
Tejun Heo (1):
ahci: fix CAP.NP and PI handling
diff --git a/arch/arm/mach-rpc/riscpc.c b/arch/arm/mach-rpc/riscpc.c
index a454451..eca558c 100644
--- a/arch/arm/mach-rpc/riscpc.c
+++ b/arch/arm/mach-rpc/riscpc.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include
+#include
#include
#include
diff --git a/arch/blackfin/mach-bf527/boards/ezkit.c
b/arch/blackfin/mach-bf527/boards/ezkit.c
index f8c411a..1795aab 100644
--- a/arch/blackfin/mach-bf527/boards/ezkit.c
+++ b/arch/blackfin/mach-bf527/boards/ezkit.c
@@ -37,7 +37,7 @@
#if defined(CONFIG_USB_ISP1362_HCD) || defined(CONFIG_USB_ISP1362_HCD_MODULE)
#include
#endif
-#include
+#include
#include
#include
#include
diff --git a/arch/blackfin/mach-bf533/boards/H8606.c
b/arch/blackfin/mach-bf533/boards/H8606.c
index a72c7a6..97378b0 100644
--- a/arch/blackfin/mach-bf533/boards/H8606.c
+++ b/arch/blackfin/mach-bf533/boards/H8606.c
@@ -38,7 +38,7 @@
#if defined(CONFIG_USB_ISP1362_HCD) || defined(CONFIG_USB_ISP1362_HCD_MODULE)
#include
#endif
-#include
+#include
#include
#include
diff --git a/arch/blackfin/mach-bf533/boards/cm_bf533.c
b/arch/blackfin/mach-bf533/boards/cm_bf533.c
index 21df2f3..886f260 100644
--- a/arch/blackfin/mach-bf533/boards/cm_bf533.c
+++ b/arch/blackfin/mach-bf533/boards/cm_bf533.c
@@ -34,7 +34,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/blackfin/mach-bf533/boards/ezkit.c
b/arch/blackfin/mach-bf533/boards/ezkit.c
index c37dd45..4026c2f 100644
--- a/arch/blackfin/mach-bf533/boards/ezkit.c
+++ b/arch/blackfin/mach-bf533/boards/ezkit.c
@@ -35,7 +35,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/blackfin/mach-bf533/boards/stamp.c
b/arch/blackfin/mach-bf533/boards/stamp.c
index ac52b04..0185350 100644
--- a/arch/blackfin/mach-bf533/boards/stamp.c
+++ b/arch/blackfin/mach-bf533/boards/stamp.c
@@ -38,7 +38,7 @@
#if defined(CONFIG_USB_ISP1362_HCD) || defined(CONFIG_USB_ISP1362_HCD_MODULE)
#include
#endif
-#include
+#include
#include
#include
#include
diff --git a/arch/blackfin/mach-bf537/boards/cm_bf537.c
b/arch/blackfin/mach-bf537/boards/cm_bf537.c
index 8703b67..f7c1f96 100644
--- a/arch/blackfin/mac
Re: [2.6 patch] ata_piix.c:piix_init_one() must be __devinit
Adrian Bunk wrote:
This patch fixes the following section mismatches:
<-- snip -->
...
WARNING: drivers/ata/built-in.o(.text+0x15072): Section mismatch in reference
from the function piix_init_one() to the function
.devinit.text:piix_init_sata_map()
WARNING: drivers/ata/built-in.o(.text+0x150dd): Section mismatch in reference
from the function piix_init_one() to the function .devinit.text:piix_init_pcs()
WARNING: drivers/ata/built-in.o(.text+0x150e5): Section mismatch in reference
from the function piix_init_one() to the function
.devinit.text:piix_init_sidpr()
WARNING: drivers/ata/built-in.o(.text+0x15107): Section mismatch in reference
from the function piix_init_one() to the function
.devinit.text:piix_check_450nx_errata()
...
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
222e97f95d38ce7cb41980671cc4383df28b5f7a
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index a65c8ae..7a3b9ef 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -1595,7 +1595,8 @@ static void piix_iocfg_bit18_quirk(struct pci_dev *pdev)
* Zero on success, or -ERRNO value.
*/
-static int piix_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
+static int __devinit piix_init_one(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
{
static int printed_version;
struct device *dev = &pdev->dev;
applied
-
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] libata-core: unblacklist HITACHI drives
David Milburn wrote:
The HITACHI HDS7250SASUN500G and HITACHI HDS7225SBSUN250 drives
do not need to be blacklisted, the NCQ problem has been resolved
with the "sata_nv: fix for completion handling" patch.
Signed-off-by David Milburn <[EMAIL PROTECTED]>
---
libata-core.c |2 --
1 files changed, 2 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index bdbd55a..ba5406e 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4154,8 +4154,6 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* NCQ is broken */
{ "Maxtor *", "BANC*", ATA_HORKAGE_NONCQ },
{ "Maxtor 7V300F0", "VA111630", ATA_HORKAGE_NONCQ },
- { "HITACHI HDS7250SASUN500G*", NULL,ATA_HORKAGE_NONCQ },
- { "HITACHI HDS7225SBSUN250G*", NULL,ATA_HORKAGE_NONCQ },
{ "ST380817AS", "3.42", ATA_HORKAGE_NONCQ },
{ "ST3160023AS", "3.42", ATA_HORKAGE_NONCQ },
applied
-
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] sata_nv: fix ATAPI issues with memory over 4GB (v7)
Robert Hancock wrote: This fixes some problems with ATAPI devices on nForce4 controllers in ADMA mode on systems with memory located above 4GB. We need to delay setting the 64-bit DMA mask until the PRD table and padding buffer are allocated so that they don't get allocated above 4GB and break legacy mode (which is needed for ATAPI devices). Also, if either port is in ATAPI mode we need to set the DMA mask for the PCI device to 32-bit to ensure that the IOMMU code properly bounces requests above 4GB, as it appears setting the bounce limit does not guarantee that we will not try to map requests above this point. Reported to fix https://bugzilla.redhat.com/show_bug.cgi?id=351451 Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> applied, though it can still be improved... let's see if this sticks. - 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 1/1] ata: drivers/ata/sata_mv.c needs dmapool.h
[EMAIL PROTECTED] wrote: From: Andrew Morton <[EMAIL PROTECTED]> mips: drivers/ata/sata_mv.c: In function `mv_port_free_dma_mem': drivers/ata/sata_mv.c:1080: error: implicit declaration of function `dma_pool_free' Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/ata/sata_mv.c |1 + 1 file changed, 1 insertion(+) diff -puN drivers/ata/sata_mv.c~ata-drivers-ata-sata_mvc-needs-dmapoolh drivers/ata/sata_mv.c --- a/drivers/ata/sata_mv.c~ata-drivers-ata-sata_mvc-needs-dmapoolh +++ a/drivers/ata/sata_mv.c @@ -69,6 +69,7 @@ #include #include #include +#include #include #include #include applied - 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] ahci: fix CAP.NP and PI handling
Tejun Heo wrote: AHCI uses CAP.NP to indicate the number of ports and PI to tell which ports are enabled. The only requirement is that the number of ports indicated by CAP.NP should equal or be higher than the number of enabled ports in PI. CAP.NP and PI carry duplicate information and there have been some interesting cases. Some early AHCI controllers didn't set PI at all and just implement from port 0 to CAP.NP. An ICH8 board which wired four out of six available ports had 3 (4 ports) for CAP.NP and 0x33 for PI. While ESB2 has less bits set in PI than the value in CAP.NP. Till now, ahci driver assumed that PI is invalid if it doesn't match CAP.NP exactly. This violates AHCI standard and the driver ends up accessing unmimplemented ports on ESB2. This patch updates CAP.NP and PI handling such that PI can have less number of bits set than indicated in CAP.NP and the highest port is determined as the maximum port of what CAP.NP and PI indicate. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Cc: Jan Beulich <[EMAIL PROTECTED]> applied - 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: libata: kill now unused n_iter and fix sata_fsl
Tejun Heo wrote: From: James Bottomley <[EMAIL PROTECTED]> qc->n_iter was used for libata's own sg walking before sg chaining replaced it. During conversion, the field and its usage in sata_fsl were left behind. Kill the filed and update sata_fsl. tj: This was part of James's libata-use-block-layer-padding patch. Separated out by me. Signed-off-by: James Bottomley <[EMAIL PROTECTED]> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Cc: Li Yang <[EMAIL PROTECTED]> applied - 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 2/3 2.6.24-git] ARM/RPC: Use HAVE_PATA_PLATFORM to select pata platform driver
ACK patch series... would it be ok to send via the ARM maintainer? I would prefer to add this at the same time as its user... - 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: [Bugme-new] [Bug 9898] New: libata fails for ALi Corporation M5229 IDE
On Wed, 6 Feb 2008 03:09:36 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9898 > >Summary: libata fails for ALi Corporation M5229 IDE >Product: IO/Storage >Version: 2.5 > KernelVersion: 2.6.24 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IDE > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Latest working kernel version: 2.6.23.14 (with blkdev) > Earliest failing kernel version: 2.6.24 (with libata) > Distribution: sidux > Hardware Environment: Acer Travelmate 632XV > Software Environment: > Problem Description: System boots fine, but after some minutes complete system > freeze. Nothing is mentioned in the logfiles. > > System informations: > lspci -nn | grep IDE > 00:10.0 IDE interface [0101]: ALi Corporation M5229 IDE [10b9:5229] (rev c4) > > Steps to reproduce: reboot and wait some minutes (<10) > A regression. What makes you think it's due to IDE? - 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
[Bug 9898] libata fails for ALi Corporation M5229 IDE
http://bugzilla.kernel.org/show_bug.cgi?id=9898 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|NEW |ASSIGNED --- Comment #2 from [EMAIL PROTECTED] 2008-02-06 03:28 --- If you build a kernel for the system using the old IDE layer with 2.6.24 what do you see and what does the log look like. Also if you boot 2.6.24 and leave it in text mode you should get traces for any ATA failure which will be needed to debug it. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are the assignee for the bug, or are watching the assignee. - 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: 2.6.26-git0: IDE oops during boot
On Wed 2008-02-06 11:53:34, Pavel Machek wrote: > Hi! > > Trying to boot 2.6.25-git0 (few days old), I get > > BUG: unable to handle kernel paging request at ..ffb0 > IP at init_irq+0x42e > > Call trace: > ide_device_add_all > ide_generic_init > kernel_init > child_rip > vgacon_cursor > kernel_init > child_rip > > Excerpt from config: > > CONFIG_IDE=y > CONFIG_BLK_DEV_IDE=y Disabling CONFIG_IDE made my machine boot, as it was using libata anyway. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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
[Bug 9898] libata fails for ALi Corporation M5229 IDE
http://bugzilla.kernel.org/show_bug.cgi?id=9898 --- Comment #1 from [EMAIL PROTECTED] 2008-02-06 03:12 --- Created an attachment (id=14721) --> (http://bugzilla.kernel.org/attachment.cgi?id=14721&action=view) dmesg output -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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
[Bug 9898] New: libata fails for ALi Corporation M5229 IDE
http://bugzilla.kernel.org/show_bug.cgi?id=9898 Summary: libata fails for ALi Corporation M5229 IDE Product: IO/Storage Version: 2.5 KernelVersion: 2.6.24 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: IDE AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Latest working kernel version: 2.6.23.14 (with blkdev) Earliest failing kernel version: 2.6.24 (with libata) Distribution: sidux Hardware Environment: Acer Travelmate 632XV Software Environment: Problem Description: System boots fine, but after some minutes complete system freeze. Nothing is mentioned in the logfiles. System informations: lspci -nn | grep IDE 00:10.0 IDE interface [0101]: ALi Corporation M5229 IDE [10b9:5229] (rev c4) Steps to reproduce: reboot and wait some minutes (<10) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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: slow resume from s2ram
Brian Keck wrote: > Hello, > > I can't get my otherwise lovely debian/sid Vaio TX17 to resume promptly > from suspend-to-ram. > > Until recently it resumed at all maybe 1 in 4 times from > 's2ram -f -p' in X, always taking several minutes, apparently > due to the hard disk (1.8" Toshiba HDD1544/MK6006GAH). > > Last week I tried 2 things: > > * added /etc/modprobe.d/libata with > options libata noacpi=0 > > * built a kernel + initrd from debian linux-source-2.6.24 with > CONFIG_BLK_DEV_IDEACPI=y > > This boots OK, with ... > >$ cat /sys/module/libata/parameters/noacpi >0 You're not using libata at all. You're using IDE driver instead. Please try libata ata_piix driver instead. -- tejun - 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
[PATCH] ahci: fix CAP.NP and PI handling
AHCI uses CAP.NP to indicate the number of ports and PI to tell which
ports are enabled. The only requirement is that the number of ports
indicated by CAP.NP should equal or be higher than the number of
enabled ports in PI.
CAP.NP and PI carry duplicate information and there have been some
interesting cases. Some early AHCI controllers didn't set PI at all
and just implement from port 0 to CAP.NP. An ICH8 board which wired
four out of six available ports had 3 (4 ports) for CAP.NP and 0x33
for PI. While ESB2 has less bits set in PI than the value in CAP.NP.
Till now, ahci driver assumed that PI is invalid if it doesn't match
CAP.NP exactly. This violates AHCI standard and the driver ends up
accessing unmimplemented ports on ESB2.
This patch updates CAP.NP and PI handling such that PI can have less
number of bits set than indicated in CAP.NP and the highest port is
determined as the maximum port of what CAP.NP and PI indicate.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Jan Beulich <[EMAIL PROTECTED]>
---
drivers/ata/ahci.c | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 27c8d56..29e71bd 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -679,24 +679,20 @@ static void ahci_save_initial_config(struct pci_dev *pdev,
/* cross check port_map and cap.n_ports */
if (port_map) {
- u32 tmp_port_map = port_map;
- int n_ports = ahci_nr_ports(cap);
+ int map_ports = 0;
- for (i = 0; i < AHCI_MAX_PORTS && n_ports; i++) {
- if (tmp_port_map & (1 << i)) {
- n_ports--;
- tmp_port_map &= ~(1 << i);
- }
- }
+ for (i = 0; i < AHCI_MAX_PORTS; i++)
+ if (port_map & (1 << i))
+ map_ports++;
- /* If n_ports and port_map are inconsistent, whine and
-* clear port_map and let it be generated from n_ports.
+ /* If PI has more ports than n_ports, whine, clear
+* port_map and let it be generated from n_ports.
*/
- if (n_ports || tmp_port_map) {
+ if (map_ports > ahci_nr_ports(cap)) {
dev_printk(KERN_WARNING, &pdev->dev,
- "nr_ports (%u) and implemented port map "
- "(0x%x) don't match, using nr_ports\n",
- ahci_nr_ports(cap), port_map);
+ "implemented port map (0x%x) contains more "
+ "ports than nr_ports (%u), using nr_ports\n",
+ port_map, ahci_nr_ports(cap));
port_map = 0;
}
}
@@ -2201,7 +2197,7 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
struct device *dev = &pdev->dev;
struct ahci_host_priv *hpriv;
struct ata_host *host;
- int i, rc;
+ int n_ports, i, rc;
VPRINTK("ENTER\n");
@@ -2255,7 +2251,14 @@ static int ahci_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (hpriv->cap & HOST_CAP_PMP)
pi.flags |= ATA_FLAG_PMP;
- host = ata_host_alloc_pinfo(&pdev->dev, ppi, fls(hpriv->port_map));
+ /* CAP.NP sometimes indicate the index of the last enabled
+* port, at other times, that of the last possible port, so
+* determining the maximum port number requires looking at
+* both CAP.NP and port_map.
+*/
+ n_ports = max(ahci_nr_ports(hpriv->cap), fls(hpriv->port_map));
+
+ host = ata_host_alloc_pinfo(&pdev->dev, ppi, n_ports);
if (!host)
return -ENOMEM;
host->iomap = pcim_iomap_table(pdev);
-
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
ST310211A and HPA ( was Re: Bug#401035: linux-image-2.6-686 - another misbehaving Seagate )
(cc'ing linux-ide)
On Mon, Feb 04, 2008 at 02:32:59AM +0100, Bart Champagne wrote:
> Just found another type of Seagate drives that shows this behaviour :
> ST310211A
> Can this one be blacklisted as well ?
Yes, do you have a patch? And a dmesg dump of the drive in use with and
without a patch?
If you do, please send them to upstream linux-ide@vger.kernel.org and hope
that the fix gets applied to Debian kernels too. Also, please test the
sata/pata driver with your drive and add a blacklist there too.
If you don't have a patch, here's one for 2.6.24 to go.
>From 4a8b40c53d2e539bad3f93996f599d69a16af94b Mon Sep 17 00:00:00 2001
From: Mikko Rapeli <[EMAIL PROTECTED]>
Date: Wed, 6 Feb 2008 09:41:14 +0200
Subject: [PATCH] ST310211A has buggy HPA too.
Signed-off-by: Mikko Rapeli <[EMAIL PROTECTED]>
---
drivers/ata/libata-core.c |1 +
drivers/ide/ide-disk.c|1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 6380726..d08f869 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4169,6 +4169,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Devices which report 1 sector over size HPA */
{ "ST340823A", NULL, ATA_HORKAGE_HPA_SIZE, },
{ "ST320413A", NULL, ATA_HORKAGE_HPA_SIZE, },
+ { "ST310211A", NULL, ATA_HORKAGE_HPA_SIZE, },
/* Devices which get the IVB wrong */
{ "QUANTUM FIREBALLlct10 05", "A03.0900", ATA_HORKAGE_IVB, },
diff --git a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
index b178190..a0f9940 100644
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -462,6 +462,7 @@ static inline int idedisk_supports_lba48(const struct
hd_driveid *id)
static const struct drive_list_entry hpa_list[] = {
{ "ST340823A", NULL },
{ "ST320413A", NULL },
+ { "ST310211A", NULL },
{ NULL, NULL }
};
--
1.4.4.4
-
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
