VT6656 wireless chipset is unsupported

[Forest Bond]

VIA has released driver source without a license. Please take a few minutes to post to viaarena encouraging VIA to re-release the driver with an appropriate license included:

http://forums.viaarena.com/messageview.aspx?catid=28&threadid=78745

This is probably the quickest way to get support for this chipset.

[Forest Bond (forest-bond)]

I've added some text to my website explaing the issue:

http://www.alittletooquiet.net/text/a-license-for-the-via-vt6656-linux-driver/

It would be good if we could generate a little noise to get some attention for this issue.

Thanks!

-Forest

[Leann Ogasawara (leannogasawara)]

Hi Forest,

Thank you for this information. However, this isn't the most appropriate forum to get your message across. These reports are meant to target bugs for code that already exists in the distribution. Thanks.

[Forest Bond (forest-bond)]

Isn't unsupported hardware a bug? It qualifies as a bug in most other cases. It should work, but it doesn't. That sounds like a bug to me.

[Leann Ogasawara (leannogasawara)]

Hi Forest,

My apologies if I misinterpreted your report. The original comments you made seemed more like a plea for publicity. I'll retarget your request toward the upcoming Hardy kernel and have tagged this as "hardy-kernel-candidate". Thanks.

[Forest Bond (forest-bond)]

Hi Leann,

It just so happens that publicity may, in fact, be the best way to fix this bug (or at least get the ball rolling :)

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[Ra'id Jamali (raid-aljamali)]

The latest source files contain a GPL license.
Version 1.19.12
Dated 02 February 2009
http://www.viaarena.com/Driver/VT6656_Linux_src_v1.19_12_x86.zip

It compiles successfully under Jaunty. Have not installed it yet though.

[Forest Bond (forest-bond)]

Thanks for noticing this Ra'id.

Both the VT6656 and the VT6655 drivers have now been released with GPL licenses. I'm working with kernel developers to get these drivers integrated.

Thanks,
Forest

[Ra'id Jamali (raid-aljamali)]

With pleasure. Of course kernel integration would be great.

Yet with dkms now easily available, we may already have a sufficient
(temporary) autoinstall solution. The compilation for VT6656 appears quite
straightforward. I'm guessing minor mods to the Makefile and a short
dkms.conf would do the trick. If I didn't find makefiles intimidating, I
would have taken this route for my install!

[Alex1024 (aneptun)]

I use Ubuntu 9.04 RC1 and the new Zotac 9300 itx board with VT6656 wireless module.
I compiled and installed the new driver 1.19.12.
But the system freezes when run gdm... whats wrong?
Thanks.

[raulmuaddib (raulmuaddib)]

I'm having a problem too, I thought this was going to be driver that would be integrated into the kernel. My wireless did not work with the RC. Will it work with the Final Release?

[raulmuaddib (raulmuaddib)]

Opps, I meant to put that I also use the Zotac 9300 ITX with VT6656.

[Forest Bond (forest-bond)]

Hi,

On Fri, Apr 24, 2009 at 03:44:03PM -0000, raulmuaddib wrote:
> I'm having a problem too, I thought this was going to be driver that
> would be integrated into the kernel. My wireless did not work with the
> RC. Will it work with the Final Release?

A new driver with a proper license was released. I am working with kernel
developers to get it into the staging area, however, it will most certainly not
be in Ubuntu 9.04.

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[LuisV (luisvivasb)]

I have the same problem with VT6656, my system is Ubuntu Remix 9.04 (jaunty), kernel 2.26.28-11-generic

[Jorge Juan (jjchico)]

Hi,

I have just produced a DKMS version of the latest driver. I have uploaded to my PPA but I have not tested it yet on my Netbook. I hope it works for you.

https://edge.launchpad.net/~jjchico/+archive/ppa

[Alex1024 (aneptun)]

DKMS version doesnt work, its freeze the system when X started (the same effect with the compiled driver).. perhaps some other module conflicts wiht this driver? (Zotac 9300 ITX Mainboard VT6656 Module)
Thanks for work :)

[Jorge Juan (jjchico)]

The DKMS package works for me. Compilation from the source also worked.

Please check you have the right hardware. In my case, "lsusb -v" reports:

Bus 002 Device 002: ID 160a:3184
...
 iProduct 2 VNT USB-802.11 Wireless LAN Adapter
...

Good luck.

jorge.

[Jochen (jradmacher)]

Works for me with jaunty.

The driver does not work with kernel 2.6.30 (karmic).
"netdev->priv" has been replaced with "netdev_priv(netdev)" in this kernel.

[benbois (boisbenjamin)]

I created a package driver on Ubuntu Jaunty (9.04) 64 bits with a kernel 2.6.28-13.
After installation, the system freezes during the X/Gnome starting.
MB: Zotac 9300 ITX

See you
--
Ben

[Jim Lieb (lieb)]

Forward porting to Karmic for testing. A number of issues were found, including 32<->64 bit bugs that would indeed crash things. This code as a ways to go in order to be merged and supported.

[Forest Bond (forest-bond)]

Jim,

Take note, this driver has been merged into drivers/staging on linux-next. If you are going to do any work on it, please do so there. Greg KH has been handling my patches there.

Thanks,
Forest

[Forest Bond (forest-bond)]

Jim,

BTW, the versions in staging do compile, no need to forward port.

Thanks,
Forest

[Jim Lieb (lieb)]

@Forrest,
I get the bug because I am on the kernel team and we get *all* of these things... ;)

I got it to compile in staging in our ubuntu-karmic git. It would not compile for 64 bit .31rc2 because the code fell into
 the sizeof(int) == sizeof(void *) trap. I fixed these by using the support fctns and macros. I have attached the diff of what I have done so far. This builds on amd64 now which is crucial for moving from staging to mainline.

In looking at the driver style, it would appear that there is an attempt to have a common code base for a number of O/S platforms. Is this true? Is there a VIA business reason for this? I don't have a personal preference one way or the other and VIA may have a good business reasons but this can be an impediment to its acceptance. I ran checkpatch.pl against this driver and it generated ~ 20-30k errors/warnings. I've coded C for a very long time and have seen lots of "styles" come and go so I am reluctant to dictate to someone else where the curly brackets *must* go but I suggest that it would be easier on inclusion if the author or maintainer gets this more in line with the Linux coding standard. I scanned thru the checkpatch output and C99 comments and indent/tab are the bulk of the 98k+ lines of error/warning followed by typedef usage that the kernel maintainers strongly discourage. The C99 comments and indent style can be easily changed by a sed script and one of the numerous "prettyprint" formatters. The result would be able to go through more compilers and become more acceptable to the developer community. Some of these typedef'd structures mimic already defined ones in the rest of the driver tree and are therefore compatibility mis-match candidates at a later date. One of the reasons Linus and the core maintainers descourage this practice is it is a source of silent incompatibility breakage when the surrounding kernel code evolves. If these could be shifted to use the shared definitions in the same way that I made changes in the diff, the code would retain better portability as the rest of the kernel evolves. If you look closely at the definition of skb_reset_mac_header, you will see what I mean. This transparently handles a space optimization on 64 bit kernels that converts a pointer usage to an offset+base pointer. This is what broke the non-ia32 builds. There is also some dead code (for various reasons) that should probably be trimmed. If there is an engineering/business reason for accomodating more O/S environments/APIs than Linux, this could be re-factored to get the common code more in one place. The re-definition of various kernel APIs to add another level of definition re-direction to get this cross-O/S is a prime example where it would be better to refactor into O/S specific and common code modules and keep the *real* interfaces as-is. It has been my experience that using this coding style to get cross platform portability is not as successful as a re-factor. If cross-platform is not really an issue, it would be best to strip this extra out completely.

I also fixed a potential suspend bug where the error return was not being propagated back. I have a FIXME comment...

[Forest Bond (forest-bond)]

Hi Jim,

On Tue, Jul 14, 2009 at 06:27:18PM -0000, Jim Lieb wrote:
> I got it to compile in staging in our ubuntu-karmic git. It would not compile
> for 64 bit .31rc2 because the code fell into the sizeof(int) == sizeof(void *)
> trap. I fixed these by using the support fctns and macros. I have attached
> the diff of what I have done so far. This builds on amd64 now which is
> crucial for moving from staging to mainline.

Great, thanks for doing this.

> In looking at the driver style, it would appear that there is an attempt
> to have a common code base for a number of O/S platforms. Is this true?
> Is there a VIA business reason for this?

I don't know. I don't think there's any value to the community in maintaining
this. VIA apparently does not have resources to assist with development or
maintenance of VT6655 or VT6656 in-tree drivers. I don't think they have any
interest in what we do here.

> I ran checkpatch.pl against this driver and it generated ~ 20-30k
> errors/warnings. I've coded C for a very long time and have seen lots of
> "styles" come and go so I am reluctant to dictate to someone else where the
> curly brackets *must* go but I suggest that it would be easier on inclusion if
> the author or maintainer gets this more in line with the Linux coding
> standard.

Agreed that coding style issues should be addressed. Your other comments
regarding typedefs, etc., sound reasonable to me. I do hope that they can be
addressed.

> I also fixed a potential suspend bug where the error return was not
> being propagated back. I have a FIXME comment in the resume to flag a
> similar problem.

Noted, thanks.

> As for carrying this in Karmic, we prefer that the driver at least be
> "on its way" out of staging before we consider it for inclusion. This
> keeps the not-inconsiderable maintenance cost of an non-mainstream patch
> and its churn to a minimum. Drivers/modules that come into the kernel
> this way also don't get lost as we rebase the kernel at each release
> cycle. I think the best way forward is for the developer to take this
> input, generate patches to staging to get it moving forward into a
> mainline merge. We can help with that effort by providing input/review.
> I do not have this device so I can't really test it myself. We will
> obviously help shepherd the patch into Ubuntu at the appropriate time.
> Keep me posted on progress through this bug. I can continue helping
> with integration at this end. I would also encourage the developer to
> get a Launchpad account and be part of the conversation.

The original author(s) are not likely to participate on this end of things. My
intent has been to get these drivers into staging with hopes that:

 * They may see some distributions pick them up, despite the problems with them,
   since this is the only avenue by which users with this hardware will see
   support (apart from compiling the drivers themselves).

 * There will be some interest from kernel developers in helping to clean them
   up. I've heard from a few interested parties.

If you/Canonical are interested in helping with any of this, I think the best
thing to do is coordinate and get patches directly ...

[Jim Lieb (lieb)]

@Forest,
Does VIA provide adequate public info appnotes for this part? What I am thinking of is that if they are just throwing it over the wall with a GPL attached but also provide info so that we can fix it, one could clean it up and make it ready for mainstream and "someone" (usually the guy who missed the design review meeting...) can pick it up. The obvious problem is if the code is "odd" and the part is a mystery it will languish in staging until beyond its sell-by date. If VIA has no intention to maintain/update this code, then there is no constraint to track with any future work product wrt this part. Is this true/sensible?

If you can coordinate what besides this patch has been done to date, I can provide a git patch against current .31 for my work so far. Once I have both archs built (i386 and amd64) I could do a formatting cleanup pass as a second pass patch. That could then be the basis for further work. Does someone already have a .31 git repo with any work that they have done
in it? If not, I have the branch of the ubuntu-karmic tree with this change, it could be propagated from here.

[gamgee911 (samuel-grund)]

has anyone gotten this to work in 64 bit 9.04? I've tried compiling and I've tried ndiswrapper on the 64 bit xp drivers with no luck. really frustrating :P

[gamgee911 (samuel-grund)]

gdm freezes after installing the driver. attached is my make and make install output if anyone thinks that'd help

[Jim Lieb (lieb)]

@gamgee911,
Cleaning up the 64 bit issues is a work in progress. No, it won't be available for 9.04 and it is questionable whether it can make it into 9.10. A reasonably working driver is still floating about in the driver staging dir of the linux-next tree and it is not ready for prime time. There is active work, it is just not done yet. We will let you know when there is a kernel package to test.

[hal2k1 (quiet1)]

@Jim Lieb

>I got it to compile in staging in our ubuntu-karmic git.

...

>As for carrying this in Karmic, we prefer that the driver at least be "on its way" out of staging before we consider it for inclusion. This keeps the not-inconsiderable maintenance cost of an non-mainstream patch and its churn to a minimum. Drivers/modules that come into the kernel this way also don't get lost as we rebase the kernel at each release cycle. I think the best way forward is for the developer to take this input, generate patches to staging to get it moving forward into a mainline merge. We can help with that effort by providing input/review. I do not have this device so I can't really test it myself.

I have a netbook that uses this device, and I previously downloaded the source from:
http://www.viaarena.com/Driver/VT6656_Linux_src_v1.19_12_x86.zip
and compiled it using checkinstall under Kubuntu 9.04 (Jaunty). That worked well enough, but of course there was a need to re-compile it every time the kernel changed.

I have recently loaded as a trial Kubuntu Karmic alpha 3 netbook image.
http://cdimage.ubuntu.com/kubuntu-netbook/daily-live/current/
I used Unetbootin with the .iso image file, and I was able to boot the netbook machine from a USB stick. Just about the only thing that didn't work straight away was of course the wireless, because of this VT6656 chip.

The source code version above that worked on Jaunty doesn't compile under Karmic.

Anyway, since I have the hardware, and I have Karmic alpha 3 installed, I am willing to test it on Karmic and provide logs of whatever happens, but I would need git CLI instructions posted here first on how I would go about compiling and installing this driver from the kernel staging area.

[Jim Lieb (lieb)]

@hal2kl,
Since my last comment, we have received some hardware and are in active work pounding this code into submittable shape. It does seem to compile and run reasonably well in 32 bit but the version you built is not 64 bit safe. I have cleaned up a number of those issues now and we are regularly committing changes upstream. As soon as I have a reasonably stable 32/64 bit driver running, I will try a backport into 10.4 (whereever it may be at the time). I will definitely keep you on my list of testers. At that point, I will supply a kernel package so you don't have to do your own compiles. Stay tuned.

[hal2k1 (quiet1)]

@ Jim Lieb

>It does seem to compile and run reasonably well in 32 bit but the version you built is not 64 bit safe. I have cleaned up a number of those issues now and we are regularly committing changes upstream. As soon as I have a reasonably stable 32/64 bit driver running, I will try a backport into 10.4 (whereever it may be at the time). I will definitely keep you on my list of testers.

The hardware that I have is a netbook. It uses an Intel Atom CPU, and although the VT6656 chip is a USB device, it is not removable from the interior of the netbook. I'd imagine that this is not an unusual usage of this chip.

This means that I personally will be unable to test the 64-bit version of the driver on my hardware. I am however keen to help if I can with testing of the 32-bit version.

[Forest Bond (forest-bond)]

@hal2k1

> The hardware that I have is a netbook. It uses an Intel Atom CPU, and
> although the VT6656 chip is a USB device, it is not removable from the
> interior of the netbook. I'd imagine that this is not an unusual usage
> of this chip.

Can you tell me which model the netbook is?

Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org

[hal2k1 (quiet1)]

@ Forest Bond

>Can you tell me which model the netbook is?

The Kogan Agora, or the Kogan Agora Pro.

http://www.kogan.com.au/shop/kogan-agora-netbook-pro/

I bought the Pro version because it came with Linux (no microsoft tax) and it was the cheapest 10-inch netbook in my country, and I got 2GB RAM with it. I grew tired of the default gOS (slow), so I installed an updated Kubuntu version.

"If it runs one version of Ubuntu, it should run another" was my thinking.

[benbois (boisbenjamin)]

Hi all,

I bought a ZOTAC GEFORCE 9300 - ITX WIFI Motherboard with an integrated VIA VT6656 wireless controller (inside the box with an internal usb cable - http://techreport.com/articles.x/16642).
The OS is Ubuntu 32bits at the moment.

I'm ready to be beta-tester, let me know how to proceed!

[benbois (boisbenjamin)]

Hi,

I compiled the driver from http://www.viaarena.com/Driver/VT6656_Linux_src_v1.19_12_x86.zip on kernel 2.6.28-14 with success.
Wireless card is now loaded by the kernel but I can't join a WAP2 protected wlan.

Do you have any suggestion?

[Jim Lieb (lieb)]

benbois,
  There was a patch in the upstream that disabled this because it was address faulting the driver. I am in the process of cleaning up the pci and memory addressing to fix 32 bit'isms etc. which are probably responsible. My intent once I get thru this bit of overhaul and get it to run on my own systems is to put together a kernel package for you and others to test. Stay tuned.

[benbois (boisbenjamin)]

@Jim Lieb

Thanks for your reply!
You mean that WPA doesn't work at the moment even with the patched driver?
In fact, I did find patch here :-)

[Matthew Tompsett (matthewbpt)]

I've tried compiling this driver with kernel 2.6.31 and it's not possible at the moment. And googling it seems that other people are also experiencing this problem. I suppose this means this driver won't be available in Karmic, unless someone patches it.

[hal2k1 (quiet1)]

>I've tried compiling this driver with kernel 2.6.31 and it's not possible at the moment.

@Matthew Tompsett

In post #29 on this thread it is explained that this code has been taken up by the Linux kernel team working on drivers, and that there is a working version of this driver (works for 32 bit only apparently) in the kernel staging area.

>I suppose this means this driver won't be available in Karmic, unless someone patches it.

Someone is patching it. That is exactly what the staging area of kernel development is for.

In post #31 there is a comment from the maintainer promising to provide a compiled version for Karmic for testing purposes once the code has been cleaned up satisfactorily.

[flohack (flori-bin)]

Guys,

just wanted to add that VIA itself has released an update (1.20.3), which works fo me with 9.10: http://www.viaarena.com/displaydrivers.aspx?PageID=1&OSID=25&CatID=2590&SubCatID=176 - despite they claim its only for 9.04. Maybe this helps anyone who cannot wait for the kernel driver :)

[ati (andre-tippel)]

I tried the VIA driver 1.20.3 on my Zotac 9300 ITX WiFi with Linux Mint 8 Helena 64 bit edition (based on Ubuntu 9.10).

I can compile the driver without errors, but after i install the driver it seems it doesn't work right. No wireless networks are detected, i'm only able to connect to hidden networks but a connection was never established.

Programms i used to configure wireless networks:

 - Network Manager Applet 0.7.996
 - ndiswrapper 1.9

Have anyone else the same problems?

[caius75it (caius)]

Hi Guys,
I've tried compiling 1.20.3 driver source code on my 9.10 karmic 64 bit (2.6.31-16-generic) and even if compilation ad installation seems to work without errors, it doens't work (no wireless network are detected).
I've tried building the .deb package with "checkinstall" and then installing just the module.........

Any ideas???

[ati (andre-tippel)]

I compile the stage driver from http://git.kernel.org/?p=linux/kernel/git/linville/wireless-2.6.git;a=tree;f=drivers/staging/vt6656;h=b6bbb56e85b8c1b57a81b405e77297df3d60335d;hb=HEAD on my zotac 9300 wifi with "linux mint helena 8 64 bit" (Ubuntu 9.10) with john cliffords patched makefile. I can compile the driver but if i try to install it (insmod) the whole system freezes, only a reboot will help.

Sorry, i can't give further informations or error messages. Doesn't find anything useful in /var/log/messages or syslog.

[Nico (nico-laurencin)]

Hi Everyone. I don't know if anyone is interested but here is my 2 cents about the resume from sleep issue with the vntwusb compiled from 1.20.3 on 9.10 32bits.
Basically when the system wakes up and the modules are reloaded, the usb port is made available to vntwusb, which then assigns it a network interface (eth1 or whatever), and then the usb device is reset (from looking at dmesg). Problem is that by that time NetworkManager has already restarted. And it seems that when the this happens, NetworkManager loses track of the device. I know a simple restart network-manager does the trick but that's not good enough.
As a comparison, in a normal boot, NetworkManager is started a long time after the modules have been loaded, so the usb device is ready and waiting.

So for me, while waiting for a better solution, I have edited the following file to introduce a (small) delay in waking up NetworkManager from suspend: the file is /usr/lib/pm-utils/sleep.d/55NetworkManager and in the resume_nm section I have a introduced the following line BEFORE the dbus_send: sleep 0.5. That way when NetworkManager wakes up the module/device pair is ready. Your mileage may vary and it might be that for some people the 0.5 needs to be longer or can be even shorter.

Otherwise the module functions quite well, if a bit slow at connecting to my WPA2 network.

[Christopher Robert Thorn (chris-crthorn)]

I have Zotac GF9300-I-E motherboard with VT6656 internal usb wireless module and Intel Pentium E5300 processor. Wireless internet access works perfectly using the Kubuntu 10.10 32bit Live CD! However when I try the Kubuntu 10.10 64bit Live CD, kernel panic occurs (numlock & capslock keyboard lights flashing). The 64bit Live CD will run if I type "nousb" as a boot option, but of course I have no usb! Then I tried a full install of Kubuntu 10.10 using the Alternate 64bit CD - this installs successfully, but kernel panic occurs at startup. Again, I can add "nousb" as a boot option but this defeats the objective, and no mouse (GF9300 board only caters for usb mouse). Frustrating as I would really like to have 64bit Kubuntu and make full use of my 4Gb memory.

[Forest Bond (forest-bond)]

Maverick is shipping the staging/vt6656 driver.

[Peter Wagner (hasu0bs)]

Has anyone got this to work for either maverick or natty? I cannot even search for reachable networks, i always get the
'Invalid argument' error.
Maybe this bug should be reopened?

[whoward (warren-madtechsupport)]

See this thread : http://ubuntuforums.org/showthread.php?t=1748355&page=3

There are issues with the vt6656_stage driver and kernel version 2.6.38-8. The vt6656_stage driver does not work with 11.04.

I just installed 11.04 on the same laptop was previously working with a version of Ubuntu Netbook Edtion.

Either this bug or another should be opened for this.

[Forest Bond (forest-bond)]

whoward: Please open a new bug to report the regression.

Peter: Was the driver previously working for you? There are known issues with this driver on 64 bit systems.

[whoward (warren-madtechsupport)]

New bug report : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/808789

Regards,

Warren.

[Ramon Ziai (rziai)]

The but above was scheduled for removal due to incompleteness, so I opened a new one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/813200

[Peter Wagner (hasu0bs)]

@Forest Bond: The driver was never working for me. I think i tried karmic maverick and natty

Wondering how Ramon managed to et it work under maverick, as he writes in the new bug report...

[Forest Bond (forest-bond)]

Peter, are you on a 64 bit system? The driver has known issues with 64 bit systems.

[Benjamín Burgos V. (bburgosv)]

Drivers dont run in 11.04. It's frustrating 'cause many itx motherboards came with this chipset. Mine in particular, is an Zotac GT9300-K-E and wifi USB module (internal) have this Via chip.

[Ramon Ziai (rziai)]

Can someone explain to me why the vt6656_stage module was silently dropped after oneiric? Debian has this driver in *all* of its current distributions, from stable to experimental. I'm usually not the complaining type, but here's a hardware issue preventing people from using Ubuntu and the devs apparently care more about integrating stuff like Angry Birds into the desktop. No wonder people are moving to different distros. I'm seriously thinking about switching to Mint or even Debian.

[Malcolm Priestley (tvboxspy)]

I have been doing some work on this driver recently.

Patches to get this driver up and running again on x86 are slowly filtering down the stable kernels.

However, the driver on 64 bit should be blacklisted, the driver does not work and will hang on probing. A patch to fix the hang has been posted to next/stable.

I have got the driver running on 64 bit with unsecured connections but there is still a nasty deadlock on with wpa supplicant.

[Tim Gardner (timg-tpi)]

Malcom - which versions of the kernel have 64 bit issues ? If you posted to stable, then I assume it was fixed at some point.

[Malcolm Priestley (tvboxspy)]

All versions of 64 bit kernels have never and will not work mainly due to sizeof long issues.

If the driver is compiled for 64 bit this patch stop the driver hanging.
http://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=commit;h=ab1dd9963137a1e122004d5378a581bf16ae9bc8

At the moment the patch is only in the staging-next tree, once it is uptream I will forward to stable.

[Ramon Ziai (rziai)]

Good to see some development here! I assume the fix will be shipped with 12.04.2. Is there a way one can get it before that?

[Tim Gardner (timg-tpi)]

It is unlikely that this driver will be fixed for the 12.04.2 point release. In the meantime I've enabled it for 13.04 which you can install from (for example) http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc4-raring/

[Malcolm Priestley (tvboxspy)]

The deadlocks in the 64 bit driver have been found.

https://patchwork.kernel.org/project/linux-wireless/list/?submitter=8383

I prefer to keep them in the next tree for now, hopefully, they will go upstream in kernel 3.8

As expected, the 64 bit v3.7-rc4-raring hangs without the patch;
staging: vt6656: [BUG] out of bound array reference in RFbSetPower

I understand 12.04.2 is on kernel 3.5 which is end of life, it will need seperate patch submission.

[Tim Gardner (timg-tpi)]

Probably won't get fixed in Quantal.

[Tim Gardner (timg-tpi)]

Probably won't get fixed in Precise

[Malcolm Priestley (tvboxspy)]

The driver is now fixed and functioning on all platforms on stable kernels from

3.2.38 for precise and 3.5.7.5 for quantal.

Also, the lastest stable kernels on 3.0, 3.4 and 3.7.

[Jorge Juan (jjchico)]

Hi!

Thanks for the great job Malcolm. So many of us have been waiting for a long time to get our netbooks working.

What is the best way to test the driver for precise? This is not yet in 3.2.0-38 for precise (from proposed). An already compiled kernel including vt6566.ko would be great.

Thanks,

jorge.

[Joe Clifford (joeclifford)]

Fabulous work indeed Malcolm! Many thanks for your hard work. I'm posting this using the new driver from linux-next on Ubuntu 12.10 x86_64 kernel 3.5.0-23-generic :)

Quick instructions to compile it yourselves peoples (similar to my instructions posted in this bug report a few years ago):

1. install build tools: sudo apt-get install build-essential linux-headers-`uname -r`
2. download driver source from linux-next branch: go to http://git.kernel.org/?p=linux/kernel/git/linville/wireless-next.git;a=tree;f=drivers/staging/vt6656 and click 'snapshot'
3. unarchive the file you just downloaded: tar -xzf wireless-next-12c2ce4.tar.gz (or similarly named archive)
4. change directory to the vt6656 source files you've just unarchived: cd wireless-next-12c2ce4
5. edit the Makefile using nano or your favourite text editor - comment out the last line: #obj-$(CONFIG_VT6656) += vt6656_stage.o
6. add a new line to the bottom of the Makefile and save it: obj-m = vt6656_stage.o
7. build the driver: make -C /lib/modules/`uname -r`/build M=`pwd` modules
8. make a new directory for the driver in the kernel modules directory: sudo mkdir -p /lib/modules/`uname -r`/kernel/drivers/staging/vt6656
9. copy the new driver to the kernel modules directory: sudo cp vt6656_stage.ko /lib/modules/`uname -r`/kernel/drivers/staging/vt6656/
10. 'do' a depmod: sudo depmod -a
11. reboot and enjoy (whilst singing praise for the developers :)

[flohack (flori-bin)]

Joe and others,

I own a small netbook since some years with exactly this nice piece of hardware. After each upgrade it was the same messy thing to somehow get VIA's code compiling, loading and not breaking the system.

Then somehow I saw light at the end of the tunnel, as I noticed the driver is in staging now. I happily started to use kernel 2.6.32 and I started to forget about this issue.

Until today, when I noticed that after my upgrade to 12.04 my WLAN is gone again. sigh. Nightmares came back. How can this be, the kernel is now 3.2.x and slowly the community should make up its mind, do we support this crappy piece of hardware or not? I could accept a denial for this thingy, but please, do not make it first work, and then break it again...

Anyway, Joe, I followed your instructions, and they do not work for me. No error, compilation successful, driver loads (lsmod), but no reaction. No output, no eth1, its just stuck in the memory. Does anyone have an idea?

kind regards Florian

[Malcolm Priestley (tvboxspy)]

To get it working on 3.2, you need to take a snap shot of the stable 3.2 kernel.

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tree;f=drivers/staging/vt6656;h=adfc9e293de7c6338723e43a6f01b8a05084c72a;hb=cd1b44e9d1843228414295e843ef208a72c44b58

and follow Joes instructions.

or modify the very bottom of main_usb.c in the upstream version as follows;

static int __init vt6656_init_module(void)
{
    return usb_register(&vt6656_driver);
}

static void __exit vt6656_cleanup_module(void)
{
 usb_deregister(&vt6656_driver);
}

module_init(vt6656_init_module);
module_exit(vt6656_cleanup_module);

//module_usb_driver(vt6656_driver);

Don't forget to comment out the last line, and compile again.

[flohack (flori-bin)]

Malcolm,

thanks this worked so far. But what will the future be for this driver? Is there a chance that it will survive?

regards Florian

[Malcolm Priestley (tvboxspy)]

Florian,

The driver has been in the kernel since 2.6.35 and there is no reason to remove it.

It was broken around 2.6.37 for i386 users.

So Maverick on i386 always worked.

Natty(2.6.38) is broken.

Oneiric(3.0) was broken and now fixed on i386 and x86_64 updated the latest stable kernel. Although you can't do a fresh install on 64 from an old ISO.

Precise and Quantal(3.2/3.5) the kernel driver is deliberately not built on Ubuntu.

Raring(3.8) the driver is built.

As the driver is in staging it is not maintained by linux wireless.

So breaks could happen again, but all the critial bugs have been fixed.

However, I will keep an eye on it.

[Malcolm Priestley (tvboxspy)]

Tim,

Why does this driver continues to be disabled in Precise and Quantal ?

There no problems with the current stable release kernels.

[Malcolm Priestley (tvboxspy)]

No problems reported on Quantal 3.5.0-46-generic

[Brad Figg (brad-figg)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-precise' to 'verification-done-precise'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Brad Figg (brad-figg)]

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-quantal' to 'verification-done-quantal'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.2.0-59.90

---------------
linux (3.2.0-59.90) precise; urgency=low

  [ Brad Figg ]

  * UBUNTU: Disable modules checking for armel and armhf for this upload; the staging/tidspbridge has been disabled

linux (3.2.0-59.89) precise; urgency=low

  [ Brad Figg ]

  * Release Tracking Bug
    - LP: #1266551

  [ Andy Whitcroft ]

  * [Debian] Improve tools version message
    - LP: #1257715

  [ Sergey Popovich ]

  * SAUCE: netfilter: xt_hashlimit: fix proc entry leak in netns destroy
    path
    - LP: #1256988

  [ Tim Gardner ]

  * [Config] Enable CONFIG_VT6656
    - LP: #162671

  [ Upstream Kernel Changes ]

  * netfilter: xt_recent: fix namespace destroy path
    - LP: #1256988
  * netfilter: xt_hashlimit: fix namespace destroy path
    - LP: #1256988
  * selinux: correct locking in selinux_netlbl_socket_connect)
    - LP: #1266546
  * NFSv4: Fix a use-after-free situation in _nfs4_proc_getlk()
    - LP: #1266546
  * USB: mos7840: fix tiocmget error handling
    - LP: #1266546
  * usb: Disable USB 2.0 Link PM before device reset.
    - LP: #1266546
  * usb: hub: Clear Port Reset Change during init/resume
    - LP: #1266546
  * rt2400pci: fix RSSI read
    - LP: #1266546
  * rt2x00: check if device is still available on rt2x00mac_flush()
    - LP: #1266546
  * alarmtimer: return EINVAL instead of ENOTSUPP if rtcdev doesn't exist
    - LP: #1266546
  * USB：add new zte 3g-dongle's pid to option.c
    - LP: #1266546
  * libata: Fix display of sata speed
    - LP: #1266546
  * ahci: disabled FBS prior to issuing software reset
    - LP: #1266546
  * drivers/libata: Set max sector to 65535 for Slimtype DVD A DS8A9SH
    drive
    - LP: #1266546
  * ALSA: 6fire: Fix probe of multiple cards
    - LP: #1266546
  * ARM: sa11x0/assabet: ensure CS2 is configured appropriately
    - LP: #1266546
  * usb: wusbcore: set the RPIPE wMaxPacketSize value correctly
    - LP: #1266546
  * usb: wusbcore: change WA_SEGS_MAX to a legal value
    - LP: #1266546
  * powerpc/vio: Fix modalias_show return values
    - LP: #1266546
  * powerpc/vio: use strcpy in modalias_show
    - LP: #1266546
  * dm: allocate buffer for messages with small number of arguments using
    GFP_NOIO
    - LP: #1266546
  * can: c_can: Fix RX message handling, handle lost message before EOB
    - LP: #1266546
  * dm mpath: fix race condition between multipath_dtr and pg_init_done
    - LP: #1266546
  * ext4: avoid bh leak in retry path of ext4_expand_extra_isize_ea()
    - LP: #1266546
  * ASoC: ak4642: prevent un-necessary changes to SG_SL1
    - LP: #1266546
  * ahci: Add Device IDs for Intel Wildcat Point-LP
    - LP: #1266546
  * KVM: IOMMU: hva align mapping page size
    - LP: #1266546
  * crypto: s390 - Fix aes-cbc IV corruption
    - LP: #1266546
  * audit: printk USER_AVC messages when audit isn't enabled
    - LP: #1266546
  * audit: fix info leak in AUDIT_GET requests
    - LP: #1266546
  * audit: use nlmsg_len() to get message payload length
    - LP: #1266546
  * drm/ttm: Fix memory type compatibility check
    - LP: #1266546
  * PM / hibernate: Avoid overflow in hibernate_preallocate_memory()
    - LP: #1266546
  * ALSA: hda - Add...

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 3.5.0-46.70

---------------
linux (3.5.0-46.70) quantal; urgency=low

  [ Brad Figg ]

  * UBUNTU: Disable abi and module checking due to broken modules being
    disabled and we have bumped the abi.

linux (3.5.0-46.69) quantal; urgency=low

  [Steve Conklin]

  * Release Tracking Bug
    - LP: #1266857

  [ Sergey Popovich ]

  * SAUCE: (no-up) netfilter: xt_hashlimit: fix proc entry leak in netns
    destroy path
    - LP: #1256988

  [ Tim Gardner ]

  * [Config] Enable CONFIG_VT6656
    - LP: #162671

  [ Upstream Kernel Changes ]

  * Revert "ima: policy for RAMFS"
    - LP: #1265562
  * netfilter: xt_recent: fix namespace destroy path
    - LP: #1256988
  * netfilter: xt_hashlimit: fix namespace destroy path
    - LP: #1256988
  * ACPICA: Interpreter: Fix Store() when implicit conversion is not
    possible.
    - LP: #1265562
  * ACPICA: DeRefOf operator: Update to fully resolve FieldUnit and
    BufferField refs.
    - LP: #1265562
  * ACPICA: Return error if DerefOf resolves to a null package element.
    - LP: #1265562
  * ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a
    field.
    - LP: #1265562
  * aacraid: prevent invalid pointer dereference
    - LP: #1265562
  * libertas: potential oops in debugfs
    - LP: #1265562
  * ARM: sa11x0/assabet: ensure CS2 is configured appropriately
    - LP: #1265562
  * dm: allocate buffer for messages with small number of arguments using
    GFP_NOIO
    - LP: #1265562
  * ext4: avoid bh leak in retry path of ext4_expand_extra_isize_ea()
    - LP: #1265562
  * drm/radeon/si: fix define for MC_SEQ_TRAIN_WAKEUP_CNTL
    - LP: #1265562
  * drm/ttm: Handle in-memory region copies
    - LP: #1265562
  * drm/ttm: Fix ttm_bo_move_memcpy
    - LP: #1265562
  * drm/ttm: Fix memory type compatibility check
    - LP: #1265562
  * PM / hibernate: Avoid overflow in hibernate_preallocate_memory()
    - LP: #1265562
  * mtd: nand: hack ONFI for non-power-of-2 dimensions
    - LP: #1265562
  * mtd: map: fixed bug in 64-bit systems
    - LP: #1265562
  * mtd: m25p80: fix allocation size
    - LP: #1265562
  * block: fix race between request completion and timeout handling
    - LP: #1265562
  * blk-core: Fix memory corruption if blkcg_init_queue fails
    - LP: #1265562
  * loop: fix crash if blk_alloc_queue fails
    - LP: #1265562
  * block: fix a probe argument to blk_register_region
    - LP: #1265562
  * block: properly stack underlying max_segment_size to DM device
    - LP: #1265562
  * xen/blkback: fix reference counting
    - LP: #1265562
  * loop: fix crash when using unassigned loop device
    - LP: #1265562
  * SUNRPC: Fix a data corruption issue when retransmitting RPC calls
    - LP: #1265562
  * mtd: gpmi: fix kernel BUG due to racing DMA operations
    - LP: #1265562
  * ALSA: msnd: Avoid duplicated driver name
    - LP: #1265562
  * x86/microcode/amd: Tone down printk(), don't treat a missing firmware
    file as an error
    - LP: #1265562
  * SUNRPC: Avoid deep recursion in rpc_release_client
    - LP: #1265562
  * ALSA: hda - Don't clear the power state at snd_hda_codec_reset()
    - LP: #1265562
  * ASoC: blackfin: Fix missing ...

[flohack (flori-bin)]

Sorry to resurrect this one...

Since 2010 or so I used an external WiFi dongle because of my issues, but now I decided to give the internal one another try.

I am now on 14.04 LTS with it, kernel 3.13.0-91, the driver loads and HW is recognized, but associating with a WPA2 AP fails:

[ 1929.539251] AP(BSS) finding:Found a AP(BSS)..
[ 1930.572203] WLAN_AUTHENTICATE_WAIT:wait 1 times!!
[ 1931.072212] WLAN_AUTHENTICATE_WAIT:wait 2 times!!
[ 1931.572259] WLAN_AUTHENTICATE_WAIT:wait 3 times!!
[ 1932.072207] WLAN_AUTHENTICATE_WAIT:wait 4 times!!
[ 1932.572206] WLAN_AUTHENTICATE_WAIT:wait 5 times!!
[ 1934.546352] Scanning [p\xffffffe9>\xffffffa1A\xffffffe1\xfffffffcg>\x01~\xffffff97\xffffffea\xffffffdck\xffffff96\xffffff8f8\*\xffffffec\xffffffb0;\xfffffffb2\xffffffaf<T\xffffffec\x18\xffffffdb\] not found, disconnected !
[ 1939.843499] Scanning [p\xffffffe9>\xffffffa1A\xffffffe1\xfffffffcg>\x01~\xffffff97\xffffffea\xffffffdck\xffffff96\xffffff8f8\*\xffffffec\xffffffb0;\xfffffffb2\xffffffaf<T\xffffffec\x18\xffffffdb\] not found, disconnected !
[ 1950.560128] Scanning [\x02\x1a\xfffffffeC\xfffffffb\xfffffffa\xffffffaa:\xfffffffb)\xffffffd1\xffffffe6\x05<|\xffffff94u\xffffffd8\xffffffbe\xffffffbea\xffffff89\xfffffff9\\xffffffbb\xffffffa8\xffffff99\x0f\xffffff95\xffffffb1\xffffffeb\xfffffff1\xffffffb3] not found, disconnected !

or smth like this:

[ 207.404922] AP(BSS) finding:Found a AP(BSS)..
[ 207.444977] 802.11 Authen (OPEN) Successful.
[ 208.445027] Association Successful, AID=2.
[ 208.445054] Link with AP(SSID): Nerdbase
[ 212.485720] AP disassociated me, reason=2.
[ 212.492714] AP deauthed me, reason=9.
[ 215.036407] perf samples too long (5017 > 5000), lowering kernel.perf_event_max_sample_rate to 25000
[ 222.156147] Re-association timeout!!!
[ 224.635240] AP(BSS) finding:Found a AP(BSS)..
[ 224.679260] 802.11 Authen (OPEN) Successful.
[ 225.677501] Association Successful, AID=2.
[ 225.677527] Link with AP(SSID): Nerdbase
\xffffffb71X\xffffffa3Z%]\x05\x17X\xffffffe9^\xffffffd4\xffffffab\xffffffab\xffffffb2\xffffffcd\xffffffc6\xffffff9b\xffffff9b\xffffffb4T\x11\x0e\xffffff82tA!=\xffffffdc\xffffff87\xffffff87] not found, disconnected !

Any ideas whats goin on?
BR Florian