From: Ronny Buchmann <ronny-lkml@vlugnet.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, Marko Kreen <marko@l-t.ee>
Subject: Re: [OOPS] 2.4.22 / HPT372N
Date: Fri, 12 Sep 2003 11:41:45 +0200 [thread overview]
Message-ID: <200309121141.45776.ronny-lkml@vlugnet.org> (raw)
In-Reply-To: <20030911123418.GA6798@l-t.ee>
Am Donnerstag 11 September 2003 14:34 schrieb Marko Kreen:
> On Tue, Sep 09, 2003 at 02:06:56PM +0200, Ronny Buchmann wrote:
> > I have the same motherboard but a different problem with the hpt chip,
> > only the first channel is recognized. (see
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97824)
>
> I saw something like that too - when disk was in second channel,
> it did not crash because it did not detect anything.
>
> > part from dmesg (klogd) output
> > ---
> > Sep 7 23:50:17 bserv kernel: HPT366: IDE controller at PCI slot 02:00.0
> > Sep 7 23:50:17 bserv kernel: HPT366: chipset revision 6
> > Sep 7 23:50:17 bserv kernel: HPT366: not 100%% native mode: will probe
> > irqs later
> > Sep 7 23:50:17 bserv kernel: hpt: HPT372N detected, using 372N timing.
> > Sep 7 23:50:17 bserv kernel: FREQ: 82 PLL: 35
>
> "FREQ: 82" is pretty high as the limit is 85.
It would be interesting to know what the average or ideal value is.
> I replaced "< 0x55" with "<= 0x55" in hpt366.c and the driver
> did not crash, but it also did not detect cdrom - only thing
> behind it ATM - so I did not bother messing with it further.
I will test with cdrom attached later today.
Currently I have one disk on each channel.
I had another look at hpt.c(from highpoint) and hpt366.c and found this:
--- linux-2.4.22-ac1/drivers/ide/pci/hpt366.c.orig 2003-09-11
21:29:06.000000000 +0200
+++ linux-2.4.22-ac1/drivers/ide/pci/hpt366.c 2003-09-12 01:05:44.000000000
+0200
@@ -713,7 +713,7 @@
/* Reconnect channels to bus */
outb(0x00, hwif->dma_base+0x73);
- outb(0x00, hwif->dma_base+0x79);
+ outb(0x00, hwif->dma_base+0x77);
}
/**
@@ -1368,7 +1368,7 @@
default: break;
}
- d->channels = 1;
+ d->channels = 2;
pci_read_config_byte(dev, PCI_INTERRUPT_PIN, &pin1);
pci_for_each_dev(findev) {
The first one is AFAICS a typo, for the second I'm not sure if there could be
any reason?
Anyhow, it works for me.
--
ronny
next prev parent reply other threads:[~2003-09-12 9:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-09 12:06 Ronny Buchmann
2003-09-11 12:34 ` Marko Kreen
2003-09-12 9:41 ` Ronny Buchmann [this message]
2003-09-12 10:48 ` Alan Cox
2003-09-12 12:32 ` Ronny Buchmann
2003-09-12 12:46 ` Alan Cox
2003-09-12 12:58 ` Bartlomiej Zolnierkiewicz
2003-09-12 14:24 ` Ronny Buchmann
2003-09-12 14:42 ` Bartlomiej Zolnierkiewicz
2003-09-12 15:26 ` Ronny Buchmann
2003-09-12 16:35 ` Bartlomiej Zolnierkiewicz
2003-09-12 20:32 ` Ronny Buchmann
-- strict thread matches above, loose matches on Subject: below --
2003-09-04 19:07 Marko Kreen
2003-09-04 21:46 ` Alan Cox
2003-09-05 14:54 ` Marko Kreen
2003-09-05 21:51 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200309121141.45776.ronny-lkml@vlugnet.org \
--to=ronny-lkml@vlugnet.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=marko@l-t.ee \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®