Promise SATA300 TX4: errors, oops in ext3 code
Hardware: Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10 320G, jumper-limited to SATA150. Kernel : 2.6.22.9 amd64 Problem: Heavy load causes errors and triggers oops. History: Problems were first encountered on kernel 2.6.19, both i686 (old system) and amd64 (gentoo installation CD). Can't say anything about older kernels. Most probably they have same issues (or worse). Problems were blamed: - SATA300 being too 'hot' (jumpered the drives) - cables (work perfectly on onboard controller) - interrupt sharing (found the only slot which does not share interrupt line) - cooling (3 fans installed, smartctl-reported temperature at max load dropped to 35C) - weak PSU (installed 600W FSP) - kernel bugs (upgraded to 2.6.22.9) All those measures significantly dropped error rate (from about 20 to 2-4 per mirror rebuild) but did not eliminate the problem. Errors are easily reproduced by performing resync on a md RAID-1. Raising overall system load (compilation, copy operations on other HDDs) makes errors happen sooner. Errors lead to data loss: if errors occur on master disk while raid rebuild is in progress, and there is some write activity (like package installation), some files disappear: package management check reports missing files. Oops was encountered while rsyncing data from disks on separate (VIA onboard) controller and simultaneously rebuilding GCC. Typical error: Sep 30 17:26:51 host ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 Sep 30 17:26:51 host ata3.00: (port_status 0x2008) Sep 30 17:26:51 host ata3.00: cmd c8/00:08:31:47:36/00:00:00:00:00/e6 tag 0 cdb 0x0 data 4096 in Sep 30 17:26:51 host res 50/00:00:38:47:36/00:00:00:00:00/e6 Emask 0x2 (HSM violation) Sep 30 17:26:52 host ata3: soft resetting port Sep 30 17:26:52 host ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Sep 30 17:26:52 host ata3.00: configured for UDMA/133 Sep 30 17:26:52 host ata3: EH complete Sep 30 17:26:52 host sd 2:0:0:0: [sda] 625142448 512-byte hardware sectors (320073 MB) Sep 30 17:26:52 host sd 2:0:0:0: [sda] Write Protect is off Sep 30 17:26:52 host sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 Sep 30 17:26:52 host sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Oops: Sep 30 17:27:46 host Unable to handle kernel NULL pointer dereference at 000e RIP: Sep 30 17:27:46 host [8024b03a] __pagevec_lru_add+0x12/0x97 Sep 30 17:27:46 host PGD fdff067 PUD 84c1067 PMD 0 Sep 30 17:27:46 host Oops: [1] Sep 30 17:27:46 host CPU 0 Sep 30 17:27:46 host Modules linked in: snd_via82xx snd_mpu401_uart snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore Sep 30 17:27:46 host Pid: 21657, comm: rsync Not tainted 2.6.22-gentoo-r8 #1 Sep 30 17:27:46 host RIP: 0010:[8024b03a] [8024b03a] __pagevec_lru_add+0x12/0x97 Sep 30 17:27:46 host RSP: :81000b081998 EFLAGS: 00010217 Sep 30 17:27:46 host RAX: RBX: 81000b0819a8 RCX: Sep 30 17:27:46 host RDX: RSI: 6db6db6db6db6db7 RDI: 000e Sep 30 17:27:46 host RBP: 0013 R08: R09: 00ff Sep 30 17:27:46 host R10: 810021c72bc0 R11: 810033a3e068 R12: 81000b081b88 Sep 30 17:27:46 host R13: 810021c72bc0 R14: 802a122c R15: 810011f3fe00 Sep 30 17:27:46 host FS: 2ae93d4d66d0() GS:80595000() knlGS:f7dc2a00 Sep 30 17:27:46 host CS: 0010 DS: ES: CR0: 8005003b Sep 30 17:27:46 host CR2: 000e CR3: 08fcd000 CR4: 06e0 Sep 30 17:27:46 host Process rsync (pid: 21657, threadinfo 81000b08, task 81003f783100) Sep 30 17:27:46 host Stack: 810001152bf8 802830f1 802a122c 802218bf Sep 30 17:27:46 host 000e 81000195cdf0 8100014e6998 Sep 30 17:27:46 host 810001ac6540 810001af2488 81000154d900 8100018aced8 Sep 30 17:27:46 host Call Trace: Sep 30 17:27:46 host [802830f1] mpage_readpages+0xe5/0x138 Sep 30 17:27:46 host [802a122c] ext3_get_block+0x0/0xe4 Sep 30 17:27:46 host [802218bf] __activate_task+0x23/0x34 Sep 30 17:27:46 host [80248f2a] __alloc_pages+0x61/0x2a8 Sep 30 17:27:46 host [8024a79e] __do_page_cache_readahead+0x124/0x217 Sep 30 17:27:46 host [80465a08] thread_return+0x0/0x94 Sep 30 17:27:46 host [80245233] sync_page+0x0/0x40 Sep 30 17:27:46 host [8024a8e4] blockable_page_cache_readahead+0x53/0xb2 Sep 30 17:27:46 host [8024a9ca] make_ahead_window+0x87/0xa3 Sep 30 17:27:46 host [8024ab6e] page_cache_readahead+0x188/0x1bf Sep 30 17:27:46 host [80245a1a] do_generic_mapping_read+0x136/0x43a Sep 30 17:27:46 host [8024500a] file_read_actor+0x0/0x11d Sep 30 17:27:46 host
Re: Promise SATA300 TX4: errors, oops in ext3 code
Alexander Sabourenkov schrieb: Hardware: Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10 320G, jumper-limited to SATA150. Kernel : 2.6.22.9 amd64 Problem: Heavy load causes errors and triggers oops. Have you checked your memory already (memtest86)? We have several applications with Promise controllers on strange hardware and we never had integrity problems with i.e. not so standard SATA connections over custom vaccum-tight connectors. Problems were blamed: - SATA300 being too 'hot' (jumpered the drives) Is this a common known problem with your harddrives or controller? (ask google) Otherwise, it sounds like a problem with broken hardware. - cables (work perfectly on onboard controller) - interrupt sharing (found the only slot which does not share interrupt line) - cooling (3 fans installed, smartctl-reported temperature at max load dropped to 35C) Try to heat up your memory a little (your wife's hair blower). If it fails more often, your memory is most likely broken. - weak PSU (installed 600W FSP) - kernel bugs (upgraded to 2.6.22.9) All those measures significantly dropped error rate (from about 20 to 2-4 per mirror rebuild) but did not eliminate the problem. Again... sounds like bad memory to me. Juat my $0.05. Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - 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: Promise SATA300 TX4: errors, oops in ext3 code
Clemens Koller wrote: Alexander Sabourenkov schrieb: Hardware: Athlon64, Asus A8V, Promise SATA300 TX4, 2xSeagate 7200.10 320G, jumper-limited to SATA150. Kernel : 2.6.22.9 amd64 Problem: Heavy load causes errors and triggers oops. Have you checked your memory already (memtest86)? Last run was about a year ago. This box gets regularly updated (rebuild of all installed software), so I'm reasonably certain that memory is ok - gcc being almost as sensitive as memtest. Will recheck anyway. We have several applications with Promise controllers on strange hardware and we never had integrity problems with i.e. not so standard SATA connections over custom vaccum-tight connectors. Judging from linux and freebsd mailing lists, the TX4 is now quite well-known for intermittent problems, which are hard to reproduce on different hardware. I have two machines with those controllers, one FreeBSD-6.2 on MSI K8Neo2 motherboard (ATI chipset), and this one. FreeBSD box does not exhibit this problem under the little load it gets, but 6-STABLE and 7-CURRENT branches do have similar symptoms since around 19 April 2007, with rare occurences (but not unheard of) before. Thus I am unable to keep machines up to date, and before having to dump $140 worth of hardware, I'd like to try to help fix this problem or at least be certain that those controllers are indeed unusable. Problems were blamed: - SATA300 being too 'hot' (jumpered the drives) Is this a common known problem with your harddrives or controller? (ask google) Otherwise, it sounds like a problem with broken hardware. This is a common problem with at least VIA onboard controllers and Seagate disks, and I think with SATA150 controllers and speed negotiation in general. This step was suggested in some mailing list as a general precaution, but actually made no difference to error rate. I did not unjumper drivers back to SATA300 so that I can easily connect the drives to the onboard controller. -- ./lxnt - 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: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Mark Lord wrote: Linux kernel development is supposed to happen incrementally nowadays. Get a nice working solution in place, and then enhance/tune it. It's not about enhancing and tuning. It's about me (and/or James B) having to __undo__ the current code, just to get things working on an entire class of SATA-capable controllers out in the field. 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
ata1.00: spurious completions during NCQ
Hi, On 15 August 2007 Tejun Heo wrote: You don't need to worry too much as long as errors are properly, recovered. All commands are retried and you won't lose any data. Please report if the spurious NCQ problem happens again. Thanks. I've just received a logcheck mail with another one. I have not seen any in the time between my initial mail [1] and now, so this is the second occurrence in 1.5 months. The message is slightly different this time. I'm currently running 2.6.23-rc8 + CFS patchset. kernel: ata1.00: spurious completions during NCQ issue=0x0 SAct=0x8 FIS=005040a1:0004 kernel: ata1.00: cmd 60/58:18:b3:56:bd/00:00:01:00:00/40 tag 3 cdb 0x0 data 45056 in kernel: res 50/00:58:b3:56:bd/00:00:01:00:00/40 Emask 0x2 (HSM violation) kernel: ata1: soft resetting port kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) kernel: ata1.00: configured for UDMA/133 kernel: ata1: EH complete kernel: sd 0:0:0:0: [sda] 321672960 512-byte hardware sectors (164697 MB) kernel: sd 0:0:0:0: [sda] Write Protect is off kernel: sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 kernel: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Cheers, Frans Pop [1] http://marc.info/?l=linux-idem=118703097726277w=2 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pata_hpt3x2n: Clean up DPLL stuff
Hello.
Alan Cox wrote:
Nobody commented when I asked for review earlier so it must be ok 8)
It's not that I've seen this before
so it must be ok 8)
Not by me at least, so let me NAK it. 8-)
Lets stick it in -mm to be sure
Now let's unstick it. :-)
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --exclude-from /usr/src/exclude --recursive
linux.vanilla-2.6.23rc8-mm1/drivers/ata/pata_hpt37x.c
linux-2.6.23rc8-mm1/drivers/ata/pata_hpt37x.c
--- linux.vanilla-2.6.23rc8-mm1/drivers/ata/pata_hpt37x.c 2007-09-26
16:46:48.0 +0100
+++ linux-2.6.23rc8-mm1/drivers/ata/pata_hpt37x.c 2007-09-18
16:44:32.0 +0100
Wait, I thought you're patching pata_hpt3x2n!
@@ -844,6 +844,46 @@
/* Never went stable */
return 0;
}
+
+static void *hpt_tune_function(struct pci_dev *dev, int dpll, int clock_slot)
+{
+ static const int MHz[4] = { 33, 40, 50, 66 };
+ /*
+* For non UDMA133 capable devices we should
+* use a 50MHz DPLL by choice
+*/
+ unsigned int f_low, f_high;
+ int adjust;
+
+ f_low = (MHz[clock_slot] * 48) / MHz[dpll];
+ f_high = f_low + 2;
+ if (clock_slot 1)
+ f_high += 2;
+ /* Select the DPLL clock. */
+ pci_write_config_byte(dev, 0x5b, 0x21);
+ pci_write_config_dword(dev, 0x5C, (f_high 16) | f_low | 0x100);
Could move the f_low/high writes to hpt37x_calibrate_dpll()...
+ for(adjust = 0; adjust 8; adjust++) {
+ if (hpt37x_calibrate_dpll(dev))
+ break;
+ /* See if it'll settle at a fractionally different clock */
+ if (adjust 1)
+ f_low -= adjust 1;
+ else
+ f_high += adjust 1;
+ pci_write_config_dword(dev, 0x5C, (f_high 16) | f_low |
0x100);
+ }
+ if (adjust == 8) {
+ printk(KERN_WARNING hpt37x: DPLL did not stabilize.\n);
Deserves KERN_ERR. Wait, I remember to have changed it to KERN_ERR.
+ return NULL;
+ }
+ printk(KERN_INFO hpt37x: Bus clock %dMHz, using DPLL.\n, MHz[dpll]);
That won't do -- it reintroduces the DPLL clock ISO bus clock reporting
bug (that I've fixed just recently)!
@@ -944,7 +984,7 @@
u8 mcr1;
u32 freq;
int prefer_dpll = 1;
-
+ int hpt374alt = 0;
unsigned long iobase = pci_resource_start(dev, 4);
const struct hpt_chip *chip_table;
@@ -1046,16 +1086,28 @@
if (chip_table == hpt372a)
outb(0x0e, iobase + 0x9c);
+ /*
+* PLL must be done once
+*/
+
+ if (chip_table == hpt374 PCI_FUNC(dev-devfn) 1) {
+ /* The HPT374 secondary devfn is tuned to 50MHz when we find
+ the primary */
Nah, the reason for that is completely different -- BIOS saves no clock
data for function 1 but calibrates it for 50 MHz anyway, thus making the
driver read already distorted f_CNT...
Not actually dangerous as the value yields 33 MHz PCI clock after clamping but
WTF...
+ port_info = *port;
+ port_info.private_data = hpt37x_timings_50;
+ }
No, this does not seem correct -- the function 1 should be tuned (for the
x86 case where there was no BIOS available to tune it beforehand). I don't see
where the manual tells that the DPLL circuitry is shared. Contrarywise, I'm
seeing it say on p. 3-22:
2. Each function has its own DPLL module, so you need set DPLL clock on every
function
/* Some devices do not let this value be accessed via PCI space
according to the old driver */
-
freq = inl(iobase + 0x90);
if ((freq 12) != 0xABCDE) {
int i;
u8 sr;
u32 total = 0;
-
+
printk(KERN_WARNING pata_hpt37x: BIOS has not set timing
clocks.\n);
+ if (hpt374alt == 1)
+ printk(KERN_ERR pata_hpt37x: No saved frequency on primary
function.\n);
What's so erratic about this? And where hpt374alt is set to 1?
+ private_data = hpt_tune_function(dev, dpll, clock_slot);
+ /* For the HPT374 tune both channels together from fn 0 */
+ if (chip_table == hpt374 !(PCI_FUNC(dev-devfn) 1)) {
+ struct pci_dev *pair = pci_get_slot(dev-bus,
dev-devfn + 1);
+ if (pair != NULL) {
+ hpt_tune_function(pair, dpll, clock_slot);
+ pci_dev_put(pair);
+ }
Ah, I see it now: you've decided to tune 2 functions of HPT374 at once...
}
- if (dpll == 3)
- private_data = (void *)hpt37x_timings_66;
- else
- private_data = (void *)hpt37x_timings_50;
-
-
linux-2.6.18 reiserfs on raid1 blocks io until rebooted - why?
Hi, there! Can someone please put some light on what happened here: Short story: linux kernel 2.6.18 block i/o on file access on reiserfs on raid1. Long story: Sorry, for the long mail... I just try to give all details. On one of our old simple samba file servers, I ran into a strange problem that programs like slocate, rsync, cp start to block somewhere in the kernel io when they access files on reiserfs on /dev/md0. History: 1. Machine was up for about 200+ days without any problems. 2. On Sept. 05th we had a power outage because a electrician got stuck somewhere in the cables. :-( 3. Machine rebooted, checked everything, nothing seems to be broken (not even the electrician). Kernel log said: [...] Sep 5 14:51:54 rio kernel: PDC20269: chipset revision 2 Sep 5 14:51:54 rio kernel: PDC20269: ROM enabled at 0x2000 Sep 5 14:51:54 rio kernel: PDC20269: 100%% native mode on irq 11 Sep 5 14:51:54 rio kernel: ide2: BM-DMA at 0x9800-0x9807, BIOS settings: hde:pio, hdf:pio Sep 5 14:51:55 rio kernel: ide3: BM-DMA at 0x9808-0x980f, BIOS settings: hdg:pio, hdh:pio Sep 5 14:51:55 rio kernel: hde: Maxtor 7L300R0, ATA DISK drive Sep 5 14:51:55 rio kernel: ide2 at 0xb000-0xb007,0xa802 on irq 11 Sep 5 14:51:56 rio kernel: hdg: Maxtor 7L300R0, ATA DISK drive Sep 5 14:51:56 rio kernel: ide3 at 0xa400-0xa407,0xa002 on irq 11 Sep 5 14:51:56 rio kernel: hda: max request size: 128KiB Sep 5 14:51:56 rio kernel: hda: 4124736 sectors (2111 MB) w/128KiB Cache, CHS=4092/16/63, UDMA(33) Sep 5 14:51:56 rio kernel: hda: cache flushes not supported Sep 5 14:51:56 rio kernel: hda: hda1 hda2 Sep 5 14:51:56 rio kernel: hdb: max request size: 128KiB Sep 5 14:51:56 rio kernel: hdb: 8446032 sectors (4324 MB) w/496KiB Cache, CHS=14896/9/63, UDMA(33) Sep 5 14:51:56 rio kernel: hdb: hdb1 hdb2 Sep 5 14:51:56 rio kernel: hde: max request size: 512KiB Sep 5 14:51:56 rio kernel: hde: 586114704 sectors (300090 MB) w/16384KiB Cache, CHS=36483/255/63, UDMA(133) Sep 5 14:51:56 rio kernel: hde: cache flushes supported Sep 5 14:51:56 rio kernel: hde: hde1 Sep 5 14:51:56 rio kernel: hdg: max request size: 512KiB Sep 5 14:51:56 rio kernel: hdg: 586114704 sectors (300090 MB) w/16384KiB Cache, CHS=36483/255/63, UDMA(133) Sep 5 14:51:56 rio kernel: hdg: cache flushes supported Sep 5 14:51:57 rio kernel: hdg: hdg1 [...] Sep 5 14:51:59 rio kernel: md: linear personality registered for level -1 Sep 5 14:51:59 rio kernel: md: raid0 personality registered for level 0 Sep 5 14:51:59 rio kernel: md: raid1 personality registered for level 1 Sep 5 14:51:59 rio kernel: md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 Sep 5 14:51:59 rio kernel: md: bitmap version 4.39 Sep 5 14:51:59 rio kernel: TCP bic registered Sep 5 14:51:59 rio kernel: Initializing IPsec netlink socket Sep 5 14:51:59 rio kernel: NET: Registered protocol family 1 Sep 5 14:51:59 rio kernel: NET: Registered protocol family 10 Sep 5 14:51:59 rio kernel: IPv6 over IPv4 tunneling driver Sep 5 14:51:59 rio kernel: NET: Registered protocol family 17 Sep 5 14:51:59 rio kernel: Using IPI Shortcut mode Sep 5 14:51:59 rio kernel: Time: tsc clocksource has been installed. Sep 5 14:52:00 rio kernel: md: Autodetecting RAID arrays. Sep 5 14:52:00 rio kernel: md: autorun ... Sep 5 14:52:00 rio kernel: md: considering hdg1 ... Sep 5 14:52:00 rio kernel: md: adding hdg1 ... Sep 5 14:52:00 rio kernel: md: adding hde1 ... Sep 5 14:52:00 rio kernel: md: created md0 Sep 5 14:52:00 rio kernel: md: bindhde1 Sep 5 14:52:00 rio kernel: md: bindhdg1 Sep 5 14:52:00 rio kernel: md: running: hdg1hde1 Sep 5 14:52:00 rio kernel: raid1: raid set md0 active with 2 out of 2 mirrors Sep 5 14:52:00 rio kernel: md: ... autorun DONE. Sep 5 14:52:00 rio kernel: ReiserFS: hda1: found reiserfs format 3.6 with standard journal Sep 5 14:52:01 rio kernel: ReiserFS: hda1: using ordered data mode Sep 5 14:52:01 rio kernel: ReiserFS: hda1: journal params: device hda1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Sep 5 14:52:01 rio kernel: ReiserFS: hda1: checking transaction log (hda1) Sep 5 14:52:01 rio kernel: ReiserFS: hda1: replayed 9 transactions in 2 seconds Sep 5 14:52:01 rio kernel: ReiserFS: hda1: Using r5 hash to sort names Sep 5 14:52:01 rio kernel: VFS: Mounted root (reiserfs filesystem) readonly. Sep 5 14:52:01 rio kernel: Freeing unused kernel memory: 168k freed Sep 5 14:52:01 rio kernel: ReiserFS: hda1: Removing [585 34512 0x0 SD]..done Sep 5 14:52:01 rio kernel: ReiserFS: hda1: Removing [41180 15603 0x0 SD]..done Sep 5 14:52:01 rio kernel: ReiserFS: hda1: Removing [199 10243 0x0 SD]..done Sep 5 14:52:01 rio kernel: ReiserFS: hda1: Removing [4 10175 0x0 SD]..done Sep 5 14:52:01 rio kernel: ReiserFS: hda1: Removing [585 10164 0x0 SD]..done Sep 5 14:52:01 rio kernel: ReiserFS: hda1: There were 5 uncompleted unlinks/truncates. Completed Sep 5 14:52:01 rio kernel: ReiserFS:
PMP Patchset against 2.6.22.latest 2.6.23.latest
Hello Tejun, i am stuck with 2.6.22.1 because this is the latest version of your PMP patchset...this is perfectly working but i can not apply these set against newer versions of the kernel...could you update your homepage or post a howto/message/link for instructions to get the patchset against 2.6.22.latest and 2.6.23.latest? Thanks in advance Daniel - 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: PMP Patchset against 2.6.22.latest 2.6.23.latest
Daniel Schroeder wrote: i am stuck with 2.6.22.1 because this is the latest version of your PMP patchset...this is perfectly working but i can not apply these set against newer versions of the kernel...could you update your homepage or post a howto/message/link for instructions to get the patchset against 2.6.22.latest and 2.6.23.latest? Once you obtain the 'master' and 'upstream' branches of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git you may simply do git diff master..upstream patch to obtain the diff against current 2.6.23-rcX (what will be 2.6.23 release). 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: ICH9 2 port SATA controller port map?
What is the difference between NA and RV? If the controller only has access to 2 ports, does it matter which I set the nonexistent port values to in the map? NA is used for unimplemented ports of a valid configuration while RV is used to mark invalid MAP value. So, NA should be mixed with P[0-3] while RV can't be mixed with any other values. -- Tejun When you say can't be mixed do you mean I should not have [P0 RV P1 RV] on the same line? If that is the case, then I assume my only choice, for the 2 port controller (physically ports 5 6) would be [P0 NA P1 NA]. Thanks! Jason - 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: Serial ATA does not find partitions (Hitachi HD, new? ATI controller) where old SATA works
Tejun netconsole, pritty nice debunging system... but (yes, there is always a but) it does not get to run. the method was well implemented, adding the acpi=off it sends the information to the receiving machine (I can even see passing a netconsole probing message in the machine under testing), but without turning off acpi it does not reach the point of loading and, consequently, it does not send a byte to the receiving machine. Hence, result: empty output. Hernan -- Hernan G. Solari ([EMAIL PROTECTED] http://www.df.uba.ar/~solari) - 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: Maxtor 6L200M0 sata irq timeouts
Hello (please CC me when replying) On 27/09/2007, Tejun Heo [EMAIL PROTECTED] wrote: Michal Suchanek wrote: On 11/09/2007, Tejun Heo [EMAIL PROTECTED] wrote: Michal Suchanek wrote: What does 'smartctl -a /dev/sda' say? Attaching output. Hmmm... How often does the condition occur? smartlog records only two occasions. Every few minutes when the system is under load, less often when not. I think the logged drive errors are unrelated, the drive delivers the interrupt, just a bit later than Linux expects. At least that is my impression after looking at the these logs and the logs from the old system (I am not sure I could still find the saved logs but with some combination of irq related kernel options I got spurious interrupt instead of timeout, and the drive got disabled). Can you please test the latest rc kernel and see whether this problem is still there? With 2.6.23-rc8 I can still reproduce the problem. I have moved the system to a pata drive and I am going to try and replace the drive to get rid of both this interrupt stuff and overheating. Thanks Michal - 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
western digital WD800ADFS ncq problems
(please cc me, as i´m not subscribed to linux-kernel/ide - thanks) hi, we have some Fujitsu Siemens Celsius M450 workstations (Intel 975X Express chipset) running Linux Kernel 2.6.22 (Debian, Ubuntu) on an md raid 1 using two Western Digital Raptor drives, it´s the WD800ADFS which is an oem version (you will find them in workstations from HP, IBM, Dell, Fujitsu-Siemens,... and they have different model numbers) using ahci and ncq we are experiencing low performace, and many hsm violations, sometimes also timeouts, so i think this drive should be added to the libata ncq blacklist, as the WD740ADFD is already blacklisted and the Raptor series generally seems to have some ncq issues... kind regards, simon. drive information: /dev/sda: ATA device, with non-removable media Model Number: WDC WD800ADFS-07SLR4 Serial Number: WD-WMANS1** Firmware Revision: 21.07QR4 Standards: Used: ATA/ATAPI-7 published, ANSI INCITS 397-2005 Supported: 7 6 5 4 Configuration: Logical max current cylinders 16383 16383 heads 16 16 sectors/track 63 63 -- CHS current addressable sectors: 16514064 LBAuser addressable sectors: 156301488 LBA48 user addressable sectors: 156301488 device size with M = 1024*1024: 76319 MBytes device size with M = 1000*1000: 80026 MBytes (80 GB) Capabilities: LBA, IORDY(can be disabled) Queue depth: 32 Standby timer values: spec'd by Standard, with device specific minimum R/W multiple sector transfer: Max = 16 Current = 16 Recommended acoustic management value: 128, current value: 254 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: *SMART feature set Security Mode feature set *Power Management feature set *Write cache *Look-ahead *Host Protected Area feature set *WRITE_BUFFER command *READ_BUFFER command *NOP cmd *DOWNLOAD_MICROCODE Power-Up In Standby feature set *SET_FEATURES required to spinup after power up SET_MAX security extension *Automatic Acoustic Management feature set *48-bit Address feature set *Device Configuration Overlay feature set *Mandatory FLUSH_CACHE *FLUSH_CACHE_EXT *SMART error logging *SMART self-test *General Purpose Logging feature set *64-bit World wide name *SATA-I signaling speed (1.5Gb/s) *SATA-II signaling speed (3.0Gb/s) *Native Command Queueing (NCQ) *Host-initiated interface power management *Phy event counters DMA Setup Auto-Activate optimization Device-initiated interface power management *Software settings preservation *SMART Command Transport (SCT) feature set *SCT Long Sector Access (AC1) *SCT LBA Segment Access (AC2) *SCT Error Recovery Control (AC3) *SCT Features Control (AC4) *SCT Data Tables (AC5) unknown 206[12] Security: Master password revision code = 65534 supported not enabled not locked frozen not expired: security count not supported: enhanced erase Checksum: correct some of the kernel messages: [70747.193717] ata3.00: exception Emask 0x2 SAct 0xfe00 SErr 0x0 action 0x2 frozen [70747.193725] ata3.00: (spurious completions during NCQ issue=0x0 SAct=0xfe00 FIS=004040a1:0100) [70747.193734] ata3.00: cmd 61/20:48:d2:9d:24/00:00:08:00:00/40 tag 9 cdb 0x0 data 16384 out [70747.193736] res 40/00:78:42:ae:24/00:00:08:00:00/40 Emask 0x2 (HSM violation) ... [70747.193789] ata3.00: cmd 61/08:78:42:ae:24/00:00:08:00:00/40 tag 15 cdb 0x0 data 4096 out [70747.193791] res 40/00:78:42:ae:24/00:00:08:00:00/40 Emask 0x2 (HSM violation) [70747.502219] ata3: soft resetting port [70747.673864] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [70747.678834] ata3.00: configured for UDMA/133 [70747.678853] ata3: EH complete [143055.609784] ata4.00: exception Emask 0x2 SAct 0xe811 SErr 0x0 action 0x2 frozen [143055.609800] ata4.00: (spurious completions during NCQ issue=0x0 SAct=0xe811 FIS=004040a1:0080) [143055.609809] ata4.00: cmd 61/10:00:02:68:56/00:00:00:00:00/40 tag 0 cdb 0x0 data 8192 out [143055.609811] res
sata_nv in 2.6.23-rc8 only detects one of two controllers
2.6.18: libata version 2.00 loaded. sata_nv :00:07.0: version 2.0 ACPI: PCI Interrupt Link [LTID] enabled at IRQ 20 GSI 18 sharing vector 0xE9 and IRQ 18 ACPI: PCI Interrupt :00:07.0[A] - Link [LTID] - GSI 20 (level, low) - IRQ 233 PCI: Setting latency timer of device :00:07.0 to 64 ata1: SATA max UDMA/133 cmd 0xB400 ctl 0xB002 bmdma 0xA400 irq 233 ata2: SATA max UDMA/133 cmd 0xAC00 ctl 0xA802 bmdma 0xA408 irq 233 scsi0 : sata_nv ... ACPI: PCI Interrupt Link [LT3D] enabled at IRQ 47 GSI 19 sharing vector 0x32 and IRQ 19 ACPI: PCI Interrupt :80:07.0[A] - Link [LT3D] - GSI 47 (level, low) - IRQ 50 PCI: Setting latency timer of device :80:07.0 to 64 ata5: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xD400 irq 50 ata6: SATA max UDMA/133 cmd 0xDC00 ctl 0xD802 bmdma 0xD408 irq 50 2.6.23-rc8: libata version 2.21 loaded. sata_nv :00:07.0: version 3.5 ACPI: PCI Interrupt Link [LTID] enabled at IRQ 22 ACPI: PCI Interrupt :00:07.0[A] - Link [LTID] - GSI 22 (level, low) - IRQ 22 sata_nv :00:07.0: Using ADMA mode PCI: Setting latency timer of device :00:07.0 to 64 scsi1 : sata_nv ... [No messages print for the second controller] https://bugzilla.redhat.com/show_bug.cgi?id=313491 - 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] SB700 contains more than one IDE channel
On Thursday 27 September 2007, Shane Huang wrote: From: [EMAIL PROTECTED] SB700 supports one physical IDE channel, but SB700 SATA controller supports combined mode. When the SATA combined mode is enabled, two SATA ports(port4 and port5) share one IDE channel from IDE controller, and PATA will share the other IDE channel. Our previous patch adding SB700 IDE device ID only support one IDE channel, which contains bug. The attached patch fix the bug. Signed-off-by: [EMAIL PROTECTED] applied The inlined patch was word-wrapped and the attached one lacked patch description so manual fixing was required anyway. Not a big problem but next time please try to use some known-to-be-good mail client to inline patches. 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 4/4] hpt366: MWDMA filter for SATA cards (take 2)
On Saturday 29 September 2007, Sergei Shtylyov wrote:
The Marvell bridge chips used on HighPoint SATA cards do not seem to support
the MWDMA modes (at least that caould be seen in their so-called drivers :-),
so the driver needs to account for this -- to achieve this:
- add mdma_filter() method from the original patch by Bartlomiej Zolnierkewicz
with his consent, also adding the method callout to ide_rate_filter();
- install the method for all chips to only return empty mask if a SATA drive
is detected on HPT372{AN]/374 chips...
Signed-off-by: Sergei Shtylyov [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
[PATCH 1/15] ali14xx: fix deadlock on error handling
Stop abusing ide_lock lock by switching to a private locking. Fixes same issue as fixed by Alan Cox in atiixp host driver with commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] --- drivers/ide/legacy/ali14xx.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Index: b/drivers/ide/legacy/ali14xx.c === --- a/drivers/ide/legacy/ali14xx.c +++ b/drivers/ide/legacy/ali14xx.c @@ -102,6 +102,8 @@ static void outReg (u8 data, u8 reg) outb_p(data, dataPort); } +static DEFINE_SPINLOCK(ali14xx_lock); + /* * Set PIO mode for the specified drive. * This function computes timing parameters @@ -129,14 +131,14 @@ static void ali14xx_set_pio_mode(ide_dri /* stuff timing parameters into controller registers */ driveNum = (HWIF(drive)-index 1) + drive-select.b.unit; - spin_lock_irqsave(ide_lock, flags); + spin_lock_irqsave(ali14xx_lock, flags); outb_p(regOn, basePort); outReg(param1, regTab[driveNum].reg1); outReg(param2, regTab[driveNum].reg2); outReg(param3, regTab[driveNum].reg3); outReg(param4, regTab[driveNum].reg4); outb_p(regOff, basePort); - spin_unlock_irqrestore(ide_lock, flags); + spin_unlock_irqrestore(ali14xx_lock, flags); } /* - 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
[PATCH 2/15] dtc2278: fix deadlock on error handling
Stop abusing ide_lock lock (switch to a private locking).
Fixes same issue as fixed by Alan Cox in atiixp host driver with
commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/legacy/dtc2278.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: b/drivers/ide/legacy/dtc2278.c
===
--- a/drivers/ide/legacy/dtc2278.c
+++ b/drivers/ide/legacy/dtc2278.c
@@ -67,18 +67,20 @@ static void sub22 (char b, char c)
}
}
+static DEFINE_SPINLOCK(dtc2278_lock);
+
static void dtc2278_set_pio_mode(ide_drive_t *drive, const u8 pio)
{
unsigned long flags;
if (pio = 3) {
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(dtc2278_lock, flags);
/*
* This enables PIO mode4 (3?) on the first interface
*/
sub22(1,0xc3);
sub22(0,0xa0);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(dtc2278_lock, flags);
} else {
/* we don't know how to set it back again.. */
}
-
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
[PATCH 3/15] qd65xx: fix deadlock on error handling
Stop abusing ide_lock lock (switch to a private locking).
Fixes same issue as fixed by Alan Cox in atiixp host driver with
commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/legacy/qd65xx.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
Index: b/drivers/ide/legacy/qd65xx.c
===
--- a/drivers/ide/legacy/qd65xx.c
+++ b/drivers/ide/legacy/qd65xx.c
@@ -89,13 +89,15 @@
static int timings[4]={-1,-1,-1,-1}; /* stores current timing for each timer */
+static DEFINE_SPINLOCK(qd65xx_lock);
+
static void qd_write_reg (u8 content, unsigned long reg)
{
unsigned long flags;
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(qd65xx_lock, flags);
outb(content,reg);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(qd65xx_lock, flags);
}
static u8 __init qd_read_reg (unsigned long reg)
@@ -103,9 +105,9 @@ static u8 __init qd_read_reg (unsigned l
unsigned long flags;
u8 read;
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(qd65xx_lock, flags);
read = inb(reg);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(qd65xx_lock, flags);
return read;
}
@@ -301,16 +303,15 @@ static void qd6580_set_pio_mode(ide_driv
static int __init qd_testreg(int port)
{
- u8 savereg;
- u8 readreg;
unsigned long flags;
+ u8 savereg, readreg;
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(qd65xx_lock, flags);
savereg = inb_p(port);
outb_p(QD_TESTVAL, port); /* safe value */
readreg = inb_p(port);
outb(savereg, port);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(qd65xx_lock, flags);
if (savereg == QD_TESTVAL) {
printk(KERN_ERR Outch ! the probe for qd65xx isn't reliable
!\n);
-
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
[PATCH 5/15] slc90e66: fix deadlock on error handling
* Stop abusing ide_lock lock (switch to a private locking).
Fixes same issue as fixed by Alan Cox in atiixp host driver with
commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627.
* Bump driver version.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/slc90e66.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
Index: b/drivers/ide/pci/slc90e66.c
===
--- a/drivers/ide/pci/slc90e66.c
+++ b/drivers/ide/pci/slc90e66.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/slc90e66.c Version 0.18Aug 9, 2007
+ * linux/drivers/ide/pci/slc90e66.c Version 0.19Sep 24, 2007
*
* Copyright (C) 2000-2002 Andre Hedrick [EMAIL PROTECTED]
* Copyright (C) 2006-2007 MontaVista Software, Inc. [EMAIL PROTECTED]
@@ -21,6 +21,8 @@
#include asm/io.h
+static DEFINE_SPINLOCK(slc90e66_lock);
+
static void slc90e66_set_pio_mode(ide_drive_t *drive, const u8 pio)
{
ide_hwif_t *hwif= HWIF(drive);
@@ -40,7 +42,7 @@ static void slc90e66_set_pio_mode(ide_dr
{ 2, 1 },
{ 2, 3 }, };
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(slc90e66_lock, flags);
pci_read_config_word(dev, master_port, master_data);
if (pio 1)
@@ -71,7 +73,7 @@ static void slc90e66_set_pio_mode(ide_dr
pci_write_config_word(dev, master_port, master_data);
if (is_slave)
pci_write_config_byte(dev, slave_port, slave_data);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(slc90e66_lock, flags);
}
static void slc90e66_set_dma_mode(ide_drive_t *drive, const u8 speed)
-
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
[PATCH 4/15] opti621: fix deadlock on error handling
* Stop abusing ide_lock lock (switch to a private locking). Fixes same issue as fixed by Alan Cox in atiixp host driver with commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627. * Bump driver version. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] --- drivers/ide/pci/opti621.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) Index: b/drivers/ide/pci/opti621.c === --- a/drivers/ide/pci/opti621.c +++ b/drivers/ide/pci/opti621.c @@ -1,5 +1,5 @@ /* - * linux/drivers/ide/pci/opti621.cVersion 0.8 Aug 27, 2007 + * linux/drivers/ide/pci/opti621.cVersion 0.9 Sep 24, 2007 * * Copyright (C) 1996-1998 Linus Torvalds authors (see below) */ @@ -133,6 +133,8 @@ static int reg_base; #define PIO_NOT_EXIST 254 #define PIO_DONT_KNOW 255 +static DEFINE_SPINLOCK(opti621_lock); + /* there are stored pio numbers from other calls of opti621_set_pio_mode */ static void compute_pios(ide_drive_t *drive, const u8 pio) /* Store values into drive-drive_data @@ -278,7 +280,7 @@ static void opti621_set_pio_mode(ide_dri second.recovery_time, drdy); #endif - spin_lock_irqsave(ide_lock, flags); + spin_lock_irqsave(opti621_lock, flags); reg_base = hwif-io_ports[IDE_DATA_OFFSET]; @@ -317,7 +319,7 @@ static void opti621_set_pio_mode(ide_dri /* and read prefetch for both drives */ write_reg(misc, MISC_REG); - spin_unlock_irqrestore(ide_lock, flags); + spin_unlock_irqrestore(opti621_lock, flags); } /* - 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
[PATCH 6/15] cmd640: fix deadlock on error handling
Stop abusing ide_lock lock (switch to a private locking).
Fixes same issue as fixed by Alan Cox in atiixp host driver with
commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627.
cmd640 is a bit special cause we still need to leave ide_lock for
-set_pio_mode with 'pio' argument == 8/9 (prefetch disable/enable).
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/cmd640.c | 48 +++
1 file changed, 28 insertions(+), 20 deletions(-)
Index: b/drivers/ide/pci/cmd640.c
===
--- a/drivers/ide/pci/cmd640.c
+++ b/drivers/ide/pci/cmd640.c
@@ -185,6 +185,8 @@ static u8 recovery_counts[4] = {16, 16,
#endif /* CONFIG_BLK_DEV_CMD640_ENHANCED */
+static DEFINE_SPINLOCK(cmd640_lock);
+
/*
* These are initialized to point at the devices we control
*/
@@ -258,12 +260,12 @@ static u8 get_cmd640_reg_vlb (u16 reg)
static u8 get_cmd640_reg(u16 reg)
{
- u8 b;
unsigned long flags;
+ u8 b;
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(cmd640_lock, flags);
b = __get_cmd640_reg(reg);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(cmd640_lock, flags);
return b;
}
@@ -271,9 +273,9 @@ static void put_cmd640_reg(u16 reg, u8 v
{
unsigned long flags;
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(cmd640_lock, flags);
__put_cmd640_reg(reg,val);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(cmd640_lock, flags);
}
static int __init match_pci_cmd640_device (void)
@@ -351,7 +353,7 @@ static int __init secondary_port_respond
{
unsigned long flags;
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(cmd640_lock, flags);
outb_p(0x0a, 0x170 + IDE_SELECT_OFFSET);/* select drive0 */
udelay(100);
@@ -359,11 +361,11 @@ static int __init secondary_port_respond
outb_p(0x1a, 0x170 + IDE_SELECT_OFFSET); /* select drive1 */
udelay(100);
if ((inb_p(0x170 + IDE_SELECT_OFFSET) 0x1f) != 0x1a) {
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(cmd640_lock, flags);
return 0; /* nothing responded */
}
}
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(cmd640_lock, flags);
return 1; /* success */
}
@@ -440,11 +442,11 @@ static void __init setup_device_ptrs (vo
static void set_prefetch_mode (unsigned int index, int mode)
{
ide_drive_t *drive = cmd_drives[index];
+ unsigned long flags;
int reg = prefetch_regs[index];
u8 b;
- unsigned long flags;
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(cmd640_lock, flags);
b = __get_cmd640_reg(reg);
if (mode) { /* want prefetch on? */
#if CMD640_PREFETCH_MASKS
@@ -460,7 +462,7 @@ static void set_prefetch_mode (unsigned
b |= prefetch_masks[index]; /* disable prefetch */
}
__put_cmd640_reg(reg, b);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(cmd640_lock, flags);
}
/*
@@ -561,7 +563,7 @@ static void program_drive_counts (unsign
/*
* Now that everything is ready, program the new timings
*/
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(cmd640_lock, flags);
/*
* Program the address_setup clocks into ARTTIM reg,
* and then the active/recovery counts into the DRWTIM reg
@@ -570,7 +572,7 @@ static void program_drive_counts (unsign
setup_count |= __get_cmd640_reg(arttim_regs[index]) 0x3f;
__put_cmd640_reg(arttim_regs[index], setup_count);
__put_cmd640_reg(drwtim_regs[index], pack_nibbles(active_count,
recovery_count));
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(cmd640_lock, flags);
}
/*
@@ -630,6 +632,7 @@ static void cmd640_set_mode (unsigned in
static void cmd640_set_pio_mode(ide_drive_t *drive, const u8 pio)
{
+ unsigned long flags;
unsigned int index = 0, cycle_time;
u8 b;
@@ -652,7 +655,12 @@ static void cmd640_set_pio_mode(ide_driv
case 8: /* set prefetch off */
case 9: /* set prefetch on */
+ /*
+* take ide_lock for drive-[no_]unmask/[no_]io_32bit
+*/
+ spin_lock_irqsave(ide_lock, flags);
set_prefetch_mode(index, pio 1);
+ spin_unlock_irqrestore(ide_lock, flags);
printk(%s: %sabled cmd640 prefetch\n, drive-name,
(pio 1) ? en : dis);
return;
}
@@ -670,20 +678,20 @@ static void
[PATCH 9/15] cs5530: remove needless ide_lock taking
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/pci/cs5530.c |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
Index: b/drivers/ide/pci/cs5530.c
===
--- a/drivers/ide/pci/cs5530.c
+++ b/drivers/ide/pci/cs5530.c
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/pci/cs5530.c Version 0.76Aug 3 2007
+ * linux/drivers/ide/pci/cs5530.c Version 0.77Sep 24 2007
*
* Copyright (C) 2000 Andre Hedrick [EMAIL PROTECTED]
* Copyright (C) 2000 Mark Lord [EMAIL PROTECTED]
@@ -146,7 +146,6 @@ static void cs5530_set_dma_mode(ide_driv
static unsigned int __devinit init_chipset_cs5530 (struct pci_dev *dev, const
char *name)
{
struct pci_dev *master_0 = NULL, *cs5530_0 = NULL;
- unsigned long flags;
if (pci_resource_start(dev, 4) == 0)
return -EFAULT;
@@ -171,9 +170,6 @@ static unsigned int __devinit init_chips
goto out;
}
- spin_lock_irqsave(ide_lock, flags);
- /* all CPUs (there should only be one CPU with this chipset) */
-
/*
* Enable BusMaster and MemoryWriteAndInvalidate for the cs5530:
* -- OR 0x14 into 16-bit PCI COMMAND reg of function 0 of the cs5530
@@ -224,8 +220,6 @@ static unsigned int __devinit init_chips
pci_write_config_byte(master_0, 0x42, 0x00);
pci_write_config_byte(master_0, 0x43, 0xc1);
- spin_unlock_irqrestore(ide_lock, flags);
-
out:
pci_dev_put(master_0);
pci_dev_put(cs5530_0);
-
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
[PATCH 10/15] ide: enhance ide_setup_pci_noise()
* Print PCI device Vendor ID, Device ID and revision in
ide_setup_pci_noise().
* Remove no longer needed PCI device revision printing from
ide_setup_pci_controller().
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/setup-pci.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
Index: b/drivers/ide/setup-pci.c
===
--- a/drivers/ide/setup-pci.c
+++ b/drivers/ide/setup-pci.c
@@ -227,8 +227,9 @@ static unsigned long ide_get_or_set_dma_
void ide_setup_pci_noise(struct pci_dev *dev, const struct ide_port_info *d)
{
- printk(KERN_INFO %s: IDE controller at PCI slot %s\n,
-d-name, pci_name(dev));
+ printk(KERN_INFO %s: IDE controller (0x%04x:0x%04x rev 0x%02x) at
+ PCI slot %s\n, d-name, dev-vendor, dev-device,
+dev-revision, pci_name(dev));
}
EXPORT_SYMBOL_GPL(ide_setup_pci_noise);
@@ -497,9 +498,6 @@ static int ide_setup_pci_controller(stru
printk(KERN_INFO %s: device enabled (Linux)\n, d-name);
}
- if (noisy)
- printk(KERN_INFO %s: chipset revision %d\n,
-d-name, dev-revision);
out:
return ret;
}
-
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
[PATCH 13/15] ide: use __ide_end_request() in ide_end_dequeued_request()
* Remove dead code for handling IDE TCQ from ide_end_dequeued_request().
* Add 'dequeue' parameter to __ide_end_request().
* Use __ide_end_request() in ide_end_dequeued_request().
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-io.c | 44 ++--
1 file changed, 10 insertions(+), 34 deletions(-)
Index: b/drivers/ide/ide-io.c
===
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -55,7 +55,7 @@
#include asm/bitops.h
static int __ide_end_request(ide_drive_t *drive, struct request *rq,
-int uptodate, unsigned int nr_bytes)
+int uptodate, unsigned int nr_bytes, int dequeue)
{
int ret = 1;
@@ -80,9 +80,11 @@ static int __ide_end_request(ide_drive_t
if (!end_that_request_chunk(rq, uptodate, nr_bytes)) {
add_disk_randomness(rq-rq_disk);
- if (!list_empty(rq-queuelist))
- blkdev_dequeue_request(rq);
- HWGROUP(drive)-rq = NULL;
+ if (dequeue) {
+ if (!list_empty(rq-queuelist))
+ blkdev_dequeue_request(rq);
+ HWGROUP(drive)-rq = NULL;
+ }
end_that_request_last(rq, uptodate);
ret = 0;
}
@@ -122,7 +124,7 @@ int ide_end_request (ide_drive_t *drive,
nr_bytes = rq-hard_cur_sectors 9;
}
- ret = __ide_end_request(drive, rq, uptodate, nr_bytes);
+ ret = __ide_end_request(drive, rq, uptodate, nr_bytes, 1);
spin_unlock_irqrestore(ide_lock, flags);
return ret;
@@ -255,39 +257,13 @@ int ide_end_dequeued_request(ide_drive_t
int uptodate, int nr_sectors)
{
unsigned long flags;
- int ret = 1;
+ int ret;
spin_lock_irqsave(ide_lock, flags);
-
BUG_ON(!blk_rq_started(rq));
-
- /*
-* if failfast is set on a request, override number of sectors and
-* complete the whole request right now
-*/
- if (blk_noretry_request(rq) end_io_error(uptodate))
- nr_sectors = rq-hard_nr_sectors;
-
- if (!blk_fs_request(rq) end_io_error(uptodate) !rq-errors)
- rq-errors = -EIO;
-
- /*
-* decide whether to reenable DMA -- 3 is a random magic for now,
-* if we DMA timeout more than 3 times, just stay in PIO
-*/
- if (drive-state == DMA_PIO_RETRY drive-retry_pio = 3) {
- drive-state = 0;
- HWGROUP(drive)-hwif-ide_dma_on(drive);
- }
-
- if (!end_that_request_first(rq, uptodate, nr_sectors)) {
- add_disk_randomness(rq-rq_disk);
- if (blk_rq_tagged(rq))
- blk_queue_end_tag(drive-queue, rq);
- end_that_request_last(rq, uptodate);
- ret = 0;
- }
+ ret = __ide_end_request(drive, rq, uptodate, nr_sectors 9, 0);
spin_unlock_irqrestore(ide_lock, flags);
+
return ret;
}
EXPORT_SYMBOL_GPL(ide_end_dequeued_request);
-
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
[PATCH 15/15] ide: remove stale comments from ide-taskfile.c
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-taskfile.c | 23 ---
1 file changed, 23 deletions(-)
Index: b/drivers/ide/ide-taskfile.c
===
--- a/drivers/ide/ide-taskfile.c
+++ b/drivers/ide/ide-taskfile.c
@@ -8,23 +8,6 @@
* Copyright (C) 2003-2004Bartlomiej Zolnierkiewicz
*
* The big the bad and the ugly.
- *
- * Problems to be fixed because of BH interface or the lack therefore.
- *
- * Fill me in stupid !!!
- *
- * HOST:
- * General refers to the Controller and Driver pair.
- * DATA HANDLER:
- * Under the context of Linux it generally refers to an interrupt handler.
- * However, it correctly describes the 'HOST'
- * DATA BLOCK:
- * The amount of data needed to be transfered as predefined in the
- * setup of the device.
- * STORAGE ATOMIC:
- * The 'DATA BLOCK' associated to the 'DATA HANDLER', and can be as
- * small as a single sector or as large as the entire command block
- * request.
*/
#include linux/module.h
@@ -685,9 +668,6 @@ int ide_wait_cmd (ide_drive_t *drive, u8
return ide_do_drive_cmd(drive, rq, ide_wait);
}
-/*
- * FIXME : this needs to map into at taskfile. [EMAIL PROTECTED]
- */
int ide_cmd_ioctl (ide_drive_t *drive, unsigned int cmd, unsigned long arg)
{
int err = 0;
@@ -751,9 +731,6 @@ static int ide_wait_cmd_task(ide_drive_t
return ide_do_drive_cmd(drive, rq, ide_wait);
}
-/*
- * FIXME : this needs to map into at taskfile. [EMAIL PROTECTED]
- */
int ide_task_ioctl (ide_drive_t *drive, unsigned int cmd, unsigned long arg)
{
void __user *p = (void __user *)arg;
-
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
[PATCH 12/15] ide: remove -dma_master field from ide_hwif_t
* Convert cmd64x, hpt366 and pdc202xx_old host drivers to use
pci_resource_start(hwif-pci_dev, 4) instead of hwif-dma_master.
* Remove no longer needed -dma_master field from ide_hwif_t.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-dma.c |7 ---
drivers/ide/ide.c |2 --
drivers/ide/pci/cmd64x.c |8 +---
drivers/ide/pci/hpt366.c | 21 +++--
drivers/ide/pci/pdc202xx_old.c | 12 ++--
include/linux/ide.h|1 -
6 files changed, 22 insertions(+), 29 deletions(-)
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -1004,11 +1004,6 @@ void ide_setup_dma(ide_hwif_t *hwif, uns
hwif-dma_base = base;
- if (hwif-mate)
- hwif-dma_master = hwif-channel ? hwif-mate-dma_base : base;
- else
- hwif-dma_master = base;
-
if (!(hwif-dma_command))
hwif-dma_command = hwif-dma_base;
if (!(hwif-dma_vendor1))
@@ -1050,8 +1045,6 @@ void ide_setup_dma(ide_hwif_t *hwif, uns
hwif-drives[1].name, (dma_stat 0x40) ? DMA : pio);
}
printk(\n);
-
- BUG_ON(!hwif-dma_master);
}
EXPORT_SYMBOL_GPL(ide_setup_dma);
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -470,7 +470,6 @@ static void ide_hwif_restore(ide_hwif_t
#endif
hwif-dma_base = tmp_hwif-dma_base;
- hwif-dma_master= tmp_hwif-dma_master;
hwif-dma_command = tmp_hwif-dma_command;
hwif-dma_vendor1 = tmp_hwif-dma_vendor1;
hwif-dma_status= tmp_hwif-dma_status;
@@ -604,7 +603,6 @@ void ide_unregister(unsigned int index)
(void) ide_release_dma(hwif);
hwif-dma_base = 0;
- hwif-dma_master = 0;
hwif-dma_command = 0;
hwif-dma_vendor1 = 0;
hwif-dma_status = 0;
Index: b/drivers/ide/pci/cmd64x.c
===
--- a/drivers/ide/pci/cmd64x.c
+++ b/drivers/ide/pci/cmd64x.c
@@ -333,13 +333,14 @@ static void cmd64x_set_dma_mode(ide_driv
static int cmd648_ide_dma_end (ide_drive_t *drive)
{
ide_hwif_t *hwif= HWIF(drive);
+ unsigned long addr = pci_resource_start(hwif-pci_dev, 4) + 0x01;
int err = __ide_dma_end(drive);
u8 irq_mask= hwif-channel ? MRDMODE_INTR_CH1 :
MRDMODE_INTR_CH0;
- u8 mrdmode = inb(hwif-dma_master + 0x01);
+ u8 mrdmode = inb(addr);
/* clear the interrupt bit */
- outb(mrdmode | irq_mask, hwif-dma_master + 0x01);
+ outb(mrdmode | irq_mask, addr);
return err;
}
@@ -364,10 +365,11 @@ static int cmd64x_ide_dma_end (ide_drive
static int cmd648_ide_dma_test_irq (ide_drive_t *drive)
{
ide_hwif_t *hwif= HWIF(drive);
+ unsigned long addr = pci_resource_start(hwif-pci_dev, 4) + 0x01;
u8 irq_mask = hwif-channel ? MRDMODE_INTR_CH1 :
MRDMODE_INTR_CH0;
u8 dma_stat = inb(hwif-dma_status);
- u8 mrdmode = inb(hwif-dma_master + 0x01);
+ u8 mrdmode = inb(addr);
#ifdef DEBUG
printk(%s: dma_stat: 0x%02x mrdmode: 0x%02x irq_mask: 0x%02x\n,
Index: b/drivers/ide/pci/hpt366.c
===
--- a/drivers/ide/pci/hpt366.c
+++ b/drivers/ide/pci/hpt366.c
@@ -827,32 +827,33 @@ static int hpt374_ide_dma_end(ide_drive_
static void hpt3xxn_set_clock(ide_hwif_t *hwif, u8 mode)
{
- u8 scr2 = inb(hwif-dma_master + 0x7b);
+ unsigned long addr = pci_resource_start(hwif-pci_dev, 4);
+ u8 scr2 = inb(addr + 0x7b);
if ((scr2 0x7f) == mode)
return;
/* Tristate the bus */
- outb(0x80, hwif-dma_master + 0x73);
- outb(0x80, hwif-dma_master + 0x77);
+ outb(0x80, addr + 0x73);
+ outb(0x80, addr + 0x77);
/* Switch clock and reset channels */
- outb(mode, hwif-dma_master + 0x7b);
- outb(0xc0, hwif-dma_master + 0x79);
+ outb(mode, addr + 0x7b);
+ outb(0xc0, addr + 0x79);
/*
* Reset the state machines.
* NOTE: avoid accidentally enabling the disabled channels.
*/
- outb(inb(hwif-dma_master + 0x70) | 0x32, hwif-dma_master + 0x70);
- outb(inb(hwif-dma_master + 0x74) | 0x32, hwif-dma_master + 0x74);
+ outb(inb(addr + 0x70) | 0x32, addr + 0x70);
+ outb(inb(addr + 0x74) | 0x32, addr + 0x74);
/* Complete reset */
-
[PATCH 14/15] ide: remove dead code from ide_driveid_update()
* Remove dead code from ide_driveid_update().
While at it:
* Remove useless comment.
* s/HWIF(drive)/drive-hwif/
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-iops.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
Index: b/drivers/ide/ide-iops.c
===
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -693,35 +693,16 @@ static u8 ide_auto_reduce_xfer (ide_driv
}
#endif /* CONFIG_BLK_DEV_IDEDMA */
-/*
- * Update the
- */
-int ide_driveid_update (ide_drive_t *drive)
+int ide_driveid_update(ide_drive_t *drive)
{
- ide_hwif_t *hwif= HWIF(drive);
+ ide_hwif_t *hwif = drive-hwif;
struct hd_driveid *id;
-#if 0
- id = kmalloc(SECTOR_WORDS*4, GFP_ATOMIC);
- if (!id)
- return 0;
-
- taskfile_lib_get_identify(drive, (char *)id);
+ unsigned long timeout, flags;
- ide_fix_driveid(id);
- if (id) {
- drive-id-dma_ultra = id-dma_ultra;
- drive-id-dma_mword = id-dma_mword;
- drive-id-dma_1word = id-dma_1word;
- /* anything more ? */
- kfree(id);
- }
- return 1;
-#else
/*
* Re-read drive-id for possible DMA mode
* change (copied from ide-probe.c)
*/
- unsigned long timeout, flags;
SELECT_MASK(drive, 1);
if (IDE_CONTROL_REG)
@@ -763,7 +744,6 @@ int ide_driveid_update (ide_drive_t *dri
}
return 1;
-#endif
}
int ide_config_drive_speed(ide_drive_t *drive, u8 speed)
-
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 12/15] ide: remove -dma_master field from ide_hwif_t
Bartlomiej Zolnierkiewicz wrote: * Convert cmd64x, hpt366 and pdc202xx_old host drivers to use pci_resource_start(hwif-pci_dev, 4) instead of hwif-dma_master. Before using pci_resource_start(), the code should check pci_resource_len() to ensure it is the appropriate size. It would be very wise to ensure that pci_resource_flags()IORESOURCE_IO is true, too. 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 12/15] ide: remove -dma_master field from ide_hwif_t
On Monday 01 October 2007, Jeff Garzik wrote: Bartlomiej Zolnierkiewicz wrote: * Convert cmd64x, hpt366 and pdc202xx_old host drivers to use pci_resource_start(hwif-pci_dev, 4) instead of hwif-dma_master. Before using pci_resource_start(), the code should check pci_resource_len() to ensure it is the appropriate size. It would be very wise to ensure that pci_resource_flags()IORESOURCE_IO is true, too. Sure but since the old code hasn't been doing these checks (old code just did pci_resource_start() - hwif-dma_base - hwif-dma_master) this is a separate issue from what the patch tries to achieve. 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
[regression] 2.6.23 sata_mv EH updates broke my 7042 controller
Hi, I just pulled out my Marvell 7042 SATA controller here to give it a spin and noticed that it no longer worked (i.e. init segvs when loading from it), etc. 2.6.22 is fine. Bisecting (just the file drivers/ata/sata_mv.c) resulted in bdd4dddee325a7dce3e84cf48201a06aa8508aa4 popping out as the culprit (file version 4537deb5e90b717a725b3d74b58b4bb1d28443d0 is fine). Just for sanity checking: Has anyone else used 7042/6042 with the current mainline driver? Hardware config in my case: Highpoint 2310 controller PPC (big endian) WD Raptor disk Works fine with the other controller I've been using (SIL24), and works fine if I revert the driver. It also works fine if I disable the IOMMU. This would point towards either a stale dma mapping, or a missing setup of one. Not being much at home in the SATA drivers I could keep digging but I figured I'd bring it up first in case it rings a bell for someone. -Olof - 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: [regression] 2.6.23 sata_mv EH updates broke my 7042 controller
Olof Johansson wrote: Hi, I just pulled out my Marvell 7042 SATA controller here to give it a spin and noticed that it no longer worked (i.e. init segvs when loading from it), etc. 2.6.22 is fine. Bisecting (just the file drivers/ata/sata_mv.c) resulted in bdd4dddee325a7dce3e84cf48201a06aa8508aa4 popping out as the culprit (file version 4537deb5e90b717a725b3d74b58b4bb1d28443d0 is fine). Just for sanity checking: Has anyone else used 7042/6042 with the current mainline driver? The update was tested extensively on 6042. I have a 7042, but haven't found a compatible PCI slot here. Hardware config in my case: Highpoint 2310 controller PPC (big endian) WD Raptor disk Works fine with the other controller I've been using (SIL24), and works fine if I revert the driver. It also works fine if I disable the IOMMU. This would point towards either a stale dma mapping, or a missing setup of one. Not being much at home in the SATA drivers I could keep digging but I figured I'd bring it up first in case it rings a bell for someone. The IOMMU data point is certainly interesting. Nothing jumps out on a re-review of the patch, so keep digging and let us know ;-) 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
libata-add-human-readable-error-value-decoding-v3.patch (was: -mm merge plans for 2.6.24)
Andrew Morton wrote: libata-add-human-readable-error-value-decoding-v3.patch I think I own this now. Will send to jgarzik then drop it if it doesn't stick. Another plug for this one, as the author. I really don't think one can object to it, and it definitely seems useful. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Jeff Garzik wrote: Polling PMP 2.6.24 is completely unacceptable. It screws the 2.6.24 SAS driver releases out of PMP. Not merging PMP has about the same effect for SAS, right? I pulled your last PMP patchset, and will now endeavor to fix the API prior to 2.6.24 merge window opening. I have a preliminary patch. The patch is pretty simple too. I'll submit after some testing but I'm not sure whether doing this right before the merge window is a good idea. I'd prefer not to support PMP on SAS for 2.6.24. Linux high level message-submit / message-complete APIs should never _require_ polling, even if its 100% polling under the hood. There are far too many cases in the field where you don't have direct access to hardware registers to poll. Or such polling would interfere with the operation of other ports. Or any of a myriad of other reasons. I don't think that's true for actual ATA controllers but, for SAS, probably true. Is the frozen reset mechanism a headache too for SAS? Thanks. -- 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: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Jeff Garzik wrote: Mark Lord wrote: Linux kernel development is supposed to happen incrementally nowadays. Get a nice working solution in place, and then enhance/tune it. It's not about enhancing and tuning. It's about me (and/or James B) having to __undo__ the current code, just to get things working on an entire class of SATA-capable controllers out in the field. Hmmm... Simpy not setting ATA_FLAG_PMP isn't enough? -- 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: Strange arbitrary port resets on ICH9R with Seagate drives
On Mon, 01 Oct 2007 01:30:59 +0100, Jonathan Bell [EMAIL PROTECTED] wrote: Hello I've just purchased a brand spanking new G33/ICH9R based system for use as a home fileserver with 4x ST3750840AS Seagate SATA drives as the main grunt drives. The problem is that all of the seagate drives keep resetting, as this dmesg excerpt shows: Oops. Hardware problem. Insufficient power applied to the hotswap caddy resulted in the drives bugging out when all 4 were accessed, hence cat/dd on an individual drive caused no problems. Now running these drives quite successfully in raid-5 with NCQ and 3.0Gbps links. Regards Jonathan - 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: [regression] 2.6.23 sata_mv EH updates broke my 7042 controller
On Mon, Oct 01, 2007 at 06:37:44PM -0400, Jeff Garzik wrote: Olof Johansson wrote: Hardware config in my case: Highpoint 2310 controller PPC (big endian) WD Raptor disk Works fine with the other controller I've been using (SIL24), and works fine if I revert the driver. It also works fine if I disable the IOMMU. This would point towards either a stale dma mapping, or a missing setup of one. Not being much at home in the SATA drivers I could keep digging but I figured I'd bring it up first in case it rings a bell for someone. The IOMMU data point is certainly interesting. Nothing jumps out on a re-review of the patch, so keep digging and let us know ;-) Looks like it's caused by enabling vmerge (which tends to be on for the common PPC defconfigs). If I disable it, things look OK. Perhaps the Marvell controller doesn't like requests larger than 64K, or wrapping some boundary. Do you have access to erratas/docs? I have verified it on a powermac now as well (had a quick scare that it might have been some problem with the PA Semi IOMMU, but no). -Olof - 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: Promise SATA300 TX4: errors, oops in ext3 code
Have you checked your memory already (memtest86)? [...] Again... sounds like bad memory to me. Nightly memtest86 run : 11 hours, 23 passes, 0 errors. -- ./lxnt - 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
