Hello,
I have a Gigabyte 7DPXDW-P, a dual Athlon motherboard whit a FastTrak
controller onboard and I found some difficulties installing the driver.
Kernel deviceses initialization recognise my PDC20276 controller and find
the disks connected (/dev/hde and /dev/hdg) and the array I made with them
(/dev/ataraid/d0 RAID1). I tryed to write in /dev/ataraid/d0 but after about
half a gigabyte written, the system stops to write and the process(es) writing
appare(s) in the outputo of ps with the flag D (IO waiting). After a lot of
tryes I tryed to write in /dev/hde and /dev/hdg at different times, but the
same thing happens.
Is the problem in the FastTrak driver, in the PDC20276 driver, or in my
hardware?
Is there a known bug?
Do somebody has the same mothrboard and can use PDC20276? If yes, can u tell
me how to do?
How can I do to debug degug the ide driver or the PDC driver? Or What
documentation have I to read?
Thank you for your time,
Daniele.
On Tue, 2002-11-12 at 14:52, Ricci Daniele wrote:
> I have a Gigabyte 7DPXDW-P, a dual Athlon motherboard whit a FastTrak
> controller onboard and I found some difficulties installing the driver.
Which driver are you using and which kernel ?
On 12 Nov 2002, Alan Cox wrote:
> On Tue, 2002-11-12 at 14:52, Ricci Daniele wrote:
> > I have a Gigabyte 7DPXDW-P, a dual Athlon motherboard whit a FastTrak
> > controller onboard and I found some difficulties installing the driver.
>
> Which driver are you using and which kernel ?
>
I tryed pdc202xx of 2.4.19 with and without ataraid and pdc202x_new (is it
correct?) of 2.5.46.
Thank you.
On Tue, 2002-11-12 at 15:23, [email protected] wrote:
>
>
> On 12 Nov 2002, Alan Cox wrote:
>
> > On Tue, 2002-11-12 at 14:52, Ricci Daniele wrote:
> > > I have a Gigabyte 7DPXDW-P, a dual Athlon motherboard whit a FastTrak
> > > controller onboard and I found some difficulties installing the driver.
> >
> > Which driver are you using and which kernel ?
> >
>
> I tryed pdc202xx of 2.4.19 with and without ataraid and pdc202x_new (is it
> correct?) of 2.5.46.
That is the correct driver yes. What problems are you seeing ?
On 12 Nov 2002, Alan Cox wrote:
> > > > I have a Gigabyte 7DPXDW-P, a dual Athlon motherboard whit a FastTrak
> > > > controller onboard and I found some difficulties installing the driver.
> > >
> > > Which driver are you using and which kernel ?
> >
> > I tryed pdc202xx of 2.4.19 with and without ataraid and pdc202x_new (is it
> > correct?) of 2.5.46.
>
> That is the correct driver yes. What problems are you seeing ?
During Slackware installation (whith kernel compiled by myself), after
about half a gigabyte written in the disk/disks all process
reading/writeing from/to the disks stop running, I cannot kill them, ps
show me them with the 'D' flag, I cannot umount the disk/disks.
On Tue, 2002-11-12 at 15:43, [email protected] wrote:
> During Slackware installation (whith kernel compiled by myself), after
> about half a gigabyte written in the disk/disks all process
> reading/writeing from/to the disks stop running, I cannot kill them, ps
> show me them with the 'D' flag, I cannot umount the disk/disks.
What drives, exactly what messages are logged (dmesg) ?
On 12 Nov 2002, Alan Cox wrote:
> On Tue, 2002-11-12 at 15:43, [email protected] wrote:
> > During Slackware installation (whith kernel compiled by myself), after
> > about half a gigabyte written in the disk/disks all process
> > reading/writeing from/to the disks stop running, I cannot kill them, ps
> > show me them with the 'D' flag, I cannot umount the disk/disks.
>
> What drives, exactly what messages are logged (dmesg) ?
>
About what message are u speaking about? Messages logged during boot, I
can send u tomorrow (the computer is not here). After the hang no messages
are logged.
On Tue, Nov 12, 2002 at 04:53:20PM +0100, [email protected] wrote:
>
>
> On 12 Nov 2002, Alan Cox wrote:
>
> > On Tue, 2002-11-12 at 15:43, [email protected] wrote:
> > > During Slackware installation (whith kernel compiled by myself), after
> > > about half a gigabyte written in the disk/disks all process
> > > reading/writeing from/to the disks stop running, I cannot kill them, ps
> > > show me them with the 'D' flag, I cannot umount the disk/disks.
> >
> > What drives, exactly what messages are logged (dmesg) ?
> >
>
> About what message are u speaking about? Messages logged during boot, I
> can send u tomorrow (the computer is not here). After the hang no messages
> are logged.
>
>
FWIW, we seem to have a not-unsimilar problem.
Board is a Gigabyte GA-7VRXP which has an on-board Promise 20276.
For me:
Processes get stuck in D after a couple of days, and kernel log shows
an invalid NULL deference in find_inode() in fs/inode.c, when it does
inode->i_ino
dereference.
It does not check for whether inode is NULL or not.
I realize that appears to be valid, because it appears to me that inode
should never be NULL when it is retrieved from list_entry().
I have the ksymoops oops file available, I would be more than happy to
post that up if anyone wants to take a look.
-- G.
--
char *p = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
On Wed, 13 Nov 2002, Geoffrey Lee wrote:
> FWIW, we seem to have a not-unsimilar problem.
>
> Board is a Gigabyte GA-7VRXP which has an on-board Promise 20276.
> Processes get stuck in D after a couple of days,
Sorry for my english, what does couple means? :)
> and kernel log shows
> an invalid NULL deference in find_inode() in fs/inode.c, when it does
>
> inode->i_ino
>
> dereference.
>
> It does not check for whether inode is NULL or not.
>
> I realize that appears to be valid, because it appears to me that inode
> should never be NULL when it is retrieved from list_entry().
Do u say this because u read list_entry() code, or why?
>
> I have the ksymoops oops file available, I would be more than happy to
> post that up if anyone wants to take a look.
I would like to help you :) but I have not idea how can I do :(
I would like to debug the kernel but I don't know how to do, can u tell me
a good documentation can I read? Please, please, please.
On Tue, 2002-11-12 at 08:53, Geoffrey Lee wrote:
> Board is a Gigabyte GA-7VRXP which has an on-board Promise 20276.
The GA-7VRXP is a known bad motherboard. It has a bad electrical
interface to the AGP slot, so if you're using an AGP graphics card
without falling back to PCI access, you are pretty much guaranteed
system hangs or crashes after some time, depending on load.
This is an issue I confirmed with AMD several (six?) months ago. I
don't know of any workarounds that maintain decent graphics performance,
and last I checked, Gigabyte had not acknowledged the problem.
Either drop your video card back to not using AGP, or buy a replacement
motherboard.
<b
Bryan O'Sullivan ([email protected]) wrote:
> On Tue, 2002-11-12 at 08:53, Geoffrey Lee wrote:
>
> > Board is a Gigabyte GA-7VRXP which has an on-board Promise 20276.
>
> The GA-7VRXP is a known bad motherboard. It has a bad electrical
> interface to the AGP slot, so if you're using an AGP graphics card
> without falling back to PCI access, you are pretty much guaranteed
> system hangs or crashes after some time, depending on load.
>
> This is an issue I confirmed with AMD several (six?) months ago. I
> don't know of any workarounds that maintain decent graphics performance,
> and last I checked, Gigabyte had not acknowledged the problem.
>
> Either drop your video card back to not using AGP, or buy a replacement
> motherboard.
Well actually Gigabyte systems are aware of this bug...
According to: http://www.thetechboard.com (original page has disappeared):
A good number of 1.0 versions of this motherboard barely worked at all
with GeForce4 cards. Stability was unheard of."
The 1.1 version of this board would sometimes work and sometimes not
work. Odds are better of getting a functioning board, but if you have
this version of the board and your GeForce4 card does NOT work,
increasing the VCore voltage by +7.5 in the BIOS can help. The side
effect of this can lead to higher temperatures causing a whole new batch
of problems. Better cooling solutions (like a Volcano7 or Coolermaster
Heatpipe AT MINIMUM) can pacify the heat issues, but I feel that long
term usage at this high of a voltage will cause inevitable failure.
After calling Gigabyte (you would think that they should call me knowing
that they sent me a few hundred motherboards with a "known issue")
because I was growing very tired of all of the tech calls I was
receiving about the board's stability issues with the GeForce4 card, I
was told that the boards needed to be reworked. Older boards were being
"updated" by adding a 4.7uF capacitor between the VR at Q36 and a spot
on the board where a surface mounted capacitor could go (but isn't
installed) at C139. A new revision (2.0) with a resistor (labeled R833)
added is already in production and being shipped.
I've(http://www.thetechboard.com) already tested the 2.0 version of the board with a PowerColor brand Ti 4200 128MB DDR and things do seem to be considerably better.
"
Hope this helps...
Bryan, Priit,
On Tue, Nov 12, 2002 at 11:13:29PM +0200, Priit Laes wrote:
> Bryan O'Sullivan ([email protected]) wrote:
> > On Tue, 2002-11-12 at 08:53, Geoffrey Lee wrote:
> >
> > > Board is a Gigabyte GA-7VRXP which has an on-board Promise 20276.
> >
> > The GA-7VRXP is a known bad motherboard. It has a bad electrical
> > interface to the AGP slot, so if you're using an AGP graphics card
> > without falling back to PCI access, you are pretty much guaranteed
> > system hangs or crashes after some time, depending on load.
> >
> > This is an issue I confirmed with AMD several (six?) months ago. I
> > don't know of any workarounds that maintain decent graphics performance,
> > and last I checked, Gigabyte had not acknowledged the problem.
> >
> > Either drop your video card back to not using AGP, or buy a replacement
> > motherboard.
> Well actually Gigabyte systems are aware of this bug...
> According to: http://www.thetechboard.com (original page has disappeared):
>
> A good number of 1.0 versions of this motherboard barely worked at all
> with GeForce4 cards. Stability was unheard of."
>
We do not have a GeForce4 card in there, but we do indeed have an AGP
card in there. It is a S3 ViRGE.
I will try disabling the AGP and see what happens.
I will say, though, that the stuck processes we have seen appear to be
doing disk I/O in the /home partition (which is disk mirrored with the
PDC driver), and apart from that, it seemed to be quite stable. If a
"crash" or a "hang" is described as getting a stuck process in disk I/O
because of some freak accident that getting an inode pointer can be
invalid, then yes, otherwise, no.
> The 1.1 version of this board would sometimes work and sometimes not
> work. Odds are better of getting a functioning board, but if you have
> this version of the board and your GeForce4 card does NOT work,
> increasing the VCore voltage by +7.5 in the BIOS can help. The side
> effect of this can lead to higher temperatures causing a whole new batch
> of problems. Better cooling solutions (like a Volcano7 or Coolermaster
> Heatpipe AT MINIMUM) can pacify the heat issues, but I feel that long
> term usage at this high of a voltage will cause inevitable failure.
>
We do have a cooler master on the CPU fitted on with enough paste. I thought
was the heat too, so we took it out of the server cabinet and let it stand
in the open. Unfortuantely, we got stuck processes in disk I/O after
a while as well. Actually, even in the server cabinet, it is not that
hot.
> After calling Gigabyte (you would think that they should call me knowing
> that they sent me a few hundred motherboards with a "known issue")
> because I was growing very tired of all of the tech calls I was
> receiving about the board's stability issues with the GeForce4 card, I
> was told that the boards needed to be reworked. Older boards were being
> "updated" by adding a 4.7uF capacitor between the VR at Q36 and a spot
> on the board where a surface mounted capacitor could go (but isn't
> installed) at C139. A new revision (2.0) with a resistor (labeled R833)
> added is already in production and being shipped.
>
> I've(http://www.thetechboard.com) already tested the 2.0 version of the board with a PowerColor brand Ti 4200 128MB DDR and things do seem to be considerably better.
> "
> Hope this helps...
I see.
I will call Gigabyte to see what are the odds of getting it fixed. But
surely, if it was a hardware problem, others would have experienced
similar issues too (processes stuck in disk I/O uninterruptible sleep)?
I did search before, and don't recall finding similar issues.
-- G.
--
char *p = "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/bin/sh";
On Tuesday 12 November 2002 21:13, Priit Laes wrote:
> Bryan O'Sullivan ([email protected]) wrote:
> > On Tue, 2002-11-12 at 08:53, Geoffrey Lee wrote:
> > The GA-7VRXP is a known bad motherboard. It has a bad electrical
> > interface to the AGP slot, so if you're using an AGP graphics card
> > without falling back to PCI access, you are pretty much guaranteed
> > system hangs or crashes after some time, depending on load.
....
> The 1.1 version of this board would sometimes work and sometimes not
> work. Odds are better of getting a functioning board, but if you have
....
> I've(http://www.thetechboard.com) already tested the 2.0 version of the board with
FWIW, I have the v1.1 GA-7VRXP using an Athlon XP 1800+ CPU and a GeForce3
Ti200, and all has so far been well. Don't know if I'm just lucky. No CPU
freq or voltage tweaks applied AFAICR.
The 20276 has been working fine controlling 2 of 4 disks of a software-RAID
(i.e. md, not ataraid) volume. No problems so far, other than a driver clash
with an older Promise board: the BIOS for the MB wouldn't run with the old
card enabled. Fixed by swapping the old board out.
Ruth
--
Ruth Ivimey-Cook
Software Engineer and Technical Author.
Ruth Ivimey-Cook ([email protected]) wrote:
> On Tuesday 12 November 2002 21:13, Priit Laes wrote:
> > Bryan O'Sullivan ([email protected]) wrote:
> > > On Tue, 2002-11-12 at 08:53, Geoffrey Lee wrote:
> > > The GA-7VRXP is a known bad motherboard. It has a bad electrical
> > > interface to the AGP slot, so if you're using an AGP graphics card
> > > without falling back to PCI access, you are pretty much guaranteed
> > > system hangs or crashes after some time, depending on load.
> ....
> > The 1.1 version of this board would sometimes work and sometimes not
> > work. Odds are better of getting a functioning board, but if you have
> ....
> > I've(http://www.thetechboard.com) already tested the 2.0 version of the board with
>
> FWIW, I have the v1.1 GA-7VRXP using an Athlon XP 1800+ CPU and a GeForce3
> Ti200, and all has so far been well. Don't know if I'm just lucky. No CPU
> freq or voltage tweaks applied AFAICR.
>
> The 20276 has been working fine controlling 2 of 4 disks of a software-RAID
> (i.e. md, not ataraid) volume. No problems so far, other than a driver clash
> with an older Promise board: the BIOS for the MB wouldn't run with the old
> card enabled. Fixed by swapping the old board out.
>
Maybe you are the lucky one, who has rev 2.0 board... ;)
On 12 Nov 2002, Bryan O'Sullivan wrote:
> The GA-7VRXP is a known bad motherboard.
>
> Either drop your video card back to not using AGP, or buy a replacement
> motherboard.
Good!
I have another gigabyte motherboard, but I have it at home, so I don't
remember the name: do u know if are there some other bugged gigabyte
motherboards?
On 12 Nov 2002, Alan Cox wrote:
> On Tue, 2002-11-12 at 15:43, [email protected] wrote:
> > During Slackware installation (whith kernel compiled by myself), after
> > about half a gigabyte written in the disk/disks all process
> > reading/writeing from/to the disks stop running, I cannot kill them, ps
> > show me them with the 'D' flag, I cannot umount the disk/disks.
>
> What drives, exactly what messages are logged (dmesg) ?
>
I made many tryes, and I taken for u 6 (I hope) significant tests
2.4.19 whith pdc drivers with and without softwer raid
2.5.46 whith pdc drivers with and without softwer raid
2.4.19 whith ataraid drivers with and without pdc drivers
all these tests issue the same problem.
For each try I have kernel config file and dmesg output and they are very
much text, so I think it isn't a good thig send all to u, tell me in
which u are interested and I'll send them.
If u think I can make a more usefull test, tell me about it.
Thank you again,
Daniele.
On 13 Nov 2002, Freaky wrote:
> I couldn't install slackware at all, even with my home compiled kernel.
> It just doesn't recognize the /dev/ataraid/d?p? drives and tells me
> there are no disks with ext2 filesystems when I try to start setup.
You can simply mount /dev/ataraid/d?p? on /mnt and start the slackware
installation setup script skipping the selection of the target, the swap
and the lilo configuration; after istallation is completed, you can edit
/etc/fstab and /etc/lilo.conf as you whish.
> You need the ataraid drivers for the pdc don't you?
I compiled the kernel with PDC202XX driver, with ataraid and with FastTrak
ataraid driver.
> How did you compile pdc without ataraid?
I tryed to compile pdc202xx and not ataraid to try to use software raid.
Is this the answer you were lookig for?
In all the cases my pdc20276 hangs after about half a gigabyte written
into any disk.