headers
Norman Diamond | 1 Mar 2009 01:58
Picon
Favicon

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

Robert Hancock wrote:
> Norman Diamond wrote:
>> [attribution stolen:]
>>
>>> Libata should be used for any new setup that doesn't have a strict 
>>> legacy requirement now.
>>
>> 90% agreed.  However, I've read that libata will never support add-on IDE 
>> boards.
>
> Huh? It already does support most or all that one is likely to see..

That is good news then.

Last week when searching for articles about Slax and libata, I found various 
postings about methods that temporarily worked but no longer (for example 
there used to be a kernel boot parameter for the combined mode of some Intel 
chipsets, and there used to be a parameter to disable probing by 
ide_generic).  While not finding a way to get a particular chipset to be 
recognized as /dev/sda instead of /dev/hda, I also found other articles 
explaining various limitations of libata.  Some said that SATA is the 
priority for libata as it should be, but PATA was low priority with just 
enough effort to get it working with common legacy IDE controllers, and 
add-on IDE boards were zero priority.  My troubles last week were with 
notebook PCs that didn't have add-on IDE cards, but I will also have to 
support add-on IDE cards.

If anyone here knows how to put libata in control of chipsets that could be 
claimed by either libata or legacy ide, please say.  As mentioned I found 
various postings by others that temporarily worked but no longer.  It was
(Continue reading)

Permalink | Reply | 8 comments |
headers
Alan Cox | 1 Mar 2009 02:16
Picon

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

> If anyone here knows how to put libata in control of chipsets that could be 
> claimed by either libata or legacy ide, please say.  As mentioned I found 

Just compile in the libata drivers you need not the old IDE ones. Simple
as that.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Andrew Schepler | 1 Mar 2009 02:57
Picon

Re: 2.6.28.7 boot problems

> Now I'm going to go try some e2fsck -cc /dev/hda3 and/or badblocks -n
> /dev/hda[12] to see if any disk problems turn up that way.

No bad blocks found.

On closer inspection of the dmesg, it looks like those CRC errors only
come up when the kernel is (attempting to?) set DMA modes, and never
again.  So I don't know if I'm actually using DMA or not, but I now
have a working, probably relatively safe, kernel.

-- Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Martin Michlmayr | 1 Mar 2009 08:59

Re: [RFC][PATCH] sata_mv: harddisk activity led no longer responsive on QNAP TS-109

* saeed bishara <saeed.bishara <at> gmail.com> [2009-02-24 11:33]:
> What I think is that this issue is seen with the specific disk that
> you have, the chip blinks the LED depending on the BUSY bit status,
> and I suspect that with the disk you have does clear that bit
> immediately after receiving the command FIS, so the LED will be off,
> though the command is not completed yet, and this makes the led
> responsiveness differ that in NCQ-disabled mode.

The LED issue was reported by two people on the QNAP forum the other
day.  I asked what disks they had and one has a WDC WD7500AACS-00D6B0
whereas the other one has a WDC WD10EADS-00L5B1.  Do you also use a
WDC disk, Frans?

References:
http://forum.qnap.com/viewtopic.php?f=147&t=1344&start=220#p55925
http://forum.qnap.com/viewtopic.php?f=147&t=1344&start=220#p56027
http://forum.qnap.com/viewtopic.php?f=147&t=1344&start=230#p56351
--

-- 
Martin Michlmayr
http://www.cyrius.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Robert Hancock | 1 Mar 2009 12:06
Picon

Re: Kernel bug crashing in HDIO_DRIVE_TASKFILE

Norman Diamond wrote:
> Robert Hancock wrote:
>> Norman Diamond wrote:
>>> [attribution stolen:]
>>>
>>>> Libata should be used for any new setup that doesn't have a strict 
>>>> legacy requirement now.
>>>
>>> 90% agreed.  However, I've read that libata will never support add-on 
>>> IDE boards.
>>
>> Huh? It already does support most or all that one is likely to see..
> 
> That is good news then.
> 
> Last week when searching for articles about Slax and libata, I found 
> various postings about methods that temporarily worked but no longer 
> (for example there used to be a kernel boot parameter for the combined 
> mode of some Intel chipsets, and there used to be a parameter to disable 
> probing by ide_generic).  While not finding a way to get a particular 
> chipset to be recognized as /dev/sda instead of /dev/hda, I also found 
> other articles explaining various limitations of libata.  Some said that 
> SATA is the priority for libata as it should be, but PATA was low 
> priority with just enough effort to get it working with common legacy 
> IDE controllers, and add-on IDE boards were zero priority.  My troubles 

That's probably a fairly old article, not really the way things are today.

> last week were with notebook PCs that didn't have add-on IDE cards, but 
> I will also have to support add-on IDE cards.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tejun Heo | 1 Mar 2009 13:26

Re: ahci fails with SATA DVD drive, IDE mode works

Hello, Chuck.

Chuck Ebbert wrote:
> The other machine has what seems to be a "real" SATA DVD writer in it.
> It reports udma5 as the connect speed. This one seems to be a PATA drive
> with an internal SATA bridge and is connecting as mwdma2.

Ah... that makes sense.  libata has problem with ATAPI devices
connected over a SATA-PATA bridge.  Albert Lee tried to track it down
a while ago but it never got resolved.  :-(

Tracking things like this can be quite difficult.  Eh... having SATA
tracer would be nice.  Oh well...

>>> ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
>>> ata2.00: cmd a0/01:00:00:00:02/00:00:00:00:00/a0 tag 0 dma 512 in
>>>          cdb a1 08 2e 00 00 00 00 00  40 ec 00 00 00 00 00 00
>>>          res 40/00:02:00:08:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
>>> ata2.00: status: { DRDY }
>>> ata2: hard resetting link
>>> ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> ata2.00: configured for MWDMA2
>>> ata2: EH complete
>> Here, BLANK has timed out but the device was recovered okay.
>>
> 
> I ran 'hdparm -I' here. Why would it send BLANK to the drive??
> (There was a 1.4 GB DVD-RW in the drive when I did that.)

CDB 0xa1 is BLANK alright.  Is the problem reproducible?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tejun Heo | 1 Mar 2009 13:51

Re: ATAPI question

Hello,

Robert Hancock wrote:
>> Using a SATA analyzer, I find that on an INQUIRY (12h) ATAPI packet
>> command, the device sets bit-6 (DRDY) and bit-4 (SERV) in the status
>> register, and bits 0 (CoD) and 1 (IO) are set in the ATAPI Interrupt
>> Reason Register (ATA Sector Count Register).  After SERVICE is flagged
>> by the ATAPI device (and not serviced), it doesn't respond properly
>> from then on.
> 
> Bit 4 isn't SERV in this context, it's DRQ. (It's only SERV when TCQ is
> in use, which it isn't.) It looks like this is a READ CAPACITY command
> that's being issued by PIO. DRQ means the device expects to transfer
> data - either to receive the CDB or send the response. Presumably that
> didn't happen for some reason. Are you sure about both the C/D and I/O
> bits being 1? That would mean command transfer to the host, which
> doesn't make any sense.
> 
> You're saying that DRQ never gets cleared after the INQUIRY command?
> It's possible the device wanted to transfer more data than the PRD table
> had room for. Not sure what AHCI ends up doing in this case. I'm CCing
> Tejun who might know more..

libata always prepares for extra space for draining so I doubt that.
Any chance you can post the traces?

--

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
(Continue reading)

Permalink | Reply | 13 comments |
headers
Frans Pop | 1 Mar 2009 13:44
Picon

Re: [RFC][PATCH] sata_mv: harddisk activity led no longer responsive on QNAP TS-109

On Sunday 01 March 2009, Martin Michlmayr wrote:
> * saeed bishara <saeed.bishara <at> gmail.com> [2009-02-24 11:33]:
> > What I think is that this issue is seen with the specific disk that
> > you have, the chip blinks the LED depending on the BUSY bit status,
> > and I suspect that with the disk you have does clear that bit
> > immediately after receiving the command FIS, so the LED will be off,
> > though the command is not completed yet, and this makes the led
> > responsiveness differ that in NCQ-disabled mode.
>
> The LED issue was reported by two people on the QNAP forum the other
> day.  I asked what disks they had and one has a WDC WD7500AACS-00D6B0
> whereas the other one has a WDC WD10EADS-00L5B1.  Do you also use a
> WDC disk, Frans?

I always was rather doubtful of Saeed's analysis (with all due respect), 
but it's good to see confirmed that the same problem manifests with other 
disks too.

I have a completely different HD:
Model Family:     Hitachi Deskstar T7K250 series
Device Model:     HDT722516DLA380
Firmware Version: V43OA91A
User Capacity:    164,696,555,520 bytes

Cheers,
FJP
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gao, Yunpeng | 1 Mar 2009 15:54
Picon
Favicon

Can I set 8KB hardware sector size in blk_queue_hardsect_size() ?


I'm developing a standalone nand flash driver. The driver use blk_queue_hardsect_size() to set hardware
sector size. Usually I set it to the actuall nand flash page size. When I use a 4KB page nand part, it works
well. But when I tried a new type nand part (which has 8KB page), it reports the BUG as below (the kernel is
linux 2.6.29 rc3):
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[    8.092337] In GLOB_SBD_init: Num blocks=8192, pagesperblock=128, pagedatasize=8192,
ECCBytesPerSector=52, SizeofGlobalMem=7537298
        ... ...
[   10.722900] drivers/block/spectra/ffsport.c, Line 679, Function: SBD_setup_device
        ... ...
[   10.762575] Capacity sects: 14983168
[   10.772499] drivers/block/spectra/ffsport.c, Line 741
[   10.785306] drivers/block/spectra/ffsport.c, Line 515, Function: GLOB_SBD_open
[   10.804700]  nda:<1>BUG: unable to handle kernel NULL pointer dereference at (null)
[   10.826715] IP: [<c0187ce7>] create_empty_buffers+0x16/0x88
[   10.839146] *pde = 00000000
[   10.849146] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
[   10.849146] last sysfs file:
[   10.849146]
[   10.849146] Pid: 1, comm: swapper Not tainted (2.6.29-rc3-developer #60)
[   10.849146] EIP: 0060:[<c0187ce7>] EFLAGS: 00010292 CPU: 0
[   10.849146] EIP is at create_empty_buffers+0x16/0x88
[   10.849146] EAX: 00000000 EBX: c16ee65c ECX: 00000001 EDX: 00002000
[   10.849146] ESI: 00000000 EDI: 00000000 EBP: cecc7d30 ESP: cecc7d24
[   10.849146]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[   10.849146] Process swapper (pid: 1, ti=cecc6000 task=cecc4020 task.ti=cecc6000)
[   10.849146] Stack:
[   10.849146]  c16ee65c c16ee65c cebc2eb0 cecc7d98 c018a399 c0140734 c018bbca cebc2d74
[   10.849146]  cebc2eb0 cecc7d58 c01408fd 00002000 00000000 cecc7d60 c0140933 cecc7d6c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sergei Shtylyov | 1 Mar 2009 20:11

Re: [PATCH 3/3 v4] AT91: initialize Compact Flash on AT91SAM9263 cpu

Hello.

Stanislaw Gruszka wrote:

> Signed-off-by: Stanislaw Gruszka <stf_xl <at> wp.pl>
>   

Acked-by: Sergei Shtylyov <sshtylyov <at> ru.mvista.com>

> diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c
> index b753cb8..f048043 100644
> --- a/arch/arm/mach-at91/at91sam9263_devices.c
> +++ b/arch/arm/mach-at91/at91sam9263_devices.c
>  <at>  <at>  -347,6 +347,111  <at>  <at>  void __init at91_add_device_mmc(short mmc_id, struct at91_mmc_data *data)
>  void __init at91_add_device_mmc(short mmc_id, struct at91_mmc_data *data) {}
>  #endif
>  
> +/* --------------------------------------------------------------------
> + *  Compact Flash (PCMCIA or IDE)
> + * -------------------------------------------------------------------- */
> +
> +#if defined(CONFIG_AT91_CF) || defined(CONFIG_AT91_CF_MODULE) || \
> +    defined(CONFIG_BLK_DEV_IDE_AT91) || defined(CONFIG_BLK_DEV_IDE_AT91_MODULE)
> +
> +static struct at91_cf_data cf0_data;
> +
> +static struct resource cf0_resources[] = {
> +	[0] = {
> +		.start	= AT91_CHIPSELECT_4,
> +		.end	= AT91_CHIPSELECT_4 + SZ_256M - 1,
(Continue reading)

Permalink | Reply | 6 comments |

Gmane