RE: [git patches] libata fixes
Hello, > Ok, so that's just a message irritation, not actually bothersome > otherwise? It is somewhat painful, because delays involved are quite long, and it is not possible to explain the machine to "ignore" the port, and skip to the next one... > > The second problem is a Jmicron363 controler that is > failing to detect > > the DVD-RW that is connected, unless I use the irqpoll > option as Tejun has > > suggested. > > .. and this one has never worked without irqpoll? Exactly. > So it's the irq16 one that is the Jmicron controller and just isn't > getting any interrupts? It's IRQ 16 that is reported as affected to the Jmicron from the dmesg output, yes. > Since all the other interrupts work (and MSI worked for other > controllers), I don't think it's interrupt-routing related. > Especially as MSI shouldn't even care about things like that. > > And since it all works when "irqpoll" is used, that implies that the > *only* thing that is broken is literally irq delivery. Surely, also if you add the using pci=nomsi doesn't change anything. > Gaah. Can you get a log through serial console or netconsole > to see what changed? I'll try to do that Regards, Paul - 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: freeze issue with the H8SSLi AM2 HT1000
Martin Mailand wrote: > Our main problem is that we can not switch to the 2.6.20 kernel, we must > use the standart Suse kernel 2.6.18.2-34-bigsmp. > Is there any workaround / fix or new fimrware known to fix this freeze > issue? Probably opening a bug report at bugzilla.novell.com and assigning it to me get you somewhere. :-) -- 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: sata_nv error with smartctl access
Richard Scobie wrote: > Hi, > > This may already be addressed, but in case anyone is interested. > > Fedora Core 6 2.6.19-1.2911.6.5, NVIDIA MCP55 based board using sata_nv. > > When querying a drive using smartctl and SMART is not enabled on the > drive, I get the following error: > > ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 > ata3.00: tag 0 cmd 0xb0 Emask 0x1 stat 0x51 err 0x4 (device error) > ata3: EH complete [--snip--] > This does not seem to cause any problems and once SMART is enabled, > there are no more errors. Yeah, that's just libata reporting that a command has failed, which is expected in your case. Maybe libata should shut up on passthru commands. Right, we're currently not honoring REQ_QUIET, but SG doesn't seem to support that flag either. Anyways, it's safe to ignore the messages. -- 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: libata Intel PIIX/ICH fails to detect both PATA drives, spews ACPI errors
Hello, Berck. Berck E. Nash wrote: > Tejun Heo wrote: >> Berck E. Nash wrote: >>> Testing the new libata ICH PATA drivers. There's one PATA port on this >>> chip, and I've got two optical drives connected to it. The master drive >>> fails to detect. The slave detects and works properly. >> Can you test 2.6.20.1 and post full dmesg? > > Here's 2.6.20.2... No ACPI errors, but still doesn't detect both drives. Please apply the attached patch and see if it works. If it works, please post the result of hdparm -I /dev/srX of the optical drive. 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: [git patches] libata fixes
Of course I forgot to CC. :-) Quoting whole message for Justin. Tejun Heo wrote: > Hello, Linus. > > Linus Torvalds wrote: >> On Sun, 11 Mar 2007, Paul Rolland wrote: >>> My machine is having two problems : the one you are describing above, >>> which is due to a SIL controler being connected to one port of the ICH7 >>> (at least, it seems to), and probing it goes timeout, but nothing is >>> connected on it. >> Ok, so that's just a message irritation, not actually bothersome >> otherwise? > > It involves a long timeout, so it's bothersome. This is caused by > Silicon Image 4726/3726 storage processor (SATA Port Multiplier with > extra features) attached to one of the ICH ports. > > If the first downstream port in the PMP is empty and it gets reset in > non-PMP way, it identifies itself as "Config Disk" of quite small size. > It's probably used to configure the extra features using standard ATA > RW commands. Anyways, this "Config Disk" is a bit peculiar and doesn't > work very well with the current ATA reset sequence and gets identified > only after a few failures thus causing long timeout. > > I keep forgetting about this. I'll ask SIMG how to deal with this. For > the time being, connecting a device to the PMP port should remove the > timeouts. > >>> The second problem is a Jmicron363 controler that is failing to detect >>> the DVD-RW that is connected, unless I use the irqpoll option as Tejun has >>> suggested. >> .. and this one has never worked without irqpoll? >> >>> But, as you suggest it, I'm adding pci=nomsi to the command line >>> rebooting... no change for this part of the problem. >>> >>> OK, the /proc/interrupt for this config, and the dmesg attached. >>> >>> 3 [23:22] [EMAIL PROTECTED]:~> cat /proc/interrupts >>>CPU0 CPU1 >>> 0: 297549 0 IO-APIC-edge timer >>> 1: 7 0 IO-APIC-edge i8042 >>> 4: 13 0 IO-APIC-edge serial >>> 6: 5 0 IO-APIC-edge floppy >>> 8: 1 0 IO-APIC-edge rtc >>> 9: 0 0 IO-APIC-fasteoi acpi >>> 12:126 0 IO-APIC-edge i8042 >>> 14: 8313 0 IO-APIC-edge libata >>> 15: 0 0 IO-APIC-edge libata >>> 16: 0 0 IO-APIC-fasteoi eth1, libata >> So it's the irq16 one that is the Jmicron controller and just isn't >> getting any interrupts? >> >> Since all the other interrupts work (and MSI worked for other >> controllers), I don't think it's interrupt-routing related. Especially as >> MSI shouldn't even care about things like that. >> >> And since it all works when "irqpoll" is used, that implies that the >> *only* thing that is broken is literally irq delivery. >> >> Is there possibly some jmicron-specific "enable interrupts" bit? > > (cc'ing Justin of JMicron. Hello, please correct me if I'm wrong.) > > Not that I know of. The PATA portion of JMB controllers is bog standard > PCI BMDMA ATA device where ATA_NIEN is the way to turn IRQ on and off. > > 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: [git patches] libata fixes
Hello, Linus. Linus Torvalds wrote: > On Sun, 11 Mar 2007, Paul Rolland wrote: >> My machine is having two problems : the one you are describing above, >> which is due to a SIL controler being connected to one port of the ICH7 >> (at least, it seems to), and probing it goes timeout, but nothing is >> connected on it. > > Ok, so that's just a message irritation, not actually bothersome > otherwise? It involves a long timeout, so it's bothersome. This is caused by Silicon Image 4726/3726 storage processor (SATA Port Multiplier with extra features) attached to one of the ICH ports. If the first downstream port in the PMP is empty and it gets reset in non-PMP way, it identifies itself as "Config Disk" of quite small size. It's probably used to configure the extra features using standard ATA RW commands. Anyways, this "Config Disk" is a bit peculiar and doesn't work very well with the current ATA reset sequence and gets identified only after a few failures thus causing long timeout. I keep forgetting about this. I'll ask SIMG how to deal with this. For the time being, connecting a device to the PMP port should remove the timeouts. >> The second problem is a Jmicron363 controler that is failing to detect >> the DVD-RW that is connected, unless I use the irqpoll option as Tejun has >> suggested. > > .. and this one has never worked without irqpoll? > >> But, as you suggest it, I'm adding pci=nomsi to the command line >> rebooting... no change for this part of the problem. >> >> OK, the /proc/interrupt for this config, and the dmesg attached. >> >> 3 [23:22] [EMAIL PROTECTED]:~> cat /proc/interrupts >>CPU0 CPU1 >> 0: 297549 0 IO-APIC-edge timer >> 1: 7 0 IO-APIC-edge i8042 >> 4: 13 0 IO-APIC-edge serial >> 6: 5 0 IO-APIC-edge floppy >> 8: 1 0 IO-APIC-edge rtc >> 9: 0 0 IO-APIC-fasteoi acpi >> 12:126 0 IO-APIC-edge i8042 >> 14: 8313 0 IO-APIC-edge libata >> 15: 0 0 IO-APIC-edge libata >> 16: 0 0 IO-APIC-fasteoi eth1, libata > > So it's the irq16 one that is the Jmicron controller and just isn't > getting any interrupts? > > Since all the other interrupts work (and MSI worked for other > controllers), I don't think it's interrupt-routing related. Especially as > MSI shouldn't even care about things like that. > > And since it all works when "irqpoll" is used, that implies that the > *only* thing that is broken is literally irq delivery. > > Is there possibly some jmicron-specific "enable interrupts" bit? (cc'ing Justin of JMicron. Hello, please correct me if I'm wrong.) Not that I know of. The PATA portion of JMB controllers is bog standard PCI BMDMA ATA device where ATA_NIEN is the way to turn IRQ on and off. 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: sata-nv hotplug feature
Hello, Russ Weeks wrote: > Thanks, Jim, Tejun. Upgrading to 2.6.20 solved all my problems. Great. > What I observe now is that once the drive is plugged in again, 2-3 > minutes may pass before the device entry appears in /dev. This isn't a > problem for me, but if you have time to explain I'd be interested to > know why. Please post the result of dmesg and lspci -nn. > Also, if you have any tips on 'best practices' for drive yanking, I'd > appreciate 'em. So far I'm just doing 'sdparm --command=stop'. That should do the job. -- 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: impact of 4k sector size on the IO & FS stack
On Mar 12, 2007 04:27 +0100, Jan Engelhardt wrote: > Assume this partition table on my current HD: > > Disk /dev/hdc: 251.0 GB, 251000193024 bytes > 255 heads, 63 sectors/track, 30515 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Start End Blocks Id System > /dev/hdc1 1 33 265041 82 Linux swap / Solaris > /dev/hdc2 34 30515 2448466655 Extended > > That is, 255 * 63 * 30515 * 512 == roughly 251 GB. > > Now, if this disk was copied byte per byte (/bin/dd) to a > 4096-based disk, and Linux would start using a sector size of > 4096 The easy answer is "don't do that". You should make a new partition table on the 4096-byte sector drive (each of the partitions at least as large as the old ones), and then copy the content of each of the partitions separately onto the new disk. > Although I would not mind the 2 TB, the partition table would > read quite differently (note the Blocks column which is > multiplied by 4 (512x4=4096)) > >Device Start End Blocks Id System > /dev/hdc1 1 33 1060164 82 Linux swap / Solaris > /dev/hdc2 34 30515 9793866605 Extended > > Which would mean that the swap partition reaches into the real > data partition and would corrupt it. In the same way you can't copy raw disks from one vendor's RAID 5 array and put them into another vendor's (or even model's) RAID 5 array, or you can't do a raw copy of a partitioned disk and expect it to suddenly become an LVM volume, you can't do raw disk copies between drives with different sector size. You also won't be able to use a copy of an ext3 filesystems with 1kB blocksize onto a 4kB sector size device - the ext3 code will detect this and refuse to mount. At that point you need to do a tar/untar (or whatever) to copy the data instead of a raw partition copy. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - 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: impact of 4k sector size on the IO & FS stack
On Mar 11 2007 22:45, Ric Wheeler wrote: > Jan Engelhardt wrote: >> On Mar 11 2007 18:51, Ric Wheeler wrote: >> >> > During the recent IO/FS workshop, we spoke briefly about the >> > coming change to a 4k sector size for disks on linux. If I >> > recall correctly, the general feeling was that the impact was >> > not significant since we already do most file system IO in 4k >> > page sizes and should be fine as long as we partition drives >> > correctly and avoid non-4k aligned partitions. >> > >> >> Sorry about jumping right in, but what about an 'old-style' >> partition table that relies on 512 as a unit? >> >> > I think that the normal case would involve new drives which > would need to be partitioned in 4k aligned partitions. > Shouldn't that work regardless of the unit used in the > partition table? Assume this partition table on my current HD: Disk /dev/hdc: 251.0 GB, 251000193024 bytes 255 heads, 63 sectors/track, 30515 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Start End Blocks Id System /dev/hdc1 1 33 265041 82 Linux swap / Solaris /dev/hdc2 34 30515 2448466655 Extended That is, 255 * 63 * 30515 * 512 == roughly 251 GB. Now, if this disk was copied byte per byte (/bin/dd) to a 4096-based disk, and Linux would start using a sector size of 4096, then I would suddenly have 255 * 63 * 30515 * 4096 == 2 TB Although I would not mind the 2 TB, the partition table would read quite differently (note the Blocks column which is multiplied by 4 (512x4=4096)) Device Start End Blocks Id System /dev/hdc1 1 33 1060164 82 Linux swap / Solaris /dev/hdc2 34 30515 9793866605 Extended Which would mean that the swap partition reaches into the real data partition and would corrupt it. That's what I am concerned about. Jan -- - 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: impact of 4k sector size on the IO & FS stack
Jan Engelhardt wrote: On Mar 11 2007 18:51, Ric Wheeler wrote: During the recent IO/FS workshop, we spoke briefly about the coming change to a 4k sector size for disks on linux. If I recall correctly, the general feeling was that the impact was not significant since we already do most file system IO in 4k page sizes and should be fine as long as we partition drives correctly and avoid non-4k aligned partitions. Sorry about jumping right in, but what about an 'old-style' partition table that relies on 512 as a unit? I think that the normal case would involve new drives which would need to be partitioned in 4k aligned partitions. Shouldn't that work regardless of the unit used in the partition table? ric - 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: impact of 4k sector size on the IO & FS stack
Alan Cox wrote: Are there other concerns in the IO or FS stack that we should bring up with vendors? I have been asked to summarize the impact of 4k sectors on linux for a disk vendor gathering and want to make sure that I put all of our linux specific items into that summary... We need to make sure the physical sector size is correctly reported by the disk (eg in the ATA7 identify data) but I think for libata at least the right bits are already there and we've got a fair amount of scsi disk experience with other media sizes (eg 2K) already. 256byte/sector media is still broken btw 8) It would be really interesting to see if we can validate this with prototype drives. I would be interested to know what the disk vendors intend to use as their strategy when (with ATA) they have a 512 byte write from an older file system/setup into a 4K block. The case where errors magically appear in other parts of the fs when such an error occurs are not IMHO too well considered. Alan As Jeff mentioned, I think that they would have to do a read-modify-write simulation which would kill performance for a small, random write work load... ric - 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: impact of 4k sector size on the IO & FS stack
Jeff Garzik wrote: Alan Cox wrote: I would be interested to know what the disk vendors intend to use as their strategy when (with ATA) they have a 512 byte write from an older file system/setup into a 4K block. The case where errors magically appear Well, you have logical and physical sector size changes. First generation of 1K sector drives will continue to use the same 512-byte ATA sector size you are familiar with. A single 512-byte write will cause the drive to perform a read-modify-write cycle. This configuration is physical 1K sector, logical 512b sector. It would seem that most writes would avoid this - hopefully the drive firmware could use the write cache to coalesce contiguous IO's into 1k multiples when getting streams of 512 byte write requests. A future configuration will change the logical ATA interface away from 512-byte sectors to 1K or 4K. Here, it is impossible to read a quantity smaller than 1K or 4K, whatever the sector size is. Jeff I will try and see if I can get some specific information on when the various flavors of this are going to appear... ric - 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: IDE/ATAPI timeouts & lost interrupts on alpha with 2.6.20.2
On Sun, Mar 11, 2007 at 01:02:13AM +0100, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > It seems that the generic IDE host driver is loaded first > (CONFIG_IDE_GENERIC=y/m) and "steals" resources needed by cy82c693. > > Please try again without the generic IDE host driver so the proper > driver could be used. $ zgrep IDE_GENERIC /proc/config.gz # CONFIG_IDE_GENERIC is not set .. and I get the same behaviour > If it doesn't help I think that the best way to chase it is git bisect git-bisect, here I come.. -- Russell Howe | Why be just another cog in the machine, [EMAIL PROTECTED] | when you can be the spanner in the works? - 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: [git patches] libata fixes
On Sun, 11 Mar 2007, Paul Rolland wrote: > > My machine is having two problems : the one you are describing above, > which is due to a SIL controler being connected to one port of the ICH7 > (at least, it seems to), and probing it goes timeout, but nothing is > connected on it. Ok, so that's just a message irritation, not actually bothersome otherwise? > The second problem is a Jmicron363 controler that is failing to detect > the DVD-RW that is connected, unless I use the irqpoll option as Tejun has > suggested. .. and this one has never worked without irqpoll? > But, as you suggest it, I'm adding pci=nomsi to the command line > rebooting... no change for this part of the problem. > > OK, the /proc/interrupt for this config, and the dmesg attached. > > 3 [23:22] [EMAIL PROTECTED]:~> cat /proc/interrupts >CPU0 CPU1 > 0: 297549 0 IO-APIC-edge timer > 1: 7 0 IO-APIC-edge i8042 > 4: 13 0 IO-APIC-edge serial > 6: 5 0 IO-APIC-edge floppy > 8: 1 0 IO-APIC-edge rtc > 9: 0 0 IO-APIC-fasteoi acpi > 12:126 0 IO-APIC-edge i8042 > 14: 8313 0 IO-APIC-edge libata > 15: 0 0 IO-APIC-edge libata > 16: 0 0 IO-APIC-fasteoi eth1, libata So it's the irq16 one that is the Jmicron controller and just isn't getting any interrupts? Since all the other interrupts work (and MSI worked for other controllers), I don't think it's interrupt-routing related. Especially as MSI shouldn't even care about things like that. And since it all works when "irqpoll" is used, that implies that the *only* thing that is broken is literally irq delivery. Is there possibly some jmicron-specific "enable interrupts" bit? > PS : I'd like to try 2.6.21-rc3, but it seems that this is breaking my > config : disk naming is no more the same, and I end up with a panic > Warning: unable to open an initial console > though i've been compiling with the same .config I was using for 2.6.21-rc2 Gaah. Can you get a log through serial console or netconsole to see what changed? 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: impact of 4k sector size on the IO & FS stack
Alan Cox wrote: I would be interested to know what the disk vendors intend to use as their strategy when (with ATA) they have a 512 byte write from an older file system/setup into a 4K block. The case where errors magically appear Well, you have logical and physical sector size changes. First generation of 1K sector drives will continue to use the same 512-byte ATA sector size you are familiar with. A single 512-byte write will cause the drive to perform a read-modify-write cycle. This configuration is physical 1K sector, logical 512b sector. A future configuration will change the logical ATA interface away from 512-byte sectors to 1K or 4K. Here, it is impossible to read a quantity smaller than 1K or 4K, whatever the sector size is. 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: impact of 4k sector size on the IO & FS stack
On Mar 11 2007 18:51, Ric Wheeler wrote: > > During the recent IO/FS workshop, we spoke briefly about the > coming change to a 4k sector size for disks on linux. If I > recall correctly, the general feeling was that the impact was > not significant since we already do most file system IO in 4k > page sizes and should be fine as long as we partition drives > correctly and avoid non-4k aligned partitions. Sorry about jumping right in, but what about an 'old-style' partition table that relies on 512 as a unit? > Are there other concerns in the IO or FS stack that we should > bring up with vendors? I have been asked to summarize the > impact of 4k sectors on linux for a disk vendor gathering and > want to make sure that I put all of our linux specific items > into that summary... Jan -- - 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: impact of 4k sector size on the IO & FS stack
> Are there other concerns in the IO or FS stack that we should bring up > with vendors? I have been asked to summarize the impact of 4k sectors > on linux for a disk vendor gathering and want to make sure that I put > all of our linux specific items into that summary... We need to make sure the physical sector size is correctly reported by the disk (eg in the ATA7 identify data) but I think for libata at least the right bits are already there and we've got a fair amount of scsi disk experience with other media sizes (eg 2K) already. 256byte/sector media is still broken btw 8) I would be interested to know what the disk vendors intend to use as their strategy when (with ATA) they have a 512 byte write from an older file system/setup into a 4K block. The case where errors magically appear in other parts of the fs when such an error occurs are not IMHO too well considered. Alan - 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
impact of 4k sector size on the IO & FS stack
During the recent IO/FS workshop, we spoke briefly about the coming change to a 4k sector size for disks on linux. If I recall correctly, the general feeling was that the impact was not significant since we already do most file system IO in 4k page sizes and should be fine as long as we partition drives correctly and avoid non-4k aligned partitions. Are there other concerns in the IO or FS stack that we should bring up with vendors? I have been asked to summarize the impact of 4k sectors on linux for a disk vendor gathering and want to make sure that I put all of our linux specific items into that summary... ric - 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: [git patches] libata fixes
Hello, > > Nope... I tried several patches from Tejun, and also some > that Jeff posted > > to linux-ide, but no luck. The only way to have this DVD-RW > working is to > > use irqpoll on the command line... > > So it has *never* worked? That's what I'm trying to see - you had a > "before" and "after" dmesg in one of your posts, and the "before" one > looked fine (as if it was working) because it didn't have the error > messages. > > So I'm just trying to figure out where the regression started... > > > To complete, here are some more output from the machine : > > What happens if you disable MSI entirely? Use "pci=nomsi" on > the command > line. > > The > > ata2.00: qc timeout (cmd 0xec) > ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104) > > messages happen for you on the controller that claims MSI: > > ata2: SATA max UDMA/133 cmd 0xc208a980 ctl > 0x bmdma 0x irq 504 > > and quite frankly, we've had lots of bugs with MSI, both in > hardware and > in software. OK, I see, we are talking about two different problems... My machine is having two problems : the one you are describing above, which is due to a SIL controler being connected to one port of the ICH7 (at least, it seems to), and probing it goes timeout, but nothing is connected on it. The second problem is a Jmicron363 controler that is failing to detect the DVD-RW that is connected, unless I use the irqpoll option as Tejun has suggested. >From what I remember, except my initial description of the problem, no attempt has been made yet to workaround/understand the first problem, and all the mails I've exchanged were focused on the second one. But, as you suggest it, I'm adding pci=nomsi to the command line rebooting... no change for this part of the problem. OK, the /proc/interrupt for this config, and the dmesg attached. 3 [23:22] [EMAIL PROTECTED]:~> cat /proc/interrupts CPU0 CPU1 0: 297549 0 IO-APIC-edge timer 1: 7 0 IO-APIC-edge i8042 4: 13 0 IO-APIC-edge serial 6: 5 0 IO-APIC-edge floppy 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12:126 0 IO-APIC-edge i8042 14: 8313 0 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 16: 0 0 IO-APIC-fasteoi eth1, libata 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 18: 6894 0 IO-APIC-fasteoi uhci_hcd:usb4 19:579 0 IO-APIC-fasteoi eth0, uhci_hcd:usb5, HDA Intel 20:104 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 21: 3 0 IO-APIC-fasteoi ohci1394 23: 7205 0 IO-APIC-fasteoi libata NMI:783540 LOC: 291823 290536 PS : I'd like to try 2.6.21-rc3, but it seems that this is breaking my config : disk naming is no more the same, and I end up with a panic Warning: unable to open an initial console though i've been compiling with the same .config I was using for 2.6.21-rc2 Regards, Paul dmesg-2.6.21-rc2-irqpoll-nomsi Description: Binary data
[PATCH libata#upstream 2/2] sata_promise: separate SATA and PATA ops
This patch changes sata_promise so that the PATA ports
on TX2plus chips are bound to the pdc_pata_ops structure.
This means that operations called from the SATA ops
structures don't need any SATA-vs-PATA tests any more.
Instead, operations that depend on a port being SATA or
PATA are separated into different procedures.
* pdc_cable_type() is split into a PATA version and a
SATA version
* pdc_error_handler() is split into a PATA version and a
SATA version, that both call a common version after
setting up the `hardreset' function pointer
* pdc_old_check_atapi_dma() is now only used for SATAI
ports, so is renamed to pdc_old_sata_check_atapi_dma()
and simplified
* pdc_sata_scr_{read,write}() are now only used for SATA
ports, so their is-not-SATA tests are removed
* pdc_port_start() is split into three procedures: a wrapper
which performs the ->ops adjustment on TX2plus PATA ports,
a procedure with the common code, and a procedure with
the SATA-specific code (this bit might be cleaned up by
Tejun's new init model)
Tested on 20619, 20575, and 20775 chips.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
---
drivers/ata/sata_promise.c | 107 +++--
1 files changed, 66 insertions(+), 41 deletions(-)
--- linux-2.6.21-rc3+upstream/drivers/ata/sata_promise.c.~1~2007-03-11
20:54:10.0 +0100
+++ linux-2.6.21-rc3+upstream/drivers/ata/sata_promise.c2007-03-11
20:54:27.0 +0100
@@ -45,7 +45,7 @@
#include "sata_promise.h"
#define DRV_NAME "sata_promise"
-#define DRV_VERSION"2.02"
+#define DRV_VERSION"2.03"
enum {
@@ -124,14 +124,16 @@ static void pdc_qc_prep(struct ata_queue
static void pdc_tf_load_mmio(struct ata_port *ap, const struct ata_taskfile
*tf);
static void pdc_exec_command_mmio(struct ata_port *ap, const struct
ata_taskfile *tf);
static int pdc_check_atapi_dma(struct ata_queued_cmd *qc);
-static int pdc_old_check_atapi_dma(struct ata_queued_cmd *qc);
+static int pdc_old_sata_check_atapi_dma(struct ata_queued_cmd *qc);
static void pdc_irq_clear(struct ata_port *ap);
static unsigned int pdc_qc_issue_prot(struct ata_queued_cmd *qc);
static void pdc_freeze(struct ata_port *ap);
static void pdc_thaw(struct ata_port *ap);
-static void pdc_error_handler(struct ata_port *ap);
+static void pdc_pata_error_handler(struct ata_port *ap);
+static void pdc_sata_error_handler(struct ata_port *ap);
static void pdc_post_internal_cmd(struct ata_queued_cmd *qc);
-static int pdc_cable_detect(struct ata_port *ap);
+static int pdc_pata_cable_detect(struct ata_port *ap);
+static int pdc_sata_cable_detect(struct ata_port *ap);
static struct scsi_host_template pdc_ata_sht = {
.module = THIS_MODULE,
@@ -164,9 +166,9 @@ static const struct ata_port_operations
.qc_issue = pdc_qc_issue_prot,
.freeze = pdc_freeze,
.thaw = pdc_thaw,
- .error_handler = pdc_error_handler,
+ .error_handler = pdc_sata_error_handler,
.post_internal_cmd = pdc_post_internal_cmd,
- .cable_detect = pdc_cable_detect,
+ .cable_detect = pdc_sata_cable_detect,
.data_xfer = ata_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear = pdc_irq_clear,
@@ -186,15 +188,15 @@ static const struct ata_port_operations
.check_status = ata_check_status,
.exec_command = pdc_exec_command_mmio,
.dev_select = ata_std_dev_select,
- .check_atapi_dma= pdc_old_check_atapi_dma,
+ .check_atapi_dma= pdc_old_sata_check_atapi_dma,
.qc_prep= pdc_qc_prep,
.qc_issue = pdc_qc_issue_prot,
.freeze = pdc_freeze,
.thaw = pdc_thaw,
- .error_handler = pdc_error_handler,
+ .error_handler = pdc_sata_error_handler,
.post_internal_cmd = pdc_post_internal_cmd,
- .cable_detect = pdc_cable_detect,
+ .cable_detect = pdc_sata_cable_detect,
.data_xfer = ata_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear = pdc_irq_clear,
@@ -219,9 +221,9 @@ static const struct ata_port_operations
.qc_issue = pdc_qc_issue_prot,
.freeze = pdc_freeze,
.thaw = pdc_thaw,
- .error_handler = pdc_error_handler,
+ .error_handler = pdc_pata_error_handler,
.post_internal_cmd = pdc_post_internal_cmd,
- .cable_detect = pdc_cable_detect,
+ .cable_detect = pdc_pata_cable_detect,
.data_xfer = ata_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear = pdc_irq_clear,
@@ -316
[PATCH libata#upstream 1/2] sata_promise: add missing cable_detect hooks
The recent change which moved cable detection from
pdc_pre_reset() to the new ->cable_detect hook only
added the hook for SATAII chips, leaving SATAI chips
and the 20619 without the hook. Fixed by this patch.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
---
drivers/ata/sata_promise.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.21-rc3/drivers/ata/sata_promise.c.~1~ 2007-03-11
18:44:04.0 +0100
+++ linux-2.6.21-rc3/drivers/ata/sata_promise.c 2007-03-11 18:44:56.0
+0100
@@ -45,7 +45,7 @@
#include "sata_promise.h"
#define DRV_NAME "sata_promise"
-#define DRV_VERSION"2.01"
+#define DRV_VERSION"2.02"
enum {
@@ -194,6 +194,7 @@ static const struct ata_port_operations
.thaw = pdc_thaw,
.error_handler = pdc_error_handler,
.post_internal_cmd = pdc_post_internal_cmd,
+ .cable_detect = pdc_cable_detect,
.data_xfer = ata_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear = pdc_irq_clear,
@@ -220,6 +221,7 @@ static const struct ata_port_operations
.thaw = pdc_thaw,
.error_handler = pdc_error_handler,
.post_internal_cmd = pdc_post_internal_cmd,
+ .cable_detect = pdc_cable_detect,
.data_xfer = ata_data_xfer,
.irq_handler= pdc_interrupt,
.irq_clear = pdc_irq_clear,
-
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: [git patches] libata fixes
On Sun, 11 Mar 2007, Paul Rolland wrote: > > Nope... I tried several patches from Tejun, and also some that Jeff posted > to linux-ide, but no luck. The only way to have this DVD-RW working is to > use irqpoll on the command line... So it has *never* worked? That's what I'm trying to see - you had a "before" and "after" dmesg in one of your posts, and the "before" one looked fine (as if it was working) because it didn't have the error messages. So I'm just trying to figure out where the regression started... > To complete, here are some more output from the machine : What happens if you disable MSI entirely? Use "pci=nomsi" on the command line. The ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x104) messages happen for you on the controller that claims MSI: ata2: SATA max UDMA/133 cmd 0xc208a980 ctl 0x bmdma 0x irq 504 and quite frankly, we've had lots of bugs with MSI, both in hardware and in software. 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: [git patches] libata fixes
Just one point that may be interesting, as it seems that this is IRQ related : at the beginning of the dmesg, it seems that IRQ16 is used for sky2/Yukon , but when reading /proc/interrupts, it has been remapped to IRQ 505... Could this also affect libata ? Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator and Peering Coordinator -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Rolland > Sent: Sunday, March 11, 2007 7:35 PM > To: 'Linus Torvalds' > Cc: 'Tejun Heo'; 'Jeff Garzik'; 'Andrew Morton'; > linux-ide@vger.kernel.org; 'LKML'; 'Eric D. Mudama' > Subject: RE: [git patches] libata fixes > > Hello, > > > do I understand correctly that the *only* difference between > > the working > > setup is that you applied (by hand) the libata patch that > > Jeff sent out? > > > > So plain 2.6.21-rc2 works fine, but with the patch applied, > > you get no > > interrupts on the DVD drive? > > Nope... I tried several patches from Tejun, and also some > that Jeff posted > to linux-ide, but no luck. The only way to have this DVD-RW > working is to > use irqpoll on the command line... > > Sorry to have been unclear > > To complete, here are some more output from the machine : > - a dmesg without irqpoll, > - a dmesg with irqpoll, > - a copy of /proc/interrupts > 6 [19:33] [EMAIL PROTECTED]:~> cat /proc/interrupts >CPU0 CPU1 > 0: 357022 0 IO-APIC-edge timer > 1: 8 0 IO-APIC-edge i8042 > 4: 14 0 IO-APIC-edge serial > 6: 5 0 IO-APIC-edge floppy > 8: 1 0 IO-APIC-edge rtc > 9: 0 0 IO-APIC-fasteoi acpi > 12:129 0 IO-APIC-edge i8042 > 14: 7639 0 IO-APIC-edge libata > 15: 0 0 IO-APIC-edge libata > 16: 0 0 IO-APIC-fasteoi libata > 17: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 > 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 > 19:204 0 IO-APIC-fasteoi uhci_hcd:usb5, > HDA Intel > 20:107 0 IO-APIC-fasteoi ehci_hcd:usb1, > uhci_hcd:usb2 > 21: 3 0 IO-APIC-fasteoi ohci1394 > 504: 8243 0 PCI-MSI-edge libata > 505: 1 0 PCI-MSI-edge eth1 > 506:386 0 PCI-MSI-edge eth0 > NMI:771531 > LOC: 569318 578684 > ERR: 0 > > Regards, > Paul > - 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: [git patches] libata fixes
Paul, do I understand correctly that the *only* difference between the working setup is that you applied (by hand) the libata patch that Jeff sent out? So plain 2.6.21-rc2 works fine, but with the patch applied, you get no interrupts on the DVD drive? On Sun, 11 Mar 2007, Paul Rolland wrote: > > > It seems like IRQ is not getting through. The first IRQ > > driven command is failing for you. > > H > > Extract is : > > ata7: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma > > 0x00019400 irq 16 > > ata8: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma > > 0x00019408 irq 16 > > IRQ 16 is IO-APIC-fasteoi for libata, and is not shared... but all the > others libata IRQ are IO-APIC-edge. Ok, that's interesting, although IO-APIC-fasteoi certainly works for others (eg me), but it's still useful. > > * Does giving 'acpi=off' or 'irqpoll' make any difference? > > > > * Can you connect a harddisk to the channel and see whether > > that works? > > Tried that.. Disk is identified as ATA-7: Mastor 6Y080L0, YAR41BW0, max > UDMA/13 and then timeout again... > > Tried then with acpi=off, same result (identify is OK, but then timeout), > and irqpoll and then it was OK Whee... There were no changes that looked interrupt-related there.. 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: libata Intel PIIX/ICH fails to detect both PATA drives, spews ACPI errors
Tejun Heo wrote: > Berck E. Nash wrote: >> Testing the new libata ICH PATA drivers. There's one PATA port on this >> chip, and I've got two optical drives connected to it. The master drive >> fails to detect. The slave detects and works properly. > > Can you test 2.6.20.1 and post full dmesg? Here's 2.6.20.2... No ACPI errors, but still doesn't detect both drives. [0.00] Linux version 2.6.20.2 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Sun Mar 11 05:50:34 MDT 2007 [0.00] Command line: root=/dev/sdc1 ro console=tty0 console=ttyS0,115200n8 BOOT_IMAGE=vmlinuz [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000e4000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3ff8 (usable) [0.00] BIOS-e820: 3ff8 - 3ff8e000 (ACPI data) [0.00] BIOS-e820: 3ff8e000 - 3ffe (ACPI NVS) [0.00] BIOS-e820: 3ffe - 4000 (reserved) [0.00] BIOS-e820: ffb0 - 0001 (reserved) [0.00] end_pfn_map = 1048576 [0.00] DMI 2.4 present. [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 262016 [0.00] ACPI: PM-Timer IO Port: 0x808 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00] Processor #1 [0.00] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) [0.00] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] Setting APIC routing to flat [0.00] ACPI: HPET id: 0x8086a201 base: 0xfed0 [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Nosave address range: 0009f000 - 000a [0.00] Nosave address range: 000a - 000e4000 [0.00] Nosave address range: 000e4000 - 0010 [0.00] Allocating PCI resources starting at 5000 (gap: 4000:bfb0) [0.00] PERCPU: Allocating 31872 bytes of per cpu data [0.00] Built 1 zonelists. Total pages: 257492 [0.00] Kernel command line: root=/dev/sdc1 ro console=tty0 console=ttyS0,115200n8 BOOT_IMAGE=vmlinuz [0.00] Initializing CPU#0 [0.00] PID hash table entries: 4096 (order: 12, 32768 bytes) [ 55.520818] Console: colour VGA+ 80x25 [ 55.783193] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 55.790592] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) [ 55.797553] Checking aperture... [ 55.808626] Memory: 1028168k/1048064k available (1968k kernel code, 19392k reserved, 887k data, 192k init) [ 55.899175] Calibrating delay using timer specific routine.. 5611.38 BogoMIPS (lpj=9349414) [ 55.907642] Mount-cache hash table entries: 256 [ 55.912287] CPU: L1 I cache: 32K, L1 D cache: 32K [ 55.917075] CPU: L2 cache: 2048K [ 55.920342] using mwait in idle threads. [ 55.924299] CPU: Physical Processor ID: 0 [ 55.928343] CPU: Processor Core ID: 0 [ 55.932044] CPU0: Thermal monitoring enabled (TM2) [ 55.936881] Freeing SMP alternatives: 24k freed [ 55.941454] ACPI: Core revision 20060707 [ 55.983013] Using local APIC timer interrupts. [ 56.023138] result 25026964 [ 56.025969] Detected 25.026 MHz APIC timer. [ 56.032439] Booting processor 1/2 APIC 0x1 [ 56.047243] Initializing CPU#1 [ 56.128968] Calibrating delay using timer specific routine.. 5608.35 BogoMIPS (lpj=9342966) [ 56.128972] CPU: L1 I cache: 32K, L1 D cache: 32K [ 56.128974] CPU: L2 cache: 2048K [ 56.128975] CPU: Physical Processor ID: 0 [ 56.128976] CPU: Processor Core ID: 1 [ 56.128980] CPU1: Thermal monitoring enabled (TM2) [ 56.129178] Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping 06 [ 56.132304] Brought up 2 CPUs [ 56.174023] testing NMI watchdog ... OK. [ 56.211020] time.c: Using 14.318180 MHz WALL HPET GTOD HPET/TSC timer. [ 56.217583] time.c: Detected 2803.022 MHz processor. [ 56.247913] migration_cost=19 [ 56.251168] NET: Regis
RE: [git patches] libata fixes
Hello, > It seems like IRQ is not getting through. The first IRQ > driven command is failing for you. H > Extract is : > ata7: PATA max UDMA/100 cmd 0x00019c00 ctl 0x00019882 bmdma > 0x00019400 irq 16 > ata8: PATA max UDMA/100 cmd 0x00019800 ctl 0x00019482 bmdma > 0x00019408 irq 16 IRQ 16 is IO-APIC-fasteoi for libata, and is not shared... but all the others libata IRQ are IO-APIC-edge. > * Does giving 'acpi=off' or 'irqpoll' make any difference? > > * Can you connect a harddisk to the channel and see whether > that works? Tried that.. Disk is identified as ATA-7: Mastor 6Y080L0, YAR41BW0, max UDMA/13 and then timeout again... Tried then with acpi=off, same result (identify is OK, but then timeout), and irqpoll and then it was OK Let's then go back to my DVD-RW and test irqpoll... and ... Yes Got it ! It is identified, it can be mounted, and read as /dev/sr1 ! /proc/interrupts show a count of 0 for IRQ 16, so yes, it goes somewhere else... Doing some diffs on copy of /proc/interrupts while accessing the DVD gives two possibilities : IRQ14 or IRQ18, but both are also counting when not accessing the DVD... Question : does running with irqpoll affects performance ? Paul - 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
