1969:1062 Hard freeze on large file transfers with Atheros AR8132 / L1c

Hi pablomme,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

As I mentioned in the report, I already tried kernel 2.6.33-02063303-generic.

Hi
I meet the same problem on a netbook asus eeepc 1201nl. When I download via transmission (with a consequent debit(flow): 350 Kb/) at the end of moment the computer congeals completely. I am obliged to stop(arrest) him(it) violently with the button of supply

If someone can help me. . .
thanks for your answer

As I mentioned in the dupicate bug, same problem here on a t60 using: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01). Before the hard freeze, I experience small intermittent temporary freezes (of less than half a second duration). If I disable the wireless when I start seeing those small ones, they dissapear and no hard freeze occurs, so this is definitely a regression related to ath5k.

Thanks!

I can confirm I am suffering the same freezes.

Machine boots up, wireless use , freeze in minutes.

This occurs to me on a IBM ThinkPad T60 with this NIC:

03:00.0 Ethernet controller: Atheros Communications Inc. AR5212 802.11abg NIC (rev 01)

these modules get to load:
lsmod | grep ath
ath5k 121976 0
mac80211 209734 1 ath5k
ath 8073 1 ath5k
cfg80211 130639 3 ath5k,mac80211,ath
led_class 2864 2 thinkpad_acpi,ath5k

I am having this problem with an eee 1201n, setting a large network download going (e.g. ISO images) will reliably freeze the system, no capslock or mouse movement possible.

lspci | grep thernet
09:00.0 Ethernet controller: Atheros Communications Atheros AR8132 / L1c Gigabit Ethernet Adapter (rev c0)

I have tried the latest source from Atheros, building the atl1e driver from the "AR81Family-Linux-v1.0.1.9" sources from http://partner.atheros.com/Drivers.aspx.
I still got a lockup 260Mb into a large file.
The Atheros notes suggest there can be a problem when you have 4Gb of memory - I have 2Gb. There are more options available about timings and memory usage, I will try and test some.

One of the related bugs suggested this may have been related to NTFS, but I duplicated the problem writing into an ext4 filesystem.

uname -a
Linux shire 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 06:07:29 UTC 2010 i686 GNU/Linux

[SOLVED] (I hope... I've now transfered 15Gb of data without a lockup, it usually locks after 250Mb)

I found a possible solution in http://kerneltrap.org/mailarchive/linux-netdev/2009/10/6/6256977/thread where Jay mentions to add pci=nomsi to the boot parameters.

To implement this I edited /etc/default/grub to include the following line:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux acpi_brightness=vendor pci=nomsi"
then ran update-grub2 as usual so that it took effect.

I have just remembered I am still running the atl1e source-built driver, I will try with the stock Ubuntu driver.

Am 20.08.2010 00:59, schrieb Tim Towers:
> [SOLVED] (I hope... I've now transfered 15Gb of data without a lockup,
> it usually locks after 250Mb)
>
> I found a possible solution in http://kerneltrap.org/mailarchive/linux-
> netdev/2009/10/6/6256977/thread where Jay mentions to add pci=nomsi to
> the boot parameters.

That would be perfect!

It thought that it could depend on my 64 Bit configuration an switched
back to 32bit yesterday.

But then I got a panic, again.

It seems to me that the panic only occurs if the network interfaces are
busy and additionally other data is transferred, e.g. over USB (onto my
external harddrive, it's NTFS, but that dousn't matter).

Therefore the pci=nomsi could be a rational solution, if large data
transfers between different PCI-devices blocks each other.

Thanks, I'll try it, too.

Philipp

I have reproduced the fix with the stock Ubuntu atl1c driver.

I have the same problem when copying files over LAN through SAMBA

I have the same problem when copying large files over LAN through SAMBA, FTP, NFS, WIFI,....

I have Ubuntu 10.10 installed on my netbook.

When the system freeze, i have to reboot the netbook in the hard way.

uname -a :
" Linux menegroth 2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010 i686 GNU/Linux "

Same with large transfert over ssh with asus 1201n on Maverick 10.10

Any solution ?

kernel option:
pci=nomsi

I also have this bug, and unfortunately the pci=nomsi not fixed completely. It helped a lot, and reduced the freezes. Now only 1-3 freezes/day instead of 3-4/hour, but it is still ridiculous.

Additionally I found a game (vdrift) what brings the lockup for five minutes after you start it. I'm not sure this lockup is the same, but I can't see differences. Magic keys are useless, the last few second of the sound repeats itself.
I even not sure this problem related to the network driver at all. I unloaded the driver, unplugged the UTP wire, and the game freezes my netbook just like before.

Currently my extra kernel parameters are: acpi_osi=Linux clocksource=hpet elevator=deadline acpi_backlight=vendor pci=nomsi
Ubuntu 10.10

Any idea?

bug still reproduced with kernel option pci=nomsi. Asus 1201 NL with Atheros ethernet card. Sometimes it frezzes after 4 Gb sometimes after 400Mb. googling does nothinng =(

pablomme, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in the development release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. As well, please comment on which kernel version specifically you tested.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream', and comment as to why specifically you were unable to test it.

Please let us know your results. Thanks in advance.

Unfortunately I don't have the netbook in question any more. Could any of the 19 other people who have declared themselves "affected" give Quantal a quick test at transferring a few GiB over ethernet?

pablomme, it is not desired for someone other than the original reporter to post attachments, comments, or debugging information. For more on this please see both https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported and https://help.ubuntu.com/community/ReportingBugs#Adding_Apport_Debug_Information_to_an_Existing_Launchpad_Bug . Instead, they should file a new report. Hence, this bug report is being closed due to your last comment regarding how you no longer have the hardware. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Are you serious?

Really?

I gave my netbook away because of this bug.

If it isn't "desired for someone other than the original reporter to post attachments, comments, or debugging information", then you may have to allow everyone to open a bug report for the same bug.

This is just stupid - there was a kernel FREEZE bug in Ubuntu in 2010 and you aren't even interested if it doesn't exist in current releases?

It's bug-reporting policy for hardware-specific bugs (which I didn't know about). I find it sensible, since interactions between different hardware components are likely to affect the behaviour of the system, although it has the downside that in many instances the multiple bug reports will be unnecessary. I don't understand the "no comments" policy though.

In any case, could someone then file a new bug report against the linux package from a quantal liveCD image (if it still exists) and link it in a comment here so that other people know what's going on?