We did some further testing this morning, and the news from our situation is not good. We purchased a second 5350 card from a second vendor. We tried to boot it up, and it behaved differently on my Dell laptop, but still refused to work. It no longer threw an error on the usb loading, but instead threw a different error. Here is the dmesg output: Nov 24 10:34:25 0973-kfries kernel: [ 420.538111] usb 1-4: configuration #1 chosen from 1 choice Nov 24 10:34:26 0973-kfries kernel: [ 420.707435] i2400m_usb 1-4:1.0: firmware: requesting i2400m-fw-usb-1.4.sbcf Nov 24 10:34:26 0973-kfries kernel: [ 421.060213] i2400m_usb: probe of 1-4:1.0 failed with error -5 But my Dell laptop is not the machine we ultimately need this to work on. So, we tried putting this onto our Intel Atom based prototypes. The new card failed on these prototypes exactly as before, 512b transfered out of 16k. I noticed that laptop had a 2.6.31-12 kernel, and the prototype had a 2.6.31-11. So, I did an upgrade on the kernel. It jumped all the way up to 2.6.31-15. Upon reboot, checked the error messages, and sure enough, the firmware transfer error was still there. This is now the 4th different build of the same Ubuntu kernel, and two different cards with identical results. Given the other issues found in Karmic, just for S&G, has anybody tried this card on a non-Ubuntu based 2.6.31 kernel such as Fedora 12? Seems to me that driver isn't the issue here... this is firmware, not driver. The firmware needs to be loaded so the device can be recognized by the driver. The errors above points more to a driver error, than the transfer message we have been following. Could it be something in Ubuntu's kernel compile settings and this particular piece of hardware that is causing an issue. This error sorta reminds me of the iPhones in reverse. Where Apple jacked with the USB handshaking and messed up everybody. In that case, the device was seen by Linux, but it could not talk to it... Driver/Handshaking problem. This is not getting that far before the catastrophic event. So, I repeat, could this be strictly an distro problem, and not a kernel or driver issue? Just asking, sometimes it too easy to overlook the obvious. Kevin Fries Senior Linux Engineer Computer and Communications Technology, Inc A division of Japan Communications Inc (303) 708-9228 x326 ________________________________________ From: wimax-bounces at linuxwimax.org [wimax-bounces at linuxwimax.org] On Behalf Of Inaky Perez-Gonzalez [inaky at linux.intel.com] Sent: Tuesday, November 24, 2009 2:33 PM To: Brandon Dell Cc: wimax at linuxwimax.org Subject: Re: Intel 5350: Getting 2.6.29 driver code to work in 2.6.31 kernel On Tue, 2009-11-24 at 07:29 -0800, Brandon Dell wrote: > Hi Inaky, > Since many of us are having problems getting the card's WiMax > functionality to work in kernels >= 2.6.30 I have started to explore > exactly where things went wrong in the driver code. I am new to this > type of work but thus far I have gotten a cluged version of 2.6.29.6 > code to compile in my 2.6.31.2 build environment (before it would fail > whenever I tried running 'make'). However, I am now seeing kernel > crashes having to do with "i2400m_dev_bootstrap" whenever I insert the > card. I have included my error message below for your reference: > Bad kludge? :) forward/backporting has many pitfalls. Use the compat-wimax tree for that (the tip of it). Actually, I hadn't thought about this. Get the compat-wimax.git tree, use the tip. Build it and install it in 2.6.29.6. Does it work ok? Then build it and install it in 2.6.30. Does it work ok? If it does, then the problem got introduced in the USB stack and somewhoe the driver code is not dealing with it properly, but it'd be way easier to do a bisection from .29 to .30. In any case, confirming. You are the one that had a Dell E5500? Or another laptop? Thanks, _______________________________________________ wimax mailing list wimax at linuxwimax.org http://lists.linuxwimax.org/listinfo/wimax
