Been here on request of Mike A. Harris as asked in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138825 The VIA driver should be enabled in CVS for x86_64 / AMD64 head cause there are now Systems out there with VIA K8M800 (a athlon 64 chipset). Some systems in the wild: http://www.shuttle.com/hq/product/barebone/specification.asp?B_id=34 http://www.dfi.com.tw/Product/xx_product_spec_details_r_us.jsp?PRODUCT_ID=3060&CATEGORY_TYPE=INFINITY&SITE=US http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=621 I had the shuttle barebone in my hands and tried Fedora Core 3 x86_64 on it but the via driver is missing there. I then tried to run the 32 bit version. The via driver is there but it's not working (even if it claims it is supported). Will attach a log. VIA seems to have newer 32-bit drivers on their web site http://www.viaarena.com, those worked fine. In 32 and 64 bit Suse the driver was there but also failed.
Created attachment 1430 [details] Failed Xorg.0.log from x86-Fedora Core 3 configured with via driver Some further, not that important info is also in redhats bugzilla, URL found above
At unichrome.sf.net we are not currently able to properly support the K8M800, PM800 or CN400. We do not have access to such hardware ourselves and people are apparently only prepared to whine about missing support. As an added bonus, the XAA support of the driver built for x86-64 hardlocks K8M800 (see unichrome bug tracker). The log provided is of 6.8.1. The via driver included is pretty much that of xfree86-4.4.0 or a somewhat cleaned up CLEXF40030. Via released this code on the first of august of 2003, at least 6 months before the K8M800 was actually available. It claimed to have K8M800 support, but didn't even know its pci-ids.
Thanks Luc for the info. Anything I (as a non programmer) can do to help? Whine at VIA that they shall open their driver-sources of their K8M800 driver?
I'm sure you guys noticed that via opened the source for some of there drivers -- but I could not find any info witch license is used... http://www.viaarena.com/default.aspx?PageID=2&Type=4
Yes, how can one miss it. The amazing thing is that they make out as if it is out of their own accord, i had to troll long and hard to get any response out of them :)
I haven't checked CVS head, but is this included on x86_64 in CVS head yet, and if not, can someone indicate the reasoning? There are an increasing number of users asking for via support for x86_64, and I'd like to provide it to them, however if X.Org does not have it enabled in CVS head, then I am to assume it is unstable and not something we would want to support in our OS on x86_64 at this time. If it is in CVS head, or does get enabled, is there any reason not to enable it in 6.8 branch as well? Fedora Core 4 will probably ship without the via driver enabled on x86_64, unless someone can give compelling reasons to get it included in Xorg CVS first. I just thought I'd ask as this bug seems stagnant, and loads of people are asking about it. TIA
The situation hasn't changed one bit.
I assume that means the via driver is unstable on x86_64 as deduced from comment #2. Thanks for the quick response Luc!
Hello all. I have laptop with chipset K8N800 (FIC AN5W) and wondering if there is some way to run via driver with it on x86_64. I was tried to compile via_drv.o from unichrome.sf.net CVS HEAD and from xorg.freedesktop.org CVS HEAD, both with xorg 6.8.2 source tree. Driver compiles fine, but don`t start. xorg.freedesktop.org version causes SIGSEGV, while unichrome.sf.net version complains about unresolved symbols: ============================================= (II) VIA: driver for VIA chipsets: CLE266, KM400/KN400, K8M800, PM800/PM880/CN400 (II) Primary Device is: PCI 01:00:0 (--) Assigning device section with no busID to primary device (--) Chipset K8M800 found (!!) VIA Technologies does not support or endorse this driver in any way. (!!) For support, please refer to http://unichrome.sourceforge.net/ or (!!) your X vendor. (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffe00000 - 0xffffffff (0x200000) MX[B](B) ...... (II) Setting vga for screen 0. (II) VIA(0): VIAPreInit (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/lib64/modules/libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 6.8.2, module version = 0.1.0 ABI class: X.Org Video Driver, version 0.7 (II) VIA(0): VIAGetRec (**) VIA(0): Depth 24, (--) framebuffer bpp 32 (==) VIA(0): RGB weight 888 (==) VIA(0): Default visual is TrueColor (==) VIA(0): Using HW cursor (--) VIA(0): Chipset: "K8M800" (II) VIA(0): VIAMapMMIO (--) VIA(0): mapping MMIO @ 0xd1000000 with size 0x9000 (--) VIA(0): mapping BitBlt MMIO @ 0xd1200000 with size 0x10000 Symbol vgaHWGetIndex from module /usr/lib64/modules/drivers/via_drv.o is unresolved! Symbol vgaHWGetIndex from module /usr/lib64/modules/drivers/via_drv.o is unresolved! Required symbol vgaHWProtect from module /usr/lib64/modules/drivers/via_drv.o is unresolved! ..... Fatal server error: Some required symbols were unresolved ========================================= Is there anything i can do with it? Should i try to compile full xorg system from CVS? How can i help? I`m programmer, but never touched hw stuffs..
Is this bug still valid? AFAICT, All xorg via driver components are 64-bit clean. VBEModes will fail on some 64-bit systems, but so does the vesa driver.
(In reply to comment #10) > Is this bug still valid? Fedora Core 5 (currently in testing) ships them for x64. So the answer probably is: No. I didn't test them, but I think closing this bug is fine for everybody.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.