Fw: [Bug 4275] New: filesystems no longer modifiable after stress tests
Your IDE disk shat itself. hdc: dma_timer_expiry: dma status == 0x20 Begin forwarded message: Date: Wed, 2 Mar 2005 12:08:04 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug 4275] New: filesystems no longer modifiable after stress tests http://bugme.osdl.org/show_bug.cgi?id=4275 Summary: filesystems no longer modifiable after stress tests Kernel Version: 2.6.11-rc4-mm1 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Distribution:SuSE SLES 9 sp1 Hardware Environment:xseries - x305 Software Environment:Linux version 2.6.11-rc4-mm1 Problem Description: After running LTP filesystem stress tests, I am no longer able to modify either of the filesystems that I was testing. In /testfs2(ext3) I am unable to delete any existing files, but ls is able to complete. I cannot get even that in /testfs3(jfs). This problem occurs within just a few hours. I tried to reproduce with SUSE's 2.6.5-7.139 kernel but had no problems even after a couple of days. Steps to reproduce: LTP fsstress: fsstress -d /testfs2 -n 500 -p 500 -r postmark: postmark /testfs3 --- 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: [PATCH] clear garbage after CDBs on SG_IO
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 makes SCSI SG_IO clear it and simplify CDB > clearing in block SG_IO. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > Cc: Mathieu Fluhr <[EMAIL PROTECTED]> > > diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c > index 2dc3264..cac7f18 100644 > --- a/block/scsi_ioctl.c > +++ b/block/scsi_ioctl.c > @@ -286,9 +286,8 @@ static int sg_io(struct file *file, requ >* fill in request structure >*/ > rq->cmd_len = hdr->cmd_len; > + memset(req->cmd, 0, BLK_MAX_CDB); /* ATAPI hates garbage after CDB */ s/req/rq/ makes the compiler happier there. - 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: Testing with 2.6.19-rc5
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 MAX_MD_DEVS=256, MD_SB_DISKS=27 > md: bitmap version 4.39 > > also missing from 2.6.19-rc5 dmesg: > > md: raidstart(pid 3158) used deprecated START_ARRAY ioctl. This will > not be supported beyond July 2006 > > Might that explain why my raid5 does not work in 2.6.19-rc5 ? That sounds like a very good theory. > I have > attached the full dmesg and kernel config's from both versions, in > case I have made a error there. > > I am currnetly using raidtools 1.00.3 That appears to be something which Ingo released three and a half years ago ;) I guess it's time to learn mdadm. - 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: possibility to merge via_pata fixes to .19 stable series?
On Sat, 18 Nov 2006 22:43:34 + Alan <[EMAIL PROTECTED]> wrote: > On Sat, 18 Nov 2006 16:20:12 -0500 > Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > I don't know if they're still concerns, nor if they're fatal concerns > > > either. But I've been sitting on that patch for nearly five months. > > > > This isn't driver-specific, so a similar change should be applied to the > > core. > > Agreed - it belongs in the core code. We see the same problem on multiple > controllers and its one of the big things that at the moment makes it > impossible to progress the PATA drivers further. A five month stall of a patch which makes the difference betweem "working" and "not working" sounds pretty serious. Is this something someone is working on? If not, is it something which Matthieu might have time to look into (please?) - 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: possibility to merge via_pata fixes to .19 stable series?
On Sun, 19 Nov 2006 14:34:52 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > On Sat, 18 Nov 2006 22:43:34 + > > Alan <[EMAIL PROTECTED]> wrote: > > > >> On Sat, 18 Nov 2006 16:20:12 -0500 > >> Jeff Garzik <[EMAIL PROTECTED]> wrote: > >>>> I don't know if they're still concerns, nor if they're fatal concerns > >>>> either. But I've been sitting on that patch for nearly five months. > >>> This isn't driver-specific, so a similar change should be applied to the > >>> core. > >> Agreed - it belongs in the core code. We see the same problem on multiple > >> controllers and its one of the big things that at the moment makes it > >> impossible to progress the PATA drivers further. > > > > A five month stall of a patch which makes the difference betweem "working" > > and "not working" sounds pretty serious. > > > > Is this something someone is working on? If not, is it something which > > Matthieu might have time to look into (please?) > > Doing SETXFER via polling is proposed as solution and verfivied by Matthieu. > > http://thread.gmane.org/gmane.linux.ide/13248/focus=13248 Great, thanks. > The patch has been updated and re-submitted a few days ago. > > http://thread.gmane.org/gmane.linux.ide/14088/focus=14088 > OIC. I'm not on linux-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
Re: [PATCH -mm] sata_nv: fix ATAPI in ADMA mode
On Sun, 26 Nov 2006 14:20:19 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> static irqreturn_t nv_adma_interrupt(int irq, void *dev_instance)
> {
> struct ata_host *host = dev_instance;
> int i, handled = 0;
> + u32 notifier_clears[2];
>
> spin_lock(&host->lock);
>
> for (i = 0; i < host->n_ports; i++) {
> struct ata_port *ap = host->ports[i];
> + notifier_clears[i] = 0;
Promise us that n_ports will never exceed 2?
-
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
Fw: [Bugme-new] [Bug 7589] New: libata: does not work anymore on VIA VT8251 AHCI/SATA 4-Port Controller
oops, we went backwards. Begin forwarded message: Date: Tue, 28 Nov 2006 16:33:38 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 7589] New: libata: does not work anymore on VIA VT8251 AHCI/SATA 4-Port Controller http://bugzilla.kernel.org/show_bug.cgi?id=7589 Summary: libata: does not work anymore on VIA VT8251 AHCI/SATA 4- Port Controller Kernel Version: 2.6.19-rc6-git10 Status: NEW Severity: blocking Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did *NOT* occur: 2.6.18.3 Distribution: Gentoo Linux Hardware Environment: - ASUS A8V-VM 00:00.0 Host bridge: VIA Technologies, Inc. Unknown device 0336 Flags: bus master, medium devsel, latency 8 Memory at f000 (32-bit, prefetchable) [size=128M] Capabilities: [80] AGP version 3.0 Capabilities: [50] Power Management version 2 Capabilities: [60] HyperTransport: Slave or Primary Interface Capabilities: [58] #00 [] 00:00.1 Host bridge: VIA Technologies, Inc. Unknown device 1336 Flags: bus master, medium devsel, latency 0 00:00.2 Host bridge: VIA Technologies, Inc. Unknown device 2336 Flags: bus master, medium devsel, latency 0 00:00.3 Host bridge: VIA Technologies, Inc. Unknown device 3336 Flags: bus master, medium devsel, latency 0 00:00.4 Host bridge: VIA Technologies, Inc. Unknown device 4336 Flags: bus master, medium devsel, latency 0 00:00.5 PIC: VIA Technologies, Inc. Unknown device 5336 (prog-if 20 [IO(X)-APIC]) Flags: bus master, fast devsel, latency 0 00:00.6 Host bridge: VIA Technologies, Inc. Unknown device 6290 Subsystem: Unknown device 0008: Flags: bus master, medium devsel, latency 0 00:00.7 Host bridge: VIA Technologies, Inc. Unknown device 7336 Flags: bus master, medium devsel, latency 0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Capabilities: [70] Power Management version 2 00:02.0 PCI bridge: VIA Technologies, Inc. K8T890 PCI to PCI Bridge Controller (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Memory behind bridge: daf0-dfff Prefetchable memory behind bridge: c000-cff0 Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [68] Power Management version 2 Capabilities: [70] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [dc] HyperTransport: MSI Mapping 00:0f.0 IDE interface: VIA Technologies, Inc. VT8251 AHCI/SATA 4-Port Controller (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: ASUSTeK Computer Inc. Unknown device 81b5 Flags: bus master, medium devsel, latency 192, IRQ 17 I/O ports at d800 [size=8] I/O ports at d400 [size=4] I/O ports at d000 [size=8] I/O ports at c800 [size=4] I/O ports at c400 [size=16] Memory at daeffc00 (32-bit, non-prefetchable) [size=1K] Capabilities: [c0] Power Management version 2 Capabilities: [e0] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 07) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. Unknown device 81b5 Flags: bus master, medium devsel, latency 32 I/O ports at fc00 [size=16] Capabilities: [c0] Power Management version 2 00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 90) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 81b5 Flags: bus master, medium devsel, latency 192, IRQ 19 I/O ports at c000 [size=32] Capabilities: [80] Power Management version 2 00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 90) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 81b5 Flags: bus master, medium devsel, latency 192, IRQ 18 I/O ports at b800 [size=32] Capabilities: [80] Power Management version 2 00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 90) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 81b5 Flags: bus master, medium devsel, latency 192, IRQ 17 I/O ports at b400 [size=32] Capabilities: [80] Power Management version 2 00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 90) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc. Unknown device 81b5
Re: [PATCH] pata_it8213: Add new driver for the IT8213 card.
On Mon, 4 Dec 2006 16:49:31 +
Alan <[EMAIL PROTECTED]> wrote:
> Add a driver for the IT8213 which is a single channel ICH-ish PATA
> controller. As it is very different to the IT8211/2 it gets its own
> driver. There is a legacy drivers/ide driver also available and I'll post
> that once I get time to test it all out (probably early January). If
> anyone else needs the drivers/ide driver and wants to do the merge for
> drivers/ide (Bart ??) then I'll forward it.
>
> ...
>
> +static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev)
> +{
> + unsigned int pio= adev->pio_mode - XFER_PIO_0;
> + struct pci_dev *dev = to_pci_dev(ap->host->dev);
> + unsigned int idetm_port= ap->port_no ? 0x42 : 0x40;
> + u16 idetm_data;
> + int control = 0;
> +
> + /*
> + * See Intel Document 298600-004 for the timing programing rules
> + * for PIIX/ICH. The 8213 is a clone so very similar
> + */
> +
> + static const /* ISP RTC */
> + u8 timings[][2] = { { 0, 0 },
> + { 0, 0 },
> + { 1, 0 },
> + { 2, 1 },
> + { 2, 3 }, };
>
> ...
>
> +
> +static void it8213_set_dmamode (struct ata_port *ap, struct ata_device *adev)
> +{
> + struct pci_dev *dev = to_pci_dev(ap->host->dev);
> + u16 master_data;
> + u8 speed= adev->dma_mode;
> + int devid = adev->devno;
> + u8 udma_enable;
> +
> + static const /* ISP RTC */
> + u8 timings[][2] = { { 0, 0 },
> + { 0, 0 },
> + { 1, 0 },
> + { 2, 1 },
> + { 2, 3 }, };
Was the duplication of timings[] deliberate?
> + const unsigned int needed_pio[3] = {
> + XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
> + };
I made this static (save the world and all that).
> +static const struct pci_device_id it8213_pci_tbl[] = {
> + { PCI_VDEVICE(ITE, PCI_DEVICE_ID_ITE_8213), },
drivers/ata/pata_it8213.c:323: error: 'PCI_DEVICE_ID_ITE_8213' undeclared here
(not in a function)
I went out on a limb and...
---
a/drivers/ata/pata_it8213.c~pata_it8213-add-new-driver-for-the-it8213-card-tidy
+++ a/drivers/ata/pata_it8213.c
@@ -194,7 +194,7 @@ static void it8213_set_dmamode (struct a
unsigned int mwdma = adev->dma_mode - XFER_MW_DMA_0;
unsigned int control;
u8 slave_data;
- const unsigned int needed_pio[3] = {
+ static const unsigned int needed_pio[3] = {
XFER_PIO_0, XFER_PIO_3, XFER_PIO_4
};
int pio = needed_pio[mwdma] - XFER_PIO_0;
@@ -352,4 +352,3 @@ MODULE_DESCRIPTION("SCSI low-level drive
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(pci, it8213_pci_tbl);
MODULE_VERSION(DRV_VERSION);
-
diff -puN
include/linux/pci_ids.h~pata_it8213-add-new-driver-for-the-it8213-card-tidy
include/linux/pci_ids.h
---
a/include/linux/pci_ids.h~pata_it8213-add-new-driver-for-the-it8213-card-tidy
+++ a/include/linux/pci_ids.h
@@ -1622,6 +1622,7 @@
#define PCI_VENDOR_ID_ITE 0x1283
#define PCI_DEVICE_ID_ITE_8211 0x8211
#define PCI_DEVICE_ID_ITE_8212 0x8212
+#define PCI_DEVICE_ID_ITE_8213 0x8213
#define PCI_DEVICE_ID_ITE_8872 0x8872
#define PCI_DEVICE_ID_ITE_IT8330G_00xe886
_
-
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: -mm merge plans for 2.6.20
On Mon, 04 Dec 2006 23:56:42 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > via-pata-controller-xfer-fixes.patch > > via-pata-controller-xfer-fixes-fix.patch > > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the > reporter as fixing things, so these two shouldn't be needed. OK thanks, I dropped it. > > > libata_resume_fix.patch > > I thought this was resolved long ago? Are there still open reports that > this solves, where upstream doesn't work? Heck, I don't know. > > > ahci-ati-sb600-sata-support-for-various-modes.patch > > With the PCI quirk, I thought ATI was finally sorted? Was it? I don't know that either. I'll drop these too. - 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: -mm merge plans for 2.6.20
On Thu, 07 Dec 2006 03:19:40 +0800
Conke Hu <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-12-04 at 21:41 -0800, Andrew Morton wrote:
> > On Mon, 04 Dec 2006 23:56:42 -0500
> > Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> > > Andrew Morton wrote:
> > > > via-pata-controller-xfer-fixes.patch
> > > > via-pata-controller-xfer-fixes-fix.patch
> > >
> > > Tejun's 3d3cca37559e3ab2b574eda11ed5207ccdb8980a has been ack'd by the
> > > reporter as fixing things, so these two shouldn't be needed.
> >
> > OK thanks, I dropped it.
> >
> > >
> > > > libata_resume_fix.patch
> > >
> > > I thought this was resolved long ago? Are there still open reports that
> > > this solves, where upstream doesn't work?
> >
> > Heck, I don't know.
> >
> > >
> > > > ahci-ati-sb600-sata-support-for-various-modes.patch
> > >
> > > With the PCI quirk, I thought ATI was finally sorted?
> >
> > Was it? I don't know that either.
> >
> > I'll drop these too.
> > -
>
> Hi Jeff, Andrew
> The following patch is ATI's final solution. It was ACKed by Alan.
> Jeff, you're the maintainer of libata, but this patch is based on
> pci/quirks.c, so I don't know who will apply this patch? You or somebody
> else?
> Andrew, could you please drop ATI's previous patch and add this one
> in next -mm patch? The previous patch I sent
> (ahci-ati-sb600-sata-support-for-various-modes.patch) is not as good as
> this one :)
>
>
> Best regards,
> Conke @AMD/ATI
Please send a signed-off-by: for this work, and a changelog which tells us
what it does and why the kernel needs this change.
I shall then remove the ifdef (it's __devinit, and other quirks don't do
this, and vmlinux doesn't know whether or not this driver will later be
loaded) and I shall fix up the word wrapping and I shall convert the spaces
back into tabs and I shall then send it on to Greg, thanks.
> [--PATCH--]
>
> --- linux-2.6.19-rc6-git4/drivers/pci/quirks.c.orig 2006-11-23
> 19:45:49.0 +0800
> +++ linux-2.6.19-rc6-git4/drivers/pci/quirks.c 2006-11-23
> 19:34:23.0 +0800
> @@ -795,6 +795,25 @@ static void __init quirk_mediagx_master(
>}
> }
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CYRIX,
> PCI_DEVICE_ID_CYRIX_PCI_MASTER, quirk_mediagx_master );
> +
> +#if defined(CONFIG_SATA_AHCI) || defined(CONFIG_SATA_AHCI_MODULE)
> +static void __devinit quirk_sb600_sata(struct pci_dev *pdev)
> +{
> + /* set sb600 sata to ahci mode */
> + if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) {
> + u8 tmp;
> +
> + pci_read_config_byte(pdev, 0x40, &tmp);
> + pci_write_config_byte(pdev, 0x40, tmp|1);
> + pci_write_config_byte(pdev, 0x9, 1);
> + pci_write_config_byte(pdev, 0xa, 6);
> + pci_write_config_byte(pdev, 0x40, tmp);
> +
> + pdev->class = 0x010601;
> + }
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
> PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
> +#endif
-
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.6.19-rc6][reRESEND] ata_piix: IDE mode SATA patch for Intel ICH9
On Thu, 07 Dec 2006 07:16:40 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Jason Gaston wrote: > > This updated patch adds the Intel ICH9 IDE mode SATA controller DID's. > > > > Signed-off-by: Jason Gaston <[EMAIL PROTECTED]> > > ACK but your mailer is still chomping things. > > Andrew, do you happen to have this one lying around? yup, will send. - 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
ata kmap_atomic abuse
[ 231.948000] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) [ 232.232000] ata1.00: configured for UDMA/33 [ 232.404000] WARNING (1) at arch/i386/mm/highmem.c:47 kmap_atomic() [ 232.404000] [] kmap_atomic+0xa9/0x1ab [ 232.404000] [] ata_scsi_rbuf_get+0x1c/0x30 [ 232.404000] [] ata_scsi_rbuf_fill+0x1a/0x87 [ 232.404000] [] ata_scsiop_mode_sense+0x0/0x309 [ 232.404000] [] end_bio_bh_io_sync+0x0/0x37 [ 232.404000] [] scsi_done+0x0/0x16 [ 232.404000] [] scsi_done+0x0/0x16 [ 232.404000] [] ata_scsi_simulate+0xb0/0x13f [ 232.404000] [] mempool_free+0x4a/0x4e [ 232.404000] [] scsi_done+0x0/0x16 [ 232.404000] [] ata_scsi_queuecmd+0xa5/0xe1 [ 232.404000] [] scsi_dispatch_cmd+0x1b3/0x226 [ 232.404000] [] scsi_request_fn+0x250/0x2c2 [ 232.404000] [] as_completed_request+0x1ce/0x1db [ 232.404000] [] blk_run_queue+0x2a/0x4b [ 232.404000] [] scsi_next_command+0x25/0x2f [ 232.404000] [] scsi_end_request+0x8c/0x96 [ 232.404000] [] scsi_io_completion+0x15a/0x329 [ 232.404000] [] ata_hsm_move+0x719/0x729 [ 232.404000] [] sd_rw_intr+0x209/0x233 [ 232.404000] [] wakeup_pmode_return+0x0/0x55 [ 232.404000] [] scsi_finish_command+0x81/0x88 [ 232.404000] [] blk_done_softirq+0x4a/0x55 [ 232.404000] [] __do_softirq+0x35/0x75 [ 232.404000] [] do_softirq+0x22/0x26 [ 232.404000] [] do_IRQ+0x67/0x81 [ 232.404000] [] common_interrupt+0x23/0x28 [ 232.404000] === It's using KM_USER0 from softirq. - 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: ata kmap_atomic abuse
On Mon, 11 Dec 2006 11:07:06 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > [ 231.948000] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
> > [ 232.232000] ata1.00: configured for UDMA/33
> > [ 232.404000] WARNING (1) at arch/i386/mm/highmem.c:47 kmap_atomic()
>
> > It's using KM_USER0 from softirq.
>
> I thought that was OK if it was kmap_atomic(). Live and learn.
Each kmap_atomic slot is basically a per-cpu global variable. If a CPU is
inside process-level kmap_atomic(KM_USER0) and then runs that softirq,
it'll return from the softirq with its kmap slot pointing at the wrong
page.
> Checked in the attached.
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index 664e137..a4790be 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -1539,7 +1539,7 @@ static unsigned int ata_scsi_rbuf_get(st
> struct scatterlist *sg;
>
> sg = (struct scatterlist *) cmd->request_buffer;
> - buf = kmap_atomic(sg->page, KM_USER0) + sg->offset;
> + buf = kmap_atomic(sg->page, KM_IRQ0) + sg->offset;
> buflen = sg->length;
> } else {
> buf = cmd->request_buffer;
> @@ -1567,7 +1567,7 @@ static inline void ata_scsi_rbuf_put(str
> struct scatterlist *sg;
>
> sg = (struct scatterlist *) cmd->request_buffer;
> - kunmap_atomic(buf - sg->offset, KM_USER0);
> + kunmap_atomic(buf - sg->offset, KM_IRQ0);
> }
> }
>
KM_IRQ0 can only be used with local interrupts disabled, for the same
reason.
-
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: OOPS: deref 0x14 at pdc_port_start+0x82 [Was: 2.6.20-rc1-mm1]
On Fri, 15 Dec 2006 15:45:55 +0059
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-rc1-mm1/
> >
> > Will appear later at
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc1/2.6.20-rc1-mm1/
>
> The kernel panics at boot in pdc_port_start+0x82 with deref of 0x14:
> http://www.fi.muni.cz/~xslaby/sklad/pdc_oops.png
>
> ATA port is not connected, only 2 SATA disks on my
> # lspci -vvxs 02:01.0
> 02:01.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300
> TX2plus) (rev 02)
> Subsystem: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> SERR- Latency: 72 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
> Interrupt: pin A routed to IRQ 19
> Region 0: I/O ports at 8000 [size=128]
> Region 2: I/O ports at 8400 [size=256]
> Region 3: Memory at fb025000 (32-bit, non-prefetchable) [size=4K]
> Region 4: Memory at fb00 (32-bit, non-prefetchable) [size=128K]
> [virtual] Expansion ROM at 5000 [disabled] [size=32K]
> Capabilities: [60] Power Management version 2
> Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 00: 5a 10 73 3d 07 00 30 02 02 00 80 01 01 48 00 00
> 10: 01 80 00 00 00 00 00 00 01 84 00 00 00 50 02 fb
> 20: 00 00 00 fb 00 00 00 00 00 00 00 00 5a 10 73 3d
> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 04 12
>
Presumably
void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
gave us a null pointer.
Something like this:
diff -puN drivers/ata/sata_promise.c~a drivers/ata/sata_promise.c
--- a/drivers/ata/sata_promise.c~a
+++ a/drivers/ata/sata_promise.c
@@ -294,6 +294,10 @@ static int pdc_port_start(struct ata_por
void __iomem *mmio = (void __iomem *) ap->ioaddr.scr_addr;
unsigned int tmp;
+ if (!mmio) {
+ rc = -EDOM;
+ goto out_kfree;
+ }
tmp = readl(mmio + 0x014);
tmp = (tmp & ~3) | 1; /* set bits 1:0 = 0:1 */
writel(tmp, mmio + 0x014);
_
should perhaps let you wobble to a state where you can get us the full
dmesg output, please.
Actually, that should already be possible simply using netconsole.
-
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: ata kmap_atomic abuse
On Sat, 16 Dec 2006 11:40:29 -0500
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Mon, 11 Dec 2006 11:07:06 -0500
> > Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> >> Andrew Morton wrote:
> >>> [ 231.948000] SCSI device sda: 195371568 512-byte hdwr sectors (100030
> >>> MB)
> >>> [ 232.232000] ata1.00: configured for UDMA/33
> >>> [ 232.404000] WARNING (1) at arch/i386/mm/highmem.c:47 kmap_atomic()
> >>> It's using KM_USER0 from softirq.
> >> I thought that was OK if it was kmap_atomic(). Live and learn.
> >
> > Each kmap_atomic slot is basically a per-cpu global variable. If a CPU is
> > inside process-level kmap_atomic(KM_USER0) and then runs that softirq,
> > it'll return from the softirq with its kmap slot pointing at the wrong
> > page.
> >
> >> Checked in the attached.
> >
> >
> > diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> >> index 664e137..a4790be 100644
> >> --- a/drivers/ata/libata-scsi.c
> >> +++ b/drivers/ata/libata-scsi.c
> >> @@ -1539,7 +1539,7 @@ static unsigned int ata_scsi_rbuf_get(st
> >>struct scatterlist *sg;
> >>
> >>sg = (struct scatterlist *) cmd->request_buffer;
> >> - buf = kmap_atomic(sg->page, KM_USER0) + sg->offset;
> >> + buf = kmap_atomic(sg->page, KM_IRQ0) + sg->offset;
> >>buflen = sg->length;
> >>} else {
> >>buf = cmd->request_buffer;
> >> @@ -1567,7 +1567,7 @@ static inline void ata_scsi_rbuf_put(str
> >>struct scatterlist *sg;
> >>
> >>sg = (struct scatterlist *) cmd->request_buffer;
> >> - kunmap_atomic(buf - sg->offset, KM_USER0);
> >> + kunmap_atomic(buf - sg->offset, KM_IRQ0);
> >>}
> >> }
> >>
> >
> > KM_IRQ0 can only be used with local interrupts disabled, for the same
> > reason.
>
> Are you making a comment, or pointing out a flaw in the patch?
> AFAICS, the code in question is always under spin_lock_irqsave()
ok. That is in fact obligatory: if we were to call this (as-modified)
function from softirq context but with local IRQs enabled, an intervening
interrupt could come in and make out kmap slot point somewhere else.
We require that local interrupts remain disabled by the caller until the
caller has called ata_scsi_rbuf_put().
This means that we require that all callers of the non-static
ata_scsi_rbuf_fill() have disabled local IRQs. The nice comment says they
must do that, so hopefully we're OK there.
So yes, it all looks to be solid to me.
-
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: Bugs in Kernels 2.6.20-rc2, rc3 and 2.6.20-rc2-mm1
On Fri, 05 Jan 2007 19:20:37 +0100
"Uwe Bugla" <[EMAIL PROTECTED]> wrote:
> Hi,
> 1.In Kernels 2.6.20-rc2 and 2.6.20-rc3 a CD- and DVD-burning application
> called nerolinux is doing nasty things:
> After a cold start you start the application, then chose the burning device,
> then close the application. Then the KDE Daemon comes up although no CD is
> inserted into the burning device. In every following use of Nerolinux after
> that nerolinux is incapable of recognizing CD- and DVD devices. In other
> words:
> The device stays active, with or without containing a CD or DVD, and is not
> released anymore!
> Dmesg looks like this:
> hdd: status error: status=0x58 { DriveReady SeekComplete DataRequest }
> ide: failed opcode was: unknown
> hdd: drive not ready for command
>
> This does not happen in Kernel 2.6.19!
Added linux-ide.
> 2.In Kernel 2.6.20-rc2-mm1 you cannot mount a conventional floppy drive
> without hanging up the whole system. This does not happen in Kernel
> 2.6.20-rc2 and rc3.
>
Yup, this is still on my list of things to look at, 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 3/3] atiixp.c: add cable detection support for ATI IDE
On Tue, 9 Jan 2007 14:54:01 +0100
"Bartlomiej Zolnierkiewicz" <[EMAIL PROTECTED]> wrote:
> The good news is that it doesn't matter now as Andrew fixed Conke's patches
> manually and applied them to -mm
I applied three pathces, but there's been such a storm of inadequately
changelogged mangled patches that I have little confidence that what I
applied was complete and up-to-date.
> [ but without my Acked-by-s :( ].
oop.
Here are the three patches. Conke, can you please tell us whether this is
all correct and complete?
From: "Conke Hu" <[EMAIL PROTECTED]>
A previous patch to atiixp.c was removed but some code has not been
cleaned. Now we remove these code sine they are no use any longer.
Signed-off-by: Conke Hu <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ide/pci/atiixp.c | 21 +
1 files changed, 1 insertion(+), 20 deletions(-)
diff -puN drivers/ide/pci/atiixp.c~atiixpc-remove-unused-code
drivers/ide/pci/atiixp.c
--- a/drivers/ide/pci/atiixp.c~atiixpc-remove-unused-code
+++ a/drivers/ide/pci/atiixp.c
@@ -320,19 +320,6 @@ static void __devinit init_hwif_atiixp(i
hwif->drives[0].autodma = hwif->autodma;
}
-static void __devinit init_hwif_sb600_legacy(ide_hwif_t *hwif)
-{
-
- hwif->atapi_dma = 1;
- hwif->ultra_mask = 0x7f;
- hwif->mwdma_mask = 0x07;
- hwif->swdma_mask = 0x07;
-
- if (!noautodma)
- hwif->autodma = 1;
- hwif->drives[0].autodma = hwif->autodma;
- hwif->drives[1].autodma = hwif->autodma;
-}
static ide_pci_device_t atiixp_pci_info[] __devinitdata = {
{ /* 0 */
@@ -342,13 +329,7 @@ static ide_pci_device_t atiixp_pci_info[
.autodma= AUTODMA,
.enablebits = {{0x48,0x01,0x00}, {0x48,0x08,0x00}},
.bootable = ON_BOARD,
- },{ /* 1 */
- .name = "ATI SB600 SATA Legacy IDE",
- .init_hwif = init_hwif_sb600_legacy,
- .channels = 2,
- .autodma= AUTODMA,
- .bootable = ON_BOARD,
- }
+ },
};
/**
_
From: "Conke Hu" <[EMAIL PROTECTED]>
AMD/ATI SB600 IDE/PATA controller only has one channel.
Signed-off-by: Conke Hu <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ide/pci/atiixp.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff -puN drivers/ide/pci/atiixp.c~atiixpc-sb600-ide-only-has-one-channel
drivers/ide/pci/atiixp.c
--- a/drivers/ide/pci/atiixp.c~atiixpc-sb600-ide-only-has-one-channel
+++ a/drivers/ide/pci/atiixp.c
@@ -329,7 +329,14 @@ static ide_pci_device_t atiixp_pci_info[
.autodma= AUTODMA,
.enablebits = {{0x48,0x01,0x00}, {0x48,0x08,0x00}},
.bootable = ON_BOARD,
- },
+ },{ /* 1 */
+ .name = "SB600_PATA",
+ .init_hwif = init_hwif_atiixp,
+ .channels = 1,
+ .autodma= AUTODMA,
+ .enablebits = {{0x48,0x01,0x00}, {0x00,0x00,0x00}},
+ .bootable = ON_BOARD,
+ },
};
/**
@@ -350,7 +357,7 @@ static struct pci_device_id atiixp_pci_t
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP200_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP300_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
- { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0},
+ { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_IDE, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 1},
{ 0, },
};
MODULE_DEVICE_TABLE(pci, atiixp_pci_tbl);
_
From: "Conke Hu" <[EMAIL PROTECTED]>
IDE HDD does not work if it uses a 40-pin PATA cable on ATI chipset.
This patch fixes the bug.
Signed-off-by: Conke Hu <[EMAIL PROTECTED]>
Cc: Alan Cox <[EMAIL PROTECTED]>
Cc: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ide/pci/atiixp.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff -puN
drivers/ide/pci/atiixp.c~atiixpc-add-cable-detection-support-for-ati-ide
drivers/ide/pci/atiixp.c
--- a/drivers/ide/pci/atiixp.c~atiixpc-add-cable-detection-support-for-ati-ide
+++ a/drivers/ide/pci/atiixp.c
@@ -291,8 +291,12 @@ fast_at
Re: 2.6.20-rc6: known unfixed regressions (v2) (part 2)
On Sun, 28 Jan 2007 14:33:44 +0100 "Uwe Bugla" <[EMAIL PROTECTED]> wrote: > > Subject: problems with CD burning > > References : http://www.spinics.net/lists/linux-ide/msg06545.html > > Submitter : Uwe Bugla <[EMAIL PROTECTED]> > > Status : unknown > > > > > > ... > > Hi everybody, > the problem I already reported for earlier release candidates of kernel 2.6.20 > (rc1 – 5) unfortunately stills persists. > > The regression has become more extreme: While in earlier release candidates > nerolinux recognized my burning devices at least after the first start and > then never again after all following starts the situation in rc6 is different > from that: > > The CD and DVD burning devices aren´t recognized even once and the drive seek > errors I already reported are still there. > > nerolinux runs excellently with kernel 2.6.19.2, but only shows an “image > recorder” (i. e. no burning device at all) in kernel 2.6.20-rc6. > > Still hope that this terrible bug will not be part of the final version of > 2.6.20! > Not sure what to do about this. It looks like a failure in the IDE driver. Perhaps you could start by telling us about the IDE hardware, which driver is in use, etc. Is the floppy-disk bug still there? - 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.20-rc6: known unfixed regressions (v2) (part 2)
On Mon, 29 Jan 2007 07:26:03 +0100
Mike Galbraith <[EMAIL PROTECTED]> wrote:
> FWIW, I just tried it with 2.6.20-rc6, and can confirm. Once nero is
> run, the kernel never gives up retrying whatever command failed, so I
> get...
>
> [ 4362.972995] hdd: status error: status=0x58 { DriveReady SeekComplete
> DataRequest }
> [ 4362.981475] ide: failed opcode was: unknown
> [ 4362.986183] hdd: drive not ready for command
>
> endlessly.
Do you have time to bisect it?
-
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.20-rc6: known unfixed regressions (v2) (part 2)
On Mon, 29 Jan 2007 20:50:58 -0600 Mike Christie <[EMAIL PROTECTED]> wrote: > With the attached patch, nero finds the cd drives and I can burn disks. > There is no errors from the ide layer like before. > > > [use-old-timeout-calc.patch text/x-patch (399B)] > diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c > index 2528a0c..aded9a0 100644 > --- a/block/scsi_ioctl.c > +++ b/block/scsi_ioctl.c > @@ -271,7 +271,7 @@ static int sg_io(struct file *file, requ > > rq->cmd_type = REQ_TYPE_BLOCK_PC; > > - rq->timeout = jiffies_to_msecs(hdr->timeout); > + rq->timeout = (hdr->timeout * HZ) / 1000; Yes, that was a buggy conversion - it should have been msecs_to_jiffies(). - 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.20-rc6: known unfixed regressions (v2) (part 2)
On Mon, 29 Jan 2007 21:18:38 -0500
Mike Christie <[EMAIL PROTECTED]> wrote:
> Ok. here is a fix with the overflow check sg.c has. Patch
> was made against Linus's tree and tested with nero.
>
> Userspace does not send us jiffies. Use msecs_to_jiffies
> and check for overflow like sg.c
>
> Signed-off-by: Mike Christie <[EMAIL PROTECTED]>
>
> diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
> index 2528a0c..5ca72c5 100644
> --- a/block/scsi_ioctl.c
> +++ b/block/scsi_ioctl.c
> @@ -223,7 +223,7 @@ static int verify_command(struct file *f
> static int sg_io(struct file *file, request_queue_t *q,
> struct gendisk *bd_disk, struct sg_io_hdr *hdr)
> {
> - unsigned long start_time;
> + unsigned long start_time. timeout;
you'll be wanting a comma there.
-
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 RFC] sd: spin down disks on removal or power-down
On Sun, 28 Jan 2007 19:47:27 -0600
Robert Hancock <[EMAIL PROTECTED]> wrote:
> Here's a patch for sd.c I've cooked up which issues a START STOP UNIT
> command to stop the drive when the SCSI disk is removed or the machine
> is powered down. The rationale behind this is that apparently on many
> drives, simply cutting power to the spinning disk forces it to do an
> emergency head park/unload which creates more wear on the drive then a
> controlled park/unload with power still applied. This change ensures
> that the drive will be spun down if the user shuts down the machine or
> if they are about to hot-unplug the drive and have done "scsiadd -r" first.
>
> The main potential concern I have about this implementation is that if
> the drive is used in a multi-initiator, iSCSI, etc. environment,
> stopping the drive may be undesirable as another initiator may still be
> accessing it. I'm not familiar enough with these setups to know if this
> problem is likely to come up or not. For this and other reasons we may
> want to make this behavior controllable - I'm open to suggestions on how
> to do this or whether it's needed.
>
> I've tested that this does work on SATA disks through libata (with my
> patch "libata: fix translation for START STOP UNIT" applied). I also
> tested with some external USB-to-IDE drive enclosures. The support for
> START STOP UNIT on those seems rather poor though, on one enclosure with
> a Genesys bridge chip it returned a check condition with "Invalid field
> in CDB", and on another with a JMicron chip the request succeeded but it
> didn't actually spin the drive down.
>
What we don't want to happen is for those disks to spin down during a reboot.
It seems that this is OK with this patch.
Also, we probably don't want them to be spun down during a kexec_load, but
I expect that's OK too.
triviata:
> --- linux-2.6.20-rc6nv/drivers/scsi/sd.c 2007-01-28 17:00:00.0
> -0600
> +++ linux-2.6.20-rc6nvedit/drivers/scsi/sd.c 2007-01-28 18:08:53.0
> -0600
> @@ -821,6 +821,39 @@ static int sd_sync_cache(struct scsi_dev
> return res;
> }
>
> +static int sd_stop_unit(struct scsi_device *sdp, struct scsi_disk* sdkp)
s/* / */
> +{
> + int res;
> + struct scsi_sense_hdr sshdr;
> + unsigned char cmd[10] = { 0 };
I don't think this initialisation-to-all-zeroes is needed, is it?
> + if (!scsi_device_online(sdp))
> + return -ENODEV;
> +
> + cmd[0] = START_STOP;
> + /*
> + * Leave the rest of the command zero to indicate
> + * transition to stopped power condition and return
> + * on completion.
> + */
> + printk(KERN_NOTICE "Stopping SCSI disk %s\n",
> + sdkp->disk->disk_name);
> + res = scsi_execute_req(sdp, cmd, DMA_NONE, NULL, 0, &sshdr,
> +SD_TIMEOUT, SD_MAX_RETRIES);
> +
> + if (res) {
> + printk(KERN_WARNING "sd stop failed: status = %x, message =
> %02x, "
> + "host = %d, driver = %02x\n",
> + status_byte(res), msg_byte(res),
> + host_byte(res), driver_byte(res));
> + if (driver_byte(res) & DRIVER_SENSE)
> + scsi_print_sense_hdr("sd", &sshdr);
> + }
> +
> + return res;
> +}
> +
> +
> static int sd_issue_flush(struct device *dev, sector_t *error_sector)
> {
> int ret = 0;
> @@ -1727,11 +1760,13 @@ static int sd_probe(struct device *dev)
> **/
> static int sd_remove(struct device *dev)
> {
> + struct scsi_device *sdp = to_scsi_device(dev);
> struct scsi_disk *sdkp = dev_get_drvdata(dev);
>
> class_device_del(&sdkp->cdev);
> del_gendisk(sdkp->disk);
> sd_shutdown(dev);
> + sd_stop_unit(sdp,sdkp);
>
> mutex_lock(&sd_ref_mutex);
> dev_set_drvdata(dev, NULL);
> @@ -1784,6 +1819,9 @@ static void sd_shutdown(struct device *d
> sdkp->disk->disk_name);
> sd_sync_cache(sdp);
> }
> + if(system_state == SYSTEM_POWER_OFF)
s/if(/if (/
> + sd_stop_unit(sdp,sdkp);
> +
> scsi_disk_put(sdkp);
> }
>
>
>
>
>
>
-
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: [git patches] libata fixes
On Fri, 2 Feb 2007 09:13:56 -0800 (PST) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Fri, 2 Feb 2007, Jeff Garzik wrote: > > > > pata_atiixp: propogate cable detection hack from drivers/ide to the > > new driver > > It's prop*a*gate. > > Damn. > > Linus "some speling mistaeks drive me wild" Torvalds http://www.google.com/search?hl=en&q=torvalds+schenario&btnG=Google+Search - 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: Add a host flag to indicate lack of IORDY capability
On Mon, 5 Feb 2007 16:15:15 + Alan <[EMAIL PROTECTED]> wrote: > This is the first preparation to doing the !IORDY cases properly. Further > diffs will then add the needed logic to do it right. > >... > > static int pio_mask = 0x1F; /* PIO range for autospeed devices */ > ++static int iordy_mask = 0x; /* Use iordy if available */ That isn't compileable. Are you sure you sent the correct patch? This patch needed some fixups against git-libata-all, but they were pretty obvious. - 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: Early CFA adapters are not required to support mode setting
On Mon, 5 Feb 2007 16:28:30 +
Alan <[EMAIL PROTECTED]> wrote:
> If we are doing a PIO setup for a CFA card and it blows up with a device
> error then assume it is an older CFA card which doesn't support this
> rather than failing the device out of existance.
>
> Stands seperate to the quieting patch but that is obviously useful with
> this change.
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
>
> diff -u --new-file --recursive --exclude-from /usr/src/exclude
> linux.vanilla-2.6.20-rc6-mm3/drivers/ata/libata-core.c
> linux-2.6.20-rc6-mm3/drivers/ata/libata-core.c
> --- linux.vanilla-2.6.20-rc6-mm3/drivers/ata/libata-core.c2007-01-31
> 14:20:39.0 +
> +++ linux-2.6.20-rc6-mm3/drivers/ata/libata-core.c2007-02-01
> 16:14:01.0 +
> @@ -2404,6 +2460,10 @@
> dev->flags |= ATA_DFLAG_PIO;
>
> err_mask = ata_dev_set_xfermode(dev);
> + /* 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;
> +
> if (err_mask) {
> ata_dev_printk(dev, KERN_ERR, "failed to set xfermode "
> "(err_mask=0x%x)\n", err_mask);
This hunk is already in
libata-fix-hopefully-all-the-remaining-problems-with.patch. Should I drop
libata-fix-hopefully-all-the-remaining-problems-with.patch?
If its presence can affect the validity of testing these four patches then
perhaps yes..
-
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: Early CFA adapters are not required to support mode setting
On Mon, 5 Feb 2007 23:11:52 + Alan <[EMAIL PROTECTED]> wrote: > > libata-fix-hopefully-all-the-remaining-problems-with.patch. Should I drop > > > > The hopefully fix all the remaining problems patch did say not to merge > it I thought. Please don't merge it yet - Jeff has asked for some > improvements and its not fixing the cases under investigation so it'll > confuse stuff rather than help at the moment. I wasn't planning on sending libata-fix-hopefully-all-the-remaining-problems-with.patch upstream. My concern is that its presence might invalidate (or get confused with) testing of the earlier patches. I'll assume it's ok... - 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: Fw: [Bugme-new] [Bug 7958] New: AE_AML_PACKAGE_LIMIT is beyond end of object
On Wed, 07 Feb 2007 21:22:06 +0300 Alexey Starikovskiy <[EMAIL PROTECTED]> wrote: > Andrew, > This bug seem to be duplicate of 7907, which in turn seem to be caused > by latest libata patches. Oh. Surprised. Let's tell Jeff about it. > Thanks, > Alex. > Andrew Morton wrote: > > This looks like something which needs attention prior to merging the new > > ACPI > > code? > > > > Begin forwarded message: > > > > Date: Wed, 7 Feb 2007 04:57:01 -0800 > > From: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > Subject: [Bugme-new] [Bug 7958] New: AE_AML_PACKAGE_LIMIT is beyond end of > > object > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=7958 > > > >Summary: AE_AML_PACKAGE_LIMIT is beyond end of object > > Kernel Version: 2.6.20-rc6-mm3 > > Status: NEW > > Severity: normal > > Owner: [EMAIL PROTECTED] > > Submitter: [EMAIL PROTECTED] > > > > > > This occured in dmesg after hw suspend and resume: > > Suspending device 0.0 > > ACPI Exception (exoparg2-0442): AE_AML_PACKAGE_LIMIT, Index (7) is > > beyon > > d end of object [20070126] > > ACPI Error (psparse-0537): Method parse/execution failed > > [\_SB_.PCI0.IDE0.GTM_] > > (Node dfe64fcc), AE_AML_PACKAGE_LIMIT > > ACPI Error (psparse-0537): Method parse/execution failed > > [\_SB_.PCI0.IDE0.CHN0._ > > GTM] (Node dfe649f0), AE_AML_PACKAGE_LIMIT > > ... > > RESUME > > ... > > hda: selected mode 0x45 > > ACPI Error (dsopcode-0481): Attempt to CreateField of length zero [20070126] > > ACPI Error (psparse-0537): Method parse/execution failed > > [\_SB_.PCI0.IDE0.RATA] > > (Node dfe64ec8), AE_AML_OPERAND_VALUE > > ACPI Error (psparse-0537): Method parse/execution failed > > [\_SB_.PCI0.IDE0.CHN0.D > > RV1._GTF] (Node dfe64964), AE_AML_OPERAND_VALUE > > do_drive_get_GTF: Run _GTF error: status = 0x3006 > > > > --- You are receiving this mail because: --- > > You are on the CC list for the bug, or are watching someone who is. > > - > > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.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
Re: [PATCH] ATA convert GSI to irq on ia64
On Thu, 8 Feb 2007 19:42:04 + Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Thu, Feb 08, 2007 at 03:40:22PM +0800, Zhang, Yanmin wrote: > > If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the > > fixed irq number. On ia64 platform, such numbers are GSI and should be > > converted > > to irq vector. > > > > Below patch against kernel 2.6.20 fixes it. > > These direct arch ifdefs in core aren't acceptable. For 2.6.21 that's true. But this is a suitable fix for 2.6.20.x, no? - 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] ATA convert GSI to irq on ia64
On Thu, 8 Feb 2007 20:34:53 + Christoph Hellwig <[EMAIL PROTECTED]> wrote: > On Thu, Feb 08, 2007 at 12:25:39PM -0800, Andrew Morton wrote: > > On Thu, 8 Feb 2007 19:42:04 + > > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > > On Thu, Feb 08, 2007 at 03:40:22PM +0800, Zhang, Yanmin wrote: > > > > If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as > > > > the > > > > fixed irq number. On ia64 platform, such numbers are GSI and should be > > > > converted > > > > to irq vector. > > > > > > > > Below patch against kernel 2.6.20 fixes it. > > > > > > These direct arch ifdefs in core aren't acceptable. > > > > For 2.6.21 that's true. But this is a suitable fix for 2.6.20.x, no? > > Just putting in an #ifndef and allow to to set it up in asm/ata.h > is almost as trivial and a lot nice conceptually. Well if that's what the 2.6.21 solution looks like then OK. Would want to see the patch though. > Then again > what happened to the idea of putting fixes into mainline before > -stable? If the preferred mainline patch involves a lot of not-really-needed restructuring then an alternative short-but-obvious fix for -stable is sometimes more appropriate. - 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.20-mm2
On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
> On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> >
> > Temporarily at
> >
> > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> >
> > Will appear later at
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
>
> Two problems:
>
> 1) A showstopper with the root partition on RAID1:
>
> md: raid1 personality registered for level 1
> [--snip--]
> md: multipath personality registered for level -4
> register_blkdev: failed to get major for mdp
> [--snip--]
> VFS: Cannot open root device "md1" or unknown-block(0,0)
Someone else reported that against mainline. Can you please debug it a bit?
I'd suggested reverting the recent changes in there:
--- a/block/genhd.c~a
+++ a/block/genhd.c
@@ -61,14 +61,6 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
- /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
- if ((60 <= index && index <= 63) ||
- (120 <= index && index <= 127) ||
- (240 <= index && index <= 254))
- continue;
if (major_names[index] == NULL)
break;
}
_
but I don't see how they could cause this.
> At the moment I have no serial console attached to the box, so I had to
> rewrite
> the messages manually.
netconsole is good.
> 2) On HPC nx6325 I get the following 100% of the time during the resume from
> disk:
>
> BUG: at drivers/pci/pci.c:823 pcim_enable_device()
>
> Call Trace:
> [] pcim_enable_device+0x93/0xb3
> [] ata_pci_device_do_resume+0x21/0x5e
> [] sil_pci_device_resume+0x1c/0x51
> [] pci_device_resume+0x22/0x53
> [] resume_device+0xca/0x131
> [] dpm_resume+0x81/0xd3
> [] device_resume+0x30/0x45
> [] snapshot_ioctl+0x245/0x63e
> [] do_ioctl+0x5e/0x77
> [] vfs_ioctl+0x25c/0x279
> [] sys_ioctl+0x5f/0x82
> [] sys_write+0x47/0x70
> [] system_call+0x7e/0x83
>
> Nevertheless, the system seems to be fully functional after the resume.
>
> [I've been observing it since 2.6.20-git10 and have reported it for a couple
> of times, but apparently nobody cares. :-(]
This is a Tejun thing - apparently it's due to swsusp calling suspend once
and resume twice (or is it vice versa). He'll be looking into it soon.
-
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.20-mm2
On Mon, 19 Feb 2007 00:25:48 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > netconsole is good. > > I know. :-) > > In the meantime, I've got something worse on another x86_64 box: > > Asus Laptop ACPI Extras version 0.30 > L5D model detected, supported > audit(1171831698.918:2): audit_pid=4281 old=0 by auid=4294967295 > general protection fault: [2] PREEMPT > last sysfs file: /class/net/eth2/carrier > CPU 0 > Modules linked in: af_packet ipv6 snd_pcm_oss snd_mixer_oss snd_seq > snd_seq_device asus_acpi backlight button battery ac dm_mod pcmr > Pid: 178, comm: pdflush Not tainted 2.6.20-mm2 #1 > RIP: 0010:[] [] > __make_request+0x134/0x370 > RSP: :81005ed659a0 EFLAGS: 00010297 > RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0203396a > RDX: 0001 RSI: 810037b4dbb0 RDI: 81004683d8c0 > RBP: 81005ed659f0 R08: 81004683d070 R09: 81003d333cc0 > R10: R11: R12: 810037b4dbb0 > R13: 81005daba3f0 R14: 810037daca90 R15: 81005daba3d0 > FS: 2ad4a29e6d00() GS:805db000() knlGS: > CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b > CR2: 2b6a345aa000 CR3: 56585000 CR4: 06e0 > Process pdflush (pid: 178, threadinfo 81005ed64000, task 810037b060c0) > Stack: 810002852540 0001 810037b4dbb0 8026be21 > 81005ed65a40 0008 810037b4dbb0 0800 > 0008 8100021d94e0 81005ed65a40 80348e7c > Call Trace: > [] mempool_alloc_slab+0x11/0x20 > [] generic_make_request+0x1ec/0x230 yeah. everyone except me is hitting that. - 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.20-mm2
On Tue, 20 Feb 2007 02:20:21 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
wrote:
> On Sunday, 18 February 2007 20:43, Andrew Morton wrote:
> > On Sun, 18 Feb 2007 13:44:54 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Sunday, 18 February 2007 06:51, Andrew Morton wrote:
> > > >
> > > > Temporarily at
> > > >
> > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/
> > > >
> > > > Will appear later at
> > > >
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/
> > >
> > > Two problems:
> > >
> > > 1) A showstopper with the root partition on RAID1:
> > >
> > > md: raid1 personality registered for level 1
> > > [--snip--]
> > > md: multipath personality registered for level -4
> > > register_blkdev: failed to get major for mdp
> > > [--snip--]
> > > VFS: Cannot open root device "md1" or unknown-block(0,0)
> >
> > Someone else reported that against mainline. Can you please debug it a bit?
>
> For now I can only say 2.6.20 + origin.patch breaks.
>
> However, it's a SUSE 10.1 system with gcc 4.1.0 and this may be the reason.
> I'll check that tomorrow.
Yes, Rolf says this goes away when you stop using gcc-4.1.0.
I'm hoping that churning the code around like below makes things work
right.
From: Andrew Morton <[EMAIL PROTECTED]>
Several people have reported failures in dynamic major device number handling
due to the recent changes in there to avoid handing out the local/experimental
majors.
Rolf reports that this is due to a gcc-4.1.0 bug.
The patch refactors that code a lot in an attempt to provoke the compiler into
behaving.
Cc: Rolf Eike Beer <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
block/genhd.c |9 ++---
drivers/base/core.c| 14 ++
fs/char_dev.c |8 ++--
include/linux/kdev_t.h |1 +
4 files changed, 19 insertions(+), 13 deletions(-)
diff -puN block/genhd.c~rework-reserved-major-handling block/genhd.c
--- a/block/genhd.c~rework-reserved-major-handling
+++ a/block/genhd.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -61,13 +62,7 @@ int register_blkdev(unsigned int major,
/* temporary */
if (major == 0) {
for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
- /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
- if ((60 <= index && index <= 63) ||
- (120 <= index && index <= 127) ||
- (240 <= index && index <= 254))
+ if (is_lanana_major(index))
continue;
if (major_names[index] == NULL)
break;
diff -puN fs/char_dev.c~rework-reserved-major-handling fs/char_dev.c
--- a/fs/char_dev.c~rework-reserved-major-handling
+++ a/fs/char_dev.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
@@ -108,12 +109,7 @@ __register_chrdev_region(unsigned int ma
/* temporary */
if (major == 0) {
for (i = ARRAY_SIZE(chrdevs)-1; i > 0; i--) {
- /*
-* Disallow the LANANA-assigned LOCAL/EXPERIMENTAL
-* majors
-*/
- if ((60 <= i && i <= 63) || (120 <= i && i <= 127) ||
- (240 <= i && i <= 254))
+ if (is_lanana_major(i))
continue;
if (chrdevs[i] == NULL)
break;
diff -puN drivers/base/core.c~rework-reserved-major-handling drivers/base/core.c
--- a/drivers/base/core.c~rework-reserved-major-handling
+++ a/drivers/base/core.c
@@ -28,6 +28,20 @@ int (*platform_notify)(struct device * d
int (*platform_notify_remove)(struct device * dev) = NULL;
/*
+ * Detect the LANANA-assigned LOCAL/EXPERIMENTAL majors
+ */
+bool is_lanana_major(unsigned int major)
+{
+ if (major >= 60 && major <= 63)
+ return 1;
+ if (major >= 120 && major <= 127)
+ return 1;
+ if (major >= 240 && major <= 254)
+ return 1;
+ return 0;
+}
+
+/*
* sysfs bindings for devices.
*/
diff -puN include/linux/kdev_t.h~rework-reserved-major-handling
include/linux/kdev_t.h
--- a/include/linux/kdev_t.h~rework-reserved-major-handling
+++ a/include/linux/kdev_t.h
@@ -87,6 +87,7 @@ static inline unsigned sysv_minor(u32 de
return dev & 0x3;
}
+bool is_lanana_major(unsigned int major);
#else /* __KERNEL__ */
_
-
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: cd/dvd inaccessible in 2.6.24-rc2
On Sat, 10 Nov 2007 15:27:11 +1100 Will Trives <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> Motherboard: Gigabyte GA-P35-DS4 (rev. 1.1)
> Chipset: Intel P35 + ICH9R
> PATA port runs off JMicron controller
> CD/DVD Device: BENQ DW1640 16X
>
> I cannot access my dvd burner under 2.6.24-rc2, I have no problems under
> 2.6.23. Basically the drive is detected OK, everything looks ok but as
> soon as I go to use it errors like this occur:
>
>
> ata9.00: qc timeout (cmd 0xa0)
> ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata9.00: cmd a0/00:00:00:02:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 2
> in
> res 51/54:03:00:02:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
> ata9.00: status: { DRDY ERR }
> ata9: soft resetting link
> ata9.00: revalidation failed (errno=-2)
> ata9: failed to recover some devices, retrying in 5 secs
> ata9: soft resetting link
> ata9.00: qc timeout (cmd 0xa1)
> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> ata9.00: revalidation failed (errno=-5)
> ata9: failed to recover some devices, retrying in 5 secs
> ata9: soft resetting link
> ata9.00: qc timeout (cmd 0xa1)
> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> ata9.00: revalidation failed (errno=-5)
> ata9.00: disabled
> ata9: soft resetting link
> ata9: EH complete
>
> The drive is locked up after the first attempt to access it occurs, the
> tray cannot be ejected.
>
>
> dmesg output
>
> http://paste.ubuntu-nl.org/43948/
>
> kernel .config
>
> http://paste.ubuntu-nl.org/43944/
>
> lspci -vvv
>
> http://paste.ubuntu-nl.org/43950/
>
Thanks for letting us know.
Added linux-ide Cc.
Rafael, it looks like another regression.
-
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: cd/dvd inaccessible in 2.6.24-rc2
On Sat, 10 Nov 2007 23:05:53 + Alan Cox <[EMAIL PROTECTED]> wrote:
> > > ata9.00: qc timeout (cmd 0xa0)
> > > ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > > ata9.00: cmd a0/00:00:00:02:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 2
> > > in
> > > res 51/54:03:00:02:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
> > > ata9.00: status: { DRDY ERR }
>
> Could be an IRQ/ACPI regression, and in fact to me it looks more like
> that, than an IDE one.
Drat. Seems that once we break that sort of thing we never fix it again.
> Probably worth trying the various IRQ routing
> options and seeing if they help.
Yup.
Please, if you have time, bisect it down to the offending commit?
There's info at http://www.kernel.org/doc/local/git-quick.html which should
help.
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: [BUG] New Kernel Bugs
On Mon, 12 Nov 2007 22:42:32 -0800 "Natalie Protasevich" <[EMAIL PROTECTED]> wrote: > This is the listing of the open bugs that are relatively new, around > 2.6.22 and up. They are vaguely classified by specific area. > (not a full list, there are more :) > > The good part is that reporters of the bugs below are still around and > haven't dissipated, or disposed of their hardware, so it is a good > time to get the bugs. > Those bugzillas that have been started as regressions on Rafael's list > are not mentioned here so far, since they are being tracked as new > regressions already. Thanks. > It would be appreciated if the corresponding maintenance team could take a > look, close off any which are fixed and see if they can fix any which aren't. > > NOTE: when replying to this email, please add the bug number to the Subject in > the form [Bug 1234] so that bugzilla will capture the discussion. > Thanks. You're optimistic. > ACPI > > System does not load without acpi=off ide=nodma noapic > http://bugzilla.kernel.org/show_bug.cgi?id=9358 > Kernel: 2.6.23.1 One response from a developer > ACPI Error attaching device data > http://bugzilla.kernel.org/show_bug.cgi?id=9354 > Kernel: 2.6.24-rc2 Zero responses from developers > /proc/acpi/battery displays Incorrect voltages > http://bugzilla.kernel.org/show_bug.cgi?id=9341 > Kernel: 2.6.23.1 Zero responses from developers > PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is beyond end of object > http://bugzilla.kernel.org/show_bug.cgi?id=9320 > Kernel: 2.6.24-rc2 > (Tejun: calling _GTF without calling _STM first. _GTM doesn't have any > prerequisite (it can't). Can someone familiar with ACPI tell me why the > method > is failing? At any rate, libata should work fine regardless of ACPI failures. > Maybe it's time to start blacklist to skip ATA-ACPI for some boards to avoid > those annoying messages during boot) Tejun doing stuff > ACPI Battery Info in /sys but not /proc/acpi > http://bugzilla.kernel.org/show_bug.cgi?id=9183 > Kernel: 2.6.23-rc8-mm2 Marked as a duplicate of an already-resolved bug. > > When using ACPI on a Compaq Presario V6221EU the laptop goes into > deadlock after a random amount of time > http://bugzilla.kernel.org/show_bug.cgi?id=9118 > Kernel: 2.6.23-rc6 Someone called Jike Song is trying to help out. Regular developers awol. > > ACPI video driver should validate brightness level before setting it via _BCM > http://bugzilla.kernel.org/show_bug.cgi?id=9277 > Kernel: 2.6.23 Zero responses from developers > VIDEO/DVB > > dvb driver reboot system > http://bugzilla.kernel.org/show_bug.cgi?id=9357 > Kernel: 2.6.21.5 Mauro thinks it might be bad hardware > > PLATFORM=== > > xipImage is built so that uBoot cant run it (ARM) > http://bugzilla.kernel.org/show_bug.cgi?id=9356 > Kernel: 2.6.21 Zero responses from developers > > Samsung R20 - ACPI: PCI Root Bridge [PCI0] (:00) > http://bugzilla.kernel.org/show_bug.cgi?id=9339 > Kernel: 2.6.24 > (boot is very long > ..MP-BIOS bug: 8254 timer not connected to IO-APIC > then the boot stop at : > ACPI: PCI Root Bridge [PCI0] (:00) > (during 3 minutes, and boot continue) No response from developers > system_64.h: switch_to inline asm should be more robbust wrt optimizations > http://bugzilla.kernel.org/show_bug.cgi?id=9302 > Kernel: 2.6.24-rc1 Not really a bug. > with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't > boot (ARM, Timer) > http://bugzilla.kernel.org/show_bug.cgi?id=9229 > Kernel: 2.6.23 No response from developers > NETWORKING=== > > RTNLGRP_ND_USEROPT does not report ifindex (IPv6) > http://bugzilla.kernel.org/show_bug.cgi?id=9349 > Kernel: 2.6.24+ No response from developers > a kernel error happend in the func: __skb_dequeue when using in > pfifo_fast_dequeue > http://bugzilla.kernel.org/show_bug.cgi?id=9342 > Kernel: 2.6.11.1 - reporter asked to try recent kernel No response from developers > e100 does not work after boot > http://bugzilla.kernel.org/show_bug.cgi?id=9336 > Kernel: 2.6.23.1 No response from developers > 2.6.23.1-smp kernel panic (network-related) > http://bugzilla.kernel.org/show_bug.cgi?id=9318 > Kernel: 2.6.23.1 > Infiniband panic No response from developers > sundance -> 4port D-Link System Inc DFE-580TX -> Log errors > http://bugzilla.kernel.org/show_bug.cgi?id=9311 > Kernel: 2.6.22.9 No response from developers > via-rhine driver stalls with: PHY status 786d, resetting... > http://bugzilla.kernel.org/show_bug.cgi?id=9300 > Kernel: 2.6.23+ No response from developers > > Weird network problems with 2.6.23-rc2 > http://bugzilla.kernel.org/show_bug.cgi?id=9080 > http://lkml.org/lkml/2007/8/11/40 - description No response from developers > rt2500pci: low TCP throughput (wireless) > http://bugzilla.kernel.org/
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 03:39:46 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Tue, 13 Nov 2007 03:15:53 -0800 > > > > NETWORKING=== > > > > > > RTNLGRP_ND_USEROPT does not report ifindex (IPv6) > > > http://bugzilla.kernel.org/show_bug.cgi?id=9349 > > > Kernel: 2.6.24+ > > > > No response from developers > > That's funny, then how come there was a proper patch fix posted > and it's now in my tree ready to go to Linus? > > I think you like just saying "No response from developers" over and > over again to make some of point about how developers are ignoring > lots of bugs. That's fine, but at least be accurate about it :-) Do you believe that our response to bug reports is adequate? - 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: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 03:58:24 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Tue, 13 Nov 2007 03:49:16 -0800 > > > Do you believe that our response to bug reports is adequate? > > Do you feel that making us feel and look like shit helps? > That doesn't answer my question. See, first we need to work out whether we have a problem. If we do this, then we can then have a think about what to do about it. I tried to convince the 2006 KS attendees that we have a problem and I resoundingly failed. People seemed to think that we're doing OK. But it appears that data such as this contradicts that belief. This is not a minor matter. If the kernel _is_ slowly deteriorating then this won't become readily apparent until it has been happening for a number of years. By that stage there will be so much work to do to get us back to an acceptable level that it will take a huge effort. And it will take a long time after that for the kerel to get its reputation back. So it is important that we catch deterioration *early* if it is happening. - 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: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 04:32:07 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Tue, 13 Nov 2007 04:12:59 -0800 > > > On Tue, 13 Nov 2007 03:58:24 -0800 (PST) David Miller <[EMAIL PROTECTED]> > > wrote: > > > > > From: Andrew Morton <[EMAIL PROTECTED]> > > > Date: Tue, 13 Nov 2007 03:49:16 -0800 > > > > > > > Do you believe that our response to bug reports is adequate? > > > > > > Do you feel that making us feel and look like shit helps? > > > > That doesn't answer my question. > > > > See, first we need to work out whether we have a problem. If we do this, > > then we can then have a think about what to do about it. > > > > I tried to convince the 2006 KS attendees that we have a problem and I > > resoundingly failed. People seemed to think that we're doing OK. > > > > But it appears that data such as this contradicts that belief. > > > > This is not a minor matter. If the kernel _is_ slowly deteriorating then > > this won't become readily apparent until it has been happening for a number > > of years. By that stage there will be so much work to do to get us back to > > an acceptable level that it will take a huge effort. And it will take a > > long time after that for the kerel to get its reputation back. > > > > So it is important that we catch deterioration *early* if it is happening. > > You tell me what I should spend my time working on, and I promise to > do it OK? :-) My suggestion: regressions. If we're really active in chasing down the regressions then I think we can be confident that the kernel isn't deteriorating. Probably it will be improving as we also fix some always-been-there bugs. I think that we're fairly good about working the regressions in Adrian/Michal/Rafael's lists but once Linus releases 2.6.x we tend to let the unsolved ones slide, and we don't pay as much attention to the regressions which 2.6.x testers report. > For example, if I have a choice between a TCP crash just about anyone > can hit and some obscure issue only reported with some device nearly > nobody has, which one should I analyze and work on? > > That's the problem. All of us prioritize and it means the chaff > collects at the bottom. You cannot fix that except by getting more > bug fixers so that the chaff pile has a chance to get smaller. > > Luckily if the report being ignored isn't chaff, it will show up again > (and again and again) and this triggers a reprioritization because not > only is the bug no longer chaff, it also now got a lot of information > tagged to it so it's a double worthwhile investment to work on the > problem. > > I think a lot of bugs that "aren't getting looked at" are simply > sitting in some early stage of this process. Yes, that's a useful technique. If multiple people are being hurt a lot by a bug then that's a more important one to fix than the single-person minor-irritant bug. otoh that doesn't work very well with driver/platform bugs. Often these are regressions which only a single person can reproduce within the time window which we have in which we can fix it. If we don't fix it in that window it'll go out to distros and presumably some more people will hit it. So I don't see much alternative here to the traditional work-with-the-originator way of resolving it. git bisection should really help us with these regressions but it doesn't appear that people are using as much as one would like. I'm hoping that the very good http://www.kernel.org/doc/local/git-quick.html will help us out here. Thanks to the mystery person who prepared that. - 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: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 19:32:19 + Russell King <[EMAIL PROTECTED]> wrote: > There's another issue I want to raise concerning bugzilla. We have the > classic case of "not enough people reading bugzilla bugs" - which is one > of the biggest problems with bugzilla. Virtually no one in the ARM > community looks for ARM bugs in bugzilla. Nor should they. > Let's not forget that it would be a waste of time for people to manually > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > into bugzilla that a weekly manual check by every maintainer would just > return the same old boring results for months and months at a time. I screen all bugzilla reports. 100% of them. - I'll try to establish whether it is a regression - I'll solicit any extra information which I believe the reveloper will need - I'll ensure that an appropriate developer has seen the report And yes, the number of arm-specific reports in there is very small. > It would be far more productive if the ARM category was deleted from > bugzilla and the few people who use bugzilla reported their bugs on the > mailing list. We've a couple of thousand people on the ARM kernel > mailing list at the moment - that's 3 orders of magnitude more of eyes > than look at bugzilla. Is that [EMAIL PROTECTED] If so, MANITAINERS claims that it is subscribers-only. That would cause some bug reporters to give up and go away. - 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: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 22:33:58 +0100 Jörn Engel <[EMAIL PROTECTED]> wrote: > On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote: > > > > I just find it weird that something can be known broken for several -rc* > > kernels before I happen to install it, discover it's broken on my own > > machine, > > and then I track it down, fix it, and submit the patch, generally all > > within a > > couple of hours. Where the heck was the dude(ess) that broke it ?? AWOL. > > > > And when I receive hostility from the "maintainers" of said code for fixing > > their bugs, well.. that really motivates me to continue reporting new ones.. > > Given a decent bug report, I agree that having the bug not looked at is > shameful. But what can a developer do if a bug report effectively reads > "there is some bug somewhere in recent kernels"? How can I know that in > this particular case it is my bug that I introduced? It could just as > easily be 50 other people and none of them are eager to debug it unless > they suspect it to be their bug. It's relatively common that a regression in subsystem A will manifest as a failure in subsystem B, and the report initially lands on the desk of the subsystem B developers. But that's OK. The subsystem B people are the ones with the expertise to be able to work out where the bug resides and to help the subsystem A people understand what went wrong. Alas, sometimes the B people will just roll eyes and do nothing because they know the problem wasn't in their code. Sometimes. - 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: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 22:18:01 + Russell King <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote: > > On Tue, 13 Nov 2007 19:32:19 + Russell King <[EMAIL PROTECTED]> wrote: > > > There's another issue I want to raise concerning bugzilla. We have the > > > classic case of "not enough people reading bugzilla bugs" - which is one > > > of the biggest problems with bugzilla. Virtually no one in the ARM > > > community looks for ARM bugs in bugzilla. > > > > Nor should they. > > So what you're saying is... > > > > Let's not forget that it would be a waste of time for people to manually > > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > > into bugzilla that a weekly manual check by every maintainer would just > > > return the same old boring results for months and months at a time. > > > > I screen all bugzilla reports. 100% of them. > > > > - I'll try to establish whether it is a regression > > > > - I'll solicit any extra information which I believe the reveloper will need > > > > - I'll ensure that an appropriate developer has seen the report > > > > And yes, the number of arm-specific reports in there is very small. > > that just because you do this everyone in a select clique, who you include > me in, should be doing this as well. > > No. Thank. You. No, I don't mean that at all and this was very plainly obviously from my very clearly written email. Let me try again. No, no subsystem developer needs to monitor new bugzilla reports. This is because *I do it for them*. I will actively make them aware of new reports which I believe are legitimate and which contain sufficient information for them to be able to take further action. > > > It would be far more productive if the ARM category was deleted from > > > bugzilla and the few people who use bugzilla reported their bugs on the > > > mailing list. We've a couple of thousand people on the ARM kernel > > > mailing list at the moment - that's 3 orders of magnitude more of eyes > > > than look at bugzilla. > > > > Is that [EMAIL PROTECTED] > > Yes. > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > some bug reporters to give up and go away. > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > non-subscribers only mailing list. Period. Not negotiable, so don't even > try to change my mind. Making a list subscribers-only will cause some bug reports to be lost. Tradeoffs are involved, against which decisions must be made. You have made yours. - 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: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 23:24:14 +0100 Jörn Engel <[EMAIL PROTECTED]> wrote: > On Tue, 13 November 2007 13:56:58 -0800, Andrew Morton wrote: > > > > It's relatively common that a regression in subsystem A will manifest as a > > failure in subsystem B, and the report initially lands on the desk of the > > subsystem B developers. > > > > But that's OK. The subsystem B people are the ones with the expertise to > > be able to work out where the bug resides and to help the subsystem A > > people understand what went wrong. > > > > Alas, sometimes the B people will just roll eyes and do nothing because > > they know the problem wasn't in their code. Sometimes. > > And sometimes the A people will ignore the B people after the root cause > has been worked out. Do you have a good idea how to shame A into > action? Should I put you on Cc:? Right now I'm in the eye-rolling > phase. > Well, that's the problem, isn't it? The best I can come up with is to suggest that all the info be captured in a bugzilla report so that at least it doesn't get forgotten about. I suppose that other options are a) try to fix it yourself. I'll take the patch and as long as we make a big enough mess of it, someone who knows what they're doing might fix it for real. b) If it was a regression, identify the offending commit and we'll just revert it. - 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: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 23:09:37 + Russell King <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 02:32:01PM -0800, Andrew Morton wrote: > > On Tue, 13 Nov 2007 22:18:01 + Russell King <[EMAIL PROTECTED]> wrote: > > > On Tue, Nov 13, 2007 at 12:52:22PM -0800, Andrew Morton wrote: > > > > On Tue, 13 Nov 2007 19:32:19 + Russell King <[EMAIL PROTECTED]> > > > > wrote: > > No, I don't mean that at all and this was very plainly obviously from my > > very > > clearly written email. Let me try again. > > If you screen all bugzilla reports then you'll know that bug #9356 arrived > at about 1400 GMT yesterday. It's hardly surprising then that your utterly > crappy responses to Natalie's message (which, incidentally, wasn't copied > to me) sent within 24 hours of that report cause *great* annoyance. > > > No, no subsystem developer needs to monitor new bugzilla reports. This is > > because *I do it for them*. I will actively make them aware of new reports > > which I believe are legitimate and which contain sufficient information for > > them to be able to take further action. > > On the whole you do an excellent job with feeding the bug reports to > people, and while I recognise that you're only human, things do > occasionally go wrong. For instance, sending clearly marked Samsung > S3C bugs to me rather than Ben Dooks (who's in MAINTAINERS for those > platforms.) Well whatever, sorry. But this is in the noise floor. Point is: many bug reports aren't being attended to. > > > > > It would be far more productive if the ARM category was deleted from > > > > > bugzilla and the few people who use bugzilla reported their bugs on > > > > > the > > > > > mailing list. We've a couple of thousand people on the ARM kernel > > > > > mailing list at the moment - that's 3 orders of magnitude more of eyes > > > > > than look at bugzilla. > > > > > > > > Is that [EMAIL PROTECTED] > > > > > > Yes. > > > > > > > If so, MANITAINERS claims that it is subscribers-only. That would cause > > > > some bug reporters to give up and go away. > > > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > > try to change my mind. > > > > Making a list subscribers-only will cause some bug reports to be lost. > > > > Tradeoffs are involved, against which decisions must be made. You have > > made yours. > > So how are they lost when they're held in a moderation queue and are > either accepted, a useful response given to the original poster, or > are forwarded to someone who can deal with the issue. > > I don't think "subscribers only" describes my lists - we don't devnull > stuff just because the poster is not a subscriber. Oh, OK, as long as there really is a human paying attention to those things then that's fine. When one is on the sending end of these things one never knows how long it will take, not whether it will even happen. - 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: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 23:29:54 + Russell King <[EMAIL PROTECTED]> wrote: > On Tue, Nov 13, 2007 at 09:13:19PM +0100, Adrian Bunk wrote: > > On Tue, Nov 13, 2007 at 07:32:19PM +, Russell King wrote: > > >... > > > There's another issue I want to raise concerning bugzilla. We have the > > > classic case of "not enough people reading bugzilla bugs" - which is one > > > of the biggest problems with bugzilla. Virtually no one in the ARM > > > community looks for ARM bugs in bugzilla. > > > > > > Let's not forget that it would be a waste of time for people to manually > > > check bugzilla for ARM bugs. There's soo few people reporting ARM bugs > > > into bugzilla that a weekly manual check by every maintainer would just > > > return the same old boring results for months and months at a time. > > >... > > > > What about having all ARM bugs in Bugzilla by default assigned to > > [EMAIL PROTECTED] [1] > > That would also work, probably much better than setting up yet another > list. cpufreq (at least) does it this way. I don't know how well it is turning out in practice. It's useful if the initial report makes it clear (ie; to me) that the report has already gone to a mailing list so I don't go and forward a duplicate. But there are so few arm reports in bugzilla that this is all rather moot. > My experience of trying to get mbligh to do this when I stopped looking > after PCMCIA stuff was *extremely* painful. Wonder if it's become any > easier of late? He's a bad, bad man ;) But he's been turning these things around pretty rapidly lately. - 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 9373] New: PDC20267 exception Emask on I/O
On Tue, 13 Nov 2007 16:11:25 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9373
>
>Summary: PDC20267 exception Emask on I/O
>Product: IO/Storage
>Version: 2.5
> KernelVersion: 2.6.24-rc2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Serial ATA
> AssignedTo: [EMAIL PROTECTED]
> ReportedBy: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
>
>
> Most recent kernel where this bug did not occur:
Are you sure? Was the relevant driver not present in 2.6.23?
> when not using the libata drivers
>
> Distribution:
> gentoo
>
> Hardware Environment:
> 00:00.0 Host bridge: Intel Corporation 82850 850 (Tehama) Chipset Host Bridge
> (MCH) (rev 02)
> 00:01.0 PCI bridge: Intel Corporation 82850 850 (Tehama) Chipset AGP Bridge
> (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 02)
> 00:1f.0 ISA bridge: Intel Corporation 82801BA ISA Bridge (LPC) (rev 02)
> 00:1f.1 IDE interface: Intel Corporation 82801BA IDE U100 Controller (rev 02)
> 00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev
> 02)
> 00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus Controller (rev 02)
> 00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB Controller #1 (rev
> 02)
> 01:00.0 VGA compatible controller: nVidia Corporation NV5 [RIVA TNT2/TNT2 Pro]
> (rev 11)
> 02:06.0 Mass storage controller: Promise Technology, Inc. PDC20267
> (FastTrak100/Ultra100) (rev 02)
> 02:09.0 RAID bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid]
> Serial ATA Controller (rev 02)
> 02:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev
> 74)
>
> Software Environment:
> Portage 2.1.3.19 (default-linux/x86/2007.0/desktop, gcc-3.4.6, glibc-2.6.1-r0,
> 2.6.24-rc2 i686)
> =
> System uname: 2.6.24-rc2 i686 Intel(R) Pentium(R) 4 CPU 1500MHz
> Timestamp of tree: Tue, 13 Nov 2007 15:16:01 +
> distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
> [disabled]
> ccache version 2.4 [enabled]
> app-shells/bash: 3.2_p17
> dev-lang/python: 2.3.5-r3, 2.4.4-r6
> dev-python/pycrypto: 2.0.1-r6
> dev-util/ccache: 2.4-r7
> sys-apps/baselayout: 1.12.9-r2
> sys-apps/sandbox:1.2.18.1-r2
> sys-devel/autoconf: 2.13, 2.61-r1
> sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
> sys-devel/binutils: 2.18-r1
> sys-devel/gcc-config: 1.3.16
> sys-devel/libtool: 1.5.24
> virtual/os-headers: 2.6.22-r2
> ACCEPT_KEYWORDS="x86"
> CBUILD="i686-pc-linux-gnu"
> CFLAGS="-march=pentium4 -O2 -pipe -msse2 -mfpmath=sse -fomit-frame-pointer"
> CHOST="i686-pc-linux-gnu"
>
> Problem Description:
> The following occures when the drive has some I/O (realized it when
> transfering
> data via FTP [only 2-5 MB/s and stalles])
>
> [ 536.333484] ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> [ 536.333489] ata8.00: BMDMA stat 0x4
> [ 536.333498] ata8.00: cmd ca/00:18:c7:10:00/00:00:00:00:00/e0 tag 0 cdb 0x0
> data 12288 out
> [ 536.333501] res 51/84:00:de:10:00/00:00:00:00:00/e0 Emask 0x10
> (ATA
> bus error)
> [ 536.333506] ata8.00: status: { DRDY ERR }
> [ 536.333510] ata8.00: error: { ICRC ABRT }
> [ 536.333531] ata8: soft resetting link
>
> Steps to reproduce:
> 1) Boot
> 2) Copy some files (via NFS/FTP/scp/cp) from the drives to/from the
> PDC20267
>
> complete dmsg can be found here:
> http://phpfi.com/276055
> (dmsg buffer seems to be full is there a way to increase it?)
>
> here's the part taken from messages:
> http://phpfi.com/276059
>
-
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: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 17:11:36 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > On Tue, 13 Nov 2007 19:52:17 -0500 > Chuck Ebbert <[EMAIL PROTECTED]> wrote: > > > On 11/13/2007 04:12 PM, Alan Cox wrote: > > >> Bug fixing is not about finding someone to blame, it's about getting the > > >> bug fixed. > > > > > > Partly - its also about understanding why the bug occurred and making it > > > not happen again. > > > > Very few people think about that part. > > Why does the kernel have very few useful tests? Tests would of course be nice, but they aren't very useful(!) Looking at this list which Natalie has generated I see around thirty which are dependent on the right hardware and ten which are not. This ratio is typical, I think. In fact I'd say that more than 75% of reported bugs are dependent on hardware. So the best test of all for the kernel is "run it on a different machine". This is why we are so dependent upon our volunteer testers/reporters to be able to do kernel development. > Lack of interest? resources? expertise? > Ideally each new feature would just be a small add on to an existing test. Sure. For system-call-visible features it would be good to do that. But this tends not to be where bugs get exposed. Because the original developer can 100% exercise such code. That isn't the case with driver/arch/platform changes. > Unlike developing new features which seems to grow well with more developers. > Bug fixing also seems to be a scarcity process. There often seems to be > a very few people that understand the problem well enough or have the > necessary > hardware to reproduce and fix the problem. We're 100% dead if "having the hardware" is a prerequisite to fixing a bug. The terminal state there is that the kernel runs on about 200 machines worldwide. We have to work with reporters via email to fix these sorts of things. As we of course do. > Recent changes like tickless and scheduler rework were well thought out and > caused > very little impact to 90% of the users. The problem is the 10% who do have > problems. > Worse, the developers often only hear about the a small sample of those. Yes. An unknown number of people just shrug and go back to an old kernel. - 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: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007 17:55:51 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote: > I've created [EMAIL PROTECTED] Let me just say - I'm astonished at how little spam gets though the vger lists. Considering how many times those email addresses must have been added to spam databases. It must be a lot of work, and whoever is doing it does it well. I don't even know. Is it Matti? You? - 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 9393] New: SError: { DevExch } occuring and causing disruption
(switched to email - please reply via emailed reply-to-all, not via the
bugzilla web interface)
On Thu, 15 Nov 2007 22:39:41 -0800 (PST) [EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9393
>
>Summary: SError: { DevExch } occuring and causing disruption
>Product: IO/Storage
>Version: 2.5
> KernelVersion: v2.6.24-rc2-g6e800af2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Serial ATA
> AssignedTo: [EMAIL PROTECTED]
> ReportedBy: [EMAIL PROTECTED]
>
>
> Most recent kernel where this bug did not occur: v2.6.23
Rafael, one for the regression list please.
> Distribution: Gentoo
>
> Since running in the latest kernels I have been getting the following, but not
> often. When it happens the computer grinds to a complete halt. Cursor will
> move
> a small small amount every 20 seconds or so, making things pretty painful
> until
> they complete.
>
> v2.6.24-rc2-g6e800af2 was the first place I saw it, I didn't see it in
> v2.6.24-rc1, but I was only on it briefly due to unrelated issues.
>
> This hasn't completely been a problem too often, it happens once every day,
> maybe two even, and I would bisect it but this occurs so infrequently I'm sure
> I wouldn't get this bug report out until v2.6.24 :).
>
> Now that I'm looking over my dmesg I also notice:
> atl1 :03:00.0: tx busy
> which could also be the problem
>
> Any way I can help please let me know.
>
Yes, that's an ATA problem.
(there is dmesg output and a few other things at the bugzilla URL).
-
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 9410] New: TOSHIBA MK1637GSX do spurious command completion
On Mon, 19 Nov 2007 13:21:36 -0800 (PST)
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9410
>
>Summary: TOSHIBA MK1637GSX do spurious command completion
>Product: IO/Storage
>Version: 2.5
> KernelVersion: 2.6.24-rc2 GIT 8c0863403f109a43d7000b4646da4818220d501f
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Serial ATA
> AssignedTo: [EMAIL PROTECTED]
> ReportedBy: [EMAIL PROTECTED]
>
>
> Most recent kernel where this bug did not occur:
> Distribution: ALTLinux Sisyphus
> Hardware Environment: Dell Inspiron 1520 (see
> http://gentoo-wiki.com/HARDWARE_Dell_Inspiron_1520 for lspci and other
> details)
> Software Environment: i586 target build. src.rpm images with build config
> available on
> http://www.unsafe.ru/lakostis/RPMS/ALTLinux/kernel-2.6.24/SRPMS.hasher/kernel-image-wks-smp-2.6.24-alt0.4.src.rpm
> Problem Description:
>
> $ dmesg
>
> ata1.00: exception Emask 0x2 SAct 0x1 SErr 0x0 action 0x2 frozen
> ata1.00: spurious completions during NCQ issue=0x0 SAct=0x1
> FIS=004040a1:0020
> ata1.00: cmd 60/70:00:83:a6:f0/00:00:04:00:00/40 tag 0 cdb 0x0 data 57344 in
> res 40/00:34:c3:a7:f0/00:00:04:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> ata1.00: configured for UDMA/100
> ata1: EH complete
> sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
>
> information from smartctl:
> Device Model: TOSHIBA MK1637GSX
> Serial Number:77VBT1CRT
> Firmware Version: DL040D
> User Capacity:160,041,885,696 bytes
> Device is:Not in smartctl database [for details use: -P showall]
> ATA Version is: 7
> ATA Standard is: Exact ATA specification draft version not indicated
> Local Time is:Sun Nov 18 18:54:33 2007 MSK
> SMART support is: Available - device has SMART capability.
> SMART support is: Enabled
>
> Steps to reproduce:
>
> compile recent vanilla kernel from GIT with libata support and install
> following drive to NCQ capable SATA controller.
>
>
Thanks. Could you please send that backlisting patch via email to
Jeff Garzik <[EMAIL PROTECTED]>
linux-ide@vger.kernel.org
Andrew Morton <[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: 2.6.24-rc3-mm1: I/O error, system hangs
On Wed, 21 Nov 2007 22:45:22 +0100 Laurent Riffard <[EMAIL PROTECTED]> wrote: > Le 21.11.2007 05:45, Andrew Morton a écrit : > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc3/2.6.24-rc3-mm1/ > > Hello, > > My system hangs shortly after I logged in Gnome desktop. SysRq-W shows > that a bunch of task are blocked in "D" state, they seem to wait for > some I/O completion. I can try to hand-copy some data if requested. > > I found these messages in dmesg: > > ~$ grep -C2 end_request dmesg-2.6.24-rc3-mm1 > EXT3-fs: mounted filesystem with ordered data mode. > sd 0:0:0:0: [sda] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sda, sector 16460 > ReiserFS: sda7: found reiserfs format "3.6" with standard journal > ReiserFS: sda7: using ordered data mode > -- > ReiserFS: sda7: Using r5 hash to sort names > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sdb, sector 19632 > sd 0:0:1:0: [sdb] Result: hostbyte=DID_NO_CONNECT > driverbyte=DRIVER_OK,SUGGEST_OK > end_request: I/O error, dev sdb, sector 40037363 > Adding 1048568k swap on /dev/mapper/vglinux1-lvswap. Priority:-1 extents:1 > across:1048568k > lp0: using parport0 (interrupt-driven). > > These errors occur *only* with 2.6.24-rc3-mm1, they are 100% reproducible. > 2.6.24-rc3 and 2.6.24-rc2-mm1 are fine. > > Maybe something is broken in pata_via driver ? > Could be - libata-reimplement-ata_acpi_cbl_80wire-using-ata_acpi_gtm_xfermask.patch and pata_amd-pata_via-de-couple-programming-of-pio-mwdma-and-udma-timings.patch touch pata_via.c. - 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.24-rc2 displays incorrect DVD description
(cc linux-ide) On Tue, 13 Nov 2007 15:48:21 -0500 (EST) [EMAIL PROTECTED] wrote: > For example, 2.6.23.1: > > Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP PREEMPT > Fri Oct 26 13:09:09 CDT 2007 > kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive > kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, > UDMA(66) > > and > > 2.6.24-rc2: > > Linux version 2.6.24-rc2 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP > PREEMPT Fri Nov 9 20:41:37 CST 2007 > kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive > kernel: hdd: ATAPI 126X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, > UDMA(66) > > The drive seems to work correctly, reading and writing just fine. I just > happened to notice this and thought I'd pass it along. > > One other odd thing while looking through the logs, 2.6.23.1 has also > reported the drive as follows: > > Linux version 2.6.23.1 ([EMAIL PROTECTED]) (gcc version 4.2.2) #1 SMP PREEMPT > Fri Oct 26 13:09:09 CDT 2007 > kernel: hdd: HP DVD Writer 1040d, ATAPI CD/DVD-ROM drive > kernel: hdd: ATAPI 32X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, > UDMA(66) > > Any idea what is going on here? It's being reported as 48X, 126X, and 32X. > - 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: sata NCQ blacklist entry
On Tue, 13 Nov 2007 21:55:15 +0100 Jan-Simon M__ller <[EMAIL PROTECTED]> wrote:
> Hi!
You removed from cc the guys who are most likely to fix this. Please always
do reply-to-all.
> Just using kernel 2.6.24-rc2 (325d22df7b19e0116aff3391d3a03f73d0634ded).
>
> When booting the system hangs, using the emergency-sync a couple of times
> gets
> the system to go on at some point.
> Its always around starting X/Firewall (can't actually say whats done in this
> moment).
>
> Looking at dmesg i found this (NCQ disabled ...)
>
> dmesg output
>
> ata1.00: exception Emask 0x2 SAct 0x4 SErr 0x0 action 0x2 frozen
> ata1.00: spurious completions during NCQ issue=0x0 SAct=0x4
> FIS=004040a1:0002
> ata1.00: cmd 61/08:10:bc:b2:5d/00:00:08:00:00/40 tag 2 cdb 0x0 data 4096 out
> res 40/00:14:bc:b2:5d/00:00:08:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: configured for UDMA/133
> ata1: EH complete
> sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> ata1.00: NCQ disabled due to excessive errors
> ata1.00: exception Emask 0x2 SAct 0xfffd3 SErr 0x0 action 0x2 frozen
> ata1.00: spurious completions during NCQ issue=0x0 SAct=0xfffd3
> FIS=004040a1:0020
> ata1.00: cmd 60/10:00:14:05:69/00:00:06:00:00/40 tag 0 cdb 0x0 data 8192 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/08:08:cc:dd:12/00:00:04:00:00/40 tag 1 cdb 0x0 data 4096 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/18:20:84:54:a3/00:00:05:00:00/40 tag 4 cdb 0x0 data 12288 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/08:30:bc:b1:07/00:00:06:00:00/40 tag 6 cdb 0x0 data 4096 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/08:38:dc:b1:07/00:00:06:00:00/40 tag 7 cdb 0x0 data 4096 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/10:40:3c:b2:07/00:00:06:00:00/40 tag 8 cdb 0x0 data 8192 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/08:48:2c:cf:07/00:00:06:00:00/40 tag 9 cdb 0x0 data 4096 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/08:50:3c:cf:07/00:00:06:00:00/40 tag 10 cdb 0x0 data 4096 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/08:58:64:b4:12/00:00:04:00:00/40 tag 11 cdb 0x0 data 4096 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/28:60:6c:b4:12/00:00:04:00:00/40 tag 12 cdb 0x0 data 20480 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/f8:68:7c:e1:07/00:00:06:00:00/40 tag 13 cdb 0x0 data 126976 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/08:70:a4:04:69/00:00:06:00:00/40 tag 14 cdb 0x0 data 4096 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/18:78:b4:04:69/00:00:06:00:00/40 tag 15 cdb 0x0 data 12288 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/08:80:a4:5c:6a/00:00:06:00:00/40 tag 16 cdb 0x0 data 4096 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/20:88:2c:05:69/00:00:06:00:00/40 tag 17 cdb 0x0 data 16384 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/30:90:54:05:69/00:00:06:00:00/40 tag 18 cdb 0x0 data 24576 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1.00: cmd 60/08:98:94:05:69/00:00:06:00:00/40 tag 19 cdb 0x0 data 4096 in
> res 40/00:04:14:05:69/00:00:06:00:00/40 Emask 0x2 (HSM violation)
> ata1.00: status: { DRDY }
> ata1: soft resetting link
> ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> ata1.00: configured for UDMA/133
> ata1: EH complete
> sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
>
Re: [PATCH 2/2] ide-scsi: use print_hex_dump from
On Mon, 26 Nov 2007 15:16:13 +0800 Denis Cheng <[EMAIL PROTECTED]> wrote:
> these utilities implemented in lib/hexdump.c are more handy, please use this.
>
> ...
>
> --- a/drivers/scsi/ide-scsi.c
> +++ b/drivers/scsi/ide-scsi.c
> @@ -242,16 +242,6 @@ static void idescsi_output_buffers (ide_drive_t *drive,
> idescsi_pc_t *pc, unsign
> }
> }
>
> -static void hexdump(u8 *x, int len)
> -{
> - int i;
> -
> - printk("[ ");
> - for (i = 0; i < len; i++)
> - printk("%x ", x[i]);
> - printk("]\n");
> -}
> -
> static int idescsi_check_condition(ide_drive_t *drive, struct request
> *failed_command)
> {
> idescsi_scsi_t *scsi = drive_to_idescsi(drive);
> @@ -282,7 +272,7 @@ static int idescsi_check_condition(ide_drive_t *drive,
> struct request *failed_co
> pc->scsi_cmd = ((idescsi_pc_t *) failed_command->special)->scsi_cmd;
> if (test_bit(IDESCSI_LOG_CMD, &scsi->log)) {
> printk ("ide-scsi: %s: queue cmd = ", drive->name);
> - hexdump(pc->c, 6);
> + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_OFFSET, 16, 1,
> pc->c, 6, 1);
> }
> rq->rq_disk = scsi->disk;
> return ide_do_drive_cmd(drive, rq, ide_preempt);
> @@ -337,7 +327,7 @@ static int idescsi_end_request (ide_drive_t *drive, int
> uptodate, int nrsecs)
> idescsi_pc_t *opc = (idescsi_pc_t *) rq->buffer;
> if (log) {
> printk ("ide-scsi: %s: wrap up check %lu, rst = ",
> drive->name, opc->scsi_cmd->serial_number);
> - hexdump(pc->buffer,16);
> + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_OFFSET, 16,
> 1, pc->buffer, 16, 1);
> }
> memcpy((void *) opc->scsi_cmd->sense_buffer, pc->buffer,
> SCSI_SENSE_BUFFERSIZE);
> kfree(pc->buffer);
> @@ -816,10 +806,10 @@ static int idescsi_queue (struct scsi_cmnd *cmd,
>
> if (test_bit(IDESCSI_LOG_CMD, &scsi->log)) {
> printk ("ide-scsi: %s: que %lu, cmd = ", drive->name,
> cmd->serial_number);
> - hexdump(cmd->cmnd, cmd->cmd_len);
> + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_OFFSET, 16, 1,
> cmd->cmnd, cmd->cmd_len, 1);
> if (memcmp(pc->c, cmd->cmnd, cmd->cmd_len)) {
> printk ("ide-scsi: %s: que %lu, tsl = ", drive->name,
> cmd->serial_number);
> - hexdump(pc->c, 12);
> + print_hex_dump(KERN_DEBUG, "", DUMP_PREFIX_OFFSET, 16,
> 1, pc->c, 12, 1);
> }
> }
>
Would you believe that this patch (which removes code) actually increases
drivers/scsi/ide-scsi.o .text by 75 bytes?
I didn't look to see why - probably that huge arg count is hurting,
possibly some additional strings being emitted?
Either way, perhaps a simple little front-end to print_hex_dump() is called
for.
-
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.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error
On Wed, 28 Nov 2007 23:01:31 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote: > Reliably spams dmesg with end_request() horrors. This happens when git > starts checking out linux tree to fresh ext2 partition. Disk is several > month old and there were no prolems with, say, 2.6.24-rc3: > > [ 225.378426] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.378659] end_request: I/O error, dev sdb, sector 141295703 > [ 225.390133] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.391988] end_request: I/O error, dev sdb, sector 141295703 > [ 225.392463] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.392625] end_request: I/O error, dev sdb, sector 141295703 > [ 225.392999] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.393161] end_request: I/O error, dev sdb, sector 141295703 > [ 225.393571] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.393731] end_request: I/O error, dev sdb, sector 141295703 > [ 225.394382] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.394544] end_request: I/O error, dev sdb, sector 141295703 > [ 225.395247] sd 2:0:1:0: [sdb] Result: hostbyte=0x01 driverbyte=0x00 > [ 225.395412] end_request: I/O error, dev sdb, sector 141295703 > > CONFIG_ATA=y > # CONFIG_ATA_NONSTANDARD is not set > CONFIG_ATA_ACPI=y > CONFIG_SATA_AHCI=y > CONFIG_ATA_PIIX=y > CONFIG_PATA_JMICRON=y and > [ 35.229713] sd 2:0:1:0: [sdb] 976773168 512-byte hardware sectors (500108 > MB) So that's an OK sector number. > [0.00] Linux version 2.6.24-rc3-mm2 ([EMAIL PROTECTED]) (gcc version > 4.1.2 (Gentoo 4.1.2 p1.0.2)) #3 SMP PREEMPT Wed Nov 28 22:23:45 MSK 2007 > [0.00] Command line: root=/dev/sda2 [EMAIL PROTECTED]/eth0,[EMAIL > PROTECTED]/00:80:48:45:EC:73 ignore_loglevel > [0.00] BIOS-provided physical RAM map: > [0.00] BIOS-e820: - 0009fc00 (usable) > [0.00] BIOS-e820: 0009fc00 - 000a (reserved) > [0.00] BIOS-e820: 000e4000 - 0010 (reserved) > [0.00] BIOS-e820: 0010 - 7ff9 (usable) > [0.00] BIOS-e820: 7ff9 - 7ff9e000 (ACPI data) > [0.00] BIOS-e820: 7ff9e000 - 7ffe (ACPI NVS) > [0.00] BIOS-e820: 7ffe - 8000 (reserved) > [0.00] BIOS-e820: fee0 - fee01000 (reserved) > [0.00] BIOS-e820: ffb0 - 0001 (reserved) > [0.00] BIOS-e820: 0001 - 00018000 (usable) > [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used > [0.00] Entering add_active_range(0, 256, 524176) 1 entries of 256 used > [0.00] Entering add_active_range(0, 1048576, 1572864) 2 entries of > 256 used > [0.00] end_pfn_map = 1572864 > [0.00] DMI 2.4 present. > [0.00] ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) > [0.00] ACPI: XSDT 7FF90100, 0054 (r1 KOZIRO FRONTIER 2000707 MSFT >97) > [0.00] ACPI: FACP 7FF90290, 00F4 (r3 MSTEST OEMFACP 2000707 MSFT >97) > [0.00] ACPI: DSDT 7FF905C0, 8FA9 (r1 A0637 A06370000 INTL > 20060113) > [0.00] ACPI: FACS 7FF9E000, 0040 > [0.00] ACPI: APIC 7FF90390, 006C (r1 MSTEST OEMAPIC 2000707 MSFT >97) > [0.00] ACPI: MCFG 7FF90400, 003C (r1 MSTEST OEMMCFG 2000707 MSFT >97) > [0.00] ACPI: SLIC 7FF90440, 0176 (r1 KOZIRO FRONTIER 2000707 MSFT >97) > [0.00] ACPI: OEMB 7FF9E040, 007B (r1 MSTEST AMI_OEM 2000707 MSFT >97) > [0.00] ACPI: HPET 7FF99570, 0038 (r1 MSTEST OEMHPET 2000707 MSFT >97) > [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used > [0.00] Entering add_active_range(0, 256, 524176) 1 entries of 256 used > [0.00] Entering add_active_range(0, 1048576, 1572864) 2 entries of > 256 used > [0.00] [e200-e21f] PMD ->81000120 on > node 0 > [0.00] [e220-e23f] PMD ->81000160 on > node 0 > [0.00] [e240-e25f] PMD ->810001A0 on > node 0 > [0.00] [e260-e27f] PMD ->810001E0 on > node 0 > [0.00] [e280-e29f] PMD ->81000220 on > node 0 > [0.00] [e2a0-e2bf] PMD ->81000260 on > node 0 > [0.00] [e2c0-e2df] PMD ->810002A0 on > node 0 > [0.00] [e2e0-e2ff] PMD ->810002E0 on > node 0 > [0.00] [e2000100-e200011f] PMD ->81000320 on > node 0 > [0.00] [e2000120-e200013f] PMD ->81000360 on > node 0 > [0.00] [e2000140-e200015f] PMD ->810003A0 on > node 0 > [
Re: 2.6.24-rc3-mm2: Result: hostbyte=0x01 driverbyte=0x00\nend_request: I/O error
On Wed, 28 Nov 2007 16:14:21 -0700
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 28, 2007 at 01:40:36PM -0800, Andrew Morton wrote:
> > On Wed, 28 Nov 2007 23:01:31 +0300
> > Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> >
> > > Reliably spams dmesg with end_request() horrors. This happens when git
> > > starts checking out linux tree to fresh ext2 partition. Disk is several
> > > month old and there were no prolems with, say, 2.6.24-rc3:
>
> Could you try reverting 6f5391c283d7fdcf24bf40786ea79061919d1e1d and see
> if the problem still exists?
>
That's not completely trivial..
I did a hand-made revert against 2.6.24-rc3-mm2 (below) but some other patch
in there causes:
drivers/scsi/scsi_lib.c: In function 'scsi_blk_pc_done':
drivers/scsi/scsi_lib.c:1251: error: 'struct scsi_cmnd' has no member named
'request_bufflen'
--- a/drivers/scsi/scsi.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
+++ a/drivers/scsi/scsi.c
@@ -59,7 +59,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -379,8 +378,9 @@ void scsi_log_send(struct scsi_cmnd *cmd
scsi_print_command(cmd);
if (level > 3) {
printk(KERN_INFO "buffer = 0x%p, bufflen = %d,"
- " queuecommand 0x%p\n",
+ " done = 0x%p, queuecommand 0x%p\n",
scsi_sglist(cmd), scsi_bufflen(cmd),
+ cmd->done,
cmd->device->host->hostt->queuecommand);
}
@@ -667,12 +667,6 @@ void __scsi_done(struct scsi_cmnd *cmd)
blk_complete_request(rq);
}
-/* Move this to a header if it becomes more generally useful */
-static struct scsi_driver *scsi_cmd_to_driver(struct scsi_cmnd *cmd)
-{
- return *(struct scsi_driver **)cmd->request->rq_disk->private_data;
-}
-
/**
* scsi_finish_command - cleanup and pass command back to upper layer
* @cmd: the command
@@ -685,8 +679,6 @@ void scsi_finish_command(struct scsi_cmn
{
struct scsi_device *sdev = cmd->device;
struct Scsi_Host *shost = sdev->host;
- struct scsi_driver *drv;
- unsigned int good_bytes;
scsi_device_unbusy(sdev);
@@ -712,13 +704,7 @@ void scsi_finish_command(struct scsi_cmn
"Notifying upper driver of completion "
"(result %x)\n", cmd->result));
- good_bytes = scsi_bufflen(cmd);
-if (cmd->request->cmd_type != REQ_TYPE_BLOCK_PC) {
- drv = scsi_cmd_to_driver(cmd);
- if (drv->done)
- good_bytes = drv->done(cmd);
- }
- scsi_io_completion(cmd, good_bytes);
+ cmd->done(cmd);
}
EXPORT_SYMBOL(scsi_finish_command);
diff -puN
drivers/scsi/scsi_error.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
drivers/scsi/scsi_error.c
--- a/drivers/scsi/scsi_error.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
+++ a/drivers/scsi/scsi_error.c
@@ -1697,6 +1697,7 @@ scsi_reset_provider(struct scsi_device *
scmd->scsi_done = scsi_reset_provider_done_command;
memset(&scmd->sdb, 0, sizeof(scmd->sdb));
+ scmd->done = NULL;
scmd->cmd_len = 0;
diff -puN
drivers/scsi/scsi_lib.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c~revert-6f5391c283d7fdcf24bf40786ea79061919d1e1d
+++ a/drivers/scsi/scsi_lib.c
@@ -944,6 +944,7 @@ void scsi_end_bidi_request(struct scsi_c
scsi_finalize_request(cmd, 1);
}
+EXPORT_SYMBOL(scsi_io_completion);
/*
* Function:scsi_io_completion()
@@ -1238,6 +1239,18 @@ static struct scsi_cmnd *scsi_get_cmd_fr
return cmd;
}
+static void scsi_blk_pc_done(struct scsi_cmnd *cmd)
+{
+ BUG_ON(!blk_pc_request(cmd->request));
+ /*
+* This will complete the whole command with uptodate=1 so
+* as far as the block layer is concerned the command completed
+* successfully. Since this is a REQ_BLOCK_PC command the
+* caller should check the request's errors value
+*/
+ scsi_io_completion(cmd, cmd->request_bufflen);
+}
+
int scsi_setup_blk_pc_cmnd(struct scsi_device *sdev, struct request *req)
{
struct scsi_cmnd *cmd;
@@ -1285,6 +1298,7 @@ int scsi_setup_blk_pc_cmnd(struct scsi_d
cmd->transfersize = req->data_len;
cmd->allowed = req->retries;
cmd->timeout_per_command = req->timeout;
+ cmd->done = scsi_blk_pc_done;
return BLKPREP_OK;
}
EXPORT_SYMBOL(scsi_setup_blk
Re: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)
On Sat, 1 Dec 2007 06:26:08 -0500 (EST) Justin Piszcz <[EMAIL PROTECTED]> wrote: > I am putting a new machine together and I have dual raptor raid 1 for the > root, which works just fine under all stress tests. > > Then I have the WD 750 GiB drive (not RE2, desktop ones for ~150-160 on > sale now adays): > > I ran the following: > > dd if=/dev/zero of=/dev/sdc > dd if=/dev/zero of=/dev/sdd > dd if=/dev/zero of=/dev/sde > > (as it is always a very good idea to do this with any new disk) > > And sometime along the way(?) (i had gone to sleep and let it run), this > occurred: > > [42880.680144] ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x401 > action 0x2 frozen Gee we're seeing a lot of these lately. > [42880.680231] ata3.00: irq_stat 0x00400040, connection status changed > [42880.680290] ata3.00: cmd ec/00:00:00:00:00/00:00:00:00:00/00 tag 0 cdb > 0x0 data 512 in > [42880.680292] res 40/00:ac:d8:64:54/00:00:57:00:00/40 Emask 0x10 > (ATA bus error) > [42881.841899] ata3: soft resetting port > [42885.966320] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [42915.919042] ata3.00: qc timeout (cmd 0xec) > [42915.919094] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5) > [42915.919149] ata3.00: revalidation failed (errno=-5) > [42915.919206] ata3: failed to recover some devices, retrying in 5 secs > [42920.912458] ata3: hard resetting port > [42926.411363] ata3: port is slow to respond, please be patient (Status > 0x80) > [42930.943080] ata3: COMRESET failed (errno=-16) > [42930.943130] ata3: hard resetting port > [42931.399628] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [42931.413523] ata3.00: configured for UDMA/133 > [42931.413586] ata3: EH pending after completion, repeating EH (cnt=4) > [42931.413655] ata3: EH complete > [42931.413719] sd 2:0:0:0: [sdc] 1465149168 512-byte hardware sectors > (750156 MB) > [42931.413809] sd 2:0:0:0: [sdc] Write Protect is off > [42931.413856] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 > [42931.413867] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > > Usually when I see this sort of thing with another box I have full of > raptors, it was due to a bad raptor and I never saw it again after I > replaced the disk that it happened on, but that was using the Intel P965 > chipset. > > For this board, it is a Gigabyte GSP-P35-DS4 (Rev 2.0) and I have all of > the drives (2 raptors, 3 750s connected to the Intel ICH9 Southbridge). > > I am going to do some further testing but does this indicate a bad drive? > Bad cable? Bad connector? > > As you can see above, /dev/sdc stopped responding for a little bit and > then the kernel reset the port. > > Why is this though? What is the likely root cause? Should I replace the > drive? Obviously this is not normal and cannot be good at all, the idea > is to put these drives in a RAID5 and if one is going to timeout that is > going to cause the array to go degraded and thus be worthless in a raid5 > configuration. > > Can anyone offer any insight here? It would be interesting to try 2.6.21 or 2.6.22. - 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: Kernel 2.6.23.9 / P35 Chipset + WD 750GB Drives (reset port)
On Thu, 6 Dec 2007 17:38:08 -0500 (EST) Justin Piszcz <[EMAIL PROTECTED]> wrote: > > > On Thu, 6 Dec 2007, Andrew Morton wrote: > > > On Sat, 1 Dec 2007 06:26:08 -0500 (EST) > > Justin Piszcz <[EMAIL PROTECTED]> wrote: > > > >> I am putting a new machine together and I have dual raptor raid 1 for the > >> root, which works just fine under all stress tests. > >> > >> Then I have the WD 750 GiB drive (not RE2, desktop ones for ~150-160 on > >> sale now adays): > >> > >> I ran the following: > >> > >> dd if=/dev/zero of=/dev/sdc > >> dd if=/dev/zero of=/dev/sdd > >> dd if=/dev/zero of=/dev/sde > >> > >> (as it is always a very good idea to do this with any new disk) > >> > >> And sometime along the way(?) (i had gone to sleep and let it run), this > >> occurred: > >> > >> [42880.680144] ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x401 > >> action 0x2 frozen > > > > Gee we're seeing a lot of these lately. > > > >> [42880.680231] ata3.00: irq_stat 0x00400040, connection status changed > >> [42880.680290] ata3.00: cmd ec/00:00:00:00:00/00:00:00:00:00/00 tag 0 cdb > >> 0x0 data 512 in > >> [42880.680292] res 40/00:ac:d8:64:54/00:00:57:00:00/40 Emask 0x10 > >> (ATA bus error) > >> [42881.841899] ata3: soft resetting port > >> [42885.966320] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > >> [42915.919042] ata3.00: qc timeout (cmd 0xec) > >> [42915.919094] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5) > >> [42915.919149] ata3.00: revalidation failed (errno=-5) > >> [42915.919206] ata3: failed to recover some devices, retrying in 5 secs > >> [42920.912458] ata3: hard resetting port > >> [42926.411363] ata3: port is slow to respond, please be patient (Status > >> 0x80) > >> [42930.943080] ata3: COMRESET failed (errno=-16) > >> [42930.943130] ata3: hard resetting port > >> [42931.399628] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > >> [42931.413523] ata3.00: configured for UDMA/133 > >> [42931.413586] ata3: EH pending after completion, repeating EH (cnt=4) > >> [42931.413655] ata3: EH complete > >> [42931.413719] sd 2:0:0:0: [sdc] 1465149168 512-byte hardware sectors > >> (750156 MB) > >> [42931.413809] sd 2:0:0:0: [sdc] Write Protect is off > >> [42931.413856] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 > >> [42931.413867] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: > >> enabled, doesn't support DPO or FUA > >> > >> Usually when I see this sort of thing with another box I have full of > >> raptors, it was due to a bad raptor and I never saw it again after I > >> replaced the disk that it happened on, but that was using the Intel P965 > >> chipset. > >> > >> For this board, it is a Gigabyte GSP-P35-DS4 (Rev 2.0) and I have all of > >> the drives (2 raptors, 3 750s connected to the Intel ICH9 Southbridge). > >> > >> I am going to do some further testing but does this indicate a bad drive? > >> Bad cable? Bad connector? > >> > >> As you can see above, /dev/sdc stopped responding for a little bit and > >> then the kernel reset the port. > >> > >> Why is this though? What is the likely root cause? Should I replace the > >> drive? Obviously this is not normal and cannot be good at all, the idea > >> is to put these drives in a RAID5 and if one is going to timeout that is > >> going to cause the array to go degraded and thus be worthless in a raid5 > >> configuration. > >> > >> Can anyone offer any insight here? > > > > It would be interesting to try 2.6.21 or 2.6.22. > > > > This was due to NCQ issues (disabling it fixed the problem). > I cannot locate any further email discussion on this topic. Disabling NCQ at either compile time or runtime is not a "fix" and further work should be done here to maek the kernel run acceptably on that hardware. - 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: Failure with SATA DVD-RW
On Thu, 6 Dec 2007 01:33:16 + (UTC) Parag Warudkar <[EMAIL PROTECTED]> wrote: > Tom Lanyon gmail.com> writes: > > > scsi4: ahci > > ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: limiting speed to UDMA/44 > > ata5: failed to recover some devices, retrying in 5 secs > > ata5: port is slow to respond, please be patient (Status 0x80) > > ata5: port failed to respond (30 secs, status 0x80) > > ata5: COMRESET failed (device not ready) > > ata5: hardreset failed, retrying in 5 secs > > ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: limiting speed to PIO0 > > ata5: failed to recover some devices, retrying in 5 secs > > ata5: port is slow to respond, please be patient (Status 0x80) > > ata5: port failed to respond (30 secs, status 0x80) > > ata5: COMRESET failed (device not ready) > > ata5: hardreset failed, retrying in 5 secs > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: disabled > > > Looks like it is trying to set transfer mode to UDMA/66 and failing. After > that it tried UDMA/44 and failed again. Next UDMA/66 again with unsurprising > result - failed. After that PIO0 which seems to cause some kind of trouble, > then it tries UDMA/66 again, and I am not stating the result again :) ! > > > Any ideas what to try to get it working under AHCI? > > > > I recall reading somewhere - the Pioneer drive needs UDMA/33 which it did not > try in your case - need to some how have it try UDMA/33 but I don't find a > boot parameter which will do that. So may be adding a quirk for this device > to > limit the xfer mode to 33 may work. > > What does your dmesg output for the drives look like when you run in IDE > compat mode? (Particularly the DMA for this drive?) > Please cc linux-ide on sata, pata and ide-related issues. If nothing happens within a few days please raise a report at bugzilla.kernel.org so we can ignore this in an organised fashion, 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: Failure with SATA DVD-RW
(argh, shit, resent. Please don't massage the cc list. Do reply-to-all) On Thu, 6 Dec 2007 01:33:16 + (UTC) Parag Warudkar <[EMAIL PROTECTED]> wrote: > Tom Lanyon gmail.com> writes: > > > scsi4: ahci > > ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: limiting speed to UDMA/44 > > ata5: failed to recover some devices, retrying in 5 secs > > ata5: port is slow to respond, please be patient (Status 0x80) > > ata5: port failed to respond (30 secs, status 0x80) > > ata5: COMRESET failed (device not ready) > > ata5: hardreset failed, retrying in 5 secs > > ata5: SATA link up at 1.5 Gbps (SStatus 113 SControl 300) > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: limiting speed to PIO0 > > ata5: failed to recover some devices, retrying in 5 secs > > ata5: port is slow to respond, please be patient (Status 0x80) > > ata5: port failed to respond (30 secs, status 0x80) > > ata5: COMRESET failed (device not ready) > > ata5: hardreset failed, retrying in 5 secs > > ata5.00: ATAPI, max UDMA/66 > > ata5.00: qc timeout (cmd 0xef) > > ata5.00: failed to set xfermode (err_mask=0x104) > > ata5.00: disabled > > > Looks like it is trying to set transfer mode to UDMA/66 and failing. After > that it tried UDMA/44 and failed again. Next UDMA/66 again with unsurprising > result - failed. After that PIO0 which seems to cause some kind of trouble, > then it tries UDMA/66 again, and I am not stating the result again :) ! > > > Any ideas what to try to get it working under AHCI? > > > > I recall reading somewhere - the Pioneer drive needs UDMA/33 which it did not > try in your case - need to some how have it try UDMA/33 but I don't find a > boot parameter which will do that. So may be adding a quirk for this device > to > limit the xfer mode to 33 may work. > > What does your dmesg output for the drives look like when you run in IDE > compat mode? (Particularly the DMA for this drive?) > Please cc linux-ide on sata, pata and ide-related issues. If nothing happens within a few days please raise a report at bugzilla.kernel.org so we can ignore this in an organised fashion, 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: 2.6.24-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007 11:12:57 +0100 Andreas Mohr <[EMAIL PROTECTED]> wrote: > Hi, > > On Sat, Dec 08, 2007 at 01:36:31AM -0800, Andrew Morton wrote: > > > Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is > > > beyond end of object > > > Submitter : Hans de Bruin <[EMAIL PROTECTED]> > > > References: http://bugzilla.kernel.org/show_bug.cgi?id=9320 > > > Handled-By: Robert Moore <[EMAIL PROTECTED]> > > > Tejun Heo <[EMAIL PROTECTED]> > > > Fu Michael <[EMAIL PROTECTED]> > > > Patch : > > > > > > > A number of other people are seeing the same thing and Tejun is putting in > > a blacklist of machines which cannot use libata+acpi. That patch is not > > yet in any git tree which I pull. > > > > AFACIT the machines kepe working OK - there's just some nasty dmesg spew. > > > > If any machines _are_ breaking then this could cause real problems and I'd > > prefer that we either go for a whitelist or arrange to detect the condition > > and fall back to non-acpi ata. > > Does this report now win me the lucky draw, pretty please? ;) nah, you have to cc the acpi guys to get a prize ;) Len&co, could you please take a look? Andreas, please do separately report that WOL problem too.. Our list just reached 30. > STD regression rc1 -> rc234, suspend fails completely, recovering is > pretty much useless since HDD is DEAD from this point on anyway. > Managed to capture -rc2 suspend logging via still-alive ssh session. > > 2.6.24-rc1 suspend/resume log, successful (well, a couple seconds delay, most > likely due to > well-recovered AML failure): > > swsusp: Marking nosave pages: 0009f000 - 0010 > swsusp: Basic memory bitmaps created > Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > Shrinking memory... done (0 pages freed) > Freed 0 kbytes in 0.02 seconds (0.00 MB/s) > Suspending console(s) > hub 4-0:1.0: hub_suspend > usb usb4: bus suspend > ehci_hcd :00:10.3: suspend root hub > hub 3-0:1.0: hub_suspend > usb usb3: bus suspend > usb usb3: suspend_rh > hub 2-0:1.0: hub_suspend > usb usb2: bus suspend > usb usb2: suspend_rh > hub 1-0:1.0: hub_suspend > usb usb1: bus suspend > usb usb1: suspend_rh > sd 0:0:0:0: [sda] Synchronizing SCSI cache > parport_pc 00:09: disabled > serial 00:08: disabled > serial 00:07: disabled > ACPI: PCI interrupt for device :00:11.5 disabled > ACPI handle has no context! > ACPI: PCI interrupt for device :00:11.1 disabled > ACPI: PCI interrupt for device :00:10.3 disabled > ehci_hcd :00:10.3: --> PCI D3/wakeup > uhci_hcd :00:10.2: uhci_suspend > ACPI: PCI interrupt for device :00:10.2 disabled > uhci_hcd :00:10.2: --> PCI D3 > uhci_hcd :00:10.1: uhci_suspend > ACPI: PCI interrupt for device :00:10.1 disabled > uhci_hcd :00:10.1: --> PCI D3 > uhci_hcd :00:10.0: uhci_suspend > ACPI: PCI interrupt for device :00:10.0 disabled > uhci_hcd :00:10.0: --> PCI D3 > ACPI: PCI interrupt for device :00:0d.0 disabled > ACPI handle has no context! > ACPI: PCI interrupt for device :00:0c.0 disabled > ACPI handle has no context! > pci_set_power_state(): :00:00.0: state=3, current state=5 > swsusp: critical section: > swsusp: Need to copy 51195 pages > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > evxfevnt-0079 [00] enable: System is already in ACPI mode > ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 20 > ACPI: PCI Interrupt Link [ALKB] BIOS reported IRQ 0, using IRQ 21 > ACPI: PCI Interrupt Link [ALKC] BIOS reported IRQ 0, using IRQ 22 > ACPI: PCI Interrupt Link [ALKD] BIOS reported IRQ 0, using IRQ 23 > evxfevnt-0079 [00] enable: System is already in ACPI mode > ACPI: Unable to turn cooling device [c180ff60] 'off' > PCI: Setting latency timer of device :00:01.0 to 64 > ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[19] MMIO=[db14-db1407ff] > Max Packet=[2048] IR/IT contexts=[4/8] > ACPI: PCI Interrupt :00:0a.0[A] -> GSI 18 (level, low) -> IRQ 18 > e100: eth-intel: e100_watchdog: link up, 100Mbps, full-duplex > PM: Writing back config space on device :00:0d.0 at offset 1 (was > 217, writing 213) > ACPI: PCI Interrupt :00:0d.0[A] -> GSI 19 (level, low) -> IRQ 22 > uhci_hcd :00:10.0: PCI D0, from previous PCI D3 > ACPI: PCI Interrupt :00:
Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23
On Sat, 8 Dec 2007 03:40:49 +0100 "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > This message contains a list of some regressions from 2.6.23 which have been > reported since 2.6.24-rc1 was released and for which there are no fixes in the > mainline that I know of. If any of them have been fixed already, please let > me > know. > > If you know of any other unresolved regressions from 2.6.23, please let me > know > either and I'll add them to the list. > > > Subject : PATA scan: ACPI Exception AE_AML_PACKAGE_LIMIT... is > beyond end of object > Submitter : Hans de Bruin <[EMAIL PROTECTED]> > References: http://bugzilla.kernel.org/show_bug.cgi?id=9320 > Handled-By: Robert Moore <[EMAIL PROTECTED]> > Tejun Heo <[EMAIL PROTECTED]> > Fu Michael <[EMAIL PROTECTED]> > Patch : > A number of other people are seeing the same thing and Tejun is putting in a blacklist of machines which cannot use libata+acpi. That patch is not yet in any git tree which I pull. AFACIT the machines kepe working OK - there's just some nasty dmesg spew. If any machines _are_ breaking then this could cause real problems and I'd prefer that we either go for a whitelist or arrange to detect the condition and fall back to non-acpi ata. - 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.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Fri, 07 Dec 2007 22:01:33 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote: > > On Fri, 07 Dec 2007 23:09:43 + > > Zan Lynx <[EMAIL PROTECTED]> wrote: > [cut] > > > > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I > > > > > only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I got > > > > > at least 16 MB/s. The card itself is capable of 30+ in the USB-2 > > > > > reader. > [cut] > > Maybe pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards.patch? > > > > Could you try a `patch -R' of the below? > > > > > > From: Alan Cox <[EMAIL PROTECTED]> > > > > Signed-off-by: Alan Cox <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > --- > > > > drivers/ata/pata_pcmcia.c | 31 +-- > > 1 file changed, 17 insertions(+), 14 deletions(-) > > > > diff -puN > > drivers/ata/pata_pcmcia.c~pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards > > drivers/ata/pata_pcmcia.c > [cut] > > Nope, that did not change anything. It still detects as PIO0 and still > runs at 1.6 MB/s. argh. OK. And Linus's current tree is OK, yes? In which case we should be OK for 2.6.24 and I guess we can hope like heck that the dud patch doesn't leak into mainline. Hopefully Alan will get some time to look into it before 2.6.25 opens. OK, there's a patch in Jeff's tree "pata_pcmcia: Add support for dumb 8bit IDE emulations" which could be our guy. I've uploaded two patches, against 2.6.24-rc4: http://userweb.kernel.org/~akpm/zl.with.gz origin.patch + git-libata-all.patch http://userweb.kernel.org/~akpm/zl.without.gz origin.patch + git-libata-all.patch - 5ddcddd4dfeb16a9509dad647f509828d6fee605 It would be great if you could test both. If zl.with is bad and zl.without is good then we know that 5ddcddd4dfeb16a9509dad647f509828d6fee605 caused this problem. 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: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Fri, 07 Dec 2007 23:09:43 +
Zan Lynx <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-12-07 at 15:02 -0800, Andrew Morton wrote:
> > On Fri, 07 Dec 2007 20:38:24 +
> > Zan Lynx <[EMAIL PROTECTED]> wrote:
> >
> > > While I'm reporting problems I'll get this one out there.
> > >
> > > I normally use a USB-2 memory card reader but I also have a PCMCIA
> > > CompactFlash adapter that I use occasionally. During the MM series
> > > kernels 2.6.22 and 23 (I am pretty sure) this didn't work at all. I
> > > don't know about vanilla since I don't run that.
> > >
> > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again, but I
> > > only get read rates of 1.6 MB/s. When it used to work in 2.6.20 I got
> > > at least 16 MB/s. The card itself is capable of 30+ in the USB-2
> > > reader.
> > >
>
> > Are we talking about this?
> [cut]
> > > It might be that it auto-configures for PIO-0. I have no idea why it
> > > does that.
> > >
> > > Another interesting thing is that doing a dd to or from the card brings
> > > the rest of the system to a nearly complete halt. Interrupt problem?
> >
> > Where are you seeing the evidence that it autoconfigures for PIO-0?
>
> No, this:
> pccard: PCMCIA card inserted into slot 0
> cs: memory probe 0x5000-0x57ff: excluding 0x5000-0x57ff
> cs: memory probe 0xe010-0xe17f: excluding 0xe010-0xe026
> 0xe03e-0xe082 0xe0b1-0xe10c
> pcmcia: registering new device pcmcia0.0
> scsi2 : pata_pcmcia
> ata3: PATA max PIO0 cmd 0x3100 ctl 0x310e irq 19
> ata3.00: CFA: LEXAR ATA FLASH, V2.00, max PIO6
> ata3.00: 8018640 sectors, multi 0: LBA
> ata3.00: configured for PIO0
> ata3.00: configured for PIO0
> ata3: EH complete
> isa bounce pool size: 16 pages
> scsi 2:0:0:0: Direct-Access ATA LEXAR ATA FLASH V2.0 PQ: 0 ANSI: 5
> sd 2:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB)
> sd 2:0:0:0: [sdb] Write Protect is off
> sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support
> DPO or FUA
> sd 2:0:0:0: [sdb] 8018640 512-byte hardware sectors (4106 MB)
> sd 2:0:0:0: [sdb] Write Protect is off
> sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
> sd 2:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support
> DPO or FUA sdb: sdb1
> sd 2:0:0:0: [sdb] Attached SCSI removable disk
>
> Specifically:
> ata3.00: configured for PIO0
> ata3.00: configured for PIO0
Oh, OK. Hopefully the ata guys can help out with this.
I don't know if it actually strictly a regression? Did libata ever support
that device in any earlier kernels?
Alan will be non-respnosive for a few weeks.
Maybe pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards.patch?
Could you try a `patch -R' of the below?
From: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ata/pata_pcmcia.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff -puN
drivers/ata/pata_pcmcia.c~pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards
drivers/ata/pata_pcmcia.c
---
a/drivers/ata/pata_pcmcia.c~pata_pcmcia-minor-cleanups-and-support-for-dual-channel-cards
+++ a/drivers/ata/pata_pcmcia.c
@@ -42,7 +42,7 @@
#define DRV_NAME "pata_pcmcia"
-#define DRV_VERSION "0.3.2"
+#define DRV_VERSION "0.3.3"
/*
* Private data structure to glue stuff together
@@ -198,7 +198,6 @@ do { last_fn = (fn); if ((last_ret = (re
/**
* pcmcia_init_one - attach a PCMCIA interface
* @pdev: pcmcia device
- * @ops: operations for this device
*
* Register a PCMCIA IDE interface. Such interfaces are PIO 0 and
* shared IRQ.
@@ -217,9 +216,10 @@ static int pcmcia_init_one(struct pcmcia
cistpl_cftable_entry_t dflt;
} *stk = NULL;
cistpl_cftable_entry_t *cfg;
- int pass, last_ret = 0, last_fn = 0, is_kme = 0, ret = -ENOMEM;
+ int pass, last_ret = 0, last_fn = 0, is_kme = 0, ret = -ENOMEM, p;
unsigned long io_base, ctl_base;
void __iomem *io_addr, *ctl_addr;
+ int n_ports = 1;
struct ata_port_operations *ops = &pcmcia_port_ops;
@@ -348,7 +348,7 @@ next_entry:
/* FIXME: Could be more ports at base + 0x10 but we only deal with
one right now */
if (pdev->io.NumPorts1 >= 0x20)
- printk(KERN_WARNING DRV_NAME ": second channel not yet
supported.\n");
+ n_ports = 2;
Re: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
On Sat, 08 Dec 2007 20:02:54 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2007-12-08 at 02:07 -0800, Andrew Morton wrote:
> > On Fri, 07 Dec 2007 22:01:33 -0700 Zan Lynx <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On Fri, 2007-12-07 at 15:22 -0800, Andrew Morton wrote:
> > > > On Fri, 07 Dec 2007 23:09:43 +
> > > > Zan Lynx <[EMAIL PROTECTED]> wrote:
> > > [cut]
> > > > > > > Now with MM kernels 2.6.24 rc1-4 the PCMCIA adapter works again,
> > > > > > > but I
> > > > > > > only get read rates of 1.6 MB/s. When it used to work in 2.6.20
> > > > > > > I got
> > > > > > > at least 16 MB/s. The card itself is capable of 30+ in the USB-2
> > > > > > > reader.
> [cut]
> > argh. OK. And Linus's current tree is OK, yes?
> >
> > In which case we should be OK for 2.6.24 and I guess we can hope like heck
> > that the dud patch doesn't leak into mainline. Hopefully Alan will get
> > some time to look into it before 2.6.25 opens.
>
> Linus' tree is also broken.
>
> I tried a Linus 2.6.24-rc4 and it acts the same way, with a very slow
> transfer rate.
shit
> I also tried 2.6.24-rc4 with the older not-libata PATA drivers and it is
> broken.
squared.
> dmesg had a line about the CF card detected as hda,
> but /sys/block did not have hda and /dev/hda did not function.
But these drivers did work in earlier kernels, yes? 2.6.20 worked, but
we don't know about intervening kernels.
Can you tell us which version(s)?
> I will try the patches you mentioned
Yes, that won't tell use anything.
> but I think I may also have to
> work backward through kernel versions until I find the last one where
> the PCMCIA hd{a,b,c,d,e} drivers worked.
That would be great - a git-bisect is often ideal.
http://www.kernel.org/doc/local/git-quick.html has details.
-
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 9533] New: 2.6.24-rc4: some ahci/acpi interaction causes delays during boot
On Mon, 10 Dec 2007 05:55:20 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9533 Another box-killing regression to track, please. Either ATA or ACPI. - 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 9533] New: 2.6.24-rc4: some ahci/acpi interaction causes delays during boot
On Mon, 10 Dec 2007 12:52:43 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > On Mon, 10 Dec 2007 05:55:20 -0800 (PST) > [EMAIL PROTECTED] wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=9533 > > Another box-killing regression to track, please. Either ATA or ACPI. er, no, not box-killing - just scary warnings. It's not clear what "kernel doesn't get to userland yet" is referring to - something else I guess. Your desire to avoid doing a bisection search is a good one - I've been trying to do one for a couple of days on and off and there are so many fatally buggy bisection points between 2.6.23 and 2.6.24-rc1 that I've given up on the attempt. - 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] pata_legacy: Restructure and revamp
On Sat, 8 Dec 2007 15:55:06 + Alan Cox <[EMAIL PROTECTED]> wrote:
> Rework the pata_legacy driver to have an internal way to plug multiple legacy
> interface types
> and designs into the driver.
>
> This driver supports
> - Generic legacy ISA on primary/secondary and tertiary ports
> - BIOS or jumper configured legacy ports
> - VLB controllers that snoop the mode set for PIO
> (Cirrus CLPD7220, Adaptec AIC25VL01)
> - Promise PDC20230
> - Holtek 6560A/B
> - Opti VLB controllers
> - QDI 6500/6580/6580DP controllers
>
> The new driver also adds an "all" option so you can load all the PCI drivers
> you have, decide you have
> a controller that is totally unknown and then load pata_legacy all=1 to grab
> the primary/secondary ports
> as a last resort fallback.
>
> TODO:
> Add ST412 support (needs some kind of geometry hook in libata core code)
> Winbond W83759A in programmable mode (aka DTC2278)
> Find more insane VLB controllers to support
>
> This driver obsoletes pata_qdi, which can go once this is settled in.
>
Is this patch going to screw my kernel up?
> +static __init void probe_opti_vlb(void)
> +{
> + /* If an OPTI 82C46X is present find out where the channels are */
> + static const char *optis[4] = {
> + "3/463MV", "5MV",
> + "5MVA", "5MVB"
> + };
> + u8 chans = 1;
> + u8 ctrl = (opti_syscfg(0x30) & 0xC0) >> 6;
> +
> + opti82c46x = 3; /* Assume master and slave first */
> + printk(KERN_INFO DRV_NAME ": Opti 82C46%s chipset support.\n",
> + optis[ctrl]);
> + if (ctrl == 3)
> + chans = (opti_syscfg(0x3F) & 0x20) ? 2 : 1;
this could be
if (ctrl == 3 && (opti_syscfg(0x3F) & 0x20))
chans = 2;
if that's any clearer...
-
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: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
On Thu, 13 Dec 2007 21:09:59 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote: > > OK, it's a vm issue, cc linux-mm and probable culprit. > I have tens of thousand "backward" pages after a > boot - IOW, bvec->bv_page is the page before bvprv->bv_page, not > reverse. So it looks like that bug got reintroduced. Bill Irwin fixed this a couple of years back: changed the page allocator so that it mostly hands out pages in ascending physical-address order. I guess we broke that, quite possibly in Mel's page allocator rework. It would help if you could provide us with a simple recipe for demonstrating this problem, please. - 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: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
On Thu, 13 Dec 2007 17:15:06 -0500 James Bottomley <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote: > > On Thu, 13 Dec 2007 21:09:59 +0100 > > Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > > > > > OK, it's a vm issue, > > > > cc linux-mm and probable culprit. > > > > > I have tens of thousand "backward" pages after a > > > boot - IOW, bvec->bv_page is the page before bvprv->bv_page, not > > > reverse. So it looks like that bug got reintroduced. > > > > Bill Irwin fixed this a couple of years back: changed the page allocator so > > that it mostly hands out pages in ascending physical-address order. > > > > I guess we broke that, quite possibly in Mel's page allocator rework. > > > > It would help if you could provide us with a simple recipe for > > demonstrating this problem, please. > > The simple way seems to be to malloc a large area, touch every page and > then look at the physical pages assigned ... they now mostly seem to be > descending in physical address. > OIC. -mm's /proc/pid/pagemap can be used to get the pfn's... - 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: QUEUE_FLAG_CLUSTER: not working in 2.6.24 ?
On Thu, 13 Dec 2007 19:30:00 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > Here's the commit that causes the regression: > > ... > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -760,7 +760,8 @@ static int rmqueue_bulk(struct zone *zone, unsigned int > order, > struct page *page = __rmqueue(zone, order, migratetype); > if (unlikely(page == NULL)) > break; > - list_add_tail(&page->lru, list); > + list_add(&page->lru, list); well that looks fishy. - 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] fix page_alloc for larger I/O segments
On Thu, 13 Dec 2007 19:40:09 -0500
Mark Lord <[EMAIL PROTECTED]> wrote:
> And here is a patch that seems to fix it for me here:
>
> * * * *
>
> Fix page allocator to give better change of larger contiguous segments
> (again).
>
> Signed-off-by: Mark Lord <[EMAIL PROTECTED]
> ---
>
>
> --- old/mm/page_alloc.c.orig 2007-12-13 19:25:15.0 -0500
> +++ linux-2.6/mm/page_alloc.c 2007-12-13 19:35:50.0 -0500
> @@ -954,7 +954,7 @@
> goto failed;
> }
> /* Find a page of the appropriate migrate type */
> - list_for_each_entry(page, &pcp->list, lru) {
> + list_for_each_entry_reverse(page, &pcp->list, lru) {
> if (page_private(page) == migratetype) {
> list_del(&page->lru);
> pcp->count--;
- needs help to make it apply to mainline
- needs a comment, methinks...
---
a/mm/page_alloc.c~fix-page-allocator-to-give-better-chance-of-larger-contiguous-segments-again
+++ a/mm/page_alloc.c
@@ -1060,8 +1060,12 @@ again:
goto failed;
}
- /* Find a page of the appropriate migrate type */
- list_for_each_entry(page, &pcp->list, lru)
+ /*
+* Find a page of the appropriate migrate type. Doing a
+* reverse-order search here helps us to hand out pages in
+* ascending physical-address order.
+*/
+ list_for_each_entry_reverse(page, &pcp->list, lru)
if (page_private(page) == migratetype)
break;
_
-
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] fix page_alloc for larger I/O segments (improved)
On Thu, 13 Dec 2007 19:57:29 -0500 James Bottomley <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-12-13 at 19:46 -0500, Mark Lord wrote: > > "Improved version", more similar to the 2.6.23 code: > > > > Fix page allocator to give better chance of larger contiguous segments > > (again). > > > > Signed-off-by: Mark Lord <[EMAIL PROTECTED] > > --- > > > > --- old/mm/page_alloc.c 2007-12-13 19:25:15.0 -0500 > > +++ linux-2.6/mm/page_alloc.c 2007-12-13 19:43:07.0 -0500 > > @@ -760,7 +760,7 @@ > > struct page *page = __rmqueue(zone, order, migratetype); > > if (unlikely(page == NULL)) > > break; > > - list_add(&page->lru, list); > > + list_add_tail(&page->lru, list); > > Could we put a big comment above this explaining to the would be vm > tweakers why this has to be a list_add_tail, so we don't end up back in > this position after another two years? > Already done ;) --- a/mm/page_alloc.c~fix-page_alloc-for-larger-i-o-segments-fix +++ a/mm/page_alloc.c @@ -847,6 +847,10 @@ static int rmqueue_bulk(struct zone *zon struct page *page = __rmqueue(zone, order, migratetype); if (unlikely(page == NULL)) break; + /* +* Doing a list_add_tail() here helps us to hand out pages in +* ascending physical-address order. +*/ list_add_tail(&page->lru, list); set_page_private(page, migratetype); } _ - 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: Iomega ZIP-100 drive unsupported with jmicron JMB361 chip?
On Mon, 10 Dec 2007 15:09:43 -0500 trash can <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I have tolerated this problem for a year and do not post to this list in > haste. I have posted on forums and searched the community over the past > year. Your report is welcome - thanks. Let's cc the IDE/sata development list. > I have looked at the list archive on gossamer-threads.com for > solutions. With Fedora Core 6 unsupported (the last kernel for which my > zip drive worked), it is time for my last attempt at a solution. Please > CC: any response as I have not joined the list. I have compiled a > kernel-debug RPM and can run this if its output would help. Thank you > for any time you might devote to this problem. > > motherboard: MSI P965 Platinum/Intel P965 Express Chipset Based (MS-7238 > series) > Fedora 8 : kernel 2.6.23.1-42.fc8 > Iomega Zip drive internal Model Z100ATAPI > > lspci > 03:00.0 SATA controller: JMicron Technologies, Inc. JMB361 AHCI/IDE (rev 02) > 03:00.1 IDE interface: JMicron Technologies, Inc. JMB361 AHCI/IDE (rev 02) > > # lsmod | grep ata > pata_jmicron8257 0 > ata_generic 8901 0 > ata_piix 16709 0 > libata 99633 4 ahci,pata_jmicron,ata_generic,ata_piix > scsi_mod 119757 4 sr_mod,sg,libata,sd_mod > > I have recently changed the BIOS setting for the SATA#1 Controller from > [IDE] to [AHCI] with no effect. I assume AHCI is correct? > > Text below attached as text.txt for readability. > from dmesg: > libata version 2.21 loaded. > device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL PROTECTED] > PCI: Enabling device :03:00.1 ( -> 0001) > ACPI: PCI Interrupt :03:00.1[B] -> GSI 17 (level, low) -> IRQ 17 > PCI: Setting latency timer of device :03:00.1 to 64 > scsi0 : pata_jmicron > scsi1 : pata_jmicron > ata1: PATA max UDMA/100 cmd 0x0001cc00 ctl 0x0001c882 bmdma 0x0001c400 irq 17 > ata2: PATA max UDMA/100 cmd 0x0001c800 ctl 0x0001c482 bmdma 0x0001c408 irq 17 > ata1.00: ATAPI: LITE-ON DVDRW SOHW-1693S, KS0B, max UDMA/66 > ata1.01: ATAPI: IOMEGA ZIP 100 ATAPI, 05.H, max MWDMA1, CDB intr > ata1.00: configured for UDMA/66 > ata1.01: configured for MWDMA1 > scsi 0:0:0:0: CD-ROMLITE-ON DVDRW SOHW-1693S KS0B PQ: 0 ANSI: 5 > scsi 0:0:1:0: Direct-Access IOMEGA ZIP 100 05.H PQ: 0 ANSI: 5 > sd 0:0:1:0: [sda] 196608 512-byte hardware sectors (101 MB) > sd 0:0:1:0: [sda] Write Protect is off > sd 0:0:1:0: [sda] Mode Sense: 00 40 00 00 > sd 0:0:1:0: [sda] Write cache: enabled, read cache: enabled, doesn't support > DPO or FUA > sd 0:0:1:0: [sda] 196608 512-byte hardware sectors (101 MB) > sd 0:0:1:0: [sda] Write Protect is off > sd 0:0:1:0: [sda] Mode Sense: 00 40 00 00 > sd 0:0:1:0: [sda] Write cache: enabled, read cache: enabled, doesn't support > DPO or FUA > sda:<6>sd 0:0:1:0: [sda] Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE,SUGGEST_OK > sd 0:0:1:0: [sda] Sense Key : Hardware Error [current] > sd 0:0:1:0: [sda] Add. Sense: Scsi parity error > end_request: I/O error, dev sda, sector 0 > Buffer I/O error on device sda, logical block 0 > > If a disk is inserted into the drive (/var/log/messages) > Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Spinning up > disk.<5>sd 0:0:1:0: [sda] Spinning up diskready > Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] 196608 512-byte hardware > sectors (101 MB) > Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Write Protect is off > Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Write cache: enabled, > read cache: enabled, doesn't support DPO or FUA > Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] 196608 512-byte hardware > sectors (101 MB) > Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Write Protect is off > Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Write cache: enabled, > read cache: enabled, doesn't support DPO or FUA > Dec 10 14:22:53 localhost kernel: sda:<6>sd 0:0:1:0: [sda] Result: > hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK > Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Sense Key : Hardware > Error [current] > Dec 10 14:22:53 localhost kernel: sd 0:0:1:0: [sda] Add. Sense: Scsi parity > error > Dec 10 14:22:53 localhost kernel: end_request: I/O error, dev sda, sector 0 > Dec 10 14:22:53 localhost kernel: printk: 42 messages suppressed. > Dec 10 14:22:53 localhost kernel: Buffer I/O error on device sda, logical > block 0 > So which is the most recent kernel version which worked OK? - 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: ATA bus error with external hd on esata
On Sat, 15 Dec 2007 21:10:47 +0100 Zsolt Barat <[EMAIL PROTECTED]> wrote: > Zsolt Barat schrieb: > > hi list, Let's cc the IDE development list. > > i just bought a "MyBook" called external HD with a fixed enclosure, from > > WD. Connected to the SATA port i constantly get "ATA bus error" messages > > in the kernel log. Is this a known issue? > > > > /var/log/messages: > > Dec 15 18:37:53 proto1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 > > action 0x2 > > Dec 15 18:37:53 proto1 ata2.00: irq_stat 0x4001 > > Dec 15 18:37:53 proto1 ata2.00: cmd 35/00:e0:a7:d2:01/00:01:33:00:00/e0 > > tag 0 cdb 0x0 data 245760 out > > Dec 15 18:37:53 proto1 res 51/84:00:86:d4:01/00:00:33:00:00/e0 Emask > > 0x10 (ATA bus error) > > Dec 15 18:37:54 proto1 ata2: soft resetting port > > Dec 15 18:37:54 proto1 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl > > 310) > > Dec 15 18:37:54 proto1 ata2.00: configured for UDMA/33 > > Dec 15 18:37:54 proto1 ata2: EH complete > > Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] 976773168 512-byte hardware > > sectors (500108 MB) > > Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Write Protect is off > > Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 > > Dec 15 18:37:54 proto1 sd 1:0:0:0: [sdb] Write cache: enabled, read > > cache: enabled, doesn't support DPO or FUA > > Dec 15 18:38:15 proto1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 > > action 0x2 > > Dec 15 18:38:15 proto1 ata2.00: irq_stat 0x4001 > > Dec 15 18:38:15 proto1 ata2.00: cmd 35/00:80:bf:09:14/00:01:33:00:00/e0 > > tag 0 cdb 0x0 data 196608 out > > Dec 15 18:38:15 proto1 res 51/84:00:3e:0b:14/00:00:33:00:00/e0 Emask > > 0x10 (ATA bus error) > > Dec 15 18:38:15 proto1 ata2: soft resetting port > > Dec 15 18:38:15 proto1 ata2: SATA link up 1.5 Gbps (SStatus 113 SControl > > 310) > > Dec 15 18:38:15 proto1 ata2.00: configured for UDMA/33 > > Dec 15 18:38:15 proto1 ata2: EH complete > > Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] 976773168 512-byte hardware > > sectors (500108 MB) > > Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Write Protect is off > > Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 > > Dec 15 18:38:15 proto1 sd 1:0:0:0: [sdb] Write cache: enabled, read > > cache: enabled, doesn't support DPO or FUA > > > > lspci: > > 00:00.0 Host bridge: ATI Technologies Inc Unknown device 7910 > > 00:01.0 PCI bridge: ATI Technologies Inc Unknown device 7912 > > 00:07.0 PCI bridge: ATI Technologies Inc Unknown device 7917 > > 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA > > 00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0) > > 00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1) > > 00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2) > > 00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3) > > 00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4) > > 00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI) > > 00:14.0 SMBus: ATI Technologies Inc SB600 SMBus (rev 13) > > 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE > > 00:14.2 Audio device: ATI Technologies Inc SB600 Azalia > > 00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge > > 00:14.4 PCI bridge: ATI Technologies Inc SB600 PCI to PCI Bridge > > 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > > HyperTransport Technology Configuration > > 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > > Address Map > > 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > > DRAM Controller > > 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] > > Miscellaneous Control > > 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon X1200 Series > > 01:05.2 Audio device: ATI Technologies Inc Radeon X1200 Series Audio > > Controller > > 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > > RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) > > 03:00.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host > > Controller (rev c0) > > > > thanks and best regards > > > > zsolt > > > sorry, kernel version is: 2.6.23-gentoo-r1 > - 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: CMD646 & cdrom: drive appears confused & drive not ready for command
On Mon, 17 Dec 2007 02:59:03 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > (added linux-ide) (Ths time for real) > On Sun, 16 Dec 2007 20:36:04 +0200 (EET) Meelis Roos <[EMAIL PROTECTED]> > wrote: > > > I just noticed that all my recent test kernels on Sun Ultra 5 spam dmesg > > with "hdc: drive not ready for command" messages. Oldest logs that I > > have are from 2.6.24-rc4-g94545bad and they are already bad. > > So when did thi start? Is 2.6.23 OK? > > > The > > spamming does not happen right away but some time later, and > > hald-addon-storage is the userspace daemon that polls the cdrom > > regularly. Full dmesg until the spamming begins - notice there are first > > some "drive appears confused" messages right before it happens. > > > > Dec 15 14:11:00 mandariin kernel: PROMLIB: Sun IEEE Boot Prom 'OBP 3.31.0 > > 2001/07/25 20:36' > > Dec 15 14:11:00 mandariin kernel: PROMLIB: Root node compatible: > > Dec 15 14:11:00 mandariin kernel: Linux version 2.6.24-rc5-gda8cadb3 > > ([EMAIL PROTECTED]) (gcc version 4.2.3 20071123 (prerelease) (Debian > > 4.2.2-4)) #38 Sat Dec 15 13:00:43 EET 2007 > > Dec 15 14:11:00 mandariin kernel: ARCH: SUN4U > > Dec 15 14:11:00 mandariin kernel: Ethernet address: 08:00:20:f8:c7:72 > > Dec 15 14:11:00 mandariin kernel: [0002-f880] > > page_structs=262144 node=0 entry=0/0 > > Dec 15 14:11:00 mandariin kernel: [0002-f8c0] > > page_structs=262144 node=0 entry=1/0 > > Dec 15 14:11:00 mandariin kernel: [0002-f8000100] > > page_structs=262144 node=0 entry=2/0 > > Dec 15 14:11:00 mandariin kernel: [0002-f8000140] > > page_structs=262144 node=0 entry=3/0 > > Dec 15 14:11:00 mandariin kernel: OF stdout device is: /[EMAIL > > PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED]/[EMAIL > > PROTECTED],40:a > > Dec 15 14:11:00 mandariin kernel: PROM: Built device tree with 42042 bytes > > of memory. > > Dec 15 14:11:00 mandariin kernel: On node 0 totalpages: 64952 > > Dec 15 14:11:00 mandariin kernel: Normal zone: 447 pages used for memmap > > Dec 15 14:11:00 mandariin kernel: Normal zone: 0 pages reserved > > Dec 15 14:11:00 mandariin kernel: Normal zone: 64505 pages, LIFO batch:15 > > Dec 15 14:11:00 mandariin kernel: Movable zone: 0 pages used for memmap > > Dec 15 14:11:00 mandariin kernel: Built 1 zonelists in Zone order, mobility > > grouping on. Total pages: 64505 > > Dec 15 14:11:00 mandariin kernel: Kernel command line: root=/dev/hda1 ro > > Dec 15 14:11:00 mandariin kernel: PID hash table entries: 2048 (order: 11, > > 16384 bytes) > > Dec 15 14:11:00 mandariin kernel: clocksource: mult[2c71c] shift[16] > > Dec 15 14:11:00 mandariin kernel: clockevent: mult[5c28f5c2] shift[32] > > Dec 15 14:11:00 mandariin kernel: Console: colour dummy device 80x25 > > Dec 15 14:11:00 mandariin kernel: console [tty0] enabled > > Dec 15 14:11:00 mandariin kernel: Dentry cache hash table entries: 65536 > > (order: 6, 524288 bytes) > > Dec 15 14:11:00 mandariin kernel: Inode-cache hash table entries: 32768 > > (order: 5, 262144 bytes) > > Dec 15 14:11:00 mandariin kernel: Memory: 501368k available (2696k kernel > > code, 904k data, 128k init) [f800,1ff42000] > > Dec 15 14:11:00 mandariin kernel: SLUB: Genslabs=12, HWalign=32, Order=0-2, > > MinObjects=8, CPUs=1, Nodes=1 > > Dec 15 14:11:00 mandariin kernel: Calibrating delay using timer specific > > routine.. 721.25 BogoMIPS (lpj=3606278) > > Dec 15 14:11:00 mandariin kernel: Mount-cache hash table entries: 512 > > Dec 15 14:11:00 mandariin kernel: Initializing cgroup subsys ns > > Dec 15 14:11:00 mandariin kernel: net_namespace: 120 bytes > > Dec 15 14:11:00 mandariin kernel: NET: Registered protocol family 16 > > Dec 15 14:11:00 mandariin kernel: PCI: Probing for controllers. > > Dec 15 14:11:00 mandariin kernel: /[EMAIL PROTECTED],0: SABRE PCI Bus Module > > Dec 15 14:11:00 mandariin kernel: /[EMAIL PROTECTED],0: PCI IO[1fe0200] > > MEM[1ff] > > Dec 15 14:11:00 mandariin kernel: PCI: Scanning PBM /[EMAIL PROTECTED],0 > > Dec 15 14:11:00 mandariin kernel: ebus0: [auxio] [power] [SUNW,pll] [se] > > [su] [su] [ecpp] [fdthree] [eeprom] [flashprom] [SUNW,CS4231] > > Dec 15 14:11:00 mandariin kernel: power: Control reg at 1fff1724000 > > Dec 15 14:11:00 mandariin kernel: SCSI subsystem initialized > > Dec 15 14:11:00 mandariin kernel: libata version 3.00 loaded. > > Dec 15 14:11:00 mandariin kernel: AUXIO: Fo
Re: [patch 3/9] libata: xfer_mask is unsigned int not unsigned long
On Mon, 17 Dec 2007 20:30:33 -0500 Jeff Garzik <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > From: Tejun Heo <[EMAIL PROTECTED]> > > > > xfer_mask is unsigned int not unsigned long. Change ->mode_filter to > > take and return unsigned int. > > > > While at it, rename @adev of ata_pci_default_filter() to @dev for > > consistency. > > > > [EMAIL PROTECTED]: fix types] > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > --- > > > > drivers/ata/libata-sff.c |5 +++-- > > drivers/ata/pata_acpi.c|2 +- > > drivers/ata/pata_ali.c |2 +- > > drivers/ata/pata_amd.c | 10 +- > > drivers/ata/pata_hpt366.c |2 +- > > drivers/ata/pata_hpt37x.c |4 ++-- > > drivers/ata/pata_pdc2027x.c|4 ++-- > > drivers/ata/pata_scc.c |2 +- > > drivers/ata/pata_serverworks.c |4 ++-- > > include/linux/libata.h |9 + > > 10 files changed, 23 insertions(+), 21 deletions(-) > > patch is outdated... > What does this mean?? - 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 00/63] ide-cd: redux
On Thu, 20 Dec 2007 01:48:49 +0100 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > This patch series is a major rework of the ide-cd driver. woo-hoo. > PS ide-cd Maintainer position is still open... boo-hoo. I wish someone would fix that "The drive appears confused (ireason = 0x%02x)" thing. I had a go a while back but iirc the reporter disappeared on me. It is somewhat common. Or do you think this patch might indeed fix it? - 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: ATA device reset, shoud I be concerned?
On Mon, 14 Jan 2008 00:19:20 +0200 Georgi Chulkov <[EMAIL PROTECTED]> wrote: > Hello, > > During heavy disk load on my laptop, sometimes the IDE disk will pause for a > second and then continue. I get this in my kernel log: > > [ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 > frozen > [ 9031.028000] ata1.00: cmd c8/00:08:90:ca:ce/00:00:00:00:00/e0 tag 0 cdb 0x0 > data 4096 in > [ 9031.028000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 > (timeout) > [ 9036.068000] ata1: port is slow to respond, please be patient (Status 0xd0) > [ 9041.052000] ata1: device not ready (errno=-16), forcing hardreset > [ 9041.052000] ata1: soft resetting port > [ 9041.232000] ata1.00: configured for UDMA/100 > [ 9041.232000] ata1: EH complete > [ 9041.248000] sd 0:0:0:0: [sda] 78140160 512-byte hardware sectors (40008 MB) > [ 9041.248000] sd 0:0:0:0: [sda] Write Protect is off > [ 9041.248000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 > [ 9041.248000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, > doesn't support DPO or FUA > > My question: What is this telling me, and do I need to be concerned? > Everything continues to work normally after the message: no I/O errors, no > fsck errors, etc. > > I've seen some similar reports on the mailing list, but they include slightly > different messages. I would appreciate any information! > > uname -a (on Kubuntu Gutsy, CPU is a single-core 32-bit Pentium M): > > Linux superfly 2.6.22-14-386 #1 Tue Dec 18 07:34:24 UTC 2007 i686 GNU/Linux > Has it done this in all kernel versions or did some earler version work OK? - 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 9837] New: I can't boot with a PLEXTOR PX-740A
On Mon, 28 Jan 2008 09:46:29 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9837 > >Summary: I can't boot with a PLEXTOR PX-740A >Product: Platform Specific/Hardware >Version: 2.5 > KernelVersion: 2.6.24-4.7 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: i386 > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Kernel : https://edge.launchpad.net/ubuntu/+source/linux/2.6.24-4.7 > Distribution: Hardy Alpha3 http://www.ubuntu.com/testing/hardy/alpha3 > Hardware Environment: i386 > > Problem Description: > Using my PLEXTOR PX-740A or my Matsushita SR-8584-B (instead of) result in > error during boot process. > If i use a Traxdata CDD4911/45 the kernel boot. > > Steps to reproduce: > Please see my Bug report (attachements ...) > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/181561 > Seems to be old-IDE related. There are lots of links to follow ;) It is unclear whether this is a regression. Was this bug also present in all earlier kernel versions? - 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 9845] New: libata still broken for Pegasos on 2.6.24
On Tue, 29 Jan 2008 12:56:37 -0800 (PST) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9845 > >Summary: libata still broken for Pegasos on 2.6.24 >Product: Platform Specific/Hardware >Version: 2.5 > KernelVersion: 2.6.24 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: PPC-32 > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > As 2.6.24 contains fix for pata_via on Pegasos I decide to give a try to this > version. Unfortunatly it seems it is still broken. Quick look on dmesg from > faulty boot shows both channels are configured to use IRQ 14 and this is not > correct in this case. > > > ata1: PATA max UDMA/100 cmd 0x1000 ctl 0x100c bmdma 0x1020 irq 14^ > ata2: PATA max UDMA/100 cmd 0x1010 ctl 0x101c bmdma 0x1028 irq 14^ > > > libata works fine on 2.6.23 when using patch > https://bugzilla.redhat.com/attachment.cgi?id=167747. Reported also > https://bugzilla.redhat.com/show_bug.cgi?id=430802 > Gargh. How does one go from https://bugzilla.redhat.com/attachment.cgi?id=167747 back to the bug to which it is attached? - 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: Problem burning DVDs with Marvell 88SE6121 on pata_marvell
(added linux-ide) On Sat, 2 Feb 2008 16:30:04 -0600 Mike Hokenson <[EMAIL PROTECTED]> wrote: > I recently put together a new system with a MSI P35 PLATINUM and although > reading from data CDs, DVDs, and watching DVD movies is working fine, DVD > burning isn't. MSI's manual says "1 IDE port by Marvell 88SE6111", but > lspci says it's a 88SE6121. I have two DVD burners, a SONY DRU-510A and > a DRU-820A. They were both working fine with TDK DVD+R media on my ASUS > K8V SE DELUXE (VIA IDE controller) prior to the upgrade. > > Here's what I see with dvd+rw-tools version 7.0-9: > > sh# dvd+rw-mediainfo /dev/dvd > /dev/null # this is blank media > :-[ GET CURRENT PERFORMACE failed with SK=5h/ASC=24h/ACQ=00h]: Input/output > error > :-[ READ TOC failed with SK=5h/ASC=24h/ACQ=00h]: Input/output error > > sh# growisofs -dvd-compat -speed=2.4 -Z /dev/dvd -rJ -joliet-long -quiet > "burn" > Executing 'genisoimage -rJ -joliet-long -quiet burn | builtin_dd of=/dev/dvd > obs=32k seek=0' > /dev/dvd: "Current Write Speed" is 2.5x1352KBps. > :-[ [EMAIL PROTECTED] failed with SK=3h/ASC=0Ch/ACQ=00h]: Input/output error > :-( write failed: Input/output error > /dev/dvd: flushing cache > /dev/dvd: closing track > :-[ CLOSE TRACK failed with SK=5h/ASC=30h/ACQ=05h]: Wrong medium type > /dev/dvd: closing disc > :-[ CLOSE DISC failed with SK=5h/ASC=30h/ACQ=05h]: Wrong medium type > > sh# dvd+rw-mediainfo /dev/dvd > /dev/null > :-[ READ TRACK INFORMATION failed with SK=3h/ASC=11h/ACQ=05h]: Input/output > error (this is 2.6.24) If nothing happens with this report in the next few days, please create an entry at bugzilla.kernel.org so we can keep an eye on it, thanks. Trying older kernels might be interesting, find out if it's a regression or if it was always this way. > And from cdrecord version 1.1.6-1: > > sh# mkisofs -rJ -joliet-long -quiet "burn" | cdrecord -v dev=/dev/dvd - > wodim: No write mode specified. > wodim: Asuming -tao mode. > wodim: Future versions of wodim may have different drive dependent defaults. > TOC Type: 1 = CD-ROM > scsidev: '/dev/dvd' > devname: '/dev/dvd' > scsibus: -2 target: -2 lun: -2 > Linux sg driver version: 3.5.27 > Wodim version: 1.1.6 > SCSI buffer size: 64512 > Device type: Removable CD-ROM > Version: 5 > Response Format: 2 > Capabilities : > Vendor_info: 'SONY' > Identification : 'DVD RW DRU-820A ' > Revision : '1.0c' > Device seems to be: Generic mmc2 DVD-R/DVD-RW. > Current: 0x0009 (CD-R) > Profile: 0x002B (DVD+R/DL) > Profile: 0x001B (DVD+R) > Profile: 0x001A (DVD+RW) > Profile: 0x0016 (DVD-R/DL layer jump recording) > Profile: 0x0015 (DVD-R/DL sequential recording) > Profile: 0x0014 (DVD-RW sequential recording) > Profile: 0x0013 (DVD-RW restricted overwrite) > Profile: 0x0012 (DVD-RAM) > Profile: 0x0011 (DVD-R sequential recording) > Profile: 0x0010 (DVD-ROM) > Profile: 0x000A (CD-RW) > Profile: 0x0009 (CD-R) (current) > Profile: 0x0008 (CD-ROM) > Profile: 0x0002 (Removable disk) > Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). > Driver flags : MMC-3 SWABAUDIO BURNFREE > Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R > Drive buf size : 1114112 = 1088 KB > Beginning DMA speed test. Set CDR_NODMATEST environment variable if device > communication breaks or freezes immediately after that. > FIFO size : 12582912 = 12288 KB > Track 01: data unknown length > Total size:0 MB (00:00.00) = 0 sectors > Lout start:0 MB (00:02/00) = 0 sectors > Current Secsize: 2048 > ATIP info from disk: > Indicated writing power: 4 > Is not unrestricted > Is not erasable > Disk sub type: Medium Type A, high Beta category (A+) (3) > ATIP start of lead in: -11849 (97:24/01) > ATIP start of lead out: 359847 (79:59/72) > Disk type:Long strategy type (Cyanine, AZO or similar) > Manuf. index: 25 > Manufacturer: Taiyo Yuden Company Limited > wodim: WARNING: Total disk size unknown. Data may not fit on disk. > Speed set to 7056 KB/s > Starting to write CD/DVD at speed 40.0 in real TAO mode for single session. > Last chance to quit, starting real write i 0 seconds. Operation starts. > Waiting for reader process to fill input buffer ... input buffer ready. > Performing OPC... > Starting new track at sector: 0 > Track 01:1 MB written (fifo 100%) [buf 97%] 5.4x.Errno: 5 > (Input/output error), write_g1 scsi sendcmd: no error > CDB: 2A 00 00 00 03 64 00 00 1F 00 > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 04 00 00 00 00 0A CF DC 00 00 08 03 00 00 > Sense Key: 0x4 Hardware Error, Segment 0 > Sense Code: 0x08 Qual 0x03 (logical unit communication crc error > (ultra-dma/32)) Fru 0x0 > Sense flags: Blk 0 (not valid) > cmd finished after 30.186s timeout 40s > > write track data: error after 1777664 bytes > wodim: A write error occured. > wodim: Please properly read the error message above. > Writing time: 46.572s > Fixating... > Errno: 5 (Input/output error), close track/session
Re: [PATCH] enclosure: add support for enclosure services
On Sun, 03 Feb 2008 18:16:51 -0600
James Bottomley <[EMAIL PROTECTED]> wrote:
>
> From: James Bottomley <[EMAIL PROTECTED]>
> Date: Sun, 3 Feb 2008 15:40:56 -0600
> Subject: [SCSI] enclosure: add support for enclosure services
>
> The enclosure misc device is really just a library providing sysfs
> support for physical enclosure devices and their components.
>
Thanks for sending it out for review.
> +struct enclosure_device *enclosure_find(struct device *dev)
> +{
> + struct enclosure_device *edev = NULL;
> +
> + mutex_lock(&container_list_lock);
> + list_for_each_entry(edev, &container_list, node) {
> + if (edev->cdev.dev == dev) {
> + mutex_unlock(&container_list_lock);
> + return edev;
> + }
> + }
> + mutex_unlock(&container_list_lock);
> +
> + return NULL;
> +}
> +EXPORT_SYMBOL_GPL(enclosure_find);
This looks a little odd. We don't take a ref on the object after looking
it up, so what prevents some other thread of control from freeing or
otherwise altering the returned object while the caller is playing with it?
> +/**
> + * enclosure_for_each_device - calls a function for each enclosure
> + * @fn: the function to call
> + * @data:the data to pass to each call
> + *
> + * Loops over all the enclosures calling the function.
> + *
> + * Note, this function uses a mutex which will be held across calls to
> + * @fn, so it must have user context, and @fn should not sleep or
Probably "non atomic context" would be more accurate.
fn() actually _can_ sleep.
> + * otherwise cause the mutex to be held for indefinite periods
> + */
> +int enclosure_for_each_device(int (*fn)(struct enclosure_device *, void *),
> + void *data)
> +{
> + int error = 0;
> + struct enclosure_device *edev;
> +
> + mutex_lock(&container_list_lock);
> + list_for_each_entry(edev, &container_list, node) {
> + error = fn(edev, data);
> + if (error)
> + break;
> + }
> + mutex_unlock(&container_list_lock);
> +
> + return error;
> +}
> +EXPORT_SYMBOL_GPL(enclosure_for_each_device);
> +
> +/**
> + * enclosure_register - register device as an enclosure
> + *
> + * @dev: device containing the enclosure
> + * @components: number of components in the enclosure
> + *
> + * This sets up the device for being an enclosure. Note that @dev does
> + * not have to be a dedicated enclosure device. It may be some other type
> + * of device that additionally responds to enclosure services
> + */
> +struct enclosure_device *
> +enclosure_register(struct device *dev, const char *name, int components,
> +struct enclosure_component_callbacks *cb)
> +{
> + struct enclosure_device *edev =
> + kzalloc(sizeof(struct enclosure_device) +
> + sizeof(struct enclosure_component)*components,
> + GFP_KERNEL);
> + int err, i;
> +
> + if (!edev)
> + return ERR_PTR(-ENOMEM);
> +
> + if (!cb) {
> + kfree(edev);
> + return ERR_PTR(-EINVAL);
> + }
It would be less fuss if this were to test cb before doing the kzalloc().
Can cb==NULL actually and legitimately happen?
> + edev->components = components;
> +
> + edev->cdev.class = &enclosure_class;
> + edev->cdev.dev = get_device(dev);
> + edev->cb = cb;
> + snprintf(edev->cdev.class_id, BUS_ID_SIZE, "%s", name);
> + err = class_device_register(&edev->cdev);
> + if (err)
> + goto err;
> +
> + for (i = 0; i < components; i++)
> + edev->component[i].number = -1;
> +
> + mutex_lock(&container_list_lock);
> + list_add_tail(&edev->node, &container_list);
> + mutex_unlock(&container_list_lock);
> +
> + return edev;
> +
> + err:
> + put_device(edev->cdev.dev);
> + kfree(edev);
> + return ERR_PTR(err);
> +}
> +EXPORT_SYMBOL_GPL(enclosure_register);
> +
> +static struct enclosure_component_callbacks enclosure_null_callbacks;
> +
> +/**
> + * enclosure_unregister - remove an enclosure
> + *
> + * @edev:the registered enclosure to remove;
> + */
> +void enclosure_unregister(struct enclosure_device *edev)
> +{
> + int i;
> +
> + if (!edev)
> + return;
Is this legal?
> + mutex_lock(&container_list_lock);
> + list_del(&edev->node);
> + mutex_unlock(&container_list_lock);
See, right now, someone who found this enclosure_device via
enclosure_find() could still be playing with it?
> + for (i = 0; i < edev->components; i++)
> + if (edev->component[i].number != -1)
> + class_device_unregister(&edev->component[i].cdev);
> +
> + /* prevent any callbacks into service user */
> + edev->cb = &enclosure_null_callbacks;
> + class_device_unregister(&edev->cdev);
> +}
> +EXPORT_SYMBOL_GPL(enclosure_unregister);
> +
> +/**
> + * enclosure_component_
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
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] sata_mv: fix loop with last port
On Thu, 07 Feb 2008 23:30:42 -0500 Mark Lord <[EMAIL PROTECTED]> wrote: > > Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> > .. > > Yup, obvious bug fixes, thanks. > Signed-off-by: Mark Lord <[EMAIL PROTECTED]> Typically we'll use Acked-by: here. Because Signed-off-by: implies that you were in the delivery path, or that you worked on the patch. afacit that is not the case. Documentation/SubmittingPatches has some explanation. I made that change to my copy of the patch - please let me know if that was incorrect, 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: [PATCHSET] printk: implement printk_header() and merging printk, take #3
On Wed, 13 Feb 2008 18:09:28 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > This is the third take of implement-printk_header-and-mprintk > patchset. > > Changes from the last take[L] are... > > * Now header is printed on every line of a multiline message. If the > header ends with ':' followed by spaces. The colon is replaced with > space from the second line. > > * s/mprintk/mprintk_flush/ and s/mprintk_add/mprintk/ as suggested. > > * mprintk_init_alloc() and mprintk_free() added to ease malloc'd > buffer handling. No need to specify buffer size. Sizing is left to > mprintk. > > This patchset aims to make printing multiline messages and assembling > message piece-by-piece easier. > > In a nutshell, printk_header() lets you do the following atomically > (against other messages). > > code: > printk(KERN_INFO "ata1.00: ", "line0\nline1\nline2\n"); > > output: > <6>ata1.00: line0 > <6>ata1.00 line1 > <6>ata1.00 line2 That seems sensible. > And mprintk the following. > > code: > DEFINE_MPRINTK(mp, 2 * 80); > > mprintk_set_header(&mp, KERN_INFO "ata%u.%2u: ", 1, 0); > mprintk_push(&mp, "ATA %d", 7); > mprintk_push(&mp, ", %u sectors\n", 1024); > mprintk(&mp, "everything seems dandy\n"); > > output: > <6>ata1.00: ATA 7, 1024 sectors > <6>ata1.00 everything seems dandy > And that looks like an awful lot of fuss. Is it really worth doing? - 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] printk: implement printk_header() and merging printk, take #3
On Thu, 14 Feb 2008 09:40:51 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Can you please take a look at ata_eh_link_report() in > drivers/ata/libata-eh.c? I did. Punishment? > Currently, it has some problems. Yes, and the patches do clean that up. ho hum. What tends to happen with this sort of thing is that fi we merge it, it ends up getting used more often than one expected... If you stand back and squint at it, there are quite a few places where we do this sort of thing: allocate a buffer, squirt characters into it, reallocating and/or flushing as we proceed. All sysfs and procfs read-side code, for a start... - 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] printk: implement printk_header() and merging printk, take #3
On Fri, 15 Feb 2008 10:49:31 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > > printk is a special case, I think. It's the primary logging/debugging > > method which can't fail and as it's mostly interpreted by human beings > > (and developers in problematic cases), it has different maneuvering room > > on errors - ie. it's far better to print messages w/o header or proper > > log level than failing to print, which is quite different requirements > > from other components. > > Andrew, any more comments or suggestions on how to proceed on this? Nope. > One > way or the other, I think this is a problem worth solving. There are a lot of such problems ;) - 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] printk: implement printk_header() and merging printk, take #3
On Fri, 15 Feb 2008 11:36:12 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > >>> printk is a special case, I think. It's the primary logging/debugging > >>> method which can't fail and as it's mostly interpreted by human beings > >>> (and developers in problematic cases), it has different maneuvering room > >>> on errors - ie. it's far better to print messages w/o header or proper > >>> log level than failing to print, which is quite different requirements > >>> from other components. > >> Andrew, any more comments or suggestions on how to proceed on this? > > > > Nope. > > > >> One > >> way or the other, I think this is a problem worth solving. > > > > There are a lot of such problems ;) > > So, I guess it's NACK w/o suggested alternatives, right? > I wouldn't nack without good reasons, and I have none here. I don't have very strong opinions either way. As a seat-of-the-pants thing, it does seem to be a lot of core code to solve a fairly minor problem in (afaik) one remote place. But I haven't looked - perhaps there are other places which could be improved if such facilities were available. - 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: [git patches] libata fixes
On Wed, 28 Mar 2007 13:53:10 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > On Wed, 28 Mar 2007, Jeff Garzik wrote: > > > > Jeff Garzik wrote: > > > This disables libata ACPI, among other things. > > > > If a -rc6 is possible, that would be quite nice... > > Heh. I don't think -rc6 is "possible" - it's "inevitable". We have too > much fallout from the timer changes still outstanding. It looks people > finally figured out a big issue with the HPET timer, and that hopefully > resolves most of the remaining timer-related regressions, but yes, we most > definitely _will_ have an -rc6. yup. > Andrew, what's your feeling apart from the timer fallout? There are two main metrics: a) the number of bugs which Adrian is tracking. I think this still exceeds 25, which is a lot. b) the rate at which fixes are arriving. I have accumulated 15-20 since the last batch (40 hours ago), which is still a pretty high rate. Based on that, we're still quite a long way from -final. (But you know me - I'd be happy releasing 2.6.21 in July) (Don't ask me what year I'm referring to, either) There is another metric to look at, too: the number of fixes which are going into 2.6.x.y. If that fix count is high, and if those fixes fix bugs which were not present in 2.6.x-1 then this is an indication that something is wrong - many regressions are sneaking through the -rc process. And I haven't run the numbers, but I get the impression that 2.6.20.x has an unusually large number of fixes in it. - 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: Silent corruption on AMD64
> On Sat, 31 Mar 2007 18:27:36 -0700 Aaron Lehmann <[EMAIL PROTECTED]> wrote: > I have spent a lot of time trying to find a simpler test case. So far, > as far as I can tell, there are three conditions that must be > satisfied for corruption to occur: > > 1. Heavy Ethernet load (nc remotehost < /dev/zero) > 2. Heavy disk write load on any non-sata_sil drive (cat /dev/zero > /path) > 3. Heavy disk read load on any other drive (tar c /path | cat > /dev/null) > > With these conditions satisfied, data read off sda or sdb (the drives > associated with sata_sil) is often corrupted. Since I can only see > this problem with files on those two drives, I'm inclined to suspect > the sata_sil driver, but I really have no idea what's going on. I know > this is not a recent issue - I experienced very similar corruption at > least a year ago. I wasn't able to reproduce it at the time, because > it only appeared in the backups I was restoring from. Are you able to provide us with some before-and-after data so we can see this corruption. See, if it's dropped-bits or shifted-data or eight-byte-aligned kernel addresses or whatever, that helps us generate theories.. - 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: Linux tape drivers
On Wed, 4 Apr 2007 12:22:35 -0700 "Willem Riede" <[EMAIL PROTECTED]> wrote: > On 4/4/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Wed, 4 Apr 2007 16:26:14 +0200 Kern Sibbald <[EMAIL PROTECTED]> wrote: > > > > > I'm all in favor of deprecating ide-tape if ide-scsi is a viable > > > alternative, > > > > ow. ide-scsi is in very bad shape and nobody is maintaining it or fixing > > bugs in it or anything. The only reason we retain ide-scsi at all is, err, > > because some tape drives need it. > > > > If we have no alternative to using ide-scsi, and if the tape controllers in > > question are not some terribly obscure things which nobody would seriously > > use then we have a bit of a problem. I don't know of anyone who we can > > turn to to get anything done in ide-scsi. > > Andrew, > > Kai suggests that libata should be able to take over from ide-scsi. > Do you concur? That would be very nice if we can make it happen. I don't know how close we are to that, but the fine folks on linux-ide might be able tell us. > That may be a better way forward than ide-scsi. > I know, because I had a hard enough time with it when I needed > to fix it so it worked for osst, at least. > > Regards, Willem Riede. - 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: Linux tape drivers
On Wed, 4 Apr 2007 23:31:06 +0200 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > On Wednesday 04 April 2007, Andrew Morton wrote: > > On Wed, 4 Apr 2007 12:22:35 -0700 > > "Willem Riede" <[EMAIL PROTECTED]> wrote: > > > > > On 4/4/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > On Wed, 4 Apr 2007 16:26:14 +0200 Kern Sibbald <[EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > I'm all in favor of deprecating ide-tape if ide-scsi is a viable > > > > > alternative, > > > > > > > > ow. ide-scsi is in very bad shape and nobody is maintaining it or > > > > fixing > > > > bugs in it or anything. The only reason we retain ide-scsi at all is, > > > > err, > > I haven't heard about any major bugs besides well known module unload problem. > > What have I missed? oop, caught making unsubstantiatable assertions. I've seen an ongoing dribble of doesn't-work and it-crashes reports and I simply have not made any record of them, because it's ide-scsi and I don't expect there's anything we can do about them :( Often these reports are from people who are writing CDROMs and the usual response is "use cdrecord dev=/dev/hdc". I think Alan and Jens might have some thoughts on the ide-scsi status? - 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: fix PCI must_checks
On Thu, 5 Apr 2007 12:13:02 +0100 Alan Cox <[EMAIL PROTECTED]> wrote: > On Wed, 4 Apr 2007 21:37:04 -0700 > Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > From: Randy Dunlap <[EMAIL PROTECTED]> > > > > Check PCI interface function results for errors in drivers/ide/pci. > > > > drivers/ide/pci/cs5530.c:244: warning: ignoring return value of > > 'pci_set_mwi', declared with attribute warn_unused_result > > NAK (again) Disagree. > The bug is in pci_set_mwi, it should not force return value checking. > Please fix that instead. You don't describe your reasoning, but I will assume that it is as follows: pci_set_mwi() is an advisory thing, and on certain platforms it might fail to set the cacheline size to the desired number. This is not a fatal error and the driver can successfully run at a lesser performance level. If that description is accurate then I'd contend that pci_set_mwi() is misdesigned. It should not be returning a negative error code for something which is not an error. The changes we should make are a) rename pci_set_pwi() to pci_try_set_mwi() b) make pci_try_set_mwi() return a positive, non-zero code when the attempt to set the cacheline size failed. And make it return a negative error code when fatal errors occur. This way a) drivers which _do_ care about whether or not the cacheline size was set successfully can test for it or generate warnings and b) we can tell when pci_try_set_mwi() encountered a fatal error for other reasons. Now this may all sound excessively anal, but it is simply the correct design. And one of the reasons for adding the __must_check annotation is to weed out design errors. Simply turning the thing off is a step backwards. And we *need* to be excessively anal in the PCI setup code. We have metric shitloads of bugs due to problems in that area, and the more formality and error handling and error reporting we can get in there the better off we will be. - 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: fix PCI must_checks
On Thu, 5 Apr 2007 21:16:09 +0100 Alan Cox <[EMAIL PROTECTED]> wrote: > > pci_set_mwi() is an advisory thing, and on certain platforms it might fail > > to set the cacheline size to the desired number. This is not a fatal error > > and the driver can successfully run at a lesser performance level. > > Correct. > > > If that description is accurate then I'd contend that pci_set_mwi() is > > misdesigned. It should not be returning a negative error code for > > something which is not an error. > > It is an error to *some* drivers but not all. Kind of like setting some > of the other features may be essential for some chips and not others. > > > And we *need* to be excessively anal in the PCI setup code. We have metric > > shitloads of bugs due to problems in that area, and the more formality and > > error handling and error reporting we can get in there the better off we > > will be. > > No argument there > > If we want to deal with some of the mess we should also remove all direct > writing of PCI latency timers and replace them with a function to stop > drivers setting unsafe values and ignoring chip errata the core knows > about but they dont hm. Well, what to do? How about we prevail upon Randy to: - rename pci_set_mwi() to pci_try_set_mwi() - make it return 0 on success, 1 if the "try" failed - make it return -EFOO on error (presently unimplemented) - review callers - remove __must_check ? I have a feeling that this is "still wrong": even things like pci_read_config_foo() can get errors, and there are various PCI-bus error handling proposals floating about which might require that callers be more careful in what they accept. - 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.21-rc7-mm1 BUG at kernel/sched-clock.c:175 init_sched_clock()
On Tue, 24 Apr 2007 12:28:29 -0600 "Berck E. Nash" <[EMAIL PROTECTED]> wrote: > > Kernel panic on boot, console output attached. > Thanks, cc's added. > > [14316256.221707] Linux version 2.6.21-rc7-mm1 ([EMAIL PROTECTED]) (gcc > version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Tue Apr 24 > 12:09:02 MDT 2007 > [14316256.221707] Command line: root=/dev/sdc1 ro console=tty0 > console=ttyS0,115200n8 BOOT_IMAGE=vmlinuz > [14316256.221707] BIOS-provided physical RAM map: > [14316256.221707] BIOS-e820: - 0009fc00 (usable) > [14316256.221707] BIOS-e820: 0009fc00 - 000a (reserved) > [14316256.221707] BIOS-e820: 000e4000 - 0010 (reserved) > [14316256.221707] BIOS-e820: 0010 - 3ff8 (usable) > [14316256.221707] BIOS-e820: 3ff8 - 3ff8e000 (ACPI data) > [14316256.221707] BIOS-e820: 3ff8e000 - 3ffe (ACPI NVS) > [14316256.221707] BIOS-e820: 3ffe - 4000 (reserved) > [14316256.221707] BIOS-e820: ffb0 - 0001 (reserved) > [14316256.221707] end_pfn_map = 1048576 > [14316256.221707] DMI 2.4 present. > [14316256.221707] ACPI: RSDP 000FAF20, 0024 (r2 ACPIAM) > [14316256.221707] ACPI: XSDT 3FF80100, 0064 (r1 NEC 1000724 MSFT > 97) > [14316256.221707] ACPI: FACP 3FF80290, 00F4 (r3 A_M_I_ OEMFACP 1000724 MSFT > 97) > [14316256.221707] ACPI: DSDT 3FF80590, 9560 (r1 A0543 A05430000 INTL > 20060113) > [14316256.221707] ACPI: FACS 3FF8E000, 0040 > [14316256.221707] ACPI: APIC 3FF80390, 0080 (r1 A_M_I_ OEMAPIC 1000724 MSFT > 97) > [14316256.221707] ACPI: SLIC 3FF80410, 0176 (r1 NEC 1000724 MSFT > 97) > [14316256.221707] ACPI: OEMB 3FF8E040, 0066 (r1 A_M_I_ AMI_OEM 1000724 MSFT > 97) > [14316256.221707] ACPI: HPET 3FF89AF0, 0038 (r1 A_M_I_ OEMHPET 1000724 MSFT > 97) > [14316256.221707] ACPI: MCFG 3FF89B30, 003C (r1 A_M_I_ OEMMCFG 1000724 MSFT > 97) > [14316256.221707] ACPI: SSDT 3FF8E0B0, 01C6 (r1AMI CPU1PM1 INTL > 20060113) > [14316256.221707] ACPI: SSDT 3FF8E280, 013A (r1AMI CPU2PM1 INTL > 20060113) > [14316256.221707] Zone PFN ranges: > [14316256.221707] DMA 0 -> 4096 > [14316256.221707] DMA324096 -> 1048576 > [14316256.221707] Normal1048576 -> 1048576 > [14316256.221707] Movable zone start PFN for each node > [14316256.221707] early_node_map[2] active PFN ranges > [14316256.221707] 0:0 -> 159 > [14316256.221707] 0: 256 -> 262016 > [14316256.221707] ACPI: PM-Timer IO Port: 0x808 > [14316256.221707] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) > [14316256.221707] Processor #0 (Bootup-CPU) > [14316256.221707] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) > [14316256.221707] Processor #1 > [14316256.221707] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) > [14316256.221707] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) > [14316256.221707] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) > [14316256.221707] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 > [14316256.221707] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [14316256.221707] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > [14316256.221707] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > [14316256.221707] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > [14316256.221707] Setting APIC routing to flat > [14316256.221707] ACPI: HPET id: 0x8086a201 base: 0xfed0 > [14316256.221707] Using ACPI (MADT) for SMP configuration information > [14316256.221707] Allocating PCI resources starting at 5000 (gap: > 4000:bfb0) > [14316256.221707] PERCPU: Allocating 32896 bytes of per cpu data > [14316256.221707] Built 1 zonelists, mobility grouping on. Total pages: > 257236 > [14316256.221707] Kernel command line: root=/dev/sdc1 ro console=tty0 > console=ttyS0,115200n8 BOOT_IMAGE=vmlinuz > [14316256.221707] Initializing CPU#0 > [14316256.221707] PID hash table entries: 4096 (order: 12, 32768 bytes) > [14316256.221707] time.c: Detected 2564.902 MHz processor. > [14316256.231707] Console: colour VGA+ 80x25 > [14316256.235040] Dentry cache hash table entries: 131072 (order: 8, 1048576 > bytes) > [14316256.235040] Inode-cache hash table entries: 65536 (order: 7, 524288 > bytes) > [14316256.235040] Checking aperture... > [14316256.241707] Memory: 1026888k/1048064k available (2355k kernel code, > 20620k reserved, 1490k data, 212k init) > [14316256.325040] Calibrating delay using timer specific routine.. 5134.38 > BogoMIPS (lpj=8554219) > [14316256.325040] Mount-cache hash table entries: 256 > [14316256.325040] CPU: L1 I cache: 32K, L1 D cache: 32K > [14316256.325040] CPU: L2 cache: 2048K > [14316256.325040] using mwait in idle threads. > [14316256.325040] CPU: Physical Processor ID: 0 > [14316256.325040] CPU: Proc
Re: 2.6.21-rc7-mm1 BUG at kernel/sched-clock.c:175 init_sched_clock()
On Wed, 25 Apr 2007 17:42:41 +0900 Tejun Heo <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > >> [2.953862] RIP: 0010:[] [] > >> scsi_schedule_eh+0xa/0x57 > >> [3.058672] [] ata_port_schedule_eh+0x4c/0x50 > >> [3.064725] [] ata_port_abort+0xa2/0xae > >> [3.070248] [] ata_port_freeze+0x46/0x57 > >> [3.075853] [] ahci_interrupt+0x300/0x47a > >> [3.081552] [] handle_IRQ_event+0x27/0x57 > >> [3.087253] [] handle_edge_irq+0xee/0x133 > >> [3.092960] [] do_IRQ+0x6d/0xd5 > >> [3.097793] [] ret_from_intr+0x0/0xa > >> [3.103059] [] mwait_idle+0x46/0x4b > >> [3.108231] [] cpu_idle+0x87/0xaa > >> [3.113227] [] rest_init+0x49/0x4b > >> [3.118322] [] start_kernel+0x291/0x29c > >> [3.123837] [] _sinittext+0x13a/0x141 > >> > > > > So we took an AHCI interrupt when ata_port.scsi_host was still NULL. > > > > It appears that ATA is presently requesting its IRQ before allocating all > > the resources which are needed to handle an interrupt. Does this > > (resource-leaky) patch fix things? > > No, that would break host probing. The port is in frozen (controller > initialized and IRQs masked off) state, so it's not allowed to take > interrupt. Sounds dodgy. What happens if the IRQ line is shared with some other device? We'll enter ahci_interrupt(). We've alread set up ->port_map and ->n_ports so we're wholly dependent upon that read from HOST_IRQ_STAT returning zeroes. /* sigh. 0x is a valid return from h/w */ if that happens we're dead, aren't we? > If interrupt triggers at this point, it's low level driver > bug. Berck, how reliably can you reproduce this problem? Can you post > the result of 'lspci -nn'? Berck doesn't apepar to be sharing that IRQ, so it'll be something else. However do note that if CONFIG_DEBUG_SHIRQ is enabled, request_irq() will deliberately run the handler, to catch buggy drivers. - 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: BUG: Null pointer dereference in fs/open.c
On Wed, 25 Apr 2007 22:53:00 + (GMT) William Heimbigner <[EMAIL PROTECTED]>
wrote:
> On Wed, 25 Apr 2007, Andrew Morton wrote:
>
> > OK. I am able to use the pktcdvd driver OK in mainline with a piix/sata
> > drive. It could be that something is going wrong at the IDE level for you.
> Perhaps; I'll try an external usb cd burner, and see where that goes.
>
> > Are you able to identify the most recent kernel which actually worked?
> No, because I haven't set packet writing up in Linux before - however, I do
> know
> that I've successfully set up packet writing (using 2 of the 3 cd burners I
> have) in another operating system before. I'll try 2.6.18 and see if that gets
> me anywhere different, though.
OK.
A quick summary: mainline's pktcdvd isn't working for William using IDE.
It is working for me using sata.
> dmesg.1.txt is the dmesg output from immediately after system finishes
> booting
> (the unusually large printk times are due to kexec)
>
> # pktsetup 0 /dev/hdc
> [19861.831160] pktcdvd: writer pktcdvd0 mapped to hdc
> [19861.837138]
> [19861.837142] =
> [19861.844343] [ INFO: possible recursive locking detected ]
> [19861.849738] 2.6.21-rc7 #2
> [19861.852361] -
> [19861.857750] vol_id/4433 is trying to acquire lock:
> [19861.862533] (&bdev->bd_mutex){--..}, at: [] do_open+0x4f/0x2c0
> [19861.869386]
> [19861.869387] but task is already holding lock:
> [19861.875225] (&bdev->bd_mutex){--..}, at: [] do_open+0x4f/0x2c0
> [19861.882070]
> [19861.882071] other info that might help us debug this:
> [19861.888602] 2 locks held by vol_id/4433:
> [19861.892518] #0: (&bdev->bd_mutex){--..}, at: []
> do_open+0x4f/0x2c0
> [19861.899813] #1: (&ctl_mutex#2){--..}, at: []
> mutex_lock+0x1c/0x20
> [19861.907046]
> [19861.907047] stack backtrace:
> [19861.911415] [] show_trace_log_lvl+0x1a/0x30
> [19861.916569] [] show_trace+0x12/0x20
> [19861.921021] [] dump_stack+0x16/0x20
> [19861.925475] [] __lock_acquire+0xbc0/0x1040
> [19861.930542] [] lock_acquire+0x70/0x90
> [19861.935169] [] mutex_lock_nested+0x7e/0x2e0
> [19861.940315] [] do_open+0x4f/0x2c0
> [19861.944595] [] __blkdev_get+0x79/0x90
> [19861.949222] [] blkdev_get+0x15/0x20
> [19861.953674] [] pkt_open+0xb7/0xd80
> [19861.958050] [] do_open+0x85/0x2c0
> [19861.962330] [] blkdev_open+0x33/0x70
> [19861.966870] [] __dentry_open+0xf4/0x220
> [19861.971678] [] nameidata_to_filp+0x35/0x40
> [19861.976738] [] do_filp_open+0x49/0x50
> [19861.981365] [] do_sys_open+0x47/0xd0
> [19861.985904] [] sys_open+0x1c/0x20
> [19861.990184] [] sysenter_past_esp+0x5f/0x99
> [19861.995243] ===
Yeah, I'm not worrying about that one for now.
> # pktsetup 1 /dev/hdd
> [19909.635795] cdrom: This disc doesn't have any tracks I recognize!
> [19909.689394] pktcdvd: writer pktcdvd1 mapped to hdd
> [19909.820337] drivers/ide/ide-cd.c:729: setting error to 2
> [19909.825649] [] show_trace_log_lvl+0x1a/0x30
> [19909.830810] [] show_trace+0x12/0x20
> [19909.835263] [] dump_stack+0x16/0x20
> [19909.839716] [] cdrom_decode_status+0x1f4/0x3b0
> [19909.845131] [] cdrom_newpc_intr+0x38/0x320
> [19909.850190] [] ide_intr+0x96/0x200
> [19909.854557] [] handle_IRQ_event+0x28/0x60
> [19909.859538] [] handle_edge_irq+0xa6/0x130
> [19909.864511] [] do_IRQ+0x49/0xa0
> [19909.868618] [] common_interrupt+0x2e/0x34
> [19909.873591] [] mwait_idle+0x12/0x20
> [19909.878044] [] cpu_idle+0x4a/0x80
> [19909.882324] [] rest_init+0x37/0x40
> [19909.886690] [] start_kernel+0x34b/0x420
> [19909.891499] [<>] 0x0
> [19909.894488] ===
> [19909.921518] pktcdvd: pkt_get_last_written failed
>
> # pktsetup 2 /dev/sr0
> [19982.934793] drivers/scsi/scsi_lib.c:838: setting error to 134217730
> [19982.941070] [] show_trace_log_lvl+0x1a/0x30
> [19982.946256] [] show_trace+0x12/0x20
> [19982.950744] [] dump_stack+0x16/0x20
> [19982.955232] [] scsi_io_completion+0x28a/0x3a0
> [19982.960586] [] scsi_blk_pc_done+0x1b/0x30
> [19982.965594] [] scsi_finish_command+0x4c/0x60
> [19982.970861] [] scsi_softirq_done+0x77/0xe0
> [19982.975955] [] blk_done_softirq+0x6b/0x80
> [19982.980962] [] __do_softirq+0x62/0xc0
> [19982.985624] [] do_softirq+0x55/0x60
> [19982.990112] [] ksoftirqd+0x65/0x100
> [19982.994599] [] kthread+0xa3/0xd0
> [19982.998827] [] kernel_thread_helper+0x7/0x10
> [19983.004095] ===
> [19983.009065] cdrom: This disc doesn't have any tracks I recognize!
So what has happened here
Re: [git patches] IDE update
On Wed, 09 May 2007 18:47:23 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Bartlomiej Zolnierkiewicz wrote: > > * the code for selecting and programming the best DMA transfer mode > > has been reworked to be cleaner, more generic and more libata-like, > > (> 500 LOCs gone and this change allows the change described below) > > > Bartlomiej Zolnierkiewicz (11): > > ide: rework the code for selecting the best DMA transfer mode (v3) > > > Has this seen testing/exposure in -mm tree? > argh. If this was in a file called ide-rework-the-code-for-selecting-the-best-DMA-transfer-mode.patch then it would be so easy. ah, it's hidden in ide-max-dma-mode-v3.patch. akpm:/usr/src/25> grep ide-max-dma-mode-v3 pc/*series pc/2.6.21-mm1-series:ide-ide-max-dma-mode-v3.patch pc/2.6.21-mm2-series:ide-ide-max-dma-mode-v3.patch pc/2.6.21-rc2-mm2-series:ide-ide-max-dma-mode-v3.patch pc/2.6.21-rc3-mm1-series:ide-ide-max-dma-mode-v3.patch pc/2.6.21-rc3-mm2-series:ide-ide-max-dma-mode-v3.patch pc/2.6.21-rc4-mm1-series:ide-ide-max-dma-mode-v3.patch pc/2.6.21-rc5-mm3-series:ide-ide-max-dma-mode-v3.patch pc/2.6.21-rc5-mm4-series:ide-ide-max-dma-mode-v3.patch pc/2.6.21-rc6-mm1-series:ide-ide-max-dma-mode-v3.patch pc/2.6.21-rc7-mm1-series:ide-ide-max-dma-mode-v3.patch pc/2.6.21-rc7-mm2-series:ide-ide-max-dma-mode-v3.patch No probs. - 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/7] libata: check for AN support
On Wed, 9 May 2007 16:38:09 -0700 Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote: > /** > + * ata_dev_set_AN - Issue SET FEATURES - SATA FEATURES > + * with sector count set to indicate > + * Asynchronous Notification feature I think kenreldoc requires that all this be on a single line? > + * @dev: Device to which command will be sent > + * > + * Issue SET FEATURES - SATA FEATURES command to device @dev > + * on port @ap. > + * > + * LOCKING: > + * PCI/etc. bus probe sem. > + * > + * RETURNS: > + * 0 on success, AC_ERR_* mask otherwise. > + */ ooh, locking and return value documentation. Often missed, and nice. - 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
