[jggimi]

Recommendations:

1. Obtain a dmesg. Since you do not have a network connection, you'll have to place the file on external media, per FAQ 4.15. That FAQ doesn't tell you that you can use a USB stick as another method for obtaining it. When you insert a stick it you should see blue kernel messages that tell you which virtual SCSI device it is. If it is formatted for a FAT (windows) filesystem it will automatically be assigned partition "i" on the SCSI device. To obtain your dmesg, just mount it and send the dmesg output to a file you can copy and paste while in another OS. If you're using Windows, make the text file type ".wri" so that the file does not require Microsoft's ancient CR/LF bytes at the end of each line. (You can open it with WordPad, which is included with Windows.)
   
   This example assumes a USB stick formatted FAT is assigned SCSI device #0 (sd0):
   
   # mount -t msdos /dev/sd0i /mnt
   # dmesg > /mnt/dmesg.wri
   # umount /mnt
   
   We may, or may not, see something of value within your dmesg. But it will be required should you wish to formally make a bug report, and may prove valuable here. Hopefully, there will be something in the dmesg (such as a chipset involved with your Atheros-compatible NIC) that leads to a solution.
2. Hanging systems can be forced to enter the ddb(4) kernel debugger, from which diagnostic data can be obtained. The diagnostic data can sometimes point to the specific problem. This is not recommended for the newbie, unless the newbie is already comfortable with *nix kernel debugging.
   
   Pre-planning is required: One needs sufficient swap space and space in /var. One must set the sysctl "ddb.console" to 1 in advance. Then after the hang, either typing a kernel break sequence or issuing a BREAK from a serial console, then issuing a series of ddb commands to collect backtraces, then forcing a crash dump, then on reboot obtaining a good copy of the dump in /var/crash, then using dmesg(8) to examine the backtraces in the dmesg in the dump, followed by using gdb(1) to diagnose the kernel operations. A custom kernel compilation with symbols is necessary to make the gdb(1) output understandable. Some additional help can be found in crash(8) for gdb(1) use, and FAQ 5 describes kernel build procedures. If you feel comfortable with all this, you will be able to conduct your own diagnosis.