Hi,
I'm currently contemplating going for an Athlon 64 system. However,
I'll primarily be using a Linux-based OS (Gentoo, namely), so I need
to know how well the chipsets are supported currently.
I'd really like to go Via - but the crummy KT890 / VT8237 combo sucks
- mainly due to the lack of SATA II with NCQ. I share the sentiments
of the person in a post in the AnandTech forums
(http://tinyurl.com/6d9bx) who says:
"The feature set on the K8T890 sucks. It was supposed to use the
VT8251 southbridge, bringing SATA-II/NCQ, HD Audio, etc.
Unfortunately, this southbridge has since dissappeared off the face of
the earth, and all the current K8T890 boards use the old VT8237.
nForce4, on the other hand, has SATA-II/NCQ, hardware firewall, nice
software overclocking/monitoring tools (ntune), gigabit lan, etc. On
top of that, performance and overclocking is pretty damn good. I was
at one point looking forward to the K8T890, but considering how much
of a joke the whole product line has been (lacking features, months of
delays with no explanation, lack of any variety of retail boards), I
have to say I'd avoid it like the plague."
NForce4 Ultra is brilliant - in many ways. Except it requires binary
drivers, which I really don't want to use. And apparently, the
hardware firewall seems to restrict bandwidth a bit. And even when
its off, external chips that end up being faster
(http://tinyurl.com/4zssp)
So, I'm wondering, are my assumptions correct? Do I have to use
binary drivers to make absolutely full use of the Nforce4 chipset? Or
is there sufficient support for me to make use of the features on it
without using binary drivers?
Sorry for asking something that may have been asked before, but I've
tried searching several times through the mailing list and on a search
engine, but have had little luck.
Thanks,
Asfand Yar
p.s. Here's something for the search engines to latch on to, so this
post and any repies are easier to find: via nvidia nforce4 nforce 4
kt890 kt 890 vt8237 comparison feature set supported compatibility
binary drivers
On Thu, Mar 24, 2005 at 09:20:29AM +0000, Asfand Yar Qazi wrote:
> Hi,
>
> I'm currently contemplating going for an Athlon 64 system. However,
> I'll primarily be using a Linux-based OS (Gentoo, namely), so I need
> to know how well the chipsets are supported currently.
>
> I'd really like to go Via - but the crummy KT890 / VT8237 combo sucks
> - mainly due to the lack of SATA II with NCQ. I share the sentiments
> of the person in a post in the AnandTech forums
> (http://tinyurl.com/6d9bx) who says:
>
> "The feature set on the K8T890 sucks. It was supposed to use the
> VT8251 southbridge, bringing SATA-II/NCQ, HD Audio, etc.
> Unfortunately, this southbridge has since dissappeared off the face of
> the earth, and all the current K8T890 boards use the old VT8237.
> nForce4, on the other hand, has SATA-II/NCQ, hardware firewall, nice
> software overclocking/monitoring tools (ntune), gigabit lan, etc. On
> top of that, performance and overclocking is pretty damn good. I was
> at one point looking forward to the K8T890, but considering how much
> of a joke the whole product line has been (lacking features, months of
> delays with no explanation, lack of any variety of retail boards), I
> have to say I'd avoid it like the plague."
Well, let's cut through the B.S. ;-)
* Even when the SATA core is updated to support NCQ, nForce will not
support it under Linux. No hardware info.
* "hardware firewall" -- sounds silly. Pretty sure Linux doesn't support
it in any case.
* overclocking -- overclockers are always playing with fire. any
overclocked hardware is suspect and unsupportable.
* via comes with gigabit lan these days. My own VIA-based Athlon64
system comes with r8169 gigabit.
Jeff
>
> * "hardware firewall" -- sounds silly. Pretty sure Linux doesn't support
> it in any case.
>
probably just one of those things implemented in the binary drivers in
software, just like the "hardware" IDE raid is most of the time (3ware
being the positive exception there)
Arjan van de Ven wrote:
>>* "hardware firewall" -- sounds silly. Pretty sure Linux doesn't support
>>it in any case.
>>
>
>
> probably just one of those things implemented in the binary drivers in
> software, just like the "hardware" IDE raid is most of the time (3ware
> being the positive exception there)
>
http://www.neoseeker.com/Articles/Hardware/Previews/nvnforce4/3.html
You're right there - some semi-hardware support combined with drivers
apparently result in lower CPU usage that software firewalls. Apparently.
Actually, these people like it:
http://www.bjorn3d.com/read.php?cID=712&pageID=1096
However one feature that you can't laugh at is the fact that it can be
made to block packets in the span of time between the OS being loaded
up, and the "real" firewall coming up. This small time span
theoretically leaves the PC vulnerable, so I think this is the only
use for "ActiveAmor Firewall".
However, this doesn't answer my original question (which I suppose I
should have made clearer): can I get SATA II NCQ support in Linux with
an nForce 4 chipset?
Arjan van de Ven wrote:
>>* "hardware firewall" -- sounds silly. Pretty sure Linux doesn't support
>>it in any case.
>>
>>
>>
>
>probably just one of those things implemented in the binary drivers in
>software, just like the "hardware" IDE raid is most of the time (3ware
>being the positive exception there)
>
Incorrect. While the logic is is almost certainly implemented in the
drivers, there is silicon acceleration of the functionality built into
the Nforce4 chipset (unlike the nforce3), and requires almost no CPU
time to do its job. Nvidia calls this chipset support ActiveArmor.
-Tupshin
Asfand Yar Qazi wrote:
> Arjan van de Ven wrote:
>
>>> * "hardware firewall" -- sounds silly. Pretty sure Linux doesn't
>>> support
>>> it in any case.
>>>
>>
>>
>> probably just one of those things implemented in the binary drivers in
>> software, just like the "hardware" IDE raid is most of the time (3ware
>> being the positive exception there)
>>
>
> http://www.neoseeker.com/Articles/Hardware/Previews/nvnforce4/3.html
>
> You're right there - some semi-hardware support combined with drivers
> apparently result in lower CPU usage that software firewalls. Apparently.
>
> Actually, these people like it:
> http://www.bjorn3d.com/read.php?cID=712&pageID=1096
>
> However one feature that you can't laugh at is the fact that it can be
> made to block packets in the span of time between the OS being loaded
> up, and the "real" firewall coming up. This small time span
> theoretically leaves the PC vulnerable, so I think this is the only use
> for "ActiveAmor Firewall".
>
> However, this doesn't answer my original question (which I suppose I
> should have made clearer): can I get SATA II NCQ support in Linux with
> an nForce 4 chipset?
>
>
Argh already been answered. Another question: which add-in SATA RAID
boards (preferably in PCI Express flavour) support NCQ fully and will
be fully supported in Linux?
<OT>
Do You really need nforce4?
Maybe sis76[01]GX will be enough? :-)
http://www.sis.com/products/sis760gx.htm
http://www.sis.com/pressroom/pressrelease_000184.htm
</OT>
On Thu, 2005-03-24 at 10:00 +0000, Asfand Yar Qazi wrote:
> Arjan van de Ven wrote:
> >>* "hardware firewall" -- sounds silly. Pretty sure Linux doesn't support
> >>it in any case.
> >>
> >
> >
> > probably just one of those things implemented in the binary drivers in
> > software, just like the "hardware" IDE raid is most of the time (3ware
> > being the positive exception there)
> >
>
> http://www.neoseeker.com/Articles/Hardware/Previews/nvnforce4/3.html
>
> You're right there - some semi-hardware support combined with drivers
> apparently result in lower CPU usage that software firewalls. Apparently.
lower CPU usage than the *windows* firewall.
While there is a potential gain from a firewall function on the other
side of the PCI bus, this gain is when you reject most packets. Eg you
save "bad" packets from going over the bus. Now the question is how many
bad packets do you get per second...
> However one feature that you can't laugh at is the fact that it can be
> made to block packets in the span of time between the OS being loaded
> up, and the "real" firewall coming up. This small time span
> theoretically leaves the PC vulnerable, so I think this is the only
> use for "ActiveAmor Firewall".
This is a joke right? In linux at least, the OS doesn't get packets
unless it asks for it; I can't imagine any other OS doing that
differently (since most are somewhat based on the same model). And all
linux distros I know of first install the firewall rules and then tell
the NIC to start receiving packets. In that order. I don't know how
windows does it (and I don't care), but if it gets this wrong it would
be a really bad bug in windows. But I guess it'd give the chipset
marketing people something to boast about ;)
Pawel Sikora wrote:
> <OT>
>
> Do You really need nforce4?
> Maybe sis76[01]GX will be enough? :-)
>
> http://www.sis.com/products/sis760gx.htm
> http://www.sis.com/pressroom/pressrelease_000184.htm
>
> </OT>
No, but I do need NCQ
On Thu, Mar 24, 2005 at 04:30:32AM -0500, Jeff Garzik wrote:
> Well, let's cut through the B.S. ;-)
>
> * Even when the SATA core is updated to support NCQ, nForce will not
> support it under Linux. No hardware info.
Hmm, either that or someone will figure it out anyhow, like they did
with forcedeth. Would be nice if nvidia would realize just how dumb not
releasing programing specs is. How can that be considered a secret.
Maybe they just have a company wide policy of "release nothing" rather
than "don't release the clever 3D acceleration in our drivers that ATI
can't have". Some comapnies just don't seem to realize they are in the
business of _selling_ hardware, not hardware interface specifications.
> * "hardware firewall" -- sounds silly. Pretty sure Linux doesn't support
> it in any case.
>
> * overclocking -- overclockers are always playing with fire. any
> overclocked hardware is suspect and unsupportable.
>
> * via comes with gigabit lan these days. My own VIA-based Athlon64
> system comes with r8169 gigabit.
I think the r8139 has ruined realtek for me forever. I like the Marvell
Yukon chip Asus includes on many boards (although some people have
reported problems with some Asus boards using them with Linux).
Len Sorensen
On Thu, Mar 24, 2005 at 10:00:46AM +0000, Asfand Yar Qazi wrote:
> http://www.neoseeker.com/Articles/Hardware/Previews/nvnforce4/3.html
>
> You're right there - some semi-hardware support combined with drivers
> apparently result in lower CPU usage that software firewalls. Apparently.
>
> Actually, these people like it:
> http://www.bjorn3d.com/read.php?cID=712&pageID=1096
>
> However one feature that you can't laugh at is the fact that it can be
> made to block packets in the span of time between the OS being loaded
> up, and the "real" firewall coming up. This small time span
> theoretically leaves the PC vulnerable, so I think this is the only
> use for "ActiveAmor Firewall".
Until the OS loads network drivers AND configures IP support AND starts
accepting packets in, there is nothing for the firewall to do.
Certainly on Linux I can make sure iptables is populated (or least has a
sane policy set) before I bring up networking. In other words: "Who
cares".
> However, this doesn't answer my original question (which I suppose I
> should have made clearer): can I get SATA II NCQ support in Linux with
> an nForce 4 chipset?
Don't know. I think 3ware's controllers do their own NCQ, which is
pretty neat.
Len Sorensen
Lennart Sorensen wrote:
> Until the OS loads network drivers AND configures IP support AND starts
> accepting packets in, there is nothing for the firewall to do.
> Certainly on Linux I can make sure iptables is populated (or least has a
> sane policy set) before I bring up networking. In other words: "Who
> cares".
guess that's a windows thing...
On Thu, Mar 24, 2005 at 10:33:03AM +0000, Asfand Yar Qazi wrote:
> No, but I do need NCQ
Perhaps a stupid question... but: Why do you _need_ NCQ? If you need it
that badly (not sure why anyone would), you could always get SCSI or a
3ware controller.
NCQ is a nice feature, but hardly essential.
Len Sorensen
Lennart Sorensen wrote:
> On Thu, Mar 24, 2005 at 10:33:03AM +0000, Asfand Yar Qazi wrote:
>
>>No, but I do need NCQ
>
>
> Perhaps a stupid question... but: Why do you _need_ NCQ? If you need it
> that badly (not sure why anyone would), you could always get SCSI or a
> 3ware controller.
>
For the novelty value.
> NCQ is a nice feature, but hardly essential.
So is baking soda flavoured toothpaste - whats yer point? :-)
>
> Len Sorensen
>
Anyway, the 3ware controller (if it is avaliable for PCI express)
sounds good. Off-mainboard solutions tend to be quicker anyway.
Asfand Yar Qazi wrote:
> However, this doesn't answer my original question (which I suppose I
> should have made clearer): can I get SATA II NCQ support in Linux with
> an nForce 4 chipset?
I answered this question already. The answer is no.
Jeff
Lennart Sorensen wrote:
> I think the r8139 has ruined realtek for me forever. I like the Marvell
> Yukon chip Asus includes on many boards (although some people have
> reported problems with some Asus boards using them with Linux).
I won't disagree with your experiences. For me, outside of one brief
moment when the r8169 driver didn't work on Athlon64, it has worked
flawlessly for me.
RealTek 8169 is currently my favorite gigabit chip.
WRT Marvell Yukon, make sure it is not the Yukon2. Yukon2 isn't
supported by any driver in the kernel, presently.
Jeff
Asfand Yar Qazi wrote:
> NForce4 Ultra is brilliant - in many ways. Except it requires binary
> drivers, which I really don't want to use. And apparently, the hardware
> firewall seems to restrict bandwidth a bit. And even when its off,
> external chips that end up being faster (http://tinyurl.com/4zssp)
>
> So, I'm wondering, are my assumptions correct? Do I have to use binary
> drivers to make absolutely full use of the Nforce4 chipset? Or is there
> sufficient support for me to make use of the features on it without
> using binary drivers?
>
> Sorry for asking something that may have been asked before, but I've
> tried searching several times through the mailing list and on a search
> engine, but have had little luck.
>
> Thanks,
> Asfand Yar
There is no need to use any binary drivers on the nForce4 - the only
ones even available are for the network and audio. The network works
fine with the forcedeth driver included in the kernel - I don't know
about the audio, I'm not using the onboard sound.
Some wrinkles with Linux support are that you may need to update the X
server (ex: X.org) as there are some bugs with PCI Express video on
x86_64 that were fixed somewhat recently - as well there was a bug with
USB port detection that cropped up in kernel 2.6.10 and I believe is
fixed in 2.6.11.
The nForce4 chipset supports NCQ on the SATA interface, however this is
not supported in Linux yet. It seems like the SATA controller has some
similarity or is based on the ADMA architecture (the Windows driver is
called "NVIDIA nForce4 ADMA Controller", so using it with the ADMA
driver might be doable at some point, though I haven't heard of any
hardware specs being released..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
On Thu, 2005-03-24 at 20:15 -0600, Robert Hancock wrote:
> There is no need to use any binary drivers on the nForce4 - the only
> ones even available are for the network and audio. The network works
> fine with the forcedeth driver included in the kernel - I don't know
> about the audio, I'm not using the onboard sound.
Your statement is self contradictory. How can you say there's no need
to use binary drivers if you don't know anything about the audio
support? Many users consider sound a critical feature.
As a matter of fact there are a few quirks with the audio on Nvidia
chipsets, due to (surprise) lack of documentation.
Lee
On Thu, 24 Mar 2005 at 10:34:12 +0100, Arjan van de Ven wrote:
> probably just one of those things implemented in the binary drivers in
> software, just like the "hardware" IDE raid is most of the time (3ware
> being the positive exception there)
IT8212 is a real hardware ATA RAID controller. Too bad it will never get
merged from -ac into mainline with the HW RAID support intact...
--
Chuck
http://www.counterfeitmini.org
Hi
Just to answer some questions :
- USB works ok since 2.6.11
- audio works too. The only problem is that two applications can't
open /dev/dsp in the same time.
- network works
I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
experiment the following problem :
Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
DriveReady SeekComplete DataRequest }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
Mar 25 22:42:55 evenflow kernel:
Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Of course, if I disable DMA with hdparm, this problem disappear.. but
it isn't a long-term solution ;-)
Using vanilla 2.6.11.5 kernel. I attached the config file.
I also experiment sometimes a complete hang of the system. But I
didn't find how to reproduce the bug yet, especially because it seems
to happen when I do nothing (when I'm sleeping or am at work ;), and I
can't get a Oops because I don't have any serial console...
Kind regards,
--
Julien Wajsberg
On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> - audio works too. The only problem is that two applications can't
> open /dev/dsp in the same time.
Not a problem. ALSA does software mixing for chipsets that can't do it
in hardware. Google for dmix.
However this doesn't (and can't be made to) work with the in-kernel OSS
emulation (it works fine with the alsa-lib/libaoss emulation). So you
are technically correct in that two OSS apps can't open /dev/dsp at the
same time, but there is no problem with multiple apps sharing the sound
device, as long as they use the ALSA API (which they should be using
anyway).
Lee
On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
> Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
> Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
> Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
> DriveReady SeekComplete DataRequest }
> Mar 25 22:42:55 evenflow kernel:
> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
> Mar 25 22:42:55 evenflow kernel:
> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
Are you sure the drive is OK? Those messages are the classic signs of a
failing drive...
Lee
On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> I also experiment sometimes a complete hang of the system. But I
> didn't find how to reproduce the bug yet, especially because it seems
> to happen when I do nothing (when I'm sleeping or am at work ;), and I
> can't get a Oops because I don't have any serial console...
You could try netconsole...
Lee
On Fri, 25 Mar 2005 18:21:42 -0500, Lee Revell <[email protected]> wrote:
> On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> > Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
> > Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
> > Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
> > Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
> > DriveReady SeekComplete DataRequest }
> > Mar 25 22:42:55 evenflow kernel:
> > Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> > Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> > Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
> > Mar 25 22:42:55 evenflow kernel:
> > Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> > Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
> > Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
>
> Are you sure the drive is OK? Those messages are the classic signs of a
> failing drive...
It's nearly new, and it was ok in my last computer (an old P3-500 with
PIIX4, IIRC).
BTW I did a complete badblocks check on it, and it found nothing.
--
Julien
On Fri, 25 Mar 2005 18:20:54 -0500, Lee Revell <[email protected]> wrote:
> On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> > I also experiment sometimes a complete hang of the system. But I
> > didn't find how to reproduce the bug yet, especially because it seems
> > to happen when I do nothing (when I'm sleeping or am at work ;), and I
> > can't get a Oops because I don't have any serial console...
>
> You could try netconsole...
Good point... I just tried, but forcedeth doesn't support netpoll. If
you have a pointer, I could try to implement it ;-)
--
Julien
On Fri, 25 Mar 2005 18:14:22 -0500, Lee Revell <[email protected]> wrote:
> On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> > - audio works too. The only problem is that two applications can't
> > open /dev/dsp in the same time.
>
> Not a problem. ALSA does software mixing for chipsets that can't do it
> in hardware. Google for dmix.
>
> However this doesn't (and can't be made to) work with the in-kernel OSS
> emulation (it works fine with the alsa-lib/libaoss emulation). So you
> are technically correct in that two OSS apps can't open /dev/dsp at the
> same time, but there is no problem with multiple apps sharing the sound
> device, as long as they use the ALSA API (which they should be using
> anyway).
Okay, good to know. Then I'll have to find out why beep-media-player
doesn't work with alsa :-)
--
Julien
On Sat, 2005-03-26 at 01:38 +0100, Julien Wajsberg wrote:
> On Fri, 25 Mar 2005 18:14:22 -0500, Lee Revell <[email protected]> wrote:
> > On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> > > - audio works too. The only problem is that two applications can't
> > > open /dev/dsp in the same time.
> >
> > Not a problem. ALSA does software mixing for chipsets that can't do it
> > in hardware. Google for dmix.
> >
> > However this doesn't (and can't be made to) work with the in-kernel OSS
> > emulation (it works fine with the alsa-lib/libaoss emulation). So you
> > are technically correct in that two OSS apps can't open /dev/dsp at the
> > same time, but there is no problem with multiple apps sharing the sound
> > device, as long as they use the ALSA API (which they should be using
> > anyway).
>
> Okay, good to know. Then I'll have to find out why beep-media-player
> doesn't work with alsa :-)
>
Without knowing anything about it, I'm willing to guess "programmer
laziness/lack of time" (depending on your perspective). As long as ALSA
continues to provide OSS emulation, lazy developers will not update
their apps to the (superior) ALSA API.
I just upgraded all my home machines to a Gnome 2.10 based distro and
way shocked to find that it still uses esd via OSS emulation for system
sounds. So the endless user complaints about "wtf, esd is blocking my
sound device, on windows my apps can share it" will not be going away in
the forseeable future.
Ugh. dmix has only been available for, oh, 18 months, and the apps
still have not caught up.
Lee
--- linux-2.6.12-rc1/drivers/net/forcedeth.c.orig 2005-03-26 15:00:12.000000000 +0100
+++ linux-2.6.12-rc1/drivers/net/forcedeth.c 2005-03-26 15:08:56.000000000 +0100
@@ -1480,6 +1480,13 @@ static void nv_do_nic_poll(unsigned long
enable_irq(dev->irq);
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void nv_poll_controller(struct net_device *dev)
+{
+ nv_do_nic_poll((long) dev);
+}
+#endif
+
static void nv_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
{
struct fe_priv *np = get_nvpriv(dev);
@@ -1962,6 +1969,9 @@ static int __devinit nv_probe(struct pci
dev->get_stats = nv_get_stats;
dev->change_mtu = nv_change_mtu;
dev->set_multicast_list = nv_set_multicast;
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ dev->poll_controller = nv_poll_controller;
+#endif
SET_ETHTOOL_OPS(dev, &ops);
dev->tx_timeout = nv_tx_timeout;
dev->watchdog_timeo = NV_WATCHDOG_TIMEO;
On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
> Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
> Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
> Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
> DriveReady SeekComplete DataRequest }
> Mar 25 22:42:55 evenflow kernel:
> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
> Mar 25 22:42:55 evenflow kernel:
> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
(something) like the same problem here:
I get lots of:
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
The disk (WDC WD800JB) is about 1/2 year old.
I've checked the drive in my old system... nothing!
Also WD's diagnostic kit doesn't report any problems like bad sectors,
or other troubles...
(Please CC me, I'm not on the list)
`
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x84 { DriveStatusError BadCRC
BadCRC is 99% sure a cabling issue; either a bad/overheated cable or a
cable used at too high a speed for the cable.
On 2005-03-26, at 16:19, Arjan van de Ven wrote:
> `
>> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
>> hda: dma_intr: error=0x84 { DriveStatusError BadCRC
>
> BadCRC is 99% sure a cabling issue; either a bad/overheated cable or a
> cable used at too high a speed for the cable.
No. It is more likely that the timing programming between the disk and
host controller
are in a miss-match state. UDMA mode detection can come in to mind too.
It makes sense to experiment with hdparm to see if the problem goes
away in non
Ultra DMA modes.
On Saturday, 26. March 2005 18:32, Marcin Dalecki wrote:
> On 2005-03-26, at 16:19, Arjan van de Ven wrote:
> > `
> >
> >> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> >> hda: dma_intr: error=0x84 { DriveStatusError BadCRC
> >
> > BadCRC is 99% sure a cabling issue; either a bad/overheated cable or a
> > cable used at too high a speed for the cable.
>
> No. It is more likely that the timing programming between the disk and
> host controller
> are in a miss-match state. UDMA mode detection can come in to mind too.
> It makes sense to experiment with hdparm to see if the problem goes
> away in non
> Ultra DMA modes.
Thanks, I tried the cable that came with the drive (it was still sealed) and
experimented a little bit with hdparm...
Now, the problem seems to be gone...
Jeff Garzik <[email protected]> writes:
>
> I won't disagree with your experiences. For me, outside of one brief
> moment when the r8169 driver didn't work on Athlon64, it has worked
> flawlessly for me.
>
> RealTek 8169 is currently my favorite gigabit chip.
It does not seem to support DAC (or rather it breaks with DAC enabled),
which makes it not very useful on any machine with >3GB of memory.
-Andi
On Sat, 26 Mar 2005 15:13:47 +0100, Michal Schmidt
<[email protected]> wrote:
> Julien Wajsberg wrote:
> > Good point... I just tried, but forcedeth doesn't support netpoll. If
> > you have a pointer, I could try to implement it ;-)
>
> Can you try the attached patch for forcedeth?
> It compiles for me, but I don't have nForce hardware to test it.
Okay, it works :)
maybe I'll have something for you to debug at the next crash...
--
Julien
> --- linux-2.6.12-rc1/drivers/net/forcedeth.c.orig 2005-03-26 15:00:12.000000000 +0100
> +++ linux-2.6.12-rc1/drivers/net/forcedeth.c 2005-03-26 15:08:56.000000000 +0100
> @@ -1480,6 +1480,13 @@ static void nv_do_nic_poll(unsigned long
> enable_irq(dev->irq);
> }
>
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +static void nv_poll_controller(struct net_device *dev)
> +{
> + nv_do_nic_poll((long) dev);
> +}
> +#endif
> +
> static void nv_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info)
> {
> struct fe_priv *np = get_nvpriv(dev);
> @@ -1962,6 +1969,9 @@ static int __devinit nv_probe(struct pci
> dev->get_stats = nv_get_stats;
> dev->change_mtu = nv_change_mtu;
> dev->set_multicast_list = nv_set_multicast;
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + dev->poll_controller = nv_poll_controller;
> +#endif
> SET_ETHTOOL_OPS(dev, &ops);
> dev->tx_timeout = nv_tx_timeout;
> dev->watchdog_timeo = NV_WATCHDOG_TIMEO;
>
>
>
On Fri, Mar 25, 2005 at 06:14:22PM -0500, Lee Revell wrote:
> On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> > - audio works too. The only problem is that two applications can't
> > open /dev/dsp in the same time.
>
> Not a problem. ALSA does software mixing for chipsets that can't do it
> in hardware. Google for dmix.
>
> However this doesn't (and can't be made to) work with the in-kernel OSS
> emulation (it works fine with the alsa-lib/libaoss emulation). So you
quake3 still segfaults when run through "aoss". And can't be fixed, as
it's closed source still.
--
Tomasz Torcz "Never underestimate the bandwidth of a station
[email protected] wagon filled with backup tapes." -- Jim Gray
On Tue, 2005-03-29 at 20:58 +0200, Tomasz Torcz wrote:
> On Fri, Mar 25, 2005 at 06:14:22PM -0500, Lee Revell wrote:
> > On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> > > - audio works too. The only problem is that two applications can't
> > > open /dev/dsp in the same time.
> >
> > Not a problem. ALSA does software mixing for chipsets that can't do it
> > in hardware. Google for dmix.
> >
> > However this doesn't (and can't be made to) work with the in-kernel OSS
> > emulation (it works fine with the alsa-lib/libaoss emulation). So you
>
> quake3 still segfaults when run through "aoss". And can't be fixed, as
> it's closed source still.
>
I guess that's Quake3's problem...
Lee
On Tue, Mar 29, 2005 at 03:40:07PM -0500, Lee Revell wrote:
> On Tue, 2005-03-29 at 20:58 +0200, Tomasz Torcz wrote:
> > On Fri, Mar 25, 2005 at 06:14:22PM -0500, Lee Revell wrote:
> > > On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> > > > - audio works too. The only problem is that two applications can't
> > > > open /dev/dsp in the same time.
> > >
> > > Not a problem. ALSA does software mixing for chipsets that can't do it
> > > in hardware. Google for dmix.
> > >
> > > However this doesn't (and can't be made to) work with the in-kernel OSS
> > > emulation (it works fine with the alsa-lib/libaoss emulation). So you
> >
> > quake3 still segfaults when run through "aoss". And can't be fixed, as
> > it's closed source still.
> >
> I guess that's Quake3's problem...
It an glaring example, dmix is unsufficient in one third of my sound
uses (other two beeing movie and music playback)
But you advertise dmix like it was silver bullet.
--
Tomasz Torcz "Never underestimate the bandwidth of a station
[email protected] wagon filled with backup tapes." -- Jim Gray
On Wed, Mar 30, 2005 at 05:00:23PM +0200, Tomasz Torcz wrote:
> It an glaring example, dmix is unsufficient in one third of my sound
> uses (other two beeing movie and music playback)
> But you advertise dmix like it was silver bullet.
An emu10k1 is a silver bullet. :)
Len Sorensen
On Wed, 2005-03-30 at 17:00 +0200, Tomasz Torcz wrote:
> On Tue, Mar 29, 2005 at 03:40:07PM -0500, Lee Revell wrote:
> > On Tue, 2005-03-29 at 20:58 +0200, Tomasz Torcz wrote:
> > > On Fri, Mar 25, 2005 at 06:14:22PM -0500, Lee Revell wrote:
> > > > On Fri, 2005-03-25 at 23:59 +0100, Julien Wajsberg wrote:
> > > > > - audio works too. The only problem is that two applications can't
> > > > > open /dev/dsp in the same time.
> > > >
> > > > Not a problem. ALSA does software mixing for chipsets that can't do it
> > > > in hardware. Google for dmix.
> > > >
> > > > However this doesn't (and can't be made to) work with the in-kernel OSS
> > > > emulation (it works fine with the alsa-lib/libaoss emulation). So you
> > >
> > > quake3 still segfaults when run through "aoss". And can't be fixed, as
> > > it's closed source still.
> > >
> > I guess that's Quake3's problem...
>
> It an glaring example, dmix is unsufficient in one third of my sound
> uses (other two beeing movie and music playback)
> But you advertise dmix like it was silver bullet.
>
Or goes limbo randomly and no mailing to lists seems to result in a
reply (from the alsa peeps at least) ...
--
Martin Schlemmer
Andi Kleen wrote:
> Jeff Garzik <[email protected]> writes:
>
>>I won't disagree with your experiences. For me, outside of one brief
>>moment when the r8169 driver didn't work on Athlon64, it has worked
>>flawlessly for me.
>>
>>RealTek 8169 is currently my favorite gigabit chip.
>
>
> It does not seem to support DAC (or rather it breaks with DAC enabled),
> which makes it not very useful on any machine with >3GB of memory.
Driver bug. I can futz with it and get it to do 64-bit on my Athlon64.
Jeff
Jeff Garzik wrote:
> Andi Kleen wrote:
>
>> Jeff Garzik <[email protected]> writes:
>>
>>> I won't disagree with your experiences. For me, outside of one brief
>>> moment when the r8169 driver didn't work on Athlon64, it has worked
>>> flawlessly for me.
>>>
>>> RealTek 8169 is currently my favorite gigabit chip.
>>
>>
>>
>> It does not seem to support DAC (or rather it breaks with DAC
>> enabled), which makes it not very useful on any machine with >3GB of
>> memory.
>
>
> Driver bug. I can futz with it and get it to do 64-bit on my Athlon64.
Continuing with off-topic questions: is this "checksum off-load" usable
with r8169? Is there any other reason (performance?) to use hardware
TCP/IP checksumming than just "cool, a little chunk of software is
hardwired again"?
I have seen you mentioned that this causes mainly troubles if you try to
set it with ethtool. Is it still true?
Indrek
Indrek Kruusa wrote:
> Jeff Garzik wrote:
>
>> Andi Kleen wrote:
>>
>>> Jeff Garzik <[email protected]> writes:
>>>
>>>> I won't disagree with your experiences. For me, outside of one brief
>>>> moment when the r8169 driver didn't work on Athlon64, it has worked
>>>> flawlessly for me.
>>>>
>>>> RealTek 8169 is currently my favorite gigabit chip.
>>>
>>>
>>>
>>>
>>> It does not seem to support DAC (or rather it breaks with DAC
>>> enabled), which makes it not very useful on any machine with >3GB of
>>> memory.
>>
>>
>>
>> Driver bug. I can futz with it and get it to do 64-bit on my Athlon64.
>
>
>
> Continuing with off-topic questions: is this "checksum off-load" usable
> with r8169? Is there any other reason (performance?) to use hardware
> TCP/IP checksumming than just "cool, a little chunk of software is
> hardwired again"?
It's usable, and enables "zero copy" feature.
> I have seen you mentioned that this causes mainly troubles if you try to
> set it with ethtool. Is it still true?
Not sure what you are referring to.
Jeff
Jeff Garzik wrote:
> Indrek Kruusa wrote:
>
>> Jeff Garzik wrote:
>>
>>> Andi Kleen wrote:
>>>
>>>> Jeff Garzik <[email protected]> writes:
>>>>
>>>>> I won't disagree with your experiences. For me, outside of one brief
>>>>> moment when the r8169 driver didn't work on Athlon64, it has worked
>>>>> flawlessly for me.
>>>>>
>>>>> RealTek 8169 is currently my favorite gigabit chip.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> It does not seem to support DAC (or rather it breaks with DAC
>>>> enabled), which makes it not very useful on any machine with >3GB
>>>> of memory.
>>>
>>>
>>>
>>>
>>> Driver bug. I can futz with it and get it to do 64-bit on my Athlon64.
>>
>>
>>
>>
>> Continuing with off-topic questions: is this "checksum off-load"
>> usable with r8169? Is there any other reason (performance?) to use
>> hardware TCP/IP checksumming than just "cool, a little chunk of
>> software is hardwired again"?
>
>
> It's usable, and enables "zero copy" feature.
>
>
>> I have seen you mentioned that this causes mainly troubles if you try
>> to set it with ethtool. Is it still true?
>
>
> Not sure what you are referring to.
Sorry - my brains interpretation was classic rumor case: discussion I
remembered was about broken NIC not about enabling hw checksum. I
referred to this one:
http://www.ussg.iu.edu/hypermail/linux/kernel/0503.3/0369.html
Jeff Garzik wrote:
> Evgeniy Polyakov wrote:
>
>> Noone will complain on Linux if NIC is broken and produces wrong
>> checksum
>> and HW checksum offloading is enabled using ethtools.
>
>
>
> Actually, that is a problem and people have definitely complained
> about it in the past.
On Wed, 2005-03-30 at 21:19 +0200, Martin Schlemmer wrote:
> On Wed, 2005-03-30 at 17:00 +0200, Tomasz Torcz wrote:
> > > > quake3 still segfaults when run through "aoss". And can't be fixed, as
> > > > it's closed source still.
> > > >
> > > I guess that's Quake3's problem...
> >
> > It an glaring example, dmix is unsufficient in one third of my sound
> > uses (other two beeing movie and music playback)
> > But you advertise dmix like it was silver bullet.
> >
>
> Or goes limbo randomly and no mailing to lists seems to result in a
> reply (from the alsa peeps at least) ...
>
Because no one has ever produced a simple test program with source code
that demonstrates the problem. You really expect the ALSA developers to
go chasing bugs in closed source apps?
Anyway, do you really need to hear your system sounds and MP3s while
playing Q3? This is hardly a fatal problem.
Lee
Jeff Garzik <[email protected]> :
> Andi Kleen wrote:
[r8169 driver]
> >It does not seem to support DAC (or rather it breaks with DAC enabled),
> >which makes it not very useful on any machine with >3GB of memory.
>
> Driver bug. I can futz with it and get it to do 64-bit on my Athlon64.
Care to send a patch ?
--
Ueimor
Francois Romieu wrote:
> Jeff Garzik <[email protected]> :
>
>>Andi Kleen wrote:
>
> [r8169 driver]
>
>>>It does not seem to support DAC (or rather it breaks with DAC enabled),
>>>which makes it not very useful on any machine with >3GB of memory.
>>
>>Driver bug. I can futz with it and get it to do 64-bit on my Athlon64.
>
>
> Care to send a patch ?
Not globally applicable, judging from the reports :(
Jeff
On Wed, 2005-03-30 at 16:01 -0500, Lee Revell wrote:
> On Wed, 2005-03-30 at 21:19 +0200, Martin Schlemmer wrote:
> > On Wed, 2005-03-30 at 17:00 +0200, Tomasz Torcz wrote:
> > > > > quake3 still segfaults when run through "aoss". And can't be fixed, as
> > > > > it's closed source still.
> > > > >
> > > > I guess that's Quake3's problem...
> > >
> > > It an glaring example, dmix is unsufficient in one third of my sound
> > > uses (other two beeing movie and music playback)
> > > But you advertise dmix like it was silver bullet.
> > >
> >
> > Or goes limbo randomly and no mailing to lists seems to result in a
> > reply (from the alsa peeps at least) ...
> >
>
> Because no one has ever produced a simple test program with source code
> that demonstrates the problem. You really expect the ALSA developers to
> go chasing bugs in closed source apps?
>
> Anyway, do you really need to hear your system sounds and MP3s while
> playing Q3? This is hardly a fatal problem.
>
It never involved Q3 - what makes you assume this? I just chipped in
due to your dmix advertising.
--
Martin Schlemmer
On Mar 26, 2005 7:32 PM, Marcin Dalecki <[email protected]> wrote:
>
> On 2005-03-26, at 16:19, Arjan van de Ven wrote:
>
> > `
> >> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> >> hda: dma_intr: error=0x84 { DriveStatusError BadCRC
> >
> > BadCRC is 99% sure a cabling issue; either a bad/overheated cable or a
> > cable used at too high a speed for the cable.
>
> No. It is more likely that the timing programming between the disk and
> host controller
> are in a miss-match state. UDMA mode detection can come in to mind too.
> It makes sense to experiment with hdparm to see if the problem goes
> away in non
> Ultra DMA modes.
Do you mean "multiword dma modes" or "pio modes" ?
--
Julien
On Mar 26, 2005 12:59 AM, Julien Wajsberg <[email protected]> wrote:
> I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
> experiment the following problem :
>
> Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
> Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
> Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
> Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
> DriveReady SeekComplete DataRequest }
> Mar 25 22:42:55 evenflow kernel:
> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
> Mar 25 22:42:55 evenflow kernel:
> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
>
> Of course, if I disable DMA with hdparm, this problem disappear.. but
> it isn't a long-term solution ;-)
>
> Using vanilla 2.6.11.5 kernel. I attached the config file.
I tried the multidma mode (as opposed to ultradma), and the system
hanged immediately. (Thanks to the patched-for-netpoll forcedeth
driver), I got the following message:
Unknown interrupt or fault at EIP 00000206 00000060 c0247a3a
There's definitely something wrong here...
I'm still using the same setup as in my first mail.
--
Julien
On Tue, 5 Apr 2005, Julien Wajsberg wrote:
> On Mar 26, 2005 12:59 AM, Julien Wajsberg <[email protected]> wrote:
>> I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
>> experiment the following problem :
>>
>> Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
>> Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
>> Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
>> Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
>> DriveReady SeekComplete DataRequest }
>> Mar 25 22:42:55 evenflow kernel:
>> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
>> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
>> Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
>> Mar 25 22:42:55 evenflow kernel:
>> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
>> Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
^^^^^^^^^^^^^^^^^
>> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
>>
>> Of course, if I disable DMA with hdparm, this problem disappear.. but
>> it isn't a long-term solution ;-)
>>
The long-term solution is to replace either the drive, cable, or the
motherboard that can't do DMA. A bad DMA operation can write data
anywhere (right into the middle of the kernel). There isn't
anything software can do about it. Software sets up the
controller for a DMA operation, then waits for an interrupt
that tells it has completed or failed. Software can retry failed
operations until software gets destroyed by the hardware, but
there isn't anything else that can be done.
The fact that disabling DMA makes the problem(s) go away is
proof that it isn't a software problem. There are flash-RAM
devices that emulate IDE drives. Most of these can't do DMA
and the IDE driver doesn't accept that fact. That is a known
bug. One needs to use hdparm to tell it to stop trying to
use DMA. In your case, the driver stopped using DMA when
it found out that it didn't work. There is no bug.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Apr 5, 2005 4:10 PM, Richard B. Johnson <[email protected]> wrote:
> On Tue, 5 Apr 2005, Julien Wajsberg wrote:
>
> > On Mar 26, 2005 12:59 AM, Julien Wajsberg <[email protected]> wrote:
> >> I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
> >> experiment the following problem :
> >>
> >> Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
> >> Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
> >> Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
> >> Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
> >> DriveReady SeekComplete DataRequest }
> >> Mar 25 22:42:55 evenflow kernel:
> >> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> >> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> >> Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
> >> Mar 25 22:42:55 evenflow kernel:
> >> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> >> Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
> ^^^^^^^^^^^^^^^^^
> >> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> >>
> >> Of course, if I disable DMA with hdparm, this problem disappear.. but
> >> it isn't a long-term solution ;-)
> >>
>
> The long-term solution is to replace either the drive, cable, or the
> motherboard that can't do DMA.
It's a recent drive that did ultra DMA on another motherboard, and a
recent motherboard with a cable that did ultra DMA before.It was ultra
DMA2 on this old motherboard, but it still was ultra DMA.
> A bad DMA operation can write data
> anywhere (right into the middle of the kernel). There isn't
> anything software can do about it. Software sets up the
> controller for a DMA operation, then waits for an interrupt
> that tells it has completed or failed. Software can retry failed
> operations until software gets destroyed by the hardware, but
> there isn't anything else that can be done.
>
> The fact that disabling DMA makes the problem(s) go away is
> proof that it isn't a software problem. There are flash-RAM
> devices that emulate IDE drives. Most of these can't do DMA
> and the IDE driver doesn't accept that fact. That is a known
> bug. One needs to use hdparm to tell it to stop trying to
> use DMA. In your case, the driver stopped using DMA when
> it found out that it didn't work. There is no bug.
In my case, the driver stopped for hdb, that is my dvd-burner/player.
It did nothing for hda or hdc, I had to disable DMA myself.
Will I have to install Windows XP to prove ultra DMA works correctly
on this setup ? I really don't hope...
--
Julien
On Tue, 5 Apr 2005, Julien Wajsberg wrote:
> On Apr 5, 2005 4:10 PM, Richard B. Johnson <[email protected]> wrote:
>> On Tue, 5 Apr 2005, Julien Wajsberg wrote:
>>
>>> On Mar 26, 2005 12:59 AM, Julien Wajsberg <[email protected]> wrote:
>>>> I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
>>>> experiment the following problem :
>>>>
>>>> Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
>>>> Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
>>>> Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
>>>> Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
>>>> DriveReady SeekComplete DataRequest }
>>>> Mar 25 22:42:55 evenflow kernel:
>>>> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
>>>> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
>>>> Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
>>>> Mar 25 22:42:55 evenflow kernel:
>>>> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
>>>> Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
>> ^^^^^^^^^^^^^^^^^
>>>> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
>>>>
>>>> Of course, if I disable DMA with hdparm, this problem disappear.. but
>>>> it isn't a long-term solution ;-)
>>>>
>>
>> The long-term solution is to replace either the drive, cable, or the
>> motherboard that can't do DMA.
> It's a recent drive that did ultra DMA on another motherboard, and a
> recent motherboard with a cable that did ultra DMA before.It was ultra
> DMA2 on this old motherboard, but it still was ultra DMA.
>
>> A bad DMA operation can write data
>> anywhere (right into the middle of the kernel). There isn't
>> anything software can do about it. Software sets up the
>> controller for a DMA operation, then waits for an interrupt
>> that tells it has completed or failed. Software can retry failed
>> operations until software gets destroyed by the hardware, but
>> there isn't anything else that can be done.
>>
>> The fact that disabling DMA makes the problem(s) go away is
>> proof that it isn't a software problem. There are flash-RAM
>> devices that emulate IDE drives. Most of these can't do DMA
>> and the IDE driver doesn't accept that fact. That is a known
>> bug. One needs to use hdparm to tell it to stop trying to
>> use DMA. In your case, the driver stopped using DMA when
>> it found out that it didn't work. There is no bug.
>
> In my case, the driver stopped for hdb, that is my dvd-burner/player.
> It did nothing for hda or hdc, I had to disable DMA myself.
>
> Will I have to install Windows XP to prove ultra DMA works correctly
> on this setup ? I really don't hope...
How would you know? Windows will just run it as PIOW and be done
with it. Did you ever try to copy a large file in XP? Try it.
Try the same thing in linux on the same hardware. You don't need
a stop-watch. On Win-XP, a 10 megabyte file (hardly large) takes
about 10 seconds. That's 1 megabyte/second. Linux tries to be
a bit faster.
>
> --
> Julien
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Apr 6, 2005 1:41 PM, Richard B. Johnson <[email protected]> wrote:
> On Tue, 5 Apr 2005, Julien Wajsberg wrote:
>
> > On Apr 5, 2005 4:10 PM, Richard B. Johnson <[email protected]> wrote:
> >> On Tue, 5 Apr 2005, Julien Wajsberg wrote:
> >>
> >>> On Mar 26, 2005 12:59 AM, Julien Wajsberg <[email protected]> wrote:
> >>>> I own an Asus A8N-Sli motherboard with the Nforce4-Sli chipset, and I
> >>>> experiment the following problem :
> >>>>
> >>>> Mar 25 22:42:55 evenflow kernel: hda: dma_timer_expiry: dma status == 0x60
> >>>> Mar 25 22:42:55 evenflow kernel: hda: DMA timeout retry
> >>>> Mar 25 22:42:55 evenflow kernel: hda: timeout waiting for DMA
> >>>> Mar 25 22:42:55 evenflow kernel: hda: status error: status=0x58 {
> >>>> DriveReady SeekComplete DataRequest }
> >>>> Mar 25 22:42:55 evenflow kernel:
> >>>> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> >>>> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> >>>> Mar 25 22:42:55 evenflow kernel: hda: status timeout: status=0xd0 { Busy }
> >>>> Mar 25 22:42:55 evenflow kernel:
> >>>> Mar 25 22:42:55 evenflow kernel: ide: failed opcode was: unknown
> >>>> Mar 25 22:42:55 evenflow kernel: hdb: DMA disabled
> >> ^^^^^^^^^^^^^^^^^
> >>>> Mar 25 22:42:55 evenflow kernel: hda: drive not ready for command
> >>>>
> >>>> Of course, if I disable DMA with hdparm, this problem disappear.. but
> >>>> it isn't a long-term solution ;-)
> >>>>
> >>
> >> The long-term solution is to replace either the drive, cable, or the
> >> motherboard that can't do DMA.
> > It's a recent drive that did ultra DMA on another motherboard, and a
> > recent motherboard with a cable that did ultra DMA before.It was ultra
> > DMA2 on this old motherboard, but it still was ultra DMA.
> >
> >> A bad DMA operation can write data
> >> anywhere (right into the middle of the kernel). There isn't
> >> anything software can do about it. Software sets up the
> >> controller for a DMA operation, then waits for an interrupt
> >> that tells it has completed or failed. Software can retry failed
> >> operations until software gets destroyed by the hardware, but
> >> there isn't anything else that can be done.
> >>
> >> The fact that disabling DMA makes the problem(s) go away is
> >> proof that it isn't a software problem. There are flash-RAM
> >> devices that emulate IDE drives. Most of these can't do DMA
> >> and the IDE driver doesn't accept that fact. That is a known
> >> bug. One needs to use hdparm to tell it to stop trying to
> >> use DMA. In your case, the driver stopped using DMA when
> >> it found out that it didn't work. There is no bug.
There still can be a bug in setting up DMA timings etc.
It is hard to even guess as you haven't given any details about your
system: dmesg/hdparm/lspci/config... (or I overlooked it somehow).
> > In my case, the driver stopped for hdb, that is my dvd-burner/player.
> > It did nothing for hda or hdc, I had to disable DMA myself.
> >
> > Will I have to install Windows XP to prove ultra DMA works correctly
> > on this setup ? I really don't hope...
That would be very helpful.
Another useful thing would be to try non-nVidia motherboard
(if you have one handy) without changing anything else.
Bartlomiej
On Apr 6, 2005 1:41 PM, Richard B. Johnson <[email protected]> wrote:
>
> How would you know? Windows will just run it as PIOW and be done
> with it.
Yes, but there's a way to know which mode you're using (maybe not
precisely, but at least PIO vs DMA).
> Did you ever try to copy a large file in XP? Try it.
> Try the same thing in linux on the same hardware. You don't need
> a stop-watch. On Win-XP, a 10 megabyte file (hardly large) takes
> about 10 seconds. That's 1 megabyte/second. Linux tries to be
> a bit faster.
Usually, I only have Linux on any hardware I have ;) And there is no
point comparing these things here...
--
Julien
PS: Sorry Richard, I forgot my "reply to all" button...
On Apr 6, 2005 6:02 PM, Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> There still can be a bug in setting up DMA timings etc.
>
> It is hard to even guess as you haven't given any details about your
> system: dmesg/hdparm/lspci/config... (or I overlooked it somehow).
I sent the related dmesg lines, and my .config.
for dmesg and .config :
http://marc.theaimsgroup.com/?l=linux-kernel&m=111179215521092&w=2
what part of lspci would you need ?
hdparm :
flash@evenflow:~$ sudo hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 6Y160P0, FwRev=YAR41BW0, SerialNo=Y47J8CRE
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: (null):
* signifies the current active mode
(it shows no mode... it's strange, because this drive should be nearly
the same as the following)
flash@evenflow:~$ sudo hdparm -i /dev/hdc
/dev/hdc:
Model=Maxtor 6Y120L0, FwRev=YAR41BW0, SerialNo=Y31LWCXE
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=240121728
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: (null):
* signifies the current active mode
flash@evenflow:~$ sudo hdparm -d /dev/hdc
/dev/hdc:
using_dma = 0 (off)
(Note : hdparm -i says 'udma6', and hdparm -d says 'no dma'...
Strange, isn't it ?)
> > > In my case, the driver stopped for hdb, that is my dvd-burner/player.
> > > It did nothing for hda or hdc, I had to disable DMA myself.
> > >
> > > Will I have to install Windows XP to prove ultra DMA works correctly
> > > on this setup ? I really don't hope...
>
> That would be very helpful.
I'll try that...
> Another useful thing would be to try non-nVidia motherboard
> (if you have one handy) without changing anything else.
I succesfully used these drives with another motherboard (PIIX4)
before, in udma2 mode, for years...
But first thing : I have to check if the cables are correctly plugged
in (I mean in the correct order)... I didn't have the time to do that
yet.
Thanks for your answer.
--
Julien