Fun with Ubuntu Gutsy and kernel 2.6.22 et al

Good morning, attached is my hsfdiag. The serial number's been stripped out
of it (by me) because license status is not my problem.

My problem is that the driver is quite unreliable. Interestingly, the
source-code driver is less reliable than the prepackaged one. I hope that
this can provide some insight into the problem.

The following is a kernel message I got today:

Oct 22 06:25:41 agamemnon kernel: [49775.292000] hda_intel: azx_get_response
timeout, switching to polling mode...

This is interesting because I watch network traffic with gkrellm and this
message came after a break in the download. Naturally, this is not very
scientific, because there are so many things which can affect such a
download. However, being on a modem means that you are rarely waiting on the
remote site; the opposite is generally true. In any case, then that error
occurred, followed by a second or so of no transfer, and then the download
picked back up again at the "full" rate - on my connection, about 3.1kB/sec
:(

I realize that I'm on the bleeding edge. Incidentally, I upgraded to
7.68.00.04 (from 7.68.00.01) because .01 didn't work on 2.6.22. I haven't
read the release notes or anything, so this is probably well-known and the
reason for the new release, but I thought I'd mention it anyway.

When on Feisty I had built myself a kernel with the 16k stacks patch. But
right now I need to do a lot of downloading before I can do any kernel
building. I hope to get that done today while I'm someplace with a superior
connection, and I'll see if it helps. I very much want to run the source
release of the driver, so that I can upgrade my kernel and have it maybe
work (it has in the past, though not going from 2.6.20 to 2.6.22. Still, no
plan is perfect.)

I sent a message in about my problems (I have and since feisty always have
had the "cnxthsf_OsEventWaitTime(ea6136e0/HDA CodecUnsolicitedmessage, 40):
returning OSEVENT_WAIT_TIMEOUT" problem) before upgrading to gutsy-rc, but
the first time I sent it in without gzipping the hsfdiag, so I cancelled
that one, then resent after gzipping it, and it was eaten by the listserver,
or at some intermediate point. So I am now sending a more complete report,
on a newer kernel.

Is this driver going to live in kernel space forever, or is it going to go
userspace? It seems like the whole linux world is heading towards a smaller
stack size for performance reasons.

_______________________________________________
hsflinux mailing list
[email protected]
https://www.linuxant.com/mailman/listinfo/hsflinux