As i used the pen&paper method for oops tracking i dont have
full oops.
In hpt366.c function hpt372_tune_chipset line 427:
list_conf = pci_bus_clock_list(speed,
(struct chipset_bus_clock_list_entry *)
pci_get_drvdata(dev));
pci_get_drvdata(dev) returns NULL.
Crash happens only if there are some devices attached to hpt.
lspci -vv:
02:00.0 RAID bus controller: Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 06)
Subsystem: Triones Technologies, Inc. HPT370A
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 120 (2000ns min, 2000ns max)
Interrupt: pin A routed to IRQ 22
Region 0: I/O ports at a000 [size=8]
Region 1: I/O ports at a400 [size=4]
Region 2: I/O ports at a800 [size=8]
Region 3: I/O ports at ac00 [size=4]
Region 4: I/O ports at b000 [size=256]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Full config, dmesg(of a non-crash boot) & lspci:
http://www.l-t.ee/marko/hptcrash.tgz
On Iau, 2003-09-04 at 20:07, Marko Kreen wrote:
> As i used the pen&paper method for oops tracking i dont have
> full oops.
>
> In hpt366.c function hpt372_tune_chipset line 427:
>
> list_conf = pci_bus_clock_list(speed,
> (struct chipset_bus_clock_list_entry *)
I thought I'd fixed that crash case but it seems your system is over
clocked.
FREQ: 85 PLL: 41
hpt: no known IDE timings,
so your PCI bus is running at somewhere about 35Mhz and outside the
drivers safe threshold.
Alan
On Thu, Sep 04, 2003 at 10:46:53PM +0100, Alan Cox wrote:
> On Iau, 2003-09-04 at 20:07, Marko Kreen wrote:
> > As i used the pen&paper method for oops tracking i dont have
> > full oops.
> >
> > In hpt366.c function hpt372_tune_chipset line 427:
> >
> > list_conf = pci_bus_clock_list(speed,
> > (struct chipset_bus_clock_list_entry *)
>
> I thought I'd fixed that crash case but it seems your system is over
> clocked.
>
> FREQ: 85 PLL: 41
> hpt: no known IDE timings,
>
> so your PCI bus is running at somewhere about 35Mhz and outside the
> drivers safe threshold.
Thats surprising, nobody has intentionally overclocked it.
Now we did some experimenting with it and no BIOS settings seem
to affect the FREQ numbers. (Lower CPU/mem speed, 50/25 AGP/PCI speed.)
The FREQ still stays fixed at 85.
Motherboard is EP-4PDA2+.
Any idea how to remove the overclocking? Otherwise it seems
like driver bug to me.
--
marko
On Gwe, 2003-09-05 at 15:54, Marko Kreen wrote:
> > so your PCI bus is running at somewhere about 35Mhz and outside the
> > drivers safe threshold.
>
> Thats surprising, nobody has intentionally overclocked it.
>
> Now we did some experimenting with it and no BIOS settings seem
> to affect the FREQ numbers. (Lower CPU/mem speed, 50/25 AGP/PCI speed.)
> The FREQ still stays fixed at 85.
> Any idea how to remove the overclocking? Otherwise it seems
> like driver bug to me.
The hardware measures the PCI bus clock against its own sources and the
85 (0x55) is its timing measurement. The maximum range for the 33Mhz
timings on the card is < 0x55 so it decides your clock is outside the
safe range. HPT have never given us 40Mhz clock timings for the 372N or
as far as I can tell published them so we don't know how to drive it at
40Mhz just 33 and 66.
You could tweak the driver to accept 0x55 but either the card clock is
out or you are overclocking your IDE by doing that.
Marko Kreen wrote:
> On Thu, Sep 04, 2003 at 10:46:53PM +0100, Alan Cox wrote:
>> On Iau, 2003-09-04 at 20:07, Marko Kreen wrote:
>> > As i used the pen&paper method for oops tracking i dont have
>> > full oops.
>> >
>> > In hpt366.c function hpt372_tune_chipset line 427:
>> >
>> > list_conf = pci_bus_clock_list(speed,
>> > (struct chipset_bus_clock_list_entry *)
>>
>> I thought I'd fixed that crash case but it seems your system is over
>> clocked.
>>
>> FREQ: 85 PLL: 41
>> hpt: no known IDE timings,
>>
>> so your PCI bus is running at somewhere about 35Mhz and outside the
>> drivers safe threshold.
>
> Thats surprising, nobody has intentionally overclocked it.
>
> Now we did some experimenting with it and no BIOS settings seem
> to affect the FREQ numbers. (Lower CPU/mem speed, 50/25 AGP/PCI speed.)
> The FREQ still stays fixed at 85.
>
> Motherboard is EP-4PDA2+.
>
> Any idea how to remove the overclocking? Otherwise it seems
> like driver bug to me.
What bios version do you use? Have you tried a CMOS reset?
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)
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
Sep 7 23:50:17 bserv kernel: HPT37X: using 50MHz internal PLL
Sep 7 23:50:17 bserv kernel: ide2: BM-DMA at 0x8000-0x8007, BIOS
settings:
hde:DMA, hdf:pio
Sep 7 23:50:17 bserv kernel: HPT372N support is EXPERIMENTAL ONLY.
---
Currently the driver provided by highpoint
(http://www.highpoint-tech.com/hpt3xx-opensource-v131.tgz) is working ok for
me (apart from it's lack of s.ma.r.t. support).
Did you try this?
--
ronny
On Tue, Sep 09, 2003 at 02:06:56PM +0200, Ronny Buchmann wrote:
> Marko Kreen wrote:
> > Now we did some experimenting with it and no BIOS settings seem
> > to affect the FREQ numbers. (Lower CPU/mem speed, 50/25 AGP/PCI speed.)
> > The FREQ still stays fixed at 85.
> >
> > Motherboard is EP-4PDA2+.
> >
> > Any idea how to remove the overclocking? Otherwise it seems
> > like driver bug to me.
> What bios version do you use? Have you tried a CMOS reset?
BIOS is 6/20/2003.
Yes, we did CMOS reset, because the board 'played dead' for a
while. After staying without battery it woke up again.
HPT acts still same. I looked BIOS changelog, did not saw
anything related to overclocking.
> 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.
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.
> Currently the driver provided by highpoint
> (http://www.highpoint-tech.com/hpt3xx-opensource-v131.tgz) is working ok for
> me (apart from it's lack of s.ma.r.t. support).
>
> Did you try this?
Now I tried - that one also did not detect cdrom. I cant
experiment further as the machine needs to go to production
soon. ATM I disabled onboard HPT, and put in separate IDE
controller (HPT370) to get needed IDE channel.
My conclusions:
1) Motherboard is overclocked by manufacturer - so in the future
I intend to stay away from EPOX.
2) HPT372n support in Linux is beta (as documented...)
--
marko
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
On Gwe, 2003-09-12 at 10:41, Ronny Buchmann wrote:
> 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);
> }
Which piece of documentation makes you think that ? So I can double
check it.
>
> - d->channels = 1;
> + d->channels = 2;
Need to work out which 372N and others are dual channel but yes
Am Freitag 12 September 2003 12:48 schrieb Alan Cox:
> On Gwe, 2003-09-12 at 10:41, Ronny Buchmann wrote:
> > 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);
> > }
>
> Which piece of documentation makes you think that ? So I can double
> check it.
from hpt.c
void INLINE Switching370Clock(PChannel pChan, UCHAR ucClockValue)
{
if((InPort(pChan->NextChannelBMI + BMI_STS) & BMI_STS_ACTIVE) == 0){
PUCHAR PrimaryMiscCtrlRegister = pChan->BaseBMI + 0x70;
PUCHAR SecondaryMiscCtrlRegister = pChan->BaseBMI + 0x74;
OutPort(PrimaryMiscCtrlRegister+3, 0x80); // tri-state the primary channel
OutPort(SecondaryMiscCtrlRegister+3, 0x80); // tri-state the secondary channel
OutPort((PUCHAR)((ULONG)pChan->BaseBMI+0x7B), ucClockValue); // switching the clock
OutPort((PUCHAR)((ULONG)pChan->BaseBMI+0x79), 0xC0); // reset two channels begin
OutPort(PrimaryMiscCtrlRegister, 0x37); // reset primary channel state machine
OutPort(SecondaryMiscCtrlRegister, 0x37); // reset secordary channel state machine
OutPort((PUCHAR)((ULONG)pChan->BaseBMI+0x79), 0x00); // reset two channels finished
OutPort(PrimaryMiscCtrlRegister+3, 0x00); // normal-state the primary channel
OutPort(SecondaryMiscCtrlRegister+3, 0x00); // normal-state the secondary channel
}
}
It's the equivalent to hpt372n_set_clock().
static void hpt372n_set_clock(ide_drive_t *drive, int mode)
{
ide_hwif_t *hwif = HWIF(drive);
/* FIXME: should we check for DMA active and BUG() */
/* Tristate the bus */
outb(0x80, hwif->dma_base+0x73);
outb(0x80, hwif->dma_base+0x77);
/* Switch clock and reset channels */
outb(mode, hwif->dma_base+0x7B);
outb(0xC0, hwif->dma_base+0x79);
/* Reset state machines */
outb(0x37, hwif->dma_base+0x70);
outb(0x37, hwif->dma_base+0x74);
/* Complete reset */
outb(0x00, hwif->dma_base+0x79);
/* Reconnect channels to bus */
outb(0x00, hwif->dma_base+0x73);
outb(0x00, hwif->dma_base+0x77);
}
> > - d->channels = 1;
> > + d->channels = 2;
>
> Need to work out which 372N and others are dual channel but yes
Are there actually single channel versions?
--
ronny
On Gwe, 2003-09-12 at 13:32, Ronny Buchmann wrote
> > Which piece of documentation makes you think that ? So I can double
> > check it.
>
> from hpt.c
Nice spotting. That change looks right to me. Will add the two
On Friday 12 of September 2003 12:48, Alan Cox wrote:
> On Gwe, 2003-09-12 at 10:41, Ronny Buchmann wrote:
> > 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);
> > }
>
> Which piece of documentation makes you think that ? So I can double
> check it.
>
> > - d->channels = 1;
> > + d->channels = 2;
>
> Need to work out which 372N and others are dual channel but yes
No, "d->channels = 1" is only executed for orginal HPT366 which has separate
PCI configurations for first and second channel. For HPT372N you have correct
value in hpt366.h - ".channels = 2".
--bartlomiej
Am Freitag 12 September 2003 14:58 schrieb Bartlomiej Zolnierkiewicz:
> On Friday 12 of September 2003 12:48, Alan Cox wrote:
> > On Gwe, 2003-09-12 at 10:41, Ronny Buchmann wrote:
> > > - d->channels = 1;
> > > + d->channels = 2;
> >
> > Need to work out which 372N and others are dual channel but yes
>
> No, "d->channels = 1" is only executed for orginal HPT366 which has
> separate PCI configurations for first and second channel. For HPT372N you
> have correct value in hpt366.h - ".channels = 2".
so it should be something like this?
switch(class_rev) {
case 5:
case 4:
case 3: ide_setup_pci_device(dev, d);
return;
case 1: d->channels = 1;
default: break;
}
--
ronny
On Friday 12 of September 2003 16:24, Ronny Buchmann wrote:
> Am Freitag 12 September 2003 14:58 schrieb Bartlomiej Zolnierkiewicz:
> > On Friday 12 of September 2003 12:48, Alan Cox wrote:
> > > On Gwe, 2003-09-12 at 10:41, Ronny Buchmann wrote:
> > > > - d->channels = 1;
> > > > + d->channels = 2;
> > >
> > > Need to work out which 372N and others are dual channel but yes
> >
> > No, "d->channels = 1" is only executed for orginal HPT366 which has
> > separate PCI configurations for first and second channel. For HPT372N
> > you have correct value in hpt366.h - ".channels = 2".
>
> so it should be something like this?
>
> switch(class_rev) {
> case 5:
> case 4:
> case 3: ide_setup_pci_device(dev, d);
> return;
> case 1: d->channels = 1;
> default: break;
> }
No. I don't know about HPT368, but current code should be correct.
Note that for HPT372N class_rev is set to 5 just before this switch statement.
--bartlomiej
Am Freitag 12 September 2003 16:42 schrieben Sie:
> On Friday 12 of September 2003 16:24, Ronny Buchmann wrote:
> > Am Freitag 12 September 2003 14:58 schrieb Bartlomiej Zolnierkiewicz:
> > > On Friday 12 of September 2003 12:48, Alan Cox wrote:
> > > > On Gwe, 2003-09-12 at 10:41, Ronny Buchmann wrote:
> > > > > - d->channels = 1;
> > > > > + d->channels = 2;
> > > >
> > > > Need to work out which 372N and others are dual channel but yes
> > >
> > > No, "d->channels = 1" is only executed for orginal HPT366 which has
> > > separate PCI configurations for first and second channel. For HPT372N
> > > you have correct value in hpt366.h - ".channels = 2".
Some of the HPT372N (including mine) have the same device id as the HPT366 (0004),
they differ only in revision (rev 6 is 372N).
(this logic is already used in other functions)
--- 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 17:13:31.000000000 +0200
@@ -1343,7 +1343,7 @@
u8 pin1 = 0, pin2 = 0;
unsigned int class_rev;
static char *chipset_names[] = {"HPT366", "HPT366", "HPT368",
- "HPT370", "HPT370A", "HPT372"};
+ "HPT370", "HPT370A", "HPT372", "HPT372N"};
if (PCI_FUNC(dev->devfn) & 1)
return;
@@ -1351,16 +1351,11 @@
pci_read_config_dword(dev, PCI_CLASS_REVISION, &class_rev);
class_rev &= 0xff;
- /* New ident 372N reports revision 1. We could do the
- io port based type identification instead perhaps (DID, RID) */
-
- if(d->device == PCI_DEVICE_ID_TTI_HPT372N)
- class_rev = 5;
-
- if(class_rev < 6)
+ if(class_rev <= 6)
d->name = chipset_names[class_rev];
switch(class_rev) {
+ case 6:
case 5:
case 4:
case 3: ide_setup_pci_device(dev, d);
Since the 372N with the new id (0009) is set up with init_setup_37x(), "class_rev = 5" is never executed.
So the second part of the previous patch is wrong.
--
ronny
On Friday 12 of September 2003 17:26, Ronny Buchmann wrote:
> Am Freitag 12 September 2003 16:42 schrieben Sie:
> > On Friday 12 of September 2003 16:24, Ronny Buchmann wrote:
> > > Am Freitag 12 September 2003 14:58 schrieb Bartlomiej Zolnierkiewicz:
> > > > On Friday 12 of September 2003 12:48, Alan Cox wrote:
> > > > > On Gwe, 2003-09-12 at 10:41, Ronny Buchmann wrote:
> > > > > > - d->channels = 1;
> > > > > > + d->channels = 2;
> > > > >
> > > > > Need to work out which 372N and others are dual channel but yes
> > > >
> > > > No, "d->channels = 1" is only executed for orginal HPT366 which has
> > > > separate PCI configurations for first and second channel. For
> > > > HPT372N you have correct value in hpt366.h - ".channels = 2".
>
> Some of the HPT372N (including mine) have the same device id as the HPT366
> (0004), they differ only in revision (rev 6 is 372N).
>
> (this logic is already used in other functions)
>
> --- 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 17:13:31.000000000
> +0200 @@ -1343,7 +1343,7 @@
> u8 pin1 = 0, pin2 = 0;
> unsigned int class_rev;
> static char *chipset_names[] = {"HPT366", "HPT366", "HPT368",
> - "HPT370", "HPT370A", "HPT372"};
> + "HPT370", "HPT370A", "HPT372", "HPT372N"};
>
> if (PCI_FUNC(dev->devfn) & 1)
> return;
> @@ -1351,16 +1351,11 @@
> pci_read_config_dword(dev, PCI_CLASS_REVISION, &class_rev);
> class_rev &= 0xff;
>
> - /* New ident 372N reports revision 1. We could do the
> - io port based type identification instead perhaps (DID, RID) */
> -
> - if(d->device == PCI_DEVICE_ID_TTI_HPT372N)
> - class_rev = 5;
> -
> - if(class_rev < 6)
> + if(class_rev <= 6)
> d->name = chipset_names[class_rev];
>
> switch(class_rev) {
> + case 6:
> case 5:
> case 4:
> case 3: ide_setup_pci_device(dev, d);
>
> Since the 372N with the new id (0009) is set up with init_setup_37x(),
> "class_rev = 5" is never executed.
>
> So the second part of the previous patch is wrong.
Looks good, thanks.
--bartlomiej
Am Freitag, 12. September 2003 11:41 schrieb Ronny Buchmann:
> > 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.
tested with cdrom, works
--
ronny