[PATCH] fix libata kernel-doc warnings

From: Randy Dunlap <rdunlap <at> xenotime.net>

Fix kernel-doc warnings in libata-core.

Signed-off-by: Randy Dunlap <rdunlap <at> xenotime.net>
---
 drivers/scsi/libata-core.c |    6 ++++++
 1 files changed, 6 insertions(+)

--- linux-2617-rc3.orig/drivers/scsi/libata-core.c
+++ linux-2617-rc3/drivers/scsi/libata-core.c
 <at>  <at>  -864,6 +864,9  <at>  <at>  static unsigned int ata_id_xfermask(cons
 /**
  *	ata_port_queue_task - Queue port_task
  *	 <at> ap: The ata_port to queue port_task for
+ *	 <at> fn: workqueue function to call
+ *	 <at> data: workqueue function parameter
+ *	 <at> delay: jiffies to delay before calling  <at> fn
  *
  *	Schedule  <at> fn( <at> data) for execution after  <at> delay jiffies using
  *	port_task.  There is one port_task per port and it's the
 <at>  <at>  -2739,6 +2742,8  <at>  <at>  static unsigned int ata_dev_set_xfermode
  *	ata_dev_init_params - Issue INIT DEV PARAMS command
  *	 <at> ap: Port associated with device  <at> dev
  *	 <at> dev: Device to which command will be sent
+ *	 <at> heads: Number of heads
+ *	 <at> sectors: Number of sectors per track
  *
  *	LOCKING:
  *	Kernel thread context (may sleep)

Re: data corruption with DMA enabled on K7VT4A PRO (VIA KT400A) - it was the memory

Hi,

I guess I trusted memtest86 too much. I wrote a little test tool to
see what data I write to the disk and read back and it seems I have a
little sticky bit somewhere, maybe the CPU cache hides it and it
really needs DMA to uncover it. Anyway one of my memory modules seems
to have turned bad. It works fine with the other one...

Thanks for all the good advice,
 Florian

On 4/26/06, Florian Nierhaus <florian.p.nierhaus <at> xxxxxx> wrote:
> Hi Everyone,
>
> Thanks for the Ram suggestion, but I kind of doubt it is the RAM.
>
> If I set things to hdparam -d1 -X udma1 things work fine. Also I only
> changed the mother board (to get SATA ports) and  the ram worked fine
> for over a year without any problems. Last not least I ran the
> memtest86 that is part of the fedora rescue CD and that didn't report
> any problems either. Also the thing that works best currently is my
> attached usb disk which also gives no problems.
>
> The problems are really the faster DMA modes with the SATA and PATA
> drive, and I did some experiments with diff and it did not look like
> bit changes which I would expect from bad ram, but more like large
> blocks beeing wrong (but I didn't check how big the blocks are.).
>
> Also the PATA cables are the same 80 lead cables I used before w/o
> problems. And on SATA I doubt it is the cables (tried two different

[PATCH][RFT] Fix HPT37x timing tables

Hello.

    Fix/remove bad/unused timing tables: HPT370/A 66 MHz tables weren't really
needed (the chips are not UltraATA/133 capable and shouldn't support 66 MHz
PCI) and had many modes over- and underclocked, HPT372 33 MHz table was in
fact for 66 MHz and 50 MHz table missed UltraDMA mode 6, HPT374 33 MHz table
was really for 50 MHz... (Actually, HPT370/A 33 MHz tables also have issues.
e.g. HPT370 has PIO modes 0/1 overlocked.)
    There's also no need in the separate HPT374 tables because HPT372 timings
should be the same (and those tables has UltraDMA mode 6 which HPT374 supports
depending on HPT374_ALLOW_ATA133_6 #define)...
    Have been tested and works fine on HPT370 and 371N...

MBR, Sergei

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

Index: linus/drivers/ide/pci/hpt366.c
===================================================================
--- linus.orig/drivers/ide/pci/hpt366.c
+++ linus/drivers/ide/pci/hpt366.c
 <at>  <at>  -67,6 +67,10  <at>  <at> 
  * - add support for HPT302N and HPT371N clocking (the same as for HPT372N)
  * - HPT371/N are single channel chips, so avoid touching the primary channel
  *   which exists only virtually (there's no pins for it)
+ * - fix/remove bad/unused timing tables: HPT370/A  66 MHz tables weren't really
+ *   needed and had many modes over- and  underclocked,  HPT372 33 MHz table was
+ *   for 66 MHz and 50 MHz table missed UltraDMA mode 6, HPT374 33 MHz table was

[PATCH][RFT] Fix HPT3xx hotswap support

Hello.

    Fix the broken hotswap code: on HPT37x it caused RESET- to glitch  when
tristating the bus (the MISC control 3/6 and soft control 2 need to be
written to in the certain order), and for HPT36x the obsolete
HDIO_TRISTATE_HWIF ioctl() handler was called instead which treated the state
argument wrong. Also, get rid of the soft control reg. 1 wtite to enable IDE
interrupt -- this is done in init_hpt37x() already...
    Have been tested on HPT370 and 371N. Should apply on top of the HPT37x
timing table fix.

MBR, Sergei

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

Index: linus/drivers/ide/pci/hpt366.c
===================================================================
--- linus.orig/drivers/ide/pci/hpt366.c
+++ linus/drivers/ide/pci/hpt366.c
 <at>  <at>  -71,6 +71,8  <at>  <at> 
  *   needed and had many modes over- and  underclocked,  HPT372 33 MHz table was
  *   for 66 MHz and 50 MHz table missed UltraDMA mode 6, HPT374 33 MHz table was
  *   really for 50 MHz; switch to using HPT372 tables for HPT374...
+ * - fix the hotswap code:  it caused RESET- to glitch when tristating the bus,
+ *   and for HPT36x the obsolete HDIO_TRISTATE_HWIF handler was called instead
  *		<source <at> mvista.com>
  *
  */

[PATCH] Fix the case of multiple HPT3xx chips present

Hello.

    init_chipset_hpt366() modifies some fields of the ide_pci_device_t 
structure depending on the chip's revision, so pass it a copy of the structure 
to avoid issues when multiple different chips are present.
    Should apply on top of the hotswap fix.

MBR, Sergei

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

Index: linus/drivers/ide/pci/hpt366.c
===================================================================
--- linus.orig/drivers/ide/pci/hpt366.c
+++ linus/drivers/ide/pci/hpt366.c
 <at>  <at>  -73,6 +73,8  <at>  <at> 
  *   really for 50 MHz; switch to using HPT372 tables for HPT374...
  * - fix the hotswap code:  it caused RESET- to glitch when tristating the bus,
  *   and for HPT36x the obsolete HDIO_TRISTATE_HWIF handler was called instead
+ * - pass to init_chipset() handlers a copy of the IDE PCI device structure as
+ *   they tamper with its fields
  *		<source <at> mvista.com>
  *
  */
 <at>  <at>  -1621,13 +1623,16  <at>  <at>  static ide_pci_device_t hpt366_chipsets[
  *
  *	Called when the PCI registration layer (or the IDE initialization)
  *	finds a device matching our IDE device tables.

Re: [PATCH] 2.6.xx: sata_mv: another critical fix

Hi all,

I've been idle on the test system for a while, but am back in business
again. Consider me and my test system your happy lab rat if things need
testing.

I've added two Marvell MV88SX6081 controller (total of three now),
removed the bad disks from the system (all I hope), added new ones
(total of 12, 300GB Maxtor DiamondMax, connected to the controllers
now (each four disks)), and added two 2.5" disks for the OS (connected
to the onboard Nvidia).

I also upgraded to 2.6.17-rc3-mm1, which seemed oke using badblocks, but
dd and mdadm give trouble.

First of all, Linux does not always see all disks during boot. Sometimes
one or two disks are missing. I haven't checked yet if these are always
the same disks (which I can do if that would help).

The controllers during boot always see all disks.

It doesn't matter if it is a cold boot, a boot after pressing the reset
button, a boot after alt-sysrq-b, or a boot after a 'shutdown -r now'.

Doesn't bother me too much though.

This is an excerpt from dmesg, starting from the first line which
mentions 'mv'.

I've googled the errors

Re: [PATCH] 2.6.xx: sata_mv: another critical fix

> I've added two Marvell MV88SX6081 controller (total of three now),
> removed the bad disks from the system (all I hope), added new ones
> (total of 12, 300GB Maxtor DiamondMax, connected to the controllers
> now (each four disks)), and added two 2.5" disks for the OS (connected
> to the onboard Nvidia).
> 
> I also upgraded to 2.6.17-rc3-mm1, which seemed oke using badblocks, but
> dd and mdadm give trouble.
> 
> First of all, Linux does not always see all disks during boot. Sometimes
> one or two disks are missing. I haven't checked yet if these are always
...
> [  416.910684] ata12: SATA max UDMA/133 cmd 0x0 ctl 0xFFFFC200000B8120 bmdma 0x0 irq 21
> [  417.016463] BUG: warning at drivers/scsi/sata_mv.c:1904/__msleep()
> [  417.053468] 
> [  417.053469] Call Trace: <IRQ> <ffffffff803e8c33>{__mv_phy_reset+242}
> [  417.099671]        <ffffffff803e811f>{mv_channel_reset+133} <ffffffff803e9297>{mv_interrupt+568}
> [  417.152658]        <ffffffff8020ec91>{handle_IRQ_event+41} <ffffffff80282bbf>{__do_IRQ+155}
> [  417.203033]        <ffffffff8025dd91>{do_IRQ+60} <ffffffff8025be52>{default_idle+0}
> [  417.249254]        <ffffffff80256178>{ret_from_intr+0} <EOI> <ffffffff80258d00>{thread_return+86}
> [  417.302853]        <ffffffff8025be7f>{default_idle+45} <ffffffff80243c0f>{cpu_idle+98}
> [  417.350632]        <ffffffff806e8b74>{start_secondary+1127}
> [  420.701529] ata5: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4673 85:7c69 86:3e21 87:4663 88:007f
> [  420.701533] ata5: dev 0 ATA-7, max UDMA/133, 586114704 sectors: LBA48
...

> [55973.577770] ata24: translated ATA stat/err 0x50/01 to SCSI SK/ASC/ASCQ 0x3/13/00
> [55973.622012] ata24: status=0x50 { DriveReady SeekComplete }
> [55973.654966] ata24: error=0x01 { AddrMarkNotFound }
> [55973.683740] sata_mv: PCI ERROR; PCI IRQ cause=0x40000100

Re: [PATCH] 2.6.xx: sata_mv: another critical fix

Mark Lord wrote (ao):
> I'm still debugging the chip/driver on the 2.6.16.xx series,
> and my sata_mv.c code here is behaving well for most testers
> thus far here. I'm avoiding 2.6.17-* until sata_mv stabilizes
> on the existing kernels.
> 
> Does the drive probing work for you on older kernels?

Thank you for your reply. I'll try the latest 2.6.16.13 kernel and see
how that goes.

I'll also try the kernel 2.6.17-rc3 as Andrew asked me to check if the
"Assertion failed!" message is gone in that release.

> I'll email you privately and set you up with a better copy of
> sata_mv.c

Thanks!

I believe quite some bits changed in sata between 2.6.16 and 2.6.17-rcX.
I assume your sata_mv.c will not work at all on anything else than
2.6.16(.xx) ?

Btw, building raid5 over the first eight disks works fine (76% done
now). Building raid5 over the last four disks fails immediately (drives
get marked F in /proc/mdstat).

The message "PCI ERROR; PCI IRQ cause=0x40000100" gives no result in
Google. Could this be a broken or miss-seated controller?

Re: [PATCH] 2.6.xx: sata_mv: another critical fix

Sander wrote:
>
> The message "PCI ERROR; PCI IRQ cause=0x40000100" gives no result in
> Google. Could this be a broken or miss-seated controller?

Yes.  Those bits mean: "no target response within 4 PCI clock cycles".

In English, I believe the translation is "dead/disconnected controller".

Cheers
-
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

Re: [PATCH] 2.6.xx: sata_mv: another critical fix

Mark Lord wrote (ao):
> Sander wrote:
> >The message "PCI ERROR; PCI IRQ cause=0x40000100" gives no result in
> >Google. Could this be a broken or miss-seated controller?
> 
> Yes. Those bits mean: "no target response within 4 PCI clock cycles".
> 
> In English, I believe the translation is "dead/disconnected controller".

Thank you for explaining the error and the translation. 

I'll try to re-seat it then, and replace it when that fails.

	With kind regards, Sander

--

-- 
Humilis IT Services and Solutions
http://www.humilis.net
-
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