Re: Compact Flash performance...
On Thu, May 31, 2007 at 06:43:46PM -0400, Mark Lord wrote: > Jeff Garzik wrote: > >Mark Lord wrote: > >>Some cards may perform better when their "memory" interface is used > >>instead of the "I/O" interface, or vice-versa. I'm not sure which > >>of the two methods was selected by libata (probably the "memory" > >>interface). > > > >I am very CF-ignorant. How does libata select a memory or I/O interface > >on a CF device? > > Right. Usually we cannot select them, as it's the wires between > the ATA chipset (motherboard) and the CFCARD that determine this. CF cards support 3 modes (MEM, I/O and True IDE), and neither MEM nor I/O modes can talk IDE. Most often, the PIN 9 is simply shorted to the ground at the connector to set the card in True IDE mode, which makes it emulate a standard IDE disk. Cheers, Willy - 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.22 libata spindown
On Fri, 01 Jun 2007, Jeff Garzik wrote: > IIRC, Debian was the one OS that really did need a shutdown utility > update, as the message says :) Actually, editing /etc/init.d/halt is enough. Find the hddown="-h" and change it to hddown="". -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - 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: HPT374 IDE problem with 2.6.21.* kernels
On Sat, 2 Jun 2007, Sergei Shtylyov wrote: The log of a typical IDE reset is available here: http://petra.hos.u-szeged.hu/~wildy/syslog.gz This was the worst case: the IDE bus was resetted during the system boot. Could you try setting HPT374_ALLOW_ATA133_6 to 0 in drivers/ide/pci/hpt366.c and rebuild/reboot the kernel? Hi Sergei, This looks promising. Using a vanilla 2.6.22-rc3 I was able to reproduce the problem within a few seconds. With the above modification the machine is running under heavy disk I/O without problems since 30 minutes... Regards, Geller Sandor <[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: HPT374 IDE problem with 2.6.21.* kernels
On Sat, 2 Jun 2007, Sergei Shtylyov wrote: Hello. Andrew Morton wrote: I saw a similar report yesterday with '2.6.21.1 - 97% wait time on IDE operations' subject. After upgrading from 2.6.20.7 kernel to 2.6.21.1 my system started to reset infrequenly the IDE bus. In the syslog DMA timeout, resetting IDE bus messages appeared. I've changed the two disks attached to the HPT374 controller, and always the first disk had problems. I've replaced cables, plugged the disks into other IDE ports, but it was only a matter of time to experience an IDE reset. When I upgraded to 2.6.21.3 the resets became much more frequent, this time even DMA was disabled too on the first disk. I turned DMA back Manually with hdparm, and a few seconds of intense IO activity resulted in another IDE reset. Reverting back to 2.6.20.12 the problem seems to be gone. BTW I'm using the PATA driver for the HTP374, not the libata one. Is this a known problem/ is there a way I can help locating the cause of the problem? Yes, please post the boot log and the IDE reset log too for starters... (cc's added) WBR, Sergei Hi, The log of a typical IDE reset is available here: http://petra.hos.u-szeged.hu/~wildy/syslog.gz This was the worst case: the IDE bus was resetted during the system boot. Geller Sandor <[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
2.6.22-rc3 hibernate(?) disables SMART on ide
I have 2 ide disks. If I enable SMART and hibernate/suspend2disk, SMART is disabled when I resume. Same as in 2.6.21.1 cu:~# smartctl -son /dev/hda smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF ENABLE/DISABLE COMMANDS SECTION === SMART Enabled. cu:~# /usr/net/bin/hibernate [poweron resume here] cu:~# smartctl -a /dev/hda smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda ATA II family Device Model: ST320420A Serial Number:3CL04RKY Firmware Version: 3.21 User Capacity:20,404,101,120 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 4 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Fri Jun 1 22:37:15 2007 BST SMART support is: Available - device has SMART capability. SMART support is: Disabled SMART Disabled. Use option -s with argument 'on' to enable it. here's some syslog Jun 1 21:56:25 cu kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 Jun 1 21:56:25 cu kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Jun 1 21:56:25 cu kernel: VP_IDE: IDE controller at PCI slot :00:0f.1 Jun 1 21:56:25 cu kernel: ACPI: PCI Interrupt :00:0f.1[A] -> GSI 20 (level, low) -> IRQ 16 Jun 1 21:56:25 cu kernel: VP_IDE: chipset revision 6 Jun 1 21:56:25 cu kernel: VP_IDE: not 100%% native mode: will probe irqs later Jun 1 21:56:25 cu kernel: VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci:00:0f.1 Jun 1 21:56:25 cu kernel: ide0: BM-DMA at 0x9000-0x9007, BIOS settings: hda:DMA, hdb:DMA Jun 1 21:56:25 cu kernel: ide1: BM-DMA at 0x9008-0x900f, BIOS settings: hdc:pio, hdd:DMA Jun 1 21:56:25 cu kernel: Probing IDE interface ide0... Jun 1 21:56:25 cu kernel: Switched to high resolution mode on CPU 0 Jun 1 21:56:25 cu kernel: hda: ST320420A, ATA DISK drive Jun 1 21:56:25 cu kernel: hdb: Maxtor 5A300J0, ATA DISK drive Jun 1 21:56:25 cu kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Jun 1 21:56:25 cu kernel: Probing IDE interface ide1... Jun 1 21:56:25 cu kernel: hdd: PLEXTOR CD-R PX-W2410A, ATAPI CD/DVD-ROM drive Jun 1 21:56:25 cu kernel: ide1 at 0x170-0x177,0x376 on irq 15 Jun 1 21:56:25 cu kernel: hda: max request size: 128KiB Jun 1 21:56:25 cu kernel: hda: 39851760 sectors (20404 MB) w/2048KiB Cache, CHS=39535/16/63, UDMA(66) Jun 1 21:56:25 cu kernel: hda: cache flushes not supported Jun 1 21:56:25 cu kernel: hda: hda1 hda2 hda3 Jun 1 21:56:25 cu kernel: hdb: max request size: 512KiB Jun 1 21:56:25 cu kernel: hdb: 585940320 sectors (31 MB) w/2048KiB Cache, CHS=36473/255/63, UDMA(133) Jun 1 21:56:25 cu kernel: hdb: cache flushes supported Jun 1 21:56:25 cu kernel: hdb: hdb1 hdb2 anything else needed? David - 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: HPT374 IDE problem with 2.6.21.* kernels
Hello. Geller Sandor wrote: I saw a similar report yesterday with '2.6.21.1 - 97% wait time on IDE operations' subject. After upgrading from 2.6.20.7 kernel to 2.6.21.1 my system started to reset infrequenly the IDE bus. In the syslog DMA timeout, resetting IDE bus messages appeared. I've changed the two disks attached to the HPT374 controller, and always the first disk had problems. I've replaced cables, plugged the disks into other IDE ports, but it was only a matter of time to experience an IDE reset. When I upgraded to 2.6.21.3 the resets became much more frequent, this time even DMA was disabled too on the first disk. I turned DMA back Manually with hdparm, and a few seconds of intense IO activity resulted in another IDE reset. Reverting back to 2.6.20.12 the problem seems to be gone. BTW I'm using the PATA driver for the HTP374, not the libata one. Is this a known problem/ is there a way I can help locating the cause of the problem? Yes, please post the boot log and the IDE reset log too for starters... (cc's added) The log of a typical IDE reset is available here: http://petra.hos.u-szeged.hu/~wildy/syslog.gz This was the worst case: the IDE bus was resetted during the system boot. Could you try setting HPT374_ALLOW_ATA133_6 to 0 in drivers/ide/pci/hpt366.c and rebuild/reboot the kernel? MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.22 libata spindown
On 6/1/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: Tuncer Ayaz wrote: > I'm still seeing the libata warning that disks were not spun down > properly on the following two setups and am wondering whether I need > a new shutdown binary or the changeset mentioned below is not meant > to fix what I'm triggering by halt'ing. > > If it's not a bug I will try to update my shutdown utility and if > that does not work I promise not to bother lkml about a problem > caused by my userland. If it is a bug I hope it will be of interest > for 2.6.22 bug tracking. > > Setup 1: > SATA 1 Disks > AMD64 3200+ > nVidia nForce 3 250 (Ultra?) > Debian i386 Unstable > > Setup 2: > SATA 2 disks > Core 2 Duo E6600 > Intel 975X > Debian x86_64 Unstable > > Just to be clear what warning I'm talking about: > DISK MIGHT NOT BE SPUN DOWN PROPERLY. UPDATE SHUTDOWN UTILITY > For more info, visit http://linux-ata.org/shutdown.html IIRC, Debian was the one OS that really did need a shutdown utility update, as the message says :) Thanks for the confirmation. - 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: HPT374 IDE problem with 2.6.21.* kernels
Hello. Andrew Morton wrote: I saw a similar report yesterday with '2.6.21.1 - 97% wait time on IDE operations' subject. After upgrading from 2.6.20.7 kernel to 2.6.21.1 my system started to reset infrequenly the IDE bus. In the syslog DMA timeout, resetting IDE bus messages appeared. I've changed the two disks attached to the HPT374 controller, and always the first disk had problems. I've replaced cables, plugged the disks into other IDE ports, but it was only a matter of time to experience an IDE reset. When I upgraded to 2.6.21.3 the resets became much more frequent, this time even DMA was disabled too on the first disk. I turned DMA back Manually with hdparm, and a few seconds of intense IO activity resulted in another IDE reset. Reverting back to 2.6.20.12 the problem seems to be gone. BTW I'm using the PATA driver for the HTP374, not the libata one. Is this a known problem/ is there a way I can help locating the cause of the problem? Yes, please post the boot log and the IDE reset log too for starters... (cc's added) WBR, 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: HPT374 IDE problem with 2.6.21.* kernels
On Wed, 30 May 2007 11:30:00 +0200 (CEST) Geller Sandor <[EMAIL PROTECTED]> wrote: > Hi, > > I saw a similar report yesterday with '2.6.21.1 - 97% wait time on IDE > operations' subject. > > After upgrading from 2.6.20.7 kernel to 2.6.21.1 my system started to > reset infrequenly the IDE bus. In the syslog DMA timeout, resetting IDE > bus messages appeared. I've changed the two disks attached to the HPT374 > controller, and always the first disk had problems. I've replaced cables, > plugged the disks into other IDE ports, but it was only a matter of time > to experience an IDE reset. When I upgraded to 2.6.21.3 the resets became > much more frequent, this time even DMA was disabled too on the first disk. > I turned DMA back Manually with hdparm, and a few seconds of intense IO > activity resulted in another IDE reset. > > Reverting back to 2.6.20.12 the problem seems to be gone. BTW I'm using > the PATA driver for the HTP374, not the libata one. > > Is this a known problem/ is there a way I can help locating the cause of > the problem? > (cc's added) - 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.22 libata spindown
Tuncer Ayaz wrote: I'm still seeing the libata warning that disks were not spun down properly on the following two setups and am wondering whether I need a new shutdown binary or the changeset mentioned below is not meant to fix what I'm triggering by halt'ing. If it's not a bug I will try to update my shutdown utility and if that does not work I promise not to bother lkml about a problem caused by my userland. If it is a bug I hope it will be of interest for 2.6.22 bug tracking. Setup 1: SATA 1 Disks AMD64 3200+ nVidia nForce 3 250 (Ultra?) Debian i386 Unstable Setup 2: SATA 2 disks Core 2 Duo E6600 Intel 975X Debian x86_64 Unstable Just to be clear what warning I'm talking about: DISK MIGHT NOT BE SPUN DOWN PROPERLY. UPDATE SHUTDOWN UTILITY For more info, visit http://linux-ata.org/shutdown.html IIRC, Debian was the one OS that really did need a shutdown utility update, as the message says :) 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: [PATCH 2.6.21-mm1 2/2] sata_promise: SATAII-150/300 TX4 port numbering fix
Mikael Pettersson wrote:
Jeff Garzik writes:
> > +if ((pi->flags & (PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) ==
(PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) {
> > +is_sataii_tx4 = 1;
> > +dev_printk(KERN_INFO, &pdev->dev, "applying SATAII TX4 port
numbering workaround\n");
>
>...though I'm not sure the printk is really wanted. nonetheless, I
> applied it.
Thanks.
There's also the older "PATA port found\n", which is redundant
since libata will print "PATA" as it logs the corresponding ata dev.
I can remove both if you like.
Agreed, that would be nice.
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: [PATCH] sata_mv: new exception handling (hotplug, NCQ framework)
Tomasz Chmielewski wrote: Jeff Garzik schrieb: Below is a refresh of my on-going effort to convert sata_mv to the new exception handling framework. sata_mv is one of the last hold-outs, and its old-EH implementation blocks new features like hotplug and NCQ. It works for me on the one 50xx and one 60xx card I tested it on, but other testers reported regressions, which is why it is not yet upstream. Hi, If I'm correct, this patch won't make to 2.6.22, and the first possible inclusion would be 2.6.23? Correct... if that. No guarantee it will make 2.6.23 either, since it is low priority :( Could you summarize what other regressions were reported? I can't find much information about sata_mv regressiobs on linux-ide list (at least when looking at the subjects: lots of patches from you, and two reports from me). Dave Dillow and dean gaudet responded with reports that the BUG_ON/WARN_ON traps in would trigger: WARNING: at drivers/ata/sata_mv.c:1287 mv_qc_issue() and WARNING: at drivers/ata/sata_mv.c:1333 mv_get_crpb_status() which leads me to think that my sata_mv new-EH patches are accidentally turning on NCQ mode. I have a feeling that I will be able to reproduce this once I attach an NCQ-capable drive and re-test on my own systems, but again, haven't found the time :/ 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: [2/3] 2.6.22-rc3: known regressions v2
On 6/1/07, Salyzyn, Mark <[EMAIL PROTECTED]> wrote: Agree, but overstated somewhat. The card in question that the regression is reported against is not a released card and as such could have a flawed environment, Hardware, Firmware or other Incompatibility. The fix for the root cause will likely not touch the driver or the kernel So aacraid.reset_devices=1 works with Vivek's test system? YH - 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 v2.6.22-rc3
Jeff Garzik wrote: Upon quick review, it appears it should be 110ms. And actually the spec says 3ms. But to answer your question anyway... :) Actually the 3ms is the DRQ assertion delay. 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: Linux v2.6.22-rc3
On Fri, Jun 01, 2007 at 11:30:49AM -0700, Linus Torvalds wrote: > > There are no old drivers in F7 and beyond. > > # CONFIG_IDE is not set > > Ahh, that's certainly going to root out the issues. Now let's hope that > people install it.. Whilst it's too early to tell yet, there are a few really nasty bugs that made it into our final kernel (based on 2.6.21.3). For eg, a whole class of Dell laptops won't boot unless you boot with maxcpus=1 I root-caused this to one of tglx's patches that went into 2.6.21.2, but it's a head-scratcher as to why it's responsible. I'm praying that this is the worst of the 'cant install' bugs we get, and then I can just push out a 2.6.22 some time that will magically make all these problems go away. (Because .22 is going to be flawless right?) > (Fedora seems to make it hard on purpose to upgrade between major > revisions, but maybe that's just me not reading the docs as usual ;) Probably :-) I've done two successful upgrades yesterday, one with anaconda, and one using just rpm -U of the fedora-release rpm from F7 and then 'yum update'. (The former did go a little smoother though tbh). Dave -- http://www.codemonkey.org.uk - 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 v2.6.22-rc3
Linus Torvalds wrote:
On Fri, 1 Jun 2007, Jeff Garzik wrote:
With these old PATA devices, device reset is "six of one, half-dozen of the
other." Using SRST is the only way to kick some ATAPI devices into working:
http://suif.stanford.edu/~csapuntz/blackmagic.html#reset
Well, wouldn't it be a good thing to
1) if BUSY/DRQ is set even before you try the problem, obviously skip the
two polite cases, and go to #4
2) try to just do an IDENTIFY
3) if that doesn't work, do a HOST RESET and then try again
4) if that doesn't work, do the full SRST
(or some variation of the above).
Skipping reset means it doesn't get the device away from a state that
the previous boot may have configured itself to... standard "I didn't do
reset" problems you see with any hardware. Transfer modes and
removeable media status notification are the most notable that are left
in a semi-random state, but there are many other minor feature bits that
fall into this category as well.
(Btw, the 150ms wait after reset is really nasty. A few of those, and
we're wasting seconds during bootup. Why the hell does it do that, when
the old driver - and the spec - said 2ms?)
Upon quick review, it appears it should be 110ms. And actually the spec
says 3ms. But to answer your question anyway... :)
The basic libata probe came from the code procedure that is found in a
lot of PC BIOSen, even (IMO) more exposure than Linux: Hale Landis's
ATADRVR. See the attached code sample for the relevant procedure, or
the entire driver source code (PC DOS-style) at
http://www.ata-atapi.com/atadrvr.zip
Upon further review, it looks like the 110ms delay is only per-ATAPI
command, not during reset, as the sub_atapi_delay() calls don't actually
delay before the ATAPI signature has been detected.
I thought the default in Fedora was to use the PATA driver first? If so,
(see davej's reply)
Jeff
//*
//
// reg_config() - Check the host adapter and determine the
//number and type of drives attached.
//
// This process is not documented by any of the ATA standards.
//
// Infomation is returned by this function is in
// reg_config_info[] -- see ATAIO.H.
//
//*
int reg_config( void )
{
int numDev = 0;
unsigned char sc;
unsigned char sn;
unsigned char cl;
unsigned char ch;
unsigned char st;
unsigned char devCtrl;
// setup register values
devCtrl = CB_DC_HD15 | ( int_use_intr_flag ? 0 : CB_DC_NIEN );
// mark start of config in low level trace
trc_llt( 0, 0, TRC_LLT_S_CFG );
// assume there are no devices
reg_config_info[0] = REG_CONFIG_TYPE_NONE;
reg_config_info[1] = REG_CONFIG_TYPE_NONE;
// set up Device Control register
pio_outbyte( CB_DC, devCtrl );
// lets see if there is a device 0
pio_outbyte( CB_DH, CB_DH_DEV0 );
DELAY400NS;
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
pio_outbyte( CB_SC, 0xaa );
pio_outbyte( CB_SN, 0x55 );
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x55 ) && ( sn == 0xaa ) )
reg_config_info[0] = REG_CONFIG_TYPE_UNKN;
// lets see if there is a device 1
pio_outbyte( CB_DH, CB_DH_DEV1 );
DELAY400NS;
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
pio_outbyte( CB_SC, 0xaa );
pio_outbyte( CB_SN, 0x55 );
pio_outbyte( CB_SC, 0x55 );
pio_outbyte( CB_SN, 0xaa );
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x55 ) && ( sn == 0xaa ) )
reg_config_info[1] = REG_CONFIG_TYPE_UNKN;
// now we think we know which devices, if any are there,
// so lets try a soft reset (ignoring any errors).
pio_outbyte( CB_DH, CB_DH_DEV0 );
DELAY400NS;
reg_reset( 0, 0 );
// lets check device 0 again, is device 0 really there?
// is it ATA or ATAPI?
pio_outbyte( CB_DH, CB_DH_DEV0 );
DELAY400NS;
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x01 ) && ( sn == 0x01 ) )
{
reg_config_info[0] = REG_CONFIG_TYPE_UNKN;
cl = pio_inbyte( CB_CL );
ch = pio_inbyte( CB_CH );
st = pio_inbyte( CB_STAT );
if ( ( cl == 0x14 ) && ( ch == 0xeb ) )
reg_config_info[0] = REG_CONFIG_TYPE_ATAPI;
else
if ( ( cl == 0x00 ) && ( ch == 0x00 ) && ( st != 0x00 ) )
reg_config_info[0] = REG_CONFIG_TYPE_ATA;
}
// lets check device 1 again, is device 1 really there?
// is it ATA or ATAPI?
pio_outbyte( CB_DH, CB_DH_DEV1 );
DELAY400NS;
sc = pio_inbyte( CB_SC );
sn = pio_inbyte( CB_SN );
if ( ( sc == 0x01 ) && ( sn == 0x01 ) )
{
reg_config_info[1] = REG_CONFIG_TYPE_UNKN;
cl = pio_inbyte( CB_CL );
ch = pio_inbyte( CB_CH );
st = pio_inbyte( CB_STAT );
if ( ( cl == 0x14 ) && ( ch == 0xeb ) )
Re: Linux v2.6.22-rc3
On Fri, 1 Jun 2007, Dave Jones wrote: > > There are no old drivers in F7 and beyond. > > # CONFIG_IDE is not set Ahh, that's certainly going to root out the issues. Now let's hope that people install it.. (Fedora seems to make it hard on purpose to upgrade between major revisions, but maybe that's just me not reading the docs as usual ;) Linus - 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/3] 2.6.22-rc3: known regressions v2
Agree, but overstated somewhat. The card in question that the regression is reported against is not a released card and as such could have a flawed environment, Hardware, Firmware or other Incompatibility. The fix for the root cause will likely not touch the driver or the kernel. It does raise the specter of a possible follow-on patch to address the root cause under kdump should we determine that the problem can not be solved in time of release of the Firmware of the current pre-released card or if we discover that other released cards have a similar Firmware or Hardware bug. Speculation such as these do not belong on kernel regression reports IMHO. Sincerely -- Mark Salyzyn > -Original Message- > From: Vivek Goyal [mailto:[EMAIL PROTECTED] > Sent: Friday, June 01, 2007 1:54 PM > To: Andrew Morton > Cc: Michal Piotrowski; Linus Torvalds; LKML; > [EMAIL PROTECTED]; Robert de Rooy; Alan Cox; > Tejun Heo; linux-ide@vger.kernel.org; Jeff Garzik; Gregor > Jasny; [EMAIL PROTECTED]; James Bottomley; AACRAID; > Yinghai Lu; Vivek Goyal; [EMAIL PROTECTED]; David > Miller; Mikael Pettersson > Subject: Re: [2/3] 2.6.22-rc3: known regressions v2 > > > On Fri, Jun 01, 2007 at 09:01:15AM -0700, Andrew Morton wrote: > > On Fri, 01 Jun 2007 14:20:55 +0200 Michal Piotrowski > <[EMAIL PROTECTED]> wrote: > > > > > SCSI > > > > > > Subject: aacraid: adapter kernel panic'd fffd (kexec) > > > References : http://lkml.org/lkml/2007/5/29/491 > > > Submitter : Yinghai Lu <[EMAIL PROTECTED]> > > > Handled-By : Salyzyn, Mark <[EMAIL PROTECTED]> > > > Vivek Goyal <[EMAIL PROTECTED]> > > > Status : problem is being debugged > > > > Mark's > aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is > > known to fix this, so we can move this to "known > regressions with patches" > > Hi Andrew, > > aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is meant > to ensure that we don't perform an unnecessary reset of the device > during a kexec boot. During kexec, we perform the device_shutdown() > which should bring the device to a known sane state and a reset is > not required while next kernel is coming up. > > I think this fix just masks Yinghai's problem and as such does not > fix the root cause of the problem. In his case a software reset > of the card is not successful and this is a problem. This problem > will become visible during kdump. > > So I would think that this regression is still there just that got > shifted from kexec to kdump. > > But we do need above patch to make sure kexec boot is fast and does > not perform any unrequired device reset. > > Thanks > Vivek > > > - 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 v2.6.22-rc3
On Fri, Jun 01, 2007 at 10:59:51AM -0700, Linus Torvalds wrote: > > I'm mainly interested in hearing feedback from Fedora 7 damage, before > > making > > a major decision about the probing code. If this is a single dain bramaged > > device, we should avoid punishing the majority. But if this is a trend, it > > warrants careful reconsideration. > > I thought the default in Fedora was to use the PATA driver first? If so, > you're going to miss a lot of cases that "just work", because they use the > old driver. There are no old drivers in F7 and beyond. # CONFIG_IDE is not set Dave -- http://www.codemonkey.org.uk - 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/3] 2.6.22-rc3: known regressions v2
On Fri, Jun 01, 2007 at 09:01:15AM -0700, Andrew Morton wrote: > On Fri, 01 Jun 2007 14:20:55 +0200 Michal Piotrowski <[EMAIL PROTECTED]> > wrote: > > > SCSI > > > > Subject: aacraid: adapter kernel panic'd fffd (kexec) > > References : http://lkml.org/lkml/2007/5/29/491 > > Submitter : Yinghai Lu <[EMAIL PROTECTED]> > > Handled-By : Salyzyn, Mark <[EMAIL PROTECTED]> > > Vivek Goyal <[EMAIL PROTECTED]> > > Status : problem is being debugged > > Mark's aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is > known to fix this, so we can move this to "known regressions with patches" Hi Andrew, aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is meant to ensure that we don't perform an unnecessary reset of the device during a kexec boot. During kexec, we perform the device_shutdown() which should bring the device to a known sane state and a reset is not required while next kernel is coming up. I think this fix just masks Yinghai's problem and as such does not fix the root cause of the problem. In his case a software reset of the card is not successful and this is a problem. This problem will become visible during kdump. So I would think that this regression is still there just that got shifted from kexec to kdump. But we do need above patch to make sure kexec boot is fast and does not perform any unrequired device reset. Thanks Vivek - 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 v2.6.22-rc3
On Fri, 1 Jun 2007, Jeff Garzik wrote: > > With these old PATA devices, device reset is "six of one, half-dozen of the > other." Using SRST is the only way to kick some ATAPI devices into working: > http://suif.stanford.edu/~csapuntz/blackmagic.html#reset Well, wouldn't it be a good thing to 1) if BUSY/DRQ is set even before you try the problem, obviously skip the two polite cases, and go to #4 2) try to just do an IDENTIFY 3) if that doesn't work, do a HOST RESET and then try again 4) if that doesn't work, do the full SRST (or some variation of the above). That at least has the potential to get you six working devices, and half a dozen other working devices, for a total of 12. With no unnecessary resets or long timeouts! (Btw, the 150ms wait after reset is really nasty. A few of those, and we're wasting seconds during bootup. Why the hell does it do that, when the old driver - and the spec - said 2ms?) > I'm mainly interested in hearing feedback from Fedora 7 damage, before making > a major decision about the probing code. If this is a single dain bramaged > device, we should avoid punishing the majority. But if this is a trend, it > warrants careful reconsideration. I thought the default in Fedora was to use the PATA driver first? If so, you're going to miss a lot of cases that "just work", because they use the old driver. At least that was what my situation was on the P4 that I recently complained about the "set transfer mode" problem: it used to use the old PATA drivers that didn't have the issue, so I never even _knew_ the new libata-based code had problems. Linus - 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 v2.6.22-rc3
Linus Torvalds wrote: On Fri, 1 Jun 2007, Jeff Garzik wrote: I'm about to dive into some heads-down RHEL backporting (whee), so I cannot look at the code in depth this weekend, but here are my basic thoughts: * We knew there would be fallout from the new reset-sequence code, and this is clearly in that category. * It worked before #reset-seq merge AFAICT, which implies the old method of probing -- which included SRST -- worked. Well, I don't think it really "worked" before. It apparently always had a bad 30-second timeout (probably because the reset just didn't work at all). It's just that the old code didn't care, and since the identify then worked, it was all good. Ah, indeed. I certainly prefer the old result to the new one. With these old PATA devices, device reset is "six of one, half-dozen of the other." Using SRST is the only way to kick some ATAPI devices into working: http://suif.stanford.edu/~csapuntz/blackmagic.html#reset I'm mainly interested in hearing feedback from Fedora 7 damage, before making a major decision about the probing code. If this is a single dain bramaged device, we should avoid punishing the majority. But if this is a trend, it warrants careful reconsideration. The current code already has the IDENTIFY retry stuff, so it sounds like restoring the "don't care" part should be enough to restore the older behavior. 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: Linux v2.6.22-rc3
On Fri, 1 Jun 2007, Jeff Garzik wrote: > > I'm about to dive into some heads-down RHEL backporting (whee), so I cannot > look at the code in depth this weekend, but here are my basic thoughts: > > * We knew there would be fallout from the new reset-sequence code, and this is > clearly in that category. > > * It worked before #reset-seq merge AFAICT, which implies the old method of > probing -- which included SRST -- worked. Well, I don't think it really "worked" before. It apparently always had a bad 30-second timeout (probably because the reset just didn't work at all). It's just that the old code didn't care, and since the identify then worked, it was all good. Linus - 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 v2.6.22-rc3
Tejun Heo wrote: Most BIOSen, Windows and old IDE driver don't reset at all during probing. They first issue IDENTIFY unconditionally, if that fails, IDENTIFY_PACKET. From the beginning, libata has issued reset during Not true for BIOS. A large sub-section of BIOS (Phoenix and/or Award-based BIOSen) do SRST along with the Hale Landis device detection (ata_devchk in libata-core.c). Ditto for several ATA vendor BIOS found on the card. I'm about to dive into some heads-down RHEL backporting (whee), so I cannot look at the code in depth this weekend, but here are my basic thoughts: * We knew there would be fallout from the new reset-sequence code, and this is clearly in that category. * It worked before #reset-seq merge AFAICT, which implies the old method of probing -- which included SRST -- worked. * If this was a major problem, I would think there would be a flood of bug reports for Fedora 7 (just released, and in testing w/ #reset-seq for a little while), since it is using libata for PATA as well as SATA. So this, just this one bug report right? I would go back and look at the differences in the low-level register bitbanging, and what specifically changed there. If the old stuff worked, that tends to imply a problem with the new stuff... 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: [2/3] 2.6.22-rc3: known regressions v2
On Fri, 01 Jun 2007 14:20:55 +0200 Michal Piotrowski <[EMAIL PROTECTED]> wrote: > SCSI > > Subject: aacraid: adapter kernel panic'd fffd (kexec) > References : http://lkml.org/lkml/2007/5/29/491 > Submitter : Yinghai Lu <[EMAIL PROTECTED]> > Handled-By : Salyzyn, Mark <[EMAIL PROTECTED]> > Vivek Goyal <[EMAIL PROTECTED]> > Status : problem is being debugged Mark's aacraid-fix-shutdown-handler-to-also-disable-interrupts.patch is known to fix this, so we can move this to "known regressions with patches" - 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/3] 2.6.22-rc3: known regressions with patches v2
Hi all, Here is a list of some known regressions in 2.6.22-rc3 with patches available. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions Memory management Subject: bug in i386 MTRR initialization References : http://lkml.org/lkml/2007/5/19/93 Submitter : Andrea Righi <[EMAIL PROTECTED]> Status : patch available PCI Subject: Oops on 2.6.22-rc2 when unloading the cciss driver References : http://lkml.org/lkml/2007/5/24/172 Submitter : Mike Miller (OS Dev) <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/5/31/387 Status : patch available SATA/PATA Subject: libata reset-seq merge broke sata_sil on sh References : http://lkml.org/lkml/2007/5/10/63 Submitter : Paul Mundt <[EMAIL PROTECTED]> Handled-By : Tejun Heo <[EMAIL PROTECTED]> Caused-By : commit 4750def52cb2c21732dda9aa1d43a07db37b0186 Patch : http://lkml.org/lkml/2007/5/19/161 Status : patch available Timers Subject: timer statistics oops References : http://lkml.org/lkml/2007/5/29/399 Submitter : Ian Kumlien <[EMAIL PROTECTED]> Handled-By : Thomas Gleixner <[EMAIL PROTECTED]> Björn Steinbrink <[EMAIL PROTECTED]> Patch : http://lkml.org/lkml/2007/5/31/394 Status : patch was suggested Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej" - 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/3] 2.6.22-rc3: known regressions v2
Hi all, Here is a list of some known regressions in 2.6.22-rc3. Feel free to add new regressions/remove fixed etc. http://kernelnewbies.org/known_regressions PCMCIA Subject: libata and legacy ide pcmcia failure References : http://lkml.org/lkml/2007/5/17/305 Submitter : Robert de Rooy <[EMAIL PROTECTED]> Status : Unknown SATA/PATA Subject: 22-rc3 broke the CDROM in Dell notebook References : http://lkml.org/lkml/2007/5/27/63 Submitter : Gregor Jasny <[EMAIL PROTECTED]> Handled-By : Tejun Heo <[EMAIL PROTECTED]> Jeff Garzik <[EMAIL PROTECTED]> Caused-By : Tejun Heo <[EMAIL PROTECTED]> commit d4b2bab4f26345ea1803feb23ea92fbe3f6b77bc Status : problem is being debugged SCSI Subject: aacraid: adapter kernel panic'd fffd (kexec) References : http://lkml.org/lkml/2007/5/29/491 Submitter : Yinghai Lu <[EMAIL PROTECTED]> Handled-By : Salyzyn, Mark <[EMAIL PROTECTED]> Vivek Goyal <[EMAIL PROTECTED]> Status : problem is being debugged Sparc64 Subject: 2.6.22-rc broke X on Ultra5 References : http://lkml.org/lkml/2007/5/22/78 Submitter : Mikael Pettersson <[EMAIL PROTECTED]> Handled-By : David Miller <[EMAIL PROTECTED]> Status : problem is being debugged Regards, Michal -- "Najbardziej brakowało mi twojego milczenia." -- Andrzej Sapkowski "Coś więcej" - 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
