Re: PROBLEM:Bug when installing NVidia Driver Module
I have tried out the latest NVidia driver set, and they do work fine for me with plain vanilla 2.4.3 on my Athlon with GCC 2.95.3. I would blame your compiler, it's dated July 2000, that's an old CVS version AFAIK. - Aric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM:Bug when installing NVidia Driver Module
According to the kernel soruces, _mmx_memcpy is only defined when Athlon is selected... I noticed that you are using GCC 2.96... Is this the latest one that Redhat recommends you update in order to build the kernel? I forget, something like GCC 2.96-79. I have a similar setup at home... I'll try the new nVidia drivers tonight and see how it goes. - Aric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sata_sil 3112 activity LED patch
On Fri, Jul 15, 2005 at 04:15:12AM +0200, Christian Kroll wrote: > I have tested the patch against my DawiControl DC-150 RAID controller > which is basically an add-on card with a SiI 3112 ASIC and a flash ROM. > The activity LED of my case is directly connected to the add-on card. > > Unfortunately your patch doesn't have any effect on the LED. The > activity LED gets turned on by the card's BIOS at boot time and > continues to shine until I shut down the computer. > On the other hand it did not erase my Flash ROM and I haven't spotted > any data loss so far. No data loss is a good thing! That was my biggest worry, as I have no documentation for the addon card case. Out of curiosity, did the LED usage change at all before and after the patch, or was it totally unaffected. I would guess the latter. Unfortunately, what documentation I do have shows (briefly) that add on cards implement their LED via a different mechanism. If I knew the addresses for the flash read and write strobes (FL_RDN and FL_WRN), I might be able to work something out. So as it stands, there is not much hope for the people with addon cards. > If you require more information, don't hesitate to contact me. Thanks, I will. I have emailed Silicon Image in the (slim) chance that they will provide me with the information I require. If they come through then I might be able to whip something up and have you test it. If anyone has any data on the 3112a (or 3512 as I believe they are register compatible) and isn't bound by an NDA, I'd like to hear from you. -- Aric Cyr (http://acyr.net) gpg fingerprint: 943A 1549 47AC D766 B7F8 D551 6703 7142 C282 D542 pgpfSBy3ao27E.pgp Description: PGP signature
sata_sil 3112 activity LED patch
After finally getting fed up with not having my activity light working
for my SATA drives, I came up with a small patch (more like hack) to
make it work. It works quite well, but I'm afraid that there are many
restriction that this patch does not check for that it probably
should... so consider this a work-in-progress. My information is
based on a document from Silicon Image that appears to no longer be
available on their website (Sil-AN-0082-E; 8112-0082.pdf). I still
have a copy if anyone is interested.
There are two restrictions that are not checked:
1) Is the chip a 3112 or 3114? I assume that this would only work on
a 3112, but whether it is "a bad thing" on a 3114 I do not know.
2) BAR5 + 0x54 is apparently used for the flash memory address and
data lines. However for most motherboards (i.e. not add-on cards)
with the chip, like my EPOX 8RDA3+, there is no flash memory, so
these lines are hijacked as LED GPIO. I assume that this is a
common practice for motherboard makers using the sil3112 since
Silicon Image went out of their way to produce the above mentioned
document. Anyways, the problem is that this patch does not check
if flash memory is installed or not before twiddling with the GPIO
lines. This could be extremely bad for people running the 3112
from add-on cards (or any implementation with flash memory
installed).
Setting the low 8bits at BAR5+54h seems to enable the LED circuit. It
seems that this circuit is patched through into the motherboard as it
lights the regular hard drive light on the front of my case. Setting
bits [8:15] at BAR5+54h clears the bits, disabling the LED. I hooked
this logic into the ata_bmdma_start and ata_bmdma_stop which were made
into simple wrapper functions in sata_sil.c that just set the GPIO
bits and calls ata_bmdma_*.
As a sanity test, I ran my drive, loaded, overnight with no problems.
If there is a better way to do this, I would be happy to hear any
suggestions... it is kind of ugly as it is now.
--
Aric Cyr (http://acyr.net)
gpg fingerprint: 943A 1549 47AC D766 B7F8 D551 6703 7142 C282 D542
--- sata_sil.c.orig 2005-06-15 17:48:23.0 +0900
+++ sata_sil.c 2005-07-06 01:58:28.0 +0900
@@ -45,6 +45,7 @@
sil_3114= 1,
SIL_SYSCFG = 0x48,
+ SIL_GPIO= 0x54,
SIL_MASK_IDE0_INT = (1 << 22),
SIL_MASK_IDE1_INT = (1 << 23),
SIL_MASK_IDE2_INT = (1 << 24),
@@ -65,6 +66,8 @@
static u32 sil_scr_read (struct ata_port *ap, unsigned int sc_reg);
static void sil_scr_write (struct ata_port *ap, unsigned int sc_reg, u32 val);
static void sil_post_set_mode (struct ata_port *ap);
+static void sil_bmdma_start(struct ata_queued_cmd *qc);
+static void sil_bmdma_stop(struct ata_port *ap);
static struct pci_device_id sil_pci_tbl[] = {
{ 0x1095, 0x3112, PCI_ANY_ID, PCI_ANY_ID, 0, 0, sil_3112 },
@@ -138,8 +140,8 @@
.phy_reset = sata_phy_reset,
.post_set_mode = sil_post_set_mode,
.bmdma_setup= ata_bmdma_setup,
- .bmdma_start= ata_bmdma_start,
- .bmdma_stop = ata_bmdma_stop,
+ .bmdma_start= sil_bmdma_start,
+ .bmdma_stop = sil_bmdma_stop,
.bmdma_status = ata_bmdma_status,
.qc_prep= ata_qc_prep,
.qc_issue = ata_qc_issue_prot,
@@ -198,6 +200,35 @@
MODULE_DEVICE_TABLE(pci, sil_pci_tbl);
MODULE_VERSION(DRV_VERSION);
+static void sil_bmdma_start(struct ata_queued_cmd *qc)
+{
+ void* mmio_base = qc->ap->host_set->mmio_base;
+ u32 gpio = readl(mmio_base + SIL_GPIO);
+
+ /* setting the lower 8 bits to activate the activity LED */
+ gpio |= 0x00ff;
+ writel(gpio, mmio_base + SIL_GPIO);
+ readl(mmio_base + SIL_GPIO); /* flush */
+
+ ata_bmdma_start(qc);
+}
+
+static void sil_bmdma_stop(struct ata_port *ap)
+{
+ void* mmio_base = ap->host_set->mmio_base;
+ u32 gpio = readl(mmio_base + SIL_GPIO);
+
+ ata_bmdma_stop(ap);
+
+ /*
+ * setting bits [8:15] clears the lower 8 bits,
+ * deactivating the activity LED
+ */
+ gpio |= 0xff00;
+ writel(gpio, mmio_base + SIL_GPIO);
+ readl(mmio_base + SIL_GPIO); /* flush */
+}
+
static void sil_post_set_mode (struct ata_port *ap)
{
struct ata_host_set *host_set = ap->host_set;
pgphTlWdestWb.pgp
Description: PGP signature
Re: sata_sil 3112 activity LED patch
On Thu, Jul 07, 2005 at 02:47:03PM +0200, Jens Axboe wrote:
> On Wed, Jul 06 2005, Jeff Garzik wrote:
> > I don't think its ugly, necessarily. I do worry about the flash memory
> > stuff, though, which is why I don't want to merge this upstream for now.
> >
> > For your patch specifically, it would be nice to follow the coding style
> > that is found in the rest of the driver (single-tab indents, etc., read
> > CodingStyle in kernel source tree).
I cleaned it up... it got quite a bit larger since I am attempting to
check for valid usage. Unfortunately I do not know if the 3114 has a
similar GPIO mechanism, nor do I have an add on card with a 3112 to
verify with. My new/improved patch is attached, tested on my system
with 2.6.12.
If anyone with either such devices could test (with caution!) I'd like
to hear the results. Alternatively, I'd be interested in the value of
the MMIO register at BASE_ADDRESS_5 + 0x54 before the driver is
loaded.
> There's also an existing variant of this in the block layer, the
> activity_fn, that we use on the ibook/powerbook to use the sleep led as
> an activity light. Just in case you prefer that to overloading the bmdma
> start/stop handlers.
You suggestion at first looked to be incredibly nice... until I looked
at how much implementation was required. I am considering trying it,
but I cannot find a place for an sata driver to call the
blk_queue_activity_fn() with meaningful parameters during init.
On a second look, I guess I would have to override
ata_scsi_slave_config() in the driver and hook up the activity light
there. This would be fine I guess. Unless I am interpreting this
incorrectly, however, I would need to use a timer or something to turn
the light back off? I'm probably missing something, so is there a
simpler way to do this?
--
Aric Cyr (http://acyr.net)
gpg fingerprint: 943A 1549 47AC D766 B7F8 D551 6703 7142 C282 D542
--- drivers/scsi/sata_sil.c.orig2005-07-07 10:07:19.0 +0900
+++ drivers/scsi/sata_sil.c 2005-07-07 23:19:36.0 +0900
@@ -54,6 +54,7 @@
SIL_FIFO_W3 = 0x245,
SIL_SYSCFG = 0x48,
+ SIL_GPIO= 0x54,
SIL_MASK_IDE0_INT = (1 << 22),
SIL_MASK_IDE1_INT = (1 << 23),
SIL_MASK_IDE2_INT = (1 << 24),
@@ -74,6 +75,9 @@
static u32 sil_scr_read (struct ata_port *ap, unsigned int sc_reg);
static void sil_scr_write (struct ata_port *ap, unsigned int sc_reg, u32 val);
static void sil_post_set_mode (struct ata_port *ap);
+static void sil_bmdma_start(struct ata_queued_cmd *qc);
+static void sil_bmdma_stop(struct ata_port *ap);
+static void sil_host_stop (struct ata_host_set *host_set);
static struct pci_device_id sil_pci_tbl[] = {
{ 0x1095, 0x3112, PCI_ANY_ID, PCI_ANY_ID, 0, 0, sil_3112 },
@@ -149,8 +152,8 @@
.phy_reset = sata_phy_reset,
.post_set_mode = sil_post_set_mode,
.bmdma_setup= ata_bmdma_setup,
- .bmdma_start= ata_bmdma_start,
- .bmdma_stop = ata_bmdma_stop,
+ .bmdma_start= sil_bmdma_start,
+ .bmdma_stop = sil_bmdma_stop,
.bmdma_status = ata_bmdma_status,
.qc_prep= ata_qc_prep,
.qc_issue = ata_qc_issue_prot,
@@ -161,7 +164,7 @@
.scr_write = sil_scr_write,
.port_start = ata_port_start,
.port_stop = ata_port_stop,
- .host_stop = ata_host_stop,
+ .host_stop = sil_host_stop,
};
static struct ata_port_info sil_port_info[] = {
@@ -204,6 +207,10 @@
/* ... port 3 */
};
+struct sil_host_priv {
+ u8 use_gpio;
+};
+
MODULE_AUTHOR("Jeff Garzik");
MODULE_DESCRIPTION("low-level driver for Silicon Image SATA controller");
MODULE_LICENSE("GPL");
@@ -217,6 +224,48 @@
return cache_line;
}
+static void sil_bmdma_start(struct ata_queued_cmd *qc)
+{
+ struct sil_host_priv* hpriv = qc->ap->host_set->private_data;
+ if (hpriv->use_gpio) {
+ void* mmio_base = qc->ap->host_set->mmio_base;
+ u32 gpio = readl(mmio_base + SIL_GPIO);
+
+ /* set the lower 8 bits to activate the LED */
+ gpio |= 0xff;
+ writel(gpio, mmio_base + SIL_GPIO);
+ readl(mmio_base + SIL_GPIO);/* flush */
+ }
+
+ ata_bmdma_start(qc);
+}
+
+static void sil_bmdma_stop(struct ata_port *ap)
+{
+ struct sil_host_priv* hpriv = ap->host_set->private_data;
+
+ ata_bmdma_stop(ap);
+
+ if (hpriv->use_gpio) {
+ void* mmio_base = ap->host_set->mmio_base;
+ u32 gpio = readl(mmio_base + SIL_GPIO);
Re: 2.6.13 (was 2.6.11.11) and rsync oops (SATA or NFS related?)
Kalin KOZHUHAROV thinrope.net> writes: > > A closer examination of the drive: > (Model=ST3300831AS, FwRev=3.03, SerialNo=3NF07KA1 ) > and why is it so slow revealed that it was running not in UDMA. > > Got one total oops, even no logs were written to disk. > Seems that rsync-ing huge amounts of data (200 GB in *many* small files) streses the system too much. It seems that you are using the IDE-SATA driver... perhaps you should try the SCSI-SATA (i.e. libata)? The IDE one is deprecated and should no longer be used. Disable SATA from in the IDE menu and enable the SCSI libata driver for your chipset (in the scsi kernel menu). Also the reason you don't get higher UDMA modes is because your drive is a blacklisted seagate. There are known problems with some of those drives, and so they are downgraded to slower modes (this was mentioned in your kernel log if you look closely). If you upgrade the BIOS on your harddrive, you _might_ be able to remove the drive from the blacklist in the kernel to improve performance... this may be dangerous however, so don't complain if you lose your data. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13 (was 2.6.11.11) and rsync oops (SATA or NFS related?)
Kalin KOZHUHAROV thinrope.net> writes: > ata1: dev 0 configured for UDMA/100 > ata2: dev 0 configured for UDMA/100 > scsi1 : sata_sil >Vendor: ATA Model: WDC WD360GD-00FL Rev: 21.0 >Type: Direct-Access ANSI SCSI revision: 05 >Vendor: ATA Model: ST3300831AS Rev: 3.03 >Type: Direct-Access ANSI SCSI revision: 05 Looks like UDMA/100 is set up fine for both your drives. > # hdparm -t /dev/sdb > > /dev/sdb: > Timing buffered disk reads: 176 MB in 3.01 seconds = 58.43 MB/sec > HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl > for device > > I don't like the error MSG above, but 58MB/s is not bad, compared to 36.5MB/s > with ide-sata driver! This is normal. hdparm doesn't know much about SCSI drives... SATA drives are closer to SCSI than IDE. In particular the various direct IDE ioctls are not supported by the SCSI layer. Don't worry about these errors. > Might be a stupid question... but is UDMA relevant to SATA drives run by > libata?? > If yes, how do I get the current value of it? See above. > And upgrading firmware to a harddrive is done how? > Done on my BIOSes, my Plextor CD-Rs and DVD+RWs, but on a hard drive? > Any pointers, or that was just a random thought > > According to linux-2.6.13/drivers/scsi/sata_sil.c:94 my drives are not > blacklisted. Sorry, I thought your drive might be blacklisted, but I didn't actually check the driver for your model. You are getting UDMA/100 so your drive is just fine, no firmware update is required. If you were interested though, poking around seagates site would probably turn up some firmware updates, if any are available. I did have a blacklisted seagate drive, but it works fine after the firmware update and removal from the blacklist. Regards - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
