Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

[Justin Piszcz]

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 intel.nics@intel.com could comment on this 
issue?

Thanks,

Justin.

Re: Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

[Justin Piszcz]

/usr/src/linux/Documentation//networking/e1000.txt:the issue to 
linux.nics@intel.com.

^^ 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 intel.nics@intel.com could comment on this 
> issue?
>
> Thanks,
>
> Justin.
>

Re: Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

[Lee Revell]

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

Re: Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

[Justin Piszcz]

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
>

Re: Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

[Jesse Brandeburg]

On 2/19/06, Justin Piszcz <jpiszcz@lucidpixels.com> 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

Re: Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

[Jesse Brandeburg]

On 2/19/06, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
> /usr/src/linux/Documentation//networking/e1000.txt:the issue to
> linux.nics@intel.com.
>
> ^^ 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

Re: Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

[Justin Piszcz]

> 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 <jpiszcz@lucidpixels.com> 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
>

Re: Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

[Justin Piszcz]

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 <jpiszcz@lucidpixels.com> 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
>

Re: Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

[Justin Piszcz]

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 <jpiszcz@lucidpixels.com> 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
>> 
>

Re: Intel CSA Gigabit Bug in IC7-G Motherboards- Affects Windows/Linux

[Jesse Brandeburg]

On 2/22/06, Justin Piszcz <jpiszcz@lucidpixels.com> 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