Re: stable basic 4-port SATA card
Jeff Breidenbach wrote: > Thanks for the excellent rundown. > >> sata_sil24: 3124/3132 chips don't have any outstanding serious >> problems. IRQ loss on PCI-X was the only recent serious known >> problem but it's fixed now. > > I'm still a little confused how to translate this known-good chipset to > an actual buyable PCI card. It isn't obvious from basic web searching. That I don't know either. I usually magnify the product photograph and try to read the chip number (I know shapes of several chips so it's easier for me) or call the manufacturer. Just ask for the PCI ID and look it up in linux PCI IDs repository or modinfo result. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/ide/ide-probe.c, kernel 2.6.23.1
Hi, thanks for the reply. :)
Bartlomiej Zolnierkiewicz wrote:
Hi,
On Monday 12 November 2007, Andrew Morton wrote:
On Fri, 09 Nov 2007 11:22:41 +0100 Jonas Stare <[EMAIL PROTECTED]> wrote:
Hi.
This week I ran into a strange hardware problem. During boot I got a 35
second delay while waiting for IDE-disks that weren't there to report
With what chipset and host driver does this happen?
I am not sure about the chip-set but I think it was vt82c686b. It used
the via82cxxx-driver, but only _after_ using the generic ide-code to
probe/wait (a long time) for the disks. (This was in Suse 10.1 SP 1.)
that they were not in a BSY state. The problem was most likely in the
hardware but this patch enables you to ignore waiting for disks by
setting hdX=noprobe (and not setting the geometry by hand) as a kernel
option.
If no noprobe-option is set the code will work (more or less) as the
original but if set the code will skip the ide_wait_not_busy() for that
drive. Even if there would be a drive there and it is still BSY
afterwards it should not matter since it isn't probed for later.
There are other ways to get around the "35-seconds-of-waiting-in-vain",
like actually fix the hardware, insert a second drive that works or
recompile the kernel with edd-support builtin (atleast I've seen that
solution on a forum) and possibly others. But this patch would allow
people to get Linux to boot quickly on wonky hardware without having to
recompile anything.
(The code also honors the MAX_DRIVES variable instead of assuming that
ther will be 2 drives on the bus.)
I keep on hearing about problems with boot-time IDE probing. It's public
enemy #1 with the embedded guys.
The problem is that we are not hearing about them.
Please forward the reports to [EMAIL PROTECTED]
It does seem that operator intervention is needed in some fashion.
I will be happy for all the comments I can get. :) But be gentle, this
is my first patch...
Jonas, could you also put printk() dumping content of 'stat' in
ide-iops.c::ide_wait_not_busy() so we can verify that it is not
some problem with ide_wait_not_busy() itself.
Sorry. :( I don't have access to the hardware anymore (which is a
"home-made" embedded machine). But from what I could get from poking
around was that the BSY-bit on the slave (that never has or ever will
exists) was set, probably because those who built the thing wanted to
save money and/or space on that "billionth of a cent"-resistor that Alan
Cox talked about.
Best regards
Jonas Stare
Signed-off-by: Jonas Stare <[EMAIL PROTECTED]>
--
diff -u linux-2.6.23.1-orig/drivers/ide/ide-probe.c
linux-2.6.23.1/drivers/ide/ide-probe.c
--- linux-2.6.23.1-orig/drivers/ide/ide-probe.c 2007-10-12
18:43:44.0 +0200
+++ linux-2.6.23.1/drivers/ide/ide-probe.c 2007-11-09
10:43:16.0 +0100
@@ -643,6 +643,7 @@
static int wait_hwif_ready(ide_hwif_t *hwif)
{
int rc;
+ int unit;
printk(KERN_DEBUG "Probing IDE interface %s...\n", hwif->name);
@@ -659,20 +660,24 @@
return rc;
Hmm, so the first ide_wait_not_busy() (for the currently
selected device) is OK and doesn't stall?
It didn't stall for me... But even if it had, probe_hwif() will ignore
the entire controller if you set "idex=noprobe".
(From drivers/ide/ide-probe.c)
static void probe_hwif(ide_hwif_t *hwif, void (*fixup)(ide_hwif_t *hwif))
{
unsigned int unit;
unsigned long flags;
unsigned int irqd;
if (hwif->noprobe)
return;
/* Now make sure both master & slave are ready */
- SELECT_DRIVE(&hwif->drives[0]);
- hwif->OUTB(8, hwif->io_ports[IDE_CONTROL_OFFSET]);
- mdelay(2);
- rc = ide_wait_not_busy(hwif, 35000);
- if (rc)
- return rc;
- SELECT_DRIVE(&hwif->drives[1]);
- hwif->OUTB(8, hwif->io_ports[IDE_CONTROL_OFFSET]);
- mdelay(2);
- rc = ide_wait_not_busy(hwif, 35000);
+ for (unit = 0; unit < MAX_DRIVES; ++unit) {
+ /* Ignore disks that we will not probe for later. */
+ if (!hwif->drives[unit].noprobe ||
+ hwif->drives[unit].forced_geom) {
It is better to check for ->present
(->forced_geom implies that ->present is set).
Great comment. :) I'll change that right away...
+ SELECT_DRIVE(&hwif->drives[unit]);
+ hwif->OUTB(8, hwif->io_ports[IDE_CONTROL_OFFSET]);
+ mdelay(2);
+ rc = ide_wait_not_busy(hwif, 35000);
+ /* Exit function with master selected (let's be
sane) */
+ SELECT_DRIVE(&hwif->drives[0]);
This changes the previous behavior adding an extra SELECT_DRIVE()
before trying the slave drive.
Mmmm, yes, I know. But I couldn't come up with a clean and nice way to
be sure that the first drive is selected. Maybe I could move it inside
the if-statement belo
sata_nv on MCP51: NCQ possible?
While trying to test NCQ thing again, I come across a problem, it seems: the only hardware available for testing to me right now is an ASUS M2NPV-VM motherboard, which is based on Nvidia nForce 430/GeForce 6150. lspci shows this: 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev a1) I see no command queuing enabled by linux (queue depth: 0/32), and there's no way to enable it in sysfs, either. Looking at sources (sata_nv.c), it seems this chipset is marked as "GENERIC" with no ADMA/NCQ support - at least in 2.6.23 kernel. Does this chipset support ADMA/NCQ (just not supported in the driver), or am I out of luck with this testing? Thanks. /mjt - 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_nv on MCP51: NCQ possible?
[replying to myself...] Michael Tokarev wrote: > While trying to test NCQ thing again, I come across > a problem, it seems: the only hardware available for > testing to me right now is an ASUS M2NPV-VM motherboard, > which is based on Nvidia nForce 430/GeForce 6150. > lspci shows this: > > 00:0f.0 IDE interface: nVidia Corporation MCP51 Serial ATA Controller (rev > a1) > > I see no command queuing enabled by linux (queue depth: 0/32), > and there's no way to enable it in sysfs, either. Hmm. When googling harder, I've found something about this, e.g. here: http://www.mail-archive.com/linux-ide@vger.kernel.org/msg09517.html (it's a long thread). But some question(s) remains still. First, it looks like that patch(set) isn't in 2.6.23. I'll grab 2.6.24pre to see if it's there. And second, and most important -- what's "SW NCQ", or "Software NCQ"? To me it sounds like "BIOS RAID" - that "RAID" thing found on many modern desktop motherboards which isn't hardware raid, and hence it does not offer any advantage over normal linux software raid implementation (which has its own advantages anyway). So I'm a bit confused here: linux I/O scheduler and this "Software NCQ" - isn't one of the two redundrand? And sure thing - is it worth to test NCQ at all if it's "Software"? Thanks. /mjt - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata_uli puts second channel to PIO4 on 2.6.18
Grzegorz Kulewski wrote: On Wed, 7 Feb 2007, Tejun Heo wrote: Grzegorz Kulewski wrote: It worked very well for half a year but with one disk (IIRC it was even plugged into second channel but I wont bet on it). Now I have second disk (very similar) and it is always put into PIO4 mode: [ 17.404451] libata version 2.00 loaded. [ 17.404916] sata_uli :00:04.0: version 1.0 [ 17.405009] ACPI: PCI Interrupt :00:04.0[A] -> GSI 18 (level, low) -> IRQ 185 [ 17.405223] ata1: SATA max UDMA/133 cmd 0xD400 ctl 0xD002 bmdma 0xB000 irq 185 [ 17.405385] ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xB402 bmdma 0xB008 irq 185 [ 17.405519] scsi2 : sata_uli [ 17.858803] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 17.880541] ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 17.880660] ata1.00: ata1: dev 0 multi count 16 [ 17.58] ata1.00: configured for UDMA/133 [ 17.888941] scsi3 : sata_uli [ 18.342469] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 18.343573] ata2.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 18.343691] ata2.00: ata2: dev 0 multi count 16 [ 18.344972] ata2.00: configured for PIO4 Some uli controllers have simplex bit stuck high indicating that they can't perform DMA transfers simultaneously on both channels. In this case, libata configures the second channel as PIO only. This has been worked around by the following commit. commit b2a8bbe67d73631c71492fd60b757fc50a87f182 Author: Tejun Heo <[EMAIL PROTECTED]> Date: Thu Jan 25 19:40:05 2007 +0900 libata: implement ATA_FLAG_IGN_SIMPLEX and use it in sata_uli Some uli controllers have stuck SIMPLEX bit which can't be cleared with ata_pci_clear_simplex(), but the controller is capable of doing DMAs on both channels simultaneously. Implement ATA_FLAG_IGN_SIMPLEX which makes libata ignore the simplex bit and use it in sata_uli. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> For quick fix, just comment out lines which set ATA_HOST_SIMPLEX in drivers/scsi/libata-bmdma.c. e.g. /*if (inb(bmdma + 2) & 0x80) probe_ent->host_set_flags |= ATA_HOST_SIMPLEX;*/ Thanks! After this fix it is working ok. Any chance to see the proper fix in -stable kernels for at least 2.6.18.x and 2.6.19.x? Thanks, Grzegorz Kulewski I was wondering the same thing. While I could patch the kernel, and make a custom build. I prefer not to, and just upgrade to a newer version. /Patric - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libata_uli puts second channel to PIO4 on 2.6.18
Patric Karlsson wrote: Grzegorz Kulewski wrote: On Wed, 7 Feb 2007, Tejun Heo wrote: Grzegorz Kulewski wrote: It worked very well for half a year but with one disk (IIRC it was even plugged into second channel but I wont bet on it). Now I have second disk (very similar) and it is always put into PIO4 mode: [ 17.404451] libata version 2.00 loaded. [ 17.404916] sata_uli :00:04.0: version 1.0 [ 17.405009] ACPI: PCI Interrupt :00:04.0[A] -> GSI 18 (level, low) -> IRQ 185 [ 17.405223] ata1: SATA max UDMA/133 cmd 0xD400 ctl 0xD002 bmdma 0xB000 irq 185 [ 17.405385] ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xB402 bmdma 0xB008 irq 185 [ 17.405519] scsi2 : sata_uli [ 17.858803] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 17.880541] ata1.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 17.880660] ata1.00: ata1: dev 0 multi count 16 [ 17.58] ata1.00: configured for UDMA/133 [ 17.888941] scsi3 : sata_uli [ 18.342469] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [ 18.343573] ata2.00: ATA-7, max UDMA/133, 488397168 sectors: LBA48 NCQ (depth 0/32) [ 18.343691] ata2.00: ata2: dev 0 multi count 16 [ 18.344972] ata2.00: configured for PIO4 Some uli controllers have simplex bit stuck high indicating that they can't perform DMA transfers simultaneously on both channels. In this case, libata configures the second channel as PIO only. This has been worked around by the following commit. commit b2a8bbe67d73631c71492fd60b757fc50a87f182 Author: Tejun Heo <[EMAIL PROTECTED]> Date: Thu Jan 25 19:40:05 2007 +0900 libata: implement ATA_FLAG_IGN_SIMPLEX and use it in sata_uli Some uli controllers have stuck SIMPLEX bit which can't be cleared with ata_pci_clear_simplex(), but the controller is capable of doing DMAs on both channels simultaneously. Implement ATA_FLAG_IGN_SIMPLEX which makes libata ignore the simplex bit and use it in sata_uli. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> For quick fix, just comment out lines which set ATA_HOST_SIMPLEX in drivers/scsi/libata-bmdma.c. e.g. /*if (inb(bmdma + 2) & 0x80) probe_ent->host_set_flags |= ATA_HOST_SIMPLEX;*/ Thanks! After this fix it is working ok. Any chance to see the proper fix in -stable kernels for at least 2.6.18.x and 2.6.19.x? Thanks, Grzegorz Kulewski I was wondering the same thing. While I could patch the kernel, and make a custom build. I prefer not to, and just upgrade to a newer version. /Patric - 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 Nevermind, I got the date wrong. This was fixed in Linux 2.6.20-rc7. Sorry for not reseaching it more. /Patric - 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: stable basic 4-port SATA card
Jeff Breidenbach wrote: > Thanks for the excellent rundown. > > >sata_sil24: 3124/3132 chips don't have any outstanding serious > >problems. IRQ loss on PCI-X was the only recent serious known > >problem but it's fixed now. > > I'm still a little confused how to translate this known-good chipset to > an actual buyable PCI card. It isn't obvious from basic web searching. I also look for 3124/3132 and these are some that I've found: (determined by specs, product reviews, looking closely at photos, etc, it's worth a double-check before deciding) 3132 PCIe: http://www.newegg.com/Product/Product.aspx?Item=N82E16816132010 http://www.newegg.com/Product/Product.aspx?Item=N82E16816855002 http://www.newegg.com/Product/Product.aspx?Item=N82E16816132011 http://www.newegg.com/Product/Product.aspx?Item=N82E16816132008 3132 ExpressCard: http://www.newegg.com/Product/Product.aspx?Item=N82E16839150001 3124 PCI: http://www.newegg.com/Product/Product.aspx?Item=N82E16816124003 3124 PCI-X: http://www.newegg.com/Product/Product.aspx?Item=N82E16816318004 Hope this helps -jim - 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: stable basic 4-port SATA card
On Thu, 15 Nov 2007 12:32:14 +0900, Tejun Heo wrote: > * sata_promise: Generally works okay; however there are still some > problems with recent 3Gbps chips. (Mikael, please pitch in) Right, 2nd-gen 3Gbps chips have had "intermittent" issues, which we hope are cured by the recent ASIC bug workaround, but it will take a while for that fix to propagate out. To speed up that process I'm considering backporting the fix to 2.6.23 and 2.6.22. NCQ and PMP are supported in the hardware and in the vendor's driver, but not yet in sata_promise. My intention is to add NCQ soon, but there's no time-plan yet for this. /Mikael - 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_mv: hard resetting port
Tejun Heo schrieb:
Mark Lord wrote:
Tomasz Chmielewski wrote:
Is there an online Kernelish-English dictionary anywhere? ;)
..
Unfortunately not.
At some point, we *really* need to convice {Tejun,Jeff} that libata
messages should be simpler, fewer, and more human readable by default,
with perhaps a sysfs flag to re-enable the {Tejun,Jeff}-speak versions.
Ummm... Okay. That might have something to do with me not being a
native speaker. :-)
I agree that the current message looks too scary and detailed. Yeah,
essages for recovered errors can be shorter and sweeter. Those messages
are pretty helpful to developers tho.
Note that I only sent this kernel message to this list because I
couldn't understand it.
So, I wasn't really helpful to you or Mark, but I actually took your
time - to read and reply to this posting. And time is a scarce resource.
My 3 cents.
--
Tomasz Chmielewski
http://wpkg.org
-
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 14/18] ide: add IDE_HFLAG_ABUSE_SET_DMA_MODE host flag
Bartlomiej Zolnierkiewicz wrote:
* Add IDE_HFLAG_ABUSE_SET_DMA_MODE host flag and use it to decide
what to do with transfer modes < XFER_PIO_0 in ide_set_xfer_rate().
* Set IDE_HFLAG_ABUSE_SET_DMA_MODE in host drivers that need it
(aec62xx, amd74xx, cs5520, cs5535, hpt34x, hpt366, pdc202xx_old,
serverworks, tc86c001 and via82cxxx) and cleanup ->set_dma_mode
methods in host drivers that don't (IDE core code guarantees that
->set_dma_mode will be called only for modes which are present
in SWDMA/MWDMA/UDMA masks).
While at it:
* Add IDE_HFLAGS_HPT34X/HPT3XX/PDC202XX/SVWKS define in
hpt34x/hpt366/pdc202xx_old/serverworks host driver.
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
Index: b/drivers/ide/ide-lib.c
===
--- a/drivers/ide/ide-lib.c
+++ b/drivers/ide/ide-lib.c
@@ -438,6 +438,12 @@ int ide_set_xfer_rate(ide_drive_t *drive
* case could happen iff the transfer mode has already been set on
* the device by ide-proc.c::set_xfer_rate()).
*/
+ if (rate < XFER_PIO_0) {
+ if (hwif->host_flags & IDE_HFLAG_ABUSE_SET_DMA_MODE)
+ return ide_set_dma_mode(drive, rate);
Not sure if it was worth the effort at all...
+ else
+ return ide_config_drive_speed(drive, rate);
It's tome that I go and make a patch which deals with 0x00 (default PIO
mode)...
+ }
return ide_set_dma_mode(drive, rate);
}
MBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata_mv: hard resetting port
Mark Lord schrieb: (...) ata6: exception Emask 0x10 SAct 0x0 SErr 0x18 action 0x6 frozen ata6: edma_err 0x0020 ata6: hard resetting port ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata6.00: configured for UDMA/133 ata6: EH pending after completion, repeating EH (cnt=4) ata6: exception Emask 0x10 SAct 0x0 SErr 0x401 action 0x7 ata6: edma_err 0x0010, dev connect ata6: hard resetting port .. Translation: "libata reset the link, and everything appeared okay, so it reissued the failed command and continued. No data loss." And today kernel (2.6.23.1) in the same machine have spoken to not-mere-mortals again: ata6: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x6 frozen ata6: edma_err 0x0020 ata6: hard resetting port ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata6.00: configured for UDMA/133 ata6: EH complete sd 5:0:0:0: [sde] 781422768 512-byte hardware sectors (400088 MB) sd 5:0:0:0: [sde] Write Protect is off sd 5:0:0:0: [sde] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA As I understand it now, your previous translation would fit here (or not, as SErr differs?): > Translation: > "libata reset the link, and everything appeared okay, > so it reissued the failed command and continued. > No data loss." But why was the port reseted? There was no CRC error as before, was there? What worries me is that it always happens for the same drive. -- Tomasz Chmielewski http://wpkg.org - 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 14/18] ide: add IDE_HFLAG_ABUSE_SET_DMA_MODE host flag
Hello, I wrote: It's tome that I go and make a patch which deals with 0x00 (default s/tome/time/ PIO mode)... But I'm unsure how this value could reach us form userspace because of the argument check present everywhere that filters out 0 value form being passed -- look at set_xfer_rate() and ide_cmd_ioctl(). So, such fix doesn't seem to be applicable... :-| +} return ide_set_dma_mode(drive, rate); } MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: > On 15-11-07 05:16, Bron Gondwana wrote: > >> Totally unrelated - I sent something to the kolab mailing list a couple > > [ ... ] > >> I'm sure if I had something that I considered worth informing the ALSA >> project of, I'd be wary of spending the same effort writing a good post >> knowing it may be dropped in between the by a list moderator just selecing >> all and bouncing them. > > Totally unrelated indeed so why are spouting crap? If the kohab list has a > problem take it up with them but keep ALSA out of it. alsa-devel has only > ever moderated out spam -- nothing else. As an outsider to the list, how do I know what your policy will be other than "I've been rejected out of hand by someone else's list, so my experience is that member only lists aren't willing to listen to something I have to say unless I make the effort to sign up and have yet another folder accumulating unread messages". I don't. Well, ok - maybe I do here since I've let myself be dragged in to the debate. Oops. I get the same information from both project websites: "moderated for non-members, public archives" - no way of knowing that ALSA will accept me informing them of something they would be interested without committing to reading or bit-bucketing their list. The alternative is to subscribe just long enough to send something and then unsubscribe again or cold-email a member and ask them to pass a message along. Or post and hope it doesn't get rejected, not even knowing for a day or so. Bron. - 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: [alsa-devel] [BUG] New Kernel Bugs
On 15-11-07 13:02, Bron Gondwana wrote: I get the same information from both project websites: "moderated for non-members, public archives" - no way of knowing that ALSA will accept me informing them of something they would be interested without committing to reading or bit-bucketing their list. Can you please just shelve this crap? You have a way of knowing that "ALSA will accept you" and that is knowing or assuming that the ALSA project doesn't consist of drooling retards. When a project list goes to the difficulty of moderating non-subscribers it has made the explicit choice to _not_ become subscriber only. Then refusing valid non-subscribers after all makes no sense whatsoever. I'm sorry you got your feelings hurt by that other list but it was no doubt an accident; take it up with them. Rene. - 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: [alsa-devel] [BUG] New Kernel Bugs
On Thu, 15 November 2007 13:26:51 +0100, Rene Herman wrote: > > Can you please just shelve this crap? You have a way of knowing that "ALSA > will accept you" and that is knowing or assuming that the ALSA project > doesn't consist of drooling retards. Well, my experience with moderation has been that moderated mails are stuck in some queue for weeks. Two seperate lists, neither of them was alsa. If also is doing a better job, great. But it still has to live with the general reputation of non-subscriber moderation. > When a project list goes to the difficulty of moderating non-subscribers it > has made the explicit choice to _not_ become subscriber only. Then refusing > valid non-subscribers after all makes no sense whatsoever. I'm sorry you > got your feelings hurt by that other list but it was no doubt an accident; > take it up with them. Been there, done that. In spite of people not being drooling retards, the amount of time and effort they invest into either moderation or improving the ruleset is quite limited. Problems persist. And even without mails being held hostage for weeks, every single moderation mail is annoying. Like the one I'm sure to receive after sending this out. Jörn -- Joern's library part 5: http://www.faqs.org/faqs/compression-faq/part2/section-9.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: [alsa-devel] [BUG] New Kernel Bugs
On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: > Totally unrelated indeed so why are spouting crap? If the kohab list has a > problem take it up with them but keep ALSA out of it. alsa-devel has only > ever moderated out spam -- nothing else. That is incorrect. Hopefully it is the case now though, since my experience of the subject was years ago. OG. - 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: [alsa-devel] [BUG] New Kernel Bugs
At Thu, 15 Nov 2007 14:17:27 +0100, Olivier Galibert wrote: > > On Thu, Nov 15, 2007 at 06:59:34AM +0100, Rene Herman wrote: > > Totally unrelated indeed so why are spouting crap? If the kohab list has a > > problem take it up with them but keep ALSA out of it. alsa-devel has only > > ever moderated out spam -- nothing else. > > That is incorrect. Hopefully it is the case now though, since my > experience of the subject was years ago. Yeah, it was really years ago that we once switched to the open list. Funny that people never forget such a thing :) Takashi - 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: FIS structure and Command List structure for AHCI SATA controller
Hi Jeff, Does kernel2.4 support this chip (Marvell's 88SE6121)? I assume kernel 2.4 supports AHCI device. Is there any patch for this chip I may apply? And which version of kernel2.4 shall I use? Thanks for your help, Mike On 11/9/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: > mike zheng wrote: > > Hi Jeff, > > > > Actually I am using Marvell's 88SE6121 on kernel 2.4. I just wonder do > > I have to enable the FIS? The SATA Command Table of the device have > > following definitions: > > > > 00h Command FIS > > 40h ATAPI Command (CDB) > > 60h RSVD > > 80h Physical Region Descriptor Table > > > > Does it mean I can only use FIS or ATAPI for this device? > > > > Another confusion is the manual say that software should prepare the > > command header, command FIS and the ATAPI command (CDB) for the ATAPI > > command. Why it needs the FIS for ATAPI command? > > > > Thanks for your help. > > FIS == basic data message used by all Serial ATA. > > Both SATA ATA and SATA ATAPI use a FIS, it is fundamental to the nature > of Serial ATA. > >Jeff > > > > - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On 15-11-07 14:00, Jörn Engel wrote: And even without mails being held hostage for weeks, every single moderation mail is annoying. Like the one I'm sure to receive after sending this out. Certainly. Upto this thread I wasn't actually aware the list was doing that. While it might be informative once, getting it each time quickly gets old. Don't know if mailman can do anything like it but I'd suggest anyone running a non-subscriber-moderation list configure it to send such messages at most once a per address or some such. And just disable the message if it cannot do that. Fortunately, alsa-devel is (almost) no longer such a list anyway as it's moving to vger. Hurrah. David -- thanks. Rene. - 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_mv: hard resetting port
Tomasz Chmielewski wrote: And today kernel (2.6.23.1) in the same machine have spoken to not-mere-mortals again: ata6: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x6 frozen ata6: edma_err 0x0020 .. Here, the messages fail us. The edma_err value says that there should be a non-zero value in the SErr value. Except the messages show zero there, meaning the registers were probably read in the wrong sequence (some bits clear automatically on reads). In any event, the messages that follow don't say anything about I/O failing in any way, so again this is nothing to be concerned about unless it happens frequently. At this point, I would unplug/replug all of the SATA cables, to ensure they have good connections. ata6: hard resetting port ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata6.00: configured for UDMA/133 ata6: EH complete sd 5:0:0:0: [sde] 781422768 512-byte hardware sectors (400088 MB) sd 5:0:0:0: [sde] Write Protect is off sd 5:0:0:0: [sde] Mode Sense: 00 3a 00 00 sd 5:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA As I understand it now, your previous translation would fit here (or not, as SErr differs?): > Translation: > "libata reset the link, and everything appeared okay, > so it reissued the failed command and continued. > No data loss." But why was the port reseted? There was no CRC error as before, was there? .. I think the error-handling code is a bit heavy handed, in that the port reset was not actually needed in the prior case either. But this way it is simple, consistent, and does work. It just prints too many messages. What worries me is that it always happens for the same drive. .. Twiddle with the cabling for that drive, and it will probably behave. - 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.23.1 - sata_mv (7042) hang with large file operations
I have a console - and have booted with "pci=nomsi" and the behavior is ~the same or even a little worse in some case (but not by much)... I will send kernel log & the .config file separately to you... (quite long)... Further, you should note that my arch/ppc does NOT have MSI Capability (CONFIG_PCI_MSI) - thus I think this might be Is there any debugging I can turn on in the proc or sysfs? that might give more clues (e.g.: /proc/sys/dev/scsi/logging_level)? t -Original Message- From: Mark Lord [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 14, 2007 5:30 PM To: Morrison, Tom Cc: Jeff Garzik; linux-ide@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: 2.6.23.1 - sata_mv (7042) hang with large file operations Morrison, Tom wrote: > I have gotten it to boot from those hard-drives and it > has the same behavior: > > Copying a large file to the same partition (>150MEG) > causes the system to hang (no I/O - no input/output - > nothing - complete freeze - like a primary resource > is locked up or interrupts got completely & totally > turned off in an ISR and its pending for something? > > Only way to get out of this is to power-cycle the box! .. Okay, a couple of things: Do this from a text console, not a GUI. And preferably without ever starting klogd/syslogd during init. That way you've a much better chance of seeing some kernel diagnostic messages when it locks up. Can you boot with "nomsi" kernel parameter? And I guess we'll need to see the entire kernel .config as well. This is a tricky one. The driver behaves fine for me here with a 7042 rev.2 on PCIe in my x86-32 box. Cheers - 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 Thu, 15 Nov 2007, Theodore Tso wrote: > On Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote: > > I don't see any reason that we couldn't have a tool accessible to Ubuntu > > users that does a real "git bisect". Git is really good at being scripted > > by fancy GUIs. It should be easy enough to have a drop down with all of > > the Ubuntu kernel package releases, where the user selects what works and > > what doesn't. > > It's possible users who haven't yet downloaded a git repository have > to surmount some obstacles that might cause them to lose interest. > First, they have to download some 190 megs of git repository, and if > they have a slow link, that can take a while, and then they have to > build each kernel, which can take a while. It should be possible for it to clone only the portion that they actually care about based on where the known-good version is. It should also (in theory, anyway) be possible to put off some amount of the download until it's actually going to be relevant. > A full kernel build with everything selected can take good 30 minutes or > more, and that's on a fast dual-core machine with 4gigs of memory and > 7200rpm disk drives. On a slower, memory limited laptop, doing a single > kernel build can take more time than the user has patiences; multiply > that by 7 or 8 build and test boots, and it starts to get tiresome. None of this is going to take as long, even on a slow link and a slow computer, as waiting for a response to a mailing list post. It'd annoy users who are specifically waiting for it, but if the interface is that the user says "kernel package X didn't work but the current kernel does", and it says "I'll let you know when I've got something to test", and the user watches a DVD, and afterward finds a message saying there's something to test, and tries it, and reports how it went, and the process repeats until it narrows it down to a single commit after a couple of days of the user getting occasional responses, it's not that different from asking for help online. > And then on top of that there are the issues about whether there is > enough support for dealing with hitting kernel revisions that fail due > to other bugs getting merged in during the -rc1 process, etc. Could have a distro-provided mask of things that aren't worth testing and possibly back-ported fixes for revisions in particular ranges. > I agree that a tool that automated the bisection process and walked > the user through it would be helpful, but I believe it would be > possible for us do better. That would probably help for giving the user something to try right away. I still think that the main cost to the user is the number of times that the user has to stop doing stuff to reboot with a kernel to test, whether the test kernels are available quickly from the distro site, slowly built locally, or slowly as suggested by humans helping online. -Daniel *This .sig left intentionally blank* - 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 Wed, Nov 14, 2007 at 06:23:34PM -0500, Daniel Barkalow wrote: > I don't see any reason that we couldn't have a tool accessible to Ubuntu > users that does a real "git bisect". Git is really good at being scripted > by fancy GUIs. It should be easy enough to have a drop down with all of > the Ubuntu kernel package releases, where the user selects what works and > what doesn't. It's possible users who haven't yet downloaded a git repository have to surmount some obstacles that might cause them to lose interest. First, they have to download some 190 megs of git repository, and if they have a slow link, that can take a while, and then they have to build each kernel, which can take a while. A full kernel build with everything selected can take good 30 minutes or more, and that's on a fast dual-core machine with 4gigs of memory and 7200rpm disk drives. On a slower, memory limited laptop, doing a single kernel build can take more time than the user has patiences; multiply that by 7 or 8 build and test boots, and it starts to get tiresome. And then on top of that there are the issues about whether there is enough support for dealing with hitting kernel revisions that fail due to other bugs getting merged in during the -rc1 process, etc. I agree that a tool that automated the bisection process and walked the user through it would be helpful, but I believe it would be possible for us do better. - Ted - 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.23.1 - sata_mv (7042) hang with large file operations
Additional information - the ~file size this is caused is somewhere close to 260Mbytesfiles. If I create a ~260Mbytes file - my program finishes creating the file - but ~5 seconds later (I timed this by hitting enter on the console every second after completion of the command that should have done a fsync of the created file before exiting)... It hangs... I did a little playing around with /proc/sys/dev/scsi/logging_level (set to 0x7) - and it seems that the kernel/box locks up after this line: >> scsi_add_timer: scmd: efca83c0, time: 7500, (c0160660) >> scsi_delete_timer: scmd: efca83c0, rtn: 1 >> scsi_add_timer: scmd: efca8840, time: 7500, (c0160660) Further analysis (setting logging level to 65535 (0x) Has the following behavior down low) - >> scsi_add_timer: scmd: efca8960, time: 7500, (c0160660) >> sd 0:0:0:0: [sda] Send: 0xefca8960 >> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 >> buffer = 0xc0553040, bufflen = 167936, done = 0xc016b194, queuecommand 0xc017ed34 >> leaving scsi_dispatch_cmnd() >> scsi_delete_timer: scmd: efca8960, rtn: 1 >> sd 0:0:0:0: [sda] Done: 0xefca8960 SUCCESS >> sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK >> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 >> sd 0:0:0:0: [sda] scsi host busy 1 failed 0 >> sd 0:0:0:0: Notifying upper driver of completion (result 0) >> >> scsi_add_timer: scmd: efca82a0, time: 7500, (c0160660) >> sd 0:0:0:0: [sda] Send: 0xefca82a0 >> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 93 6f 00 02 40 00 >> buffer = 0xef5734c0, bufflen = 294912, done = 0xc016b194, queuecommand 0xc017ed34 >> leaving scsi_dispatch_cmnd() Nothing more - it hangs! This is really a nasty problem - 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.23.1 - sata_mv (7042) hang with large file operations
Morrison, Tom wrote: Additional information - the ~file size this is caused is somewhere close to 260Mbytesfiles. If I create a ~260Mbytes file - my program finishes creating the file - but ~5 seconds later (I timed this by hitting enter on the console every second after completion of the command that should have done a fsync of the created file before exiting)... It hangs... I did a little playing around with /proc/sys/dev/scsi/logging_level (set to 0x7) - and it seems that the kernel/box locks up after this line: scsi_add_timer: scmd: efca83c0, time: 7500, (c0160660) scsi_delete_timer: scmd: efca83c0, rtn: 1 scsi_add_timer: scmd: efca8840, time: 7500, (c0160660) Further analysis (setting logging level to 65535 (0x) Has the following behavior down low) - scsi_add_timer: scmd: efca8960, time: 7500, (c0160660) sd 0:0:0:0: [sda] Send: 0xefca8960 sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 buffer = 0xc0553040, bufflen = 167936, done = 0xc016b194, queuecommand 0xc017ed34 leaving scsi_dispatch_cmnd() scsi_delete_timer: scmd: efca8960, rtn: 1 sd 0:0:0:0: [sda] Done: 0xefca8960 SUCCESS sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_OK,SUGGEST_OK sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 sd 0:0:0:0: [sda] scsi host busy 1 failed 0 sd 0:0:0:0: Notifying upper driver of completion (result 0) scsi_add_timer: scmd: efca82a0, time: 7500, (c0160660) sd 0:0:0:0: [sda] Send: 0xefca82a0 sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 93 6f 00 02 40 00 buffer = 0xef5734c0, bufflen = 294912, done = 0xc016b194, queuecommand 0xc017ed34 leaving scsi_dispatch_cmnd() Nothing more - it hangs! This is really a nasty problem .. Yes. It's particularly nasty because, as of yet, I haven't seen anything to lead me to conclude *which* kernel subsystem is locking up. It could be the block layer. It could be some PPC arch bug. It could be mm. It could even be the CPU scheduler. Those messages above could help. Now we just need somebody to interpret them, and examine the code paths that follow to see where it might be possible to get stuck. The SCSI/libata layers by themselves could lock up the I/O, but not the entire machine.. Cheers - 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_mv: hard resetting port
Eric D. Mudama wrote: On Nov 15, 2007 7:31 AM, Mark Lord <[EMAIL PROTECTED]> wrote: Here, the messages fail us. The edma_err value says that there should be a non-zero value in the SErr value. Except the messages show zero there, meaning the registers were probably read in the wrong sequence (some bits clear automatically on reads). Isn't that the reset signature? .. No, it's just funny status. The chipset (Marvell) claims it saw a SATA error. But the SATA error register is all-zeros, meaning "no error". I think somebody forgot to save the latter before clearing it, or somebody forgot to clear the former from an earlier error. Either way, a nuisance, but no harm done here. Maybe due to insufficient power the drive decided to reboot itself. (What bits clear automatically on read, other than IRQ?) .. Mmm.. none in this case (my mistake). - 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] cmd64x: don't clear the other channels interrupt
On Tuesday 13 November 2007 21:58:36 Bartlomiej Zolnierkiewicz wrote: > On Sunday 11 November 2007, Bartlomiej Zolnierkiewicz wrote: > > On Friday 09 November 2007, Sergei Shtylyov wrote: > > > Make sure to not clear the other IDE channel's interrupt when clearing > > > an IDE interrupt via the MRDMODE register. > > > > > > Thanks to Bart for finding a coding mistake. > > > > Could you resend with "Signed-off-by:" and "Tested-by:" tags? > > > > [ A reference to the problematic commit and crediting Martin for > > patiently bisecting the issue would score an extra points. :) ] > > Well, I dealt with it myself and just added "From:" (together > with "Tested-by:"-s and an enhanced patch description)... > > For the future please always run your patches through > scripts/checkpatch.pl before posting, this prevents missing > "Signed-off-by:" (and few other issues :). > > Thanks, > Bart Thank you all for help and resolution. And all the bisecting, with or without git, I didn't really mind doing since it is for the greater good. I've even learnt something new since my linux-m68k days. :) cu Martin - 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] sis5513.c: Add Packard Bell EasyNote K5305 to laptops
On Tuesday 13 November 2007, Gabriel C wrote: > Hi, > > With newer kernels HDD in my old laptop is limited to UDMA 33. > With this patch I get UDMA 100 again. > > Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/13] ide-cris: fix DMA methods
On Wednesday 14 November 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> > * Rename cris_dma_{on,off}() to cris_dma_host_{on,off}().
>
> Haven't you killed dma_on/dma_off_quietly() methods in the previosu patch?
Yes, I did.
I left fixing ide-cris after "kill dma_on/dma_off_quietly() methods"
patch because:
* Currently this driver is broken: cris_dma_on() (returns 'int')
is assigned to hwif->dma_host_on (returns 'void') so the driver
won't build.
* ->ide_dma_on method was missing so the driver OOPS-es on attempt
to enable DMA.
* drive->using_dma was never set/cleared so DMA wouldn't be used anyway.
Unfortunately it seems that ide-cris stays broken even after this patch:
* V10: needs fixing
- ide_init_default_hwifs() should be removed
(IDE core no longer uses it)
- same for ide_init_hwif_ports() and ide_default_{irq,io_base}()
(they shouldn't be needed for ide-cris host driver)
* V32: I'm unable to find a place which defines ETRAX_ARCH_V32
but I'm leaving fixing this to CRIS gurus. :)
[ I added the above explanation to the patch description. ]
> > * Remove no longer needed ->dma_off_quietly
> > (IDE core has the needed code now).
>
> > * Make cris_dma_host_on() void.
>
> > Cc: Mikael Starvik <[EMAIL PROTECTED]>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/18] ide: add IDE_HFLAG_ABUSE_SET_DMA_MODE host flag
Hi,
On Thursday 15 November 2007, Sergei Shtylyov wrote:
> Hello, I wrote:
>
> >It's tome that I go and make a patch which deals with 0x00 (default
>
> s/tome/time/
>
> > PIO mode)...
>
> But I'm unsure how this value could reach us form userspace because of
> the
> argument check present everywhere that filters out 0 value form being passed
> -- look at set_xfer_rate() and ide_cmd_ioctl(). So, such fix doesn't seem to
> be applicable... :-|
You are right, I was mislead by "if (arg < 0 || arg > 70)":
static int set_xfer_rate (ide_drive_t *drive, int arg)
{
int err;
if (arg < 0 || arg > 70)
return -EINVAL;
err = ide_wait_cmd(drive,
WIN_SETFEATURES, (u8) arg,
SETFEATURES_XFER, 0, NULL);
if (!err && arg) {
ide_set_xfer_rate(drive, (u8) arg);
ide_driveid_update(drive);
}
return err;
}
but value "1" is still theoretically possible. ;)
Anyway fixing 0x00 is a desirable thing as it is needed for cleanly
handling many older CF cards (they don't support IORDY).
Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers/ide/ide-probe.c, kernel 2.6.23.1
Hi,
On Thursday 15 November 2007, Jonas Stare wrote:
> Hi, thanks for the reply. :)
>
> Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Monday 12 November 2007, Andrew Morton wrote:
> >> On Fri, 09 Nov 2007 11:22:41 +0100 Jonas Stare <[EMAIL PROTECTED]> wrote:
> >>
> >>> Hi.
> >>>
> >>> This week I ran into a strange hardware problem. During boot I got a 35
> >>> second delay while waiting for IDE-disks that weren't there to report
> >
> > With what chipset and host driver does this happen?
>
> I am not sure about the chip-set but I think it was vt82c686b. It used
> the via82cxxx-driver, but only _after_ using the generic ide-code to
> probe/wait (a long time) for the disks. (This was in Suse 10.1 SP 1.)
AFAIK this means kernel version 2.6.16.xx.
If this is the case maybe the underlying problem has been already fixed
(but it doesn't mean that your patch is not worth applying, quite the
contrary).
> >>> that they were not in a BSY state. The problem was most likely in the
> >>> hardware but this patch enables you to ignore waiting for disks by
> >>> setting hdX=noprobe (and not setting the geometry by hand) as a kernel
> >>> option.
> >>>
> >>> If no noprobe-option is set the code will work (more or less) as the
> >>> original but if set the code will skip the ide_wait_not_busy() for that
> >>> drive. Even if there would be a drive there and it is still BSY
> >>> afterwards it should not matter since it isn't probed for later.
> >>>
> >>> There are other ways to get around the "35-seconds-of-waiting-in-vain",
> >>> like actually fix the hardware, insert a second drive that works or
> >>> recompile the kernel with edd-support builtin (atleast I've seen that
> >>> solution on a forum) and possibly others. But this patch would allow
> >>> people to get Linux to boot quickly on wonky hardware without having to
> >>> recompile anything.
> >>> (The code also honors the MAX_DRIVES variable instead of assuming that
> >>> ther will be 2 drives on the bus.)
> >> I keep on hearing about problems with boot-time IDE probing. It's public
> >> enemy #1 with the embedded guys.
> >
> > The problem is that we are not hearing about them.
> >
> > Please forward the reports to [EMAIL PROTECTED]
> >
> >> It does seem that operator intervention is needed in some fashion.
> >>
> >>> I will be happy for all the comments I can get. :) But be gentle, this
> >>> is my first patch...
> >
> > Jonas, could you also put printk() dumping content of 'stat' in
> > ide-iops.c::ide_wait_not_busy() so we can verify that it is not
> > some problem with ide_wait_not_busy() itself.
> >
>
> Sorry. :( I don't have access to the hardware anymore (which is a
> "home-made" embedded machine). But from what I could get from poking
> around was that the BSY-bit on the slave (that never has or ever will
> exists) was set, probably because those who built the thing wanted to
> save money and/or space on that "billionth of a cent"-resistor that Alan
> Cox talked about.
>
> >>>Best regards
> >>>Jonas Stare
> >>>
> >>> Signed-off-by: Jonas Stare <[EMAIL PROTECTED]>
> >>> --
> >>> diff -u linux-2.6.23.1-orig/drivers/ide/ide-probe.c
> >>> linux-2.6.23.1/drivers/ide/ide-probe.c
> >>> --- linux-2.6.23.1-orig/drivers/ide/ide-probe.c 2007-10-12
> >>> 18:43:44.0 +0200
> >>> +++ linux-2.6.23.1/drivers/ide/ide-probe.c 2007-11-09
> >>> 10:43:16.0 +0100
> >>> @@ -643,6 +643,7 @@
> >>> static int wait_hwif_ready(ide_hwif_t *hwif)
> >>> {
> >>> int rc;
> >>> + int unit;
> >>>
> >>> printk(KERN_DEBUG "Probing IDE interface %s...\n", hwif->name);
> >>>
> >>> @@ -659,20 +660,24 @@
> >>> return rc;
> >>>
> >
> > Hmm, so the first ide_wait_not_busy() (for the currently
> > selected device) is OK and doesn't stall?
> >
>
> It didn't stall for me... But even if it had, probe_hwif() will ignore
> the entire controller if you set "idex=noprobe".
>
> (From drivers/ide/ide-probe.c)
>
> static void probe_hwif(ide_hwif_t *hwif, void (*fixup)(ide_hwif_t *hwif))
> {
> unsigned int unit;
> unsigned long flags;
> unsigned int irqd;
>
> if (hwif->noprobe)
> return;
>
>
> >>> /* Now make sure both master & slave are ready */
> >>> - SELECT_DRIVE(&hwif->drives[0]);
> >>> - hwif->OUTB(8, hwif->io_ports[IDE_CONTROL_OFFSET]);
> >>> - mdelay(2);
> >>> - rc = ide_wait_not_busy(hwif, 35000);
> >>> - if (rc)
> >>> - return rc;
> >>> - SELECT_DRIVE(&hwif->drives[1]);
> >>> - hwif->OUTB(8, hwif->io_ports[IDE_CONTROL_OFFSET]);
> >>> - mdelay(2);
> >>> - rc = ide_wait_not_busy(hwif, 35000);
> >>> + for (unit = 0; unit < MAX_DRIVES; ++unit) {
> >>> + /* Ignore disks that we will not probe for later. */
> >>> + if (!hwif->drives[unit].noprobe ||
> >>> + hwif->drives[unit].forced_geom) {
> >
> > It i
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 10:34:37PM +, Russell King wrote: > On Tue, Nov 13, 2007 at 06:25:16PM +, Alan Cox wrote: > > > Given the wide range of ARM platforms today, it is utterly idiotic to > > > expect a single person to be able to provide responses for all ARM bugs. > > > I for one wish I'd never *VOLUNTEERED* to be a part of the kernel > > > bugzilla, and really *WISH* I could pull out of that function. > > > > You can. Perhaps that bugzilla needs to point to some kind of > > [EMAIL PROTECTED] list for the various ARM platform > > maintainers ? > > That might work - though it would be hard to get all the platform > maintainers to be signed up to yet another mailing list, I'm sure > sufficient would do. As long as it would just be bug reports, I'm sure that most of us could be persuaded to subscribe. Adding another list for general discussions is probably not going to be read, the current list provides more than enough to keep us busy. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. - 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.23.1 - sata_mv (7042) hang with large file operations
The plot thickens - it looks like it might be some type of problem interacting with the setup of my 4Gig DDR memory and how I setup some translation windows in my MPC8548E I realized this morning that I have an inbound/ output PEX window Translation Setup for mapping all from/to PEX bus to outside the physical 4GIG memory space (i.e.: up at 0xC__). Thus, all output operations that translation from 0xC__ to the pci 32 bit address of _) - and vice versa for for the inbound. Note: we also have a straight 1:1 translation mapping as well for the lower 4Gig - so that's why this worked without the below mentioned change... So, I changed the Request & Response Hi Addresses (which were Being shifted by 32 bits down anyways) and 'OR' that with my 0xC (so the effective 64bit DMA address is 0xC__ (where Xxxx_ is the effective address). This was what we did to solve the problem with the Marvel Linux driver that we got from the Marvel site This all works just fine with ONLY 2 gig of memory in the system (and still have these inbound/output pex translation windows), but fails when I put back the 4 Gig (and the 8Gig) DDR memory. Unfortunately, this still hasn't solved the problem though - so there is something else which I am not seeing? I have a couple more ideas - but this is a toughy -Original Message- Morrison, Tom wrote: > Additional information - the ~file size this is caused > is somewhere close to 260Mbytesfiles. > > If I create a ~260Mbytes file - my program finishes creating > the file - but ~5 seconds later (I timed this by hitting enter > on the console every second after completion of the command > that should have done a fsync of the created file before exiting)... > It hangs... > > I did a little playing around with /proc/sys/dev/scsi/logging_level > (set to 0x7) - and it seems that the kernel/box locks up after > this line: > >>> scsi_add_timer: scmd: efca83c0, time: 7500, (c0160660) >>> scsi_delete_timer: scmd: efca83c0, rtn: 1 >>> scsi_add_timer: scmd: efca8840, time: 7500, (c0160660) > > > Further analysis (setting logging level to 65535 (0x) > Has the following behavior down low) - > >>> scsi_add_timer: scmd: efca8960, time: 7500, (c0160660) >>> sd 0:0:0:0: [sda] Send: 0xefca8960 >>> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 >>> buffer = 0xc0553040, bufflen = 167936, done = 0xc016b194, > queuecommand > 0xc017ed34 >>> leaving scsi_dispatch_cmnd() >>> scsi_delete_timer: scmd: efca8960, rtn: 1 >>> sd 0:0:0:0: [sda] Done: 0xefca8960 SUCCESS >>> sd 0:0:0:0: [sda] Result: hostbyte=DID_OK > driverbyte=DRIVER_OK,SUGGEST_OK >>> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 92 27 00 01 48 00 >>> sd 0:0:0:0: [sda] scsi host busy 1 failed 0 >>> sd 0:0:0:0: Notifying upper driver of completion (result 0) >>> >>> scsi_add_timer: scmd: efca82a0, time: 7500, (c0160660) >>> sd 0:0:0:0: [sda] Send: 0xefca82a0 >>> sd 0:0:0:0: [sda] CDB: Write(10): 2a 00 00 47 93 6f 00 02 40 00 >>> buffer = 0xef5734c0, bufflen = 294912, done = 0xc016b194, > queuecommand > 0xc017ed34 >>> leaving scsi_dispatch_cmnd() > > Nothing more - it hangs! > > This is really a nasty problem .. Yes. It's particularly nasty because, as of yet, I haven't seen anything to lead me to conclude *which* kernel subsystem is locking up. It could be the block layer. It could be some PPC arch bug. It could be mm. It could even be the CPU scheduler. Those messages above could help. Now we just need somebody to interpret them, and examine the code paths that follow to see where it might be possible to get stuck. The SCSI/libata layers by themselves could lock up the I/O, but not the entire machine.. Cheers - 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.23.1 - sata_mv (7042) hang with large file operations
Morrison, Tom wrote:
The plot thickens - it looks like it might be some type
of problem interacting with the setup of my 4Gig DDR memory
and how I setup some translation windows in my MPC8548E
I realized this morning that I have an inbound/ output PEX window
Translation Setup for mapping all from/to PEX bus to outside
the physical 4GIG memory space (i.e.: up at 0xC__). Thus,
all output operations that translation from 0xC__ to
the pci 32 bit address of _) - and vice versa for for
the inbound. Note: we also have a straight 1:1 translation mapping
as well for the lower 4Gig - so that's why this worked without
the below mentioned change...
So, I changed the Request & Response Hi Addresses (which were
Being shifted by 32 bits down anyways) and 'OR' that with my
0xC (so the effective 64bit DMA address is 0xC__ (where
Xxxx_ is the effective address). This was what we did to
solve the problem with the Marvel Linux driver that we got from
the Marvel site
This all works just fine with ONLY 2 gig of memory in the system
(and still have these inbound/output pex translation windows),
but fails when I put back the 4 Gig (and the 8Gig) DDR memory.
Unfortunately, this still hasn't solved the problem though -
so there is something else which I am not seeing?
..
I don't know much about how 32-bit PPC deals with memory addresses
that are more than 32-bits..
But does this patch have any effect:
--- old/drivers/ata/sata_mv.c 2007-10-12 12:43:44.0 -0400
+++ linux/drivers/ata/sata_mv.c 2007-11-15 17:12:24.0 -0500
@@ -685,7 +685,7 @@
{
int rc;
- if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
+ if (0 && !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
rc = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
if (rc) {
rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
-
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: stable basic 4-port SATA card
On Thu, 15 Nov 2007, Jim Paris wrote: Jeff Breidenbach wrote: Thanks for the excellent rundown. sata_sil24: 3124/3132 chips don't have any outstanding serious problems. IRQ loss on PCI-X was the only recent serious known problem but it's fixed now. I'm still a little confused how to translate this known-good chipset to an actual buyable PCI card. It isn't obvious from basic web searching. I also look for 3124/3132 and these are some that I've found: (determined by specs, product reviews, looking closely at photos, etc, it's worth a double-check before deciding) 3132 PCIe: http://www.newegg.com/Product/Product.aspx?Item=N82E16816132010 http://www.newegg.com/Product/Product.aspx?Item=N82E16816855002 http://www.newegg.com/Product/Product.aspx?Item=N82E16816132011 http://www.newegg.com/Product/Product.aspx?Item=N82E16816132008 I have used the Syba without any problems: http://www.newegg.com/Product/Product.aspx?Item=N82E16815124027 John - 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 Thu, Nov 15, 2007 at 01:50:43PM +1100, Neil Brown wrote: > Virtual Folders. > > I use VM mode in EMACS, but I believe some other mail readers have the > same functionality. > I have a virtual folder called "nfs" which shows me all mail in my > inbox which has the string 'nfs' or 'lockd' in a To, Cc, or Subject > field. When I visit that folder, I see all mail about nfs, whether it > was sent to me personally, or to a relevant list, or to lkml. Hm (googling around for "mutt" and "virtual folders"): looks like I can get most of the way there in mutt with some macros based on its "limit" command: http://www.tummy.com/journals/entries/jafo_20060303_00 Thanks.--b. - 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.23.1 - sata_mv (7042) hang with large file operations
In the case of PCI (am no big expert on this)- I believe the code
allows you to address 32 bits at a time...you can see the the
effectve address resource address is some where around
0xea90 - but, if you have PHYS_64BIT & PTE_64BIT -
you get resource_types of 64bits...that you can manipulate accordingly.
In the case of the eDMA - its 64bit dma operations - thus, you
setup the hi portion (by shifting twice by 16 (you get compiler
warnings if you try to shiftg the size of the offset - a bug IMHO))
and thus, can play the game I mentioned below and use the power
of the PEX inbound/outbound translation windows to move your data
correctly to the appropriate 32 bit location...
This game works fine very well for 2.6.11 + kernel - there are a few
more tests I need to do (like setting mem=
and see if it works correctly...and then try again just a little bit above
PEX memory space (> ~0xea90) - if it works below & doesn't work
above - it points to a problem with sata_mv doing some type of operation
outside the dma engine that is corrupting memory -
Thats another issue how does memory dribble/scribbling (only side affect
I can think of if something is going wrong with this translation)?
I'll try your 'patch' and see if that has any affect as well (and the
associated side-affects...)
t
From: Mark Lord [mailto:[EMAIL PROTECTED]
Sent: Thu 11/15/2007 5:14 PM
To: Morrison, Tom
Cc: Jeff Garzik; linux-ide@vger.kernel.org; [EMAIL PROTECTED]
Subject: Re: 2.6.23.1 - sata_mv (7042) hang with large file operations
Morrison, Tom wrote:
> The plot thickens - it looks like it might be some type
> of problem interacting with the setup of my 4Gig DDR memory
> and how I setup some translation windows in my MPC8548E
>
> I realized this morning that I have an inbound/ output PEX window
> Translation Setup for mapping all from/to PEX bus to outside
> the physical 4GIG memory space (i.e.: up at 0xC__). Thus,
> all output operations that translation from 0xC__ to
> the pci 32 bit address of _) - and vice versa for for
> the inbound. Note: we also have a straight 1:1 translation mapping
> as well for the lower 4Gig - so that's why this worked without
> the below mentioned change...
>
> So, I changed the Request & Response Hi Addresses (which were
> Being shifted by 32 bits down anyways) and 'OR' that with my
> 0xC (so the effective 64bit DMA address is 0xC__ (where
> Xxxx_ is the effective address). This was what we did to
> solve the problem with the Marvel Linux driver that we got from
> the Marvel site
>
> This all works just fine with ONLY 2 gig of memory in the system
> (and still have these inbound/output pex translation windows),
> but fails when I put back the 4 Gig (and the 8Gig) DDR memory.
>
> Unfortunately, this still hasn't solved the problem though -
> so there is something else which I am not seeing?
..
I don't know much about how 32-bit PPC deals with memory addresses
that are more than 32-bits..
But does this patch have any effect:
--- old/drivers/ata/sata_mv.c 2007-10-12 12:43:44.0 -0400
+++ linux/drivers/ata/sata_mv.c 2007-11-15 17:12:24.0 -0500
@@ -685,7 +685,7 @@
{
int rc;
- if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
+ if (0 && !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
rc = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
if (rc) {
rc = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
-
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 6/13] sgiioc4: add ide_toggle_bounce() calls
On Tue, Nov 13, 2007 at 02:20:02PM +0300, Sergei Shtylyov wrote: > Bartlomiej Zolnierkiewicz wrote: > > >Add ide_toggle_bounce() call to ->ide_dma_on/->dma_off_quietly > >methods so they match generic __ide_dma_on()/ide_dma_off_quietly(). > > >Cc: Jeremy Higdon <[EMAIL PROTECTED]> > >Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> > > Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]> Tested on an Altix. Acked-by: Jeremy Higdon <[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: [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
