Apparently, A-BIT's Intel driver works for some people, but the Linux one
causes the machine to crash. The same is also true if you use the driver
from Intel's website. I was just wondering if there was any discussion on
this list concerning this issue?
I have 4 ABIT IC7-G's and this problem only occurs on two of them, which I
have disabled the onboard CSA gigabit nic and put in PCI NICS (intel
gigabit) with no problems.
It appears there are some serious problems with Intel CSA GIGABIT with
this motherboard, just curious to see if anyone out there heard anything
about this?
The interesting part is the first page of this thread:
http://forum.abit-usa.com/showthread.php?t=18707
The author has a "death.zip" file, in which if you copy the file over the
LAN it causes an instant crash. He's tried contacting A-Bit, but is it an
A-Bit or Intel or Driver problem as it has been "reported" to work with
A-Bit's driver.
I believe this post sums up the problems of IC7-G problems:
--
Yeah, can't have it all, can we? I had serious thoughts about RMA-ing my
IC7-G last fall, but the 4 week tournaround was a bit too much downtime
for my taste. To resolve the noisy mic-input issue, I bought a cheap
soundcard. For the onboard CSA, I did nothing. Running at 1GbE, the NIC
has worked very well, disregarding the numerous occations it has strangled
my system to death, of course.
I feel sorry for you Sydtech, myself and everyone else out there ripping
their hair out over the issues of the IC7. We have spent countless hours
trying to figure out what's wrong, worrying about a lengthy RMA process
and the adherent downtime - which in Sydtech's case just as well might
result in a shabby refurbished MB fixing some problems, but adding others.
Many of us have simply resorted to buying PCI add-in cards replacing the
dysfunctional parts of the IC7.
We have paid the bill for ABIT's engineering shortcomings, not to mention
wasting a lot of time and energy. Last spring I was looking for a MB for
my new system. I wanted the best and with as many onboard functions as
possible so I could have a less crammed case. I read all the reviews for
the new i875 MB:s, where - for instance - HardOCP praised it, especially
it's superiour sound quality (they did not even try the mic-input).
Needless to say, I ended up with the expensive IC7-G, "cream of the crop"
and bucketsful of headache.
Alright, so add-in cards cramming up our cases seem to be the easiest way
to get the subsystems we've already payed for. But what's really
infuriating is that ABIT just refuses to address the issues. No helping
hand, no suggestions on how to get things right. They just keep ignoring
us. Of course they read the forums, they just think keeping things quiet
is their best strategy.
Well, anyhow, I have my strategy worked out for future technology
acquisitions: I'll NEVER again buy first revision products the minute they
come out. I refuse to again be an unpaid beta tester for an ungrateful and
unhelpful manufacturer like ABIT. And I will also take reviews with loads
of salt.
--
I was wondering if anyone from [email protected] could comment on this
issue?
Thanks,
Justin.
/usr/src/linux/Documentation//networking/e1000.txt:the issue to
[email protected].
^^ That e-mail is invalid, someone should make a diff/patch to remove it
and update it if there is a correct one or just remove it entirely.
Justin.
As of 2.6.15.3 source.
On Sun, 19 Feb 2006, Justin Piszcz wrote:
> Apparently, A-BIT's Intel driver works for some people, but the Linux one
> causes the machine to crash. The same is also true if you use the driver
> from Intel's website. I was just wondering if there was any discussion on
> this list concerning this issue?
>
> I have 4 ABIT IC7-G's and this problem only occurs on two of them, which I
> have disabled the onboard CSA gigabit nic and put in PCI NICS (intel gigabit)
> with no problems.
>
> It appears there are some serious problems with Intel CSA GIGABIT with this
> motherboard, just curious to see if anyone out there heard anything about
> this?
>
> The interesting part is the first page of this thread:
>
> http://forum.abit-usa.com/showthread.php?t=18707
>
> The author has a "death.zip" file, in which if you copy the file over the LAN
> it causes an instant crash. He's tried contacting A-Bit, but is it an A-Bit
> or Intel or Driver problem as it has been "reported" to work with A-Bit's
> driver.
>
> I believe this post sums up the problems of IC7-G problems:
>
> --
>
> Yeah, can't have it all, can we? I had serious thoughts about RMA-ing my
> IC7-G last fall, but the 4 week tournaround was a bit too much downtime for
> my taste. To resolve the noisy mic-input issue, I bought a cheap soundcard.
> For the onboard CSA, I did nothing. Running at 1GbE, the NIC has worked very
> well, disregarding the numerous occations it has strangled my system to
> death, of course.
>
> I feel sorry for you Sydtech, myself and everyone else out there ripping
> their hair out over the issues of the IC7. We have spent countless hours
> trying to figure out what's wrong, worrying about a lengthy RMA process and
> the adherent downtime - which in Sydtech's case just as well might result in
> a shabby refurbished MB fixing some problems, but adding others. Many of us
> have simply resorted to buying PCI add-in cards replacing the dysfunctional
> parts of the IC7.
>
> We have paid the bill for ABIT's engineering shortcomings, not to mention
> wasting a lot of time and energy. Last spring I was looking for a MB for my
> new system. I wanted the best and with as many onboard functions as possible
> so I could have a less crammed case. I read all the reviews for the new i875
> MB:s, where - for instance - HardOCP praised it, especially it's superiour
> sound quality (they did not even try the mic-input). Needless to say, I ended
> up with the expensive IC7-G, "cream of the crop" and bucketsful of headache.
>
> Alright, so add-in cards cramming up our cases seem to be the easiest way to
> get the subsystems we've already payed for. But what's really infuriating is
> that ABIT just refuses to address the issues. No helping hand, no suggestions
> on how to get things right. They just keep ignoring us. Of course they read
> the forums, they just think keeping things quiet is their best strategy.
>
> Well, anyhow, I have my strategy worked out for future technology
> acquisitions: I'll NEVER again buy first revision products the minute they
> come out. I refuse to again be an unpaid beta tester for an ungrateful and
> unhelpful manufacturer like ABIT. And I will also take reviews with loads of
> salt.
>
> --
>
> I was wondering if anyone from [email protected] could comment on this
> issue?
>
> Thanks,
>
> Justin.
>
On Sun, 2006-02-19 at 18:17 -0500, Justin Piszcz wrote:
>
> The author has a "death.zip" file, in which if you copy the file over
> the
> LAN it causes an instant crash.
Windows and Linux? What kind of "crash"? An Oops? Lockup? Reboot?
Anything in the logs?
Your report is way too vague to be actionable.
Lee
Essentially, when you copy large amounts of data across the NIC it will
"freeze" the box in Linux (any 2.6.x kernel, have not tried 2.4.x) or
Windows XP SP2.
If you checkout the thread, it occurs for multiple people under various
OS' but in *some* cases if they use ABIT's IC7-G CSA/INTEL driver, they
their problems go away.
In Linux when I used to use the onboard NIC, it froze the box, I did not
have sysrq enabled at the time when this happened but frozen I mean screen
is frozen, no ping, box is inoperative.
Nothing pecuilar was ever found in any of the logs or dmesg output
regarding the crash.
Basically its the first revision of CSA gigabit on a motherboard from what
I read in the forums and unless you use ABIT's specially crafted driver,
it will crash the machine when you copy either:
a) large amounts of data over a gigabit link
or
b) that death.zip file (unzipped of course) which contains the bad "bits"
that are probably seen/repeated when copying large amounts of data
Justin.
On Sun, 19 Feb 2006, Lee Revell wrote:
> On Sun, 2006-02-19 at 18:17 -0500, Justin Piszcz wrote:
>>
>> The author has a "death.zip" file, in which if you copy the file over
>> the
>> LAN it causes an instant crash.
>
> Windows and Linux? What kind of "crash"? An Oops? Lockup? Reboot?
> Anything in the logs?
>
> Your report is way too vague to be actionable.
>
> Lee
>
On 2/19/06, Justin Piszcz <[email protected]> wrote:
> Essentially, when you copy large amounts of data across the NIC it will
> "freeze" the box in Linux (any 2.6.x kernel, have not tried 2.4.x) or
> Windows XP SP2.
I've heard isolated reports about issues with the CSA connected NIC,
but we've not been able to reproduce much in our labs and (mostly)
people haven't been complaining about it.
> If you checkout the thread, it occurs for multiple people under various
> OS' but in *some* cases if they use ABIT's IC7-G CSA/INTEL driver, they
> their problems go away.
> In Linux when I used to use the onboard NIC, it froze the box, I did not
> have sysrq enabled at the time when this happened but frozen I mean screen
> is frozen, no ping, box is inoperative.
Have you tried running without NAPI? (disable it in your config in the
e1000 section)
> Nothing pecuilar was ever found in any of the logs or dmesg output
> regarding the crash.
>
> Basically its the first revision of CSA gigabit on a motherboard from what
> I read in the forums and unless you use ABIT's specially crafted driver,
> it will crash the machine when you copy either:
>
> a) large amounts of data over a gigabit link
> or
> b) that death.zip file (unzipped of course) which contains the bad "bits"
> that are probably seen/repeated when copying large amounts of data
I'll have our lab attempt to reproduce the bug (again) this time using
the special file. I can't speak to the windows crash, sorry.
please send your .config, cat /proc/interrupts, dmesg after driver is
up, whether NAPI is on, what exact steps you use to reproduce the
problem, what your environment is (i.e. copying to a windows server,
etc) pretty much follow the instructions in
http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
Jesse
On 2/19/06, Justin Piszcz <[email protected]> wrote:
> /usr/src/linux/Documentation//networking/e1000.txt:the issue to
> [email protected].
>
> ^^ That e-mail is invalid, someone should make a diff/patch to remove it
> and update it if there is a correct one or just remove it entirely.
>
> Justin.
>
> As of 2.6.15.3 source.
Agreed, I have an update pending in my queue but got lost in git-land
> Have you tried running without NAPI? (disable it in your config in the
> e1000 section)
I have always used NAPI, I will test this later today and let you know the
results with NAPI off, thanks.
Is there anything I need to be aware of using a CSA-based ethernet device
vs. no CSA?
Thanks,
Justin.
On Sun, 19 Feb 2006, Jesse Brandeburg wrote:
> On 2/19/06, Justin Piszcz <[email protected]> wrote:
>> Essentially, when you copy large amounts of data across the NIC it will
>> "freeze" the box in Linux (any 2.6.x kernel, have not tried 2.4.x) or
>> Windows XP SP2.
>
> I've heard isolated reports about issues with the CSA connected NIC,
> but we've not been able to reproduce much in our labs and (mostly)
> people haven't been complaining about it.
>
>> If you checkout the thread, it occurs for multiple people under various
>> OS' but in *some* cases if they use ABIT's IC7-G CSA/INTEL driver, they
>> their problems go away.
>
>> In Linux when I used to use the onboard NIC, it froze the box, I did not
>> have sysrq enabled at the time when this happened but frozen I mean screen
>> is frozen, no ping, box is inoperative.
>
> Have you tried running without NAPI? (disable it in your config in the
> e1000 section)
>
>> Nothing pecuilar was ever found in any of the logs or dmesg output
>> regarding the crash.
>>
>> Basically its the first revision of CSA gigabit on a motherboard from what
>> I read in the forums and unless you use ABIT's specially crafted driver,
>> it will crash the machine when you copy either:
>>
>> a) large amounts of data over a gigabit link
>> or
>> b) that death.zip file (unzipped of course) which contains the bad "bits"
>> that are probably seen/repeated when copying large amounts of data
>
> I'll have our lab attempt to reproduce the bug (again) this time using
> the special file. I can't speak to the windows crash, sorry.
>
> please send your .config, cat /proc/interrupts, dmesg after driver is
> up, whether NAPI is on, what exact steps you use to reproduce the
> problem, what your environment is (i.e. copying to a windows server,
> etc) pretty much follow the instructions in
> http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
>
> Jesse
>
Dreadful Denial of Service!!
Here is the story.
1) NAPI = ENABLED, The kernel does not crash IMMEDIATELY.
2) NAPI = DISABLED, KILLS THE VIDEO, FORCES AN IMMEDIATE REBOOT OF THE BOX
Note: When I leave the cp trying to copy the death.dat, my box hangs, will
not come up, has other problems UNTIL I disconnect or reboot the box that
originally did the cp file /nfs/directory.
The good: I got a dump of what was in dmesg before it locked up in #1.
The bad: I could do nothing in #2, it simply was like someone pressed the
reboot button on my machine!!!
Here is the log:
$ cp .stuff/mobo/death.dat /p34/x
.. then I get these in dmesg ..
then > 60 seconds the box is frozen
.. ..
Here is from part #1:
[ 251.277315] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[ 251.277317] TDH <af>
[ 251.277318] TDT <b3>
[ 251.277319] next_to_use <b3>
[ 251.277320] next_to_clean <af>
[ 251.277320] buffer_info[next_to_clean]
[ 251.277321] dma <36970802>
[ 251.277322] time_stamp <ffff4113>
[ 251.277323] next_to_watch <af>
[ 251.277324] jiffies <ffff485c>
[ 251.277325] next_to_watch.status <0>
[ 253.274703] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[ 253.274704] TDH <af>
[ 253.274706] TDT <b3>
[ 253.274706] next_to_use <b3>
[ 253.274707] next_to_clean <af>
[ 253.274708] buffer_info[next_to_clean]
[ 253.274709] dma <36970802>
[ 253.274710] time_stamp <ffff4113>
[ 253.274711] next_to_watch <af>
[ 253.274712] jiffies <ffff502d>
[ 253.274713] next_to_watch.status <0>
[ 255.270969] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[ 255.270971] TDH <af>
[ 255.270972] TDT <b3>
[ 255.270973] next_to_use <b3>
[ 255.270974] next_to_clean <af>
[ 255.270975] buffer_info[next_to_clean]
[ 255.270976] dma <36970802>
[ 255.270977] time_stamp <ffff4113>
[ 255.270978] next_to_watch <af>
[ 255.270979] jiffies <ffff57fc>
[ 255.270980] next_to_watch.status <0>
[ 257.267361] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[ 257.267363] TDH <af>
[ 257.267364] TDT <b3>
[ 257.267365] next_to_use <b3>
[ 257.267366] next_to_clean <af>
[ 257.267367] buffer_info[next_to_clean]
[ 257.267368] dma <36970802>
[ 257.267369] time_stamp <ffff4113>
[ 257.267370] next_to_watch <af>
[ 257.267371] jiffies <ffff5fcc>
[ 257.267372] next_to_watch.status <0>
[ 258.248353] NETDEV WATCHDOG: eth0: transmit timed out
[ 261.321533] e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps
Full Duplex
On Sun, 19 Feb 2006, Jesse Brandeburg wrote:
> On 2/19/06, Justin Piszcz <[email protected]> wrote:
>> Essentially, when you copy large amounts of data across the NIC it will
>> "freeze" the box in Linux (any 2.6.x kernel, have not tried 2.4.x) or
>> Windows XP SP2.
>
> I've heard isolated reports about issues with the CSA connected NIC,
> but we've not been able to reproduce much in our labs and (mostly)
> people haven't been complaining about it.
>
>> If you checkout the thread, it occurs for multiple people under various
>> OS' but in *some* cases if they use ABIT's IC7-G CSA/INTEL driver, they
>> their problems go away.
>
>> In Linux when I used to use the onboard NIC, it froze the box, I did not
>> have sysrq enabled at the time when this happened but frozen I mean screen
>> is frozen, no ping, box is inoperative.
>
> Have you tried running without NAPI? (disable it in your config in the
> e1000 section)
>
>> Nothing pecuilar was ever found in any of the logs or dmesg output
>> regarding the crash.
>>
>> Basically its the first revision of CSA gigabit on a motherboard from what
>> I read in the forums and unless you use ABIT's specially crafted driver,
>> it will crash the machine when you copy either:
>>
>> a) large amounts of data over a gigabit link
>> or
>> b) that death.zip file (unzipped of course) which contains the bad "bits"
>> that are probably seen/repeated when copying large amounts of data
>
> I'll have our lab attempt to reproduce the bug (again) this time using
> the special file. I can't speak to the windows crash, sorry.
>
> please send your .config, cat /proc/interrupts, dmesg after driver is
> up, whether NAPI is on, what exact steps you use to reproduce the
> problem, what your environment is (i.e. copying to a windows server,
> etc) pretty much follow the instructions in
> http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
>
> Jesse
>
Jesse,
Any idea what is going on? MB defect? Driver defect?
Justin.
On Mon, 20 Feb 2006, Justin Piszcz wrote:
> Dreadful Denial of Service!!
>
> Here is the story.
>
> 1) NAPI = ENABLED, The kernel does not crash IMMEDIATELY.
> 2) NAPI = DISABLED, KILLS THE VIDEO, FORCES AN IMMEDIATE REBOOT OF THE BOX
>
> Note: When I leave the cp trying to copy the death.dat, my box hangs, will
> not come up, has other problems UNTIL I disconnect or reboot the box that
> originally did the cp file /nfs/directory.
>
> The good: I got a dump of what was in dmesg before it locked up in #1.
> The bad: I could do nothing in #2, it simply was like someone pressed the
> reboot button on my machine!!!
>
> Here is the log:
>
> $ cp .stuff/mobo/death.dat /p34/x
>
> .. then I get these in dmesg ..
>
> then > 60 seconds the box is frozen
>
> .. ..
>
>
>
> Here is from part #1:
>
> [ 251.277315] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [ 251.277317] TDH <af>
> [ 251.277318] TDT <b3>
> [ 251.277319] next_to_use <b3>
> [ 251.277320] next_to_clean <af>
> [ 251.277320] buffer_info[next_to_clean]
> [ 251.277321] dma <36970802>
> [ 251.277322] time_stamp <ffff4113>
> [ 251.277323] next_to_watch <af>
> [ 251.277324] jiffies <ffff485c>
> [ 251.277325] next_to_watch.status <0>
> [ 253.274703] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [ 253.274704] TDH <af>
> [ 253.274706] TDT <b3>
> [ 253.274706] next_to_use <b3>
> [ 253.274707] next_to_clean <af>
> [ 253.274708] buffer_info[next_to_clean]
> [ 253.274709] dma <36970802>
> [ 253.274710] time_stamp <ffff4113>
> [ 253.274711] next_to_watch <af>
> [ 253.274712] jiffies <ffff502d>
> [ 253.274713] next_to_watch.status <0>
> [ 255.270969] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [ 255.270971] TDH <af>
> [ 255.270972] TDT <b3>
> [ 255.270973] next_to_use <b3>
> [ 255.270974] next_to_clean <af>
> [ 255.270975] buffer_info[next_to_clean]
> [ 255.270976] dma <36970802>
> [ 255.270977] time_stamp <ffff4113>
> [ 255.270978] next_to_watch <af>
> [ 255.270979] jiffies <ffff57fc>
> [ 255.270980] next_to_watch.status <0>
> [ 257.267361] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
> [ 257.267363] TDH <af>
> [ 257.267364] TDT <b3>
> [ 257.267365] next_to_use <b3>
> [ 257.267366] next_to_clean <af>
> [ 257.267367] buffer_info[next_to_clean]
> [ 257.267368] dma <36970802>
> [ 257.267369] time_stamp <ffff4113>
> [ 257.267370] next_to_watch <af>
> [ 257.267371] jiffies <ffff5fcc>
> [ 257.267372] next_to_watch.status <0>
> [ 258.248353] NETDEV WATCHDOG: eth0: transmit timed out
> [ 261.321533] e1000: eth0: e1000_watchdog_task: NIC Link is Up 1000 Mbps
> Full Duplex
>
>
>
> On Sun, 19 Feb 2006, Jesse Brandeburg wrote:
>
>> On 2/19/06, Justin Piszcz <[email protected]> wrote:
>>> Essentially, when you copy large amounts of data across the NIC it will
>>> "freeze" the box in Linux (any 2.6.x kernel, have not tried 2.4.x) or
>>> Windows XP SP2.
>>
>> I've heard isolated reports about issues with the CSA connected NIC,
>> but we've not been able to reproduce much in our labs and (mostly)
>> people haven't been complaining about it.
>>
>>> If you checkout the thread, it occurs for multiple people under various
>>> OS' but in *some* cases if they use ABIT's IC7-G CSA/INTEL driver, they
>>> their problems go away.
>>
>>> In Linux when I used to use the onboard NIC, it froze the box, I did not
>>> have sysrq enabled at the time when this happened but frozen I mean screen
>>> is frozen, no ping, box is inoperative.
>>
>> Have you tried running without NAPI? (disable it in your config in the
>> e1000 section)
>>
>>> Nothing pecuilar was ever found in any of the logs or dmesg output
>>> regarding the crash.
>>>
>>> Basically its the first revision of CSA gigabit on a motherboard from what
>>> I read in the forums and unless you use ABIT's specially crafted driver,
>>> it will crash the machine when you copy either:
>>>
>>> a) large amounts of data over a gigabit link
>>> or
>>> b) that death.zip file (unzipped of course) which contains the bad "bits"
>>> that are probably seen/repeated when copying large amounts of data
>>
>> I'll have our lab attempt to reproduce the bug (again) this time using
>> the special file. I can't speak to the windows crash, sorry.
>>
>> please send your .config, cat /proc/interrupts, dmesg after driver is
>> up, whether NAPI is on, what exact steps you use to reproduce the
>> problem, what your environment is (i.e. copying to a windows server,
>> etc) pretty much follow the instructions in
>> http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
>>
>> Jesse
>>
>
On 2/22/06, Justin Piszcz <[email protected]> wrote:
> Jesse,
>
> Any idea what is going on? MB defect? Driver defect?
well, no-napi shouldn't fail any worse than napi, so that may well be
a driver bug. Lets follow up offline or at mailing list e1000-devel %
lists.sf.net
otherwise no idea. There are a lot of people using these boards
without issues, it seems that ABIT even has some of this same board
that work for some people. If you can find someone that has one that
works you might try comparing your ethtool -e output to theirs. If you
change your eeprom however, thats you taking risks on your own, and we
can't support you. But it might be a useful thing to know, to give
more information to ABIT.
Jesse