[opensuse-factory] i915.modeset=0 worked with a 2.6.34-RC3 kernel, but not with RC2
All, I filed https://bugzilla.novell.com/show_bug.cgi?id=594542 a couple months ago and was given a workaround of booting with i915.modeset=0 which was fine. I've just upgraded to RC2 and that workaround is no longer working, which is a pretty serious bug if there is not an alternate workaround for this fairly common GPU. Can any one give me a suggestion? fyi: I updated the bug with this info as well as Xorg.conf and Xorg.0.log, so if anyone is curious, check the bug. Thanks Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Greg Freemyer <greg.freemyer@gmail.com> [2010-07-09 20:57]:
Use nomodeset instead. And you need to manually switch to the "intellegacy" X.org driver or you will get the VESA one by default. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jul 9, 2010 at 4:33 PM, Guido Berhoerster <guido+opensuse.org@berhoerster.name> wrote:
Thanks Guido, it works. (At least I have X. Not sure about what happens after it sleeps yet, but no reason to doubt the legacy driver.) If you or anyone knows where to document this fix in the wiki, I'd be happy to do so. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Greg Freemyer <greg.freemyer@gmail.com> [2010-07-09 23:11]:
Can you file a bug against the release notes instead? It should contain something along the lines "if you experience problems with Intel graphics hardware you can try disabling KMS by adding 'nomodeset' to the kernel parameters and adding 'Driver "intellegacy"' to /etc/X11/xorg.conf.d/50-device.conf". I can't use KMS either due to two other bugs and probably a lot of people using Intel hardware will run into bugs/regressions which might be worked around by disabling KMS and/or using the 2.9.1 driver. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
There is an uncorrectable problem with kernel 2.6.34 for some Netbook computers with Broadcom BCM4313 802.11b/g wireless devices. As this is the kernel in openSUSE 11.3, some users will be affected. The driver problem is fixed in kernel 2.6.35; however, the fix is too invasive to be backported to 2.6.34. The main problem with this bug is that the system freezes with no clue as to why it happens. It will happen for NET CD, DVD, and Live CD media. The workaround to prevent the freeze is simple; however, it will need to be distributed to users. What is the best way to make this information available to users? Sample text for the workaround follows: ==================================================================== Netbook computers with Broadcom BCM4312 wireless cards may freeze when booting any openSUSE 11.3 media. The way to circumvent this problem is to prevent loading the ssb module by adding the text "brokenmodules=ssb" text to the boot line before booting any DVD, Live CD or NET install CD. In addition to preventing the bug from freezing the computer during the boot process, this addition will lead to blacklisting ssb when the installed system is booted. To permit usage of the Broadcom wireless device after the system is installed, there are several options: (1) Install a 2.6.35 or later kernel. (2) Use the compat-wireless package for your kernel. Or (3) Install the Broadcom-wl package for your kernel. For either of the latter two options, your wireless will break whenever your kernel is updated. ===================================================================== Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Jul 10, 2010 at 11:56:31PM -0500, Larry Finger wrote:
Time to create http://en.opensuse.org/Bugs:Most_Annoying_Bugs_11.3 Or branch it from http://en.opensuse.org/Bugs:Most_Annoying_Bugs_11.3_dev I'm not sure if "to branch" is the right wording in wiki sprech. a) Don't limit the article to netbook computers. Even other systems using this hardware will suffer from the issue. b) Suggest the easier solutions first. Getting a 2.6.35 based kernel for 11.3 might be the harder way for the majority of users. The "For either of the latter two options, your wireless will break whenever your kernel is updated." I suggest to change into a "might break". The kernel update approach tries to circumvent this as good as possible. Here one of the kernel dudes might jump in and point us to the backround of the story. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On 07/11/2010 07:37 AM, Lars Müller wrote:
It seems that the particular "feature" that shows this issue is limited to Netbook motherboard design where the wireless chip is built in. If there is a separate PCIe card, then the problem does not occur.
b) Suggest the easier solutions first. Getting a 2.6.35 based kernel for 11.3 might be the harder way for the majority of users.
Thanks for the suggestion.
I am one of the b43 dudes, in fact, I found the fix once I got my hands on a unit with the problem. Unfortunately, it was too late for 2.6.34 and too invasive for 2.6.34.Y. The only hope would be to put this patch in the openSUSE collection, but that will may not be possible. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Jul 11, 2010 at 11:09 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
Just a quick report. I downloaded 11.3 GM candidates for i586 (Build 0702) and installed it on HP Mini 311 (Intel Atom N280, with WLAN Broadcom Corporation BCM4312 802.11b/g (rev 01) and Nvidia Ion). Installation went ok. And like RC2, it stop on reboot when calling b43-pci-bridge. As workaround I should mount the root partition to other openSUSE installation and add a blacklist file for broadcom for bcm43xx, ssb, b43. Reboot to 11.3 went ok after that and installation continue. To activate wlan I use broadcom-wl package from OBS. cheers, -- medwinz ======================= http://medwinz.blogsome.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 07/11/2010 11:42 AM, medwinz wrote:
Rather than mounting from another installation, just add "brokenmodules=ssb" to the boot line. As a side effect, ssb will be added to the blacklist automatically. The fix for this problem has been submitted to the 2.6.34.Y stable tree. Once there, it will be propagated to openSUSE. The next kernel upgrade for 11.3 should fix the problem. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Jul 11, 2010 at 11:42:09PM +0700, medwinz wrote:
To activate wlan I use broadcom-wl package from OBS.
Why is this package in obs? The license for the wl driver does not allow it to be redistributed, please delete it from OBS before people get in big trouble... thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 07/12/2010 11:57 AM, Greg KH wrote:
In my mind, even having it on Packman is a violation of the Broadcom license. I think the only legal way to run Broadcom wl is to download the source from Broadcom's site and compile it on your own machine! Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Jul 12, 2010 at 12:19:18PM -0500, Larry Finger wrote:
That is correct, it can not be in Pacman either. I'll go poke the OBS maintainers tomorrow to delete these illegal packages from obs. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, 2010-07-12 at 10:28 -0700, Greg KH wrote:
I am just for the sake of curiosity butting in here, but I do read this in their README file "Some distros (Ubuntu and Fedora at the least) already have a version of this driver in their repositories precompiled, tested and ready to go. You just use the package manager to install the proper package. If its available for your distro, this is usually an easier solution. See the end of this document for further discussion. " and in their LICENSE.txt file they say " 2.1. License Grants. Subject to the terms and conditions of this Agreement, Broadcom hereby grants to Licensee a non-exclusive, non-transferable, royalty-free license (i) to use and integrate the Software in conjunction with any other software; and (ii) to reproduce and distribute the Software complete, unmodified and only for use with a Broadcom Product. 2.2. Restriction on Modification. If and to the extent that the Software is designed to be compliant with any published communications standard (including, without limitation, DOCSIS, HomePNA, IEEE, and ITU standards), Licensee may not make any modifications to the Software that would cause the Software or the accompanying Broadcom Products to be incompatible with such standard. 2.3. Restriction on Distribution. Licensee shall only distribute the Software (a) under the terms of this Agreement and a copy of this Agreement accompanies such distribution, and (b) agrees to defend and indemnify Broadcom and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Software by the Licensee except as contemplated herein. " Is it because of the clause 2.1 that it is not legal for packman to host this? But Ubuntu and Fedora do indeed have rpm in their repositories as well. If this LICENSE.txt file is included, even so is it not possible to have rpm binaries in packman, for instance? Note: I don't maintain any version of the package in the obs or packman. Thanks. -- Atri -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Monday 12 July 2010 19:52:59 Atri Bhattacharya wrote:
[...] ? But Ubuntu and Fedora do indeed have rpm in their repositories as
Please double: Fedora does not have it in its repository, it's part of RPM fusion, so outside of Fedora. The openSUSE project will not distribute the broadcom-wl driver due to the GPL violation, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Tue, 2010-07-13 at 10:16 +0200, Andreas Jaeger wrote:
Thanks, this I understand. But I was wondering whether packman repos can distribute it as they do now, similar to what RPM fusion does for Fedora. Anyway, it does seem to be an ugly enough issue. I will just be careful to avoid a computer with a Broadcom chip in it that is not supported by b43 :) Bye. -- Atri -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 07/12/2010 01:28 PM, Greg KH pecked at the keyboard and wrote:
While you are at it why not also provide a link to the download area and instructions on how to compile and install the driver. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Jul 12, 2010 at 07:00:17PM -0400, Ken Schneider - openSUSE wrote:
Why would I want to promote a driver that violates Novell's public position on Linux kernel modules, as well as my own, and one that violates my personal copyright on the kernel? {sigh} greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 07/12/2010 07:21 PM, Greg KH pecked at the keyboard and wrote:
Ah yes, I forgot that you would rather that companies give up their IP then you accommodate them in the kernel. Sorry. Violating "Novell's public position" does not make using "closed source binary" kernel modules illegal. If you do not want others to provide "closed source binary" modules provide a viable (working) alternative. I was not aware that the kernel was *your* personal creative work to copyright. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Jul 12, 2010 at 9:37 PM, Ken Schneider - openSUSE <suse-list3@bout-tyme.net> wrote:
Ken, In general every individual kernel submission is copyrighted by the submitter. That's one reason the kernel is unlikely to ever move to GPL 3. Greg KH has been a major kernel contributor for years so he has submitted tons of copyrighted material to the kernel. I have no idea how that breaks down between Novell and personal copyright, but I don't think it matters. And I believe that all close source kernel modules violate GPL 2. ie. GPL2 calls for all modules/libraries that link to GPL code to be GPL. Closed source modules clearly violate that. Greg (Freemyer) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Jul 12, Ken Schneider - openSUSE wrote:
Ah yes, I forgot that you would rather that companies give up their IP then you accommodate them in the kernel. Sorry.
Implying that Greg is not supporting big companies to integrate their drivers into the Linux kernel is clearly ignoring reality. Other comanies have already shown that protecting IP and writing good opensource kernel drivers does not exclude each other, even in the wireless driver area. The issue here is Broadcom's driver and its license, not Greg's or any other kernel developer's position. I am actually mildly surprised to see people value prorietary closed-source drivers for pretty cheap hardware more than the hard work kernel developers have invested into the Linux kernel, most of them in their spare time. It's the company delivering that binary blob that people should pressure, not the Linux kernel developers. Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 07/13/2010 12:46 AM, Daniel Rahn wrote:
From a b43 developer, and on behalf of all the other b43 developers, thank you. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 13/07/2010 07:46, Daniel Rahn a écrit :
It's the company delivering that binary blob that people should pressure, not the Linux kernel developers.
but usually Kernel devs are more friendly than big companies and one don't always have the choice of his hardware :-)) jdd -- http://www.dodin.net http://www.facebook.com/pages/I-support-the-Linux-Documentation-Project/3720... http://www.facebook.com/pages/The-fan-page-of-Claire-Dodin/106485119372062?v... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, 2010-07-13 at 07:46 +0200, Daniel Rahn wrote:
Totally agree.
Their might be a fair chance that people too late find out that it is't going to be an easy ride. And once they do have the hardware it's not fine to find out their hw won't work. It used to be non-existent, but nowadays you see more and more product with tux printed on the box. So there is a broad job for our evangelists. (and even then, there are a bunch of products with tux, that don't work ;-) btw, it is certainly not limited to wireless-nics. [usb-nics, sata/scsi-cards, video, .....] Perhaps another good job for the community to have an up-to-date hw-compatibility-list ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Jul 12, 2010 at 09:37:52PM -0400, Ken Schneider - openSUSE wrote:
Ah yes, I forgot that you would rather that companies give up their IP then you accommodate them in the kernel. Sorry.
Hm, so you are stating that for some reason the IP of a single tiny driver superseeds the license of the 10 million lines of kernel code that surround it? On what legal, moral, or technical grounds can you possibly make that justification?
Violating "Novell's public position" does not make using "closed source binary" kernel modules illegal.
I have never stated that "using" a closed driver is illegal, the GPLv2 does not say anything about usage. The issue comes into play when the code is distributed, which is what is happening right now on build.opensuse.org, and in that case, it is violation of both Novell's publically stated policy, and Brodcom's license on their code as well.
Some of the kernel api calls that the Brodcom driver makes are ones that I have personal copyright on, as well as sharing copyright by companies that I work for and have worked for in the past. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Jul 12, 2010 at 11:57 PM, Greg KH <gregkh@suse.de> wrote:
I'm afraid I can't, I don't create that package :-) Usually I use one from Packman but there are many user package it, see [1] & [2] Maybe OBS Admin can delete such packages. [1] http://software.opensuse.org/search?p=1&baseproject=ALL&q=broadcom-wl. [2] http://software.opensuse.org/search?q=broadcom-wl-kmp&baseproject=ALL&lang=e... -- medwinz ======================= http://medwinz.blogsome.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Jul 10, 2010 at 11:56:31PM -0500, Larry Finger wrote:
Why don't we create a compat-wireless based package that has this driver in it, that gets installed if the user has this type of hardware in the system? We've done this for preloaded systems a lot, no reason we can't do it for openSUSE 11.3 as well, right? Do you have a compat-wireless package for this driver with the fix in it somewhere in the build service already? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 07/11/2010 09:09 AM, Greg KH wrote:
Sounds good.
Do you have a compat-wireless package for this driver with the fix in it somewhere in the build service already?
I will generate a fix and test against kernel 2.6.34-12.1. Once I have that, will it be OK to contact you again regarding generating a package? This solution will fix upgrades, but will be too late for the GM installation media. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 07/11/2010 12:08 PM, Larry Finger wrote:
Is there enough time to include it in the updates for July 15th? -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 07/11/2010 11:32 AM, Roman Bysh wrote:
Not unless some real show stopper delays the release. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Jul 11, 2010 at 2:11 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
If you can get this into the update repo, will zypper dup and/ yast2 wagon go straight to the good kernel? If so, maybe the readme should add an option that netbook users with the BCM4312 install 11.2 and then use an online upgrade to get to 11.3? Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Jul 11, 2010 at 11:08:50AM -0500, Larry Finger wrote:
Yes, please do.
This solution will fix upgrades, but will be too late for the GM installation media.
We can work to get this in the first round of updates. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sunday 11 Jul 2010 20:42:33 Greg KH wrote:
Hi . I just got to pipe in here Being one of the ones that have an affected broadcom wifi card in my laptop and no means of connecting it via a wired connection it seems this makes it a show stopper hence it needs to be intorduced into the up comming release of 11.3 Pete . -- Powered by openSUSE 11.2 (x86_64) Kernel: 2.6.30-rc6-git3-4-default KDE: 4.2.86 (KDE 4.2.86 (KDE 4.3 >= 20090514)) "release 1" 21:00 up 8 days 22:45, 4 users, load average: 1.76, 1.91, 2.11
On 07/11/2010 03:03 PM, Peter Nikolic wrote:
This problem will NOT affect a laptop. It only applies to Netbooks with Atom processors. Note: if you have the DMA problem, that has not yet been fixed in any kernel! That is a problematic configuration anyway. Without a wired connection or another wireless device, you will have a problem getting the firmware, which cannot be distributed with openSUSE by terms of the Broadcom copyright. How are you handling that device now? I recommend that you use the /usr/sbin/install_bcm43xx_firmware script to get the firmware, and then copy the files in /lib/firmware/b43 onto your /home if you save it during the installation, or onto a USB stick. In addition, I can email you the patched ssb.ko to be installed onto your system. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sunday 11 Jul 2010 23:25:52 Larry Finger wrote:
Pete . -- Powered by openSUSE 11.2 (x86_64) Kernel: 2.6.30-rc6-git3-4-default KDE: 4.2.86 (KDE 4.2.86 (KDE 4.3 >= 20090514)) "release 1" 17:00 up 9 days 18:44, 4 users, load average: 2.40, 1.92, 1.74
Greg, After I looked into the actual fix needed, it was clear that the original fix was quite invasive because it had a number of prerequisites. After reducing the fix to the bare minimum, it seems that the resulting fix may be a candidate for stable 2.6.34.Y, or at least the openSUSE kernel. Larry The tested patch is as follows: ========================================================================== From: Christoph Fritz <chf.fritz@googlemail.com> For some Netbook computers with Broadcom BCM4312 wireless interfaces, the SPROM has been moved to a new location. When the ssb driver tries to read the old location, the systems hangs when trying to read a non-existent location. Such freezes are particularly bad as they do not log the failure. This patch is modified from commit da1fdb02d9200ff28b6f3a380d21930335fe5429 with some pieces from other mainline changes so that it can be applied to stable 2.6.34.Y. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> --- Index: linux-2.6.34-12/drivers/ssb/driver_chipcommon.c =================================================================== --- linux-2.6.34-12.orig/drivers/ssb/driver_chipcommon.c +++ linux-2.6.34-12/drivers/ssb/driver_chipcommon.c @@ -233,6 +233,9 @@ void ssb_chipcommon_init(struct ssb_chip { if (!cc->dev) return; /* We don't have a ChipCommon */ + if (cc->dev->id.revision >= 11) + cc->status = chipco_read32(cc, SSB_CHIPCO_CHIPSTAT); + ssb_dprintk(KERN_INFO PFX "chipcommon status is 0x%x\n", cc->status); ssb_pmu_init(cc); chipco_powercontrol_init(cc); ssb_chipco_set_clockmode(cc, SSB_CLKMODE_FAST); Index: linux-2.6.34-12/drivers/ssb/driver_chipcommon_pmu.c =================================================================== --- linux-2.6.34-12.orig/drivers/ssb/driver_chipcommon_pmu.c +++ linux-2.6.34-12/drivers/ssb/driver_chipcommon_pmu.c @@ -502,9 +502,9 @@ static void ssb_pmu_resources_init(struc chipco_write32(cc, SSB_CHIPCO_PMU_MAXRES_MSK, max_msk); } +/* http://bcm-v4.sipsolutions.net/802.11/SSB/PmuInit */ void ssb_pmu_init(struct ssb_chipcommon *cc) { - struct ssb_bus *bus = cc->dev->bus; u32 pmucap; if (!(cc->capabilities & SSB_CHIPCO_CAP_PMU)) @@ -516,15 +516,12 @@ void ssb_pmu_init(struct ssb_chipcommon ssb_dprintk(KERN_DEBUG PFX "Found rev %u PMU (capabilities 0x%08X)\n", cc->pmu.rev, pmucap); - if (cc->pmu.rev >= 1) { - if ((bus->chip_id == 0x4325) && (bus->chip_rev < 2)) { - chipco_mask32(cc, SSB_CHIPCO_PMU_CTL, - ~SSB_CHIPCO_PMU_CTL_NOILPONW); - } else { - chipco_set32(cc, SSB_CHIPCO_PMU_CTL, - SSB_CHIPCO_PMU_CTL_NOILPONW); - } - } + if (cc->pmu.rev == 1) + chipco_mask32(cc, SSB_CHIPCO_PMU_CTL, + ~SSB_CHIPCO_PMU_CTL_NOILPONW); + else + chipco_set32(cc, SSB_CHIPCO_PMU_CTL, + SSB_CHIPCO_PMU_CTL_NOILPONW); ssb_pmu_pll_init(cc); ssb_pmu_resources_init(cc); } Index: linux-2.6.34-12/drivers/ssb/pci.c =================================================================== --- linux-2.6.34-12.orig/drivers/ssb/pci.c +++ linux-2.6.34-12/drivers/ssb/pci.c @@ -23,6 +23,7 @@ #include "ssb_private.h" +bool ssb_is_sprom_available(struct ssb_bus *bus); /* Define the following to 1 to enable a printk on each coreswitch. */ #define SSB_VERBOSE_PCICORESWITCH_DEBUG 0 @@ -168,7 +169,7 @@ err_pci: } /* Get the word-offset for a SSB_SPROM_XXX define. */ -#define SPOFF(offset) (((offset) - SSB_SPROM_BASE) / sizeof(u16)) +#define SPOFF(offset) ((offset) / sizeof(u16)) /* Helper to extract some _offset, which is one of the SSB_SPROM_XXX defines. */ #define SPEX16(_outvar, _offset, _mask, _shift) \ out->_outvar = ((in[SPOFF(_offset)] & (_mask)) >> (_shift)) @@ -253,8 +254,13 @@ static int sprom_do_read(struct ssb_bus { int i; + /* Check if SPROM can be read */ + if (ioread16(bus->mmio + bus->sprom_offset) == 0xFFFF) { + ssb_printk(KERN_ERR PFX "Unable to read SPROM\n"); + return -ENODEV; + } for (i = 0; i < bus->sprom_size; i++) - sprom[i] = ioread16(bus->mmio + SSB_SPROM_BASE + (i * 2)); + sprom[i] = ioread16(bus->mmio + bus->sprom_offset + (i * 2)); return 0; } @@ -285,7 +291,7 @@ static int sprom_do_write(struct ssb_bus ssb_printk("75%%"); else if (i % 2) ssb_printk("."); - writew(sprom[i], bus->mmio + SSB_SPROM_BASE + (i * 2)); + writew(sprom[i], bus->mmio + bus->sprom_offset + (i * 2)); mmiowb(); msleep(20); } @@ -621,21 +627,49 @@ static int ssb_pci_sprom_get(struct ssb_ int err = -ENOMEM; u16 *buf; + if (!ssb_is_sprom_available(bus)) { + ssb_printk(KERN_ERR PFX "No SPROM available!\n"); + return -ENODEV; + } + if (bus->chipco.dev) { /* can be unavailible! */ + /* + * get SPROM offset: SSB_SPROM_BASE1 except for + * chipcommon rev >= 31 or chip ID is 0x4312 and + * chipcommon status & 3 == 2 + */ + if (bus->chipco.dev->id.revision >= 31) + bus->sprom_offset = SSB_SPROM_BASE31; + else if (bus->chip_id == 0x4312 && + (bus->chipco.status & 0x03) == 2) + bus->sprom_offset = SSB_SPROM_BASE31; + else + bus->sprom_offset = SSB_SPROM_BASE1; + } else { + bus->sprom_offset = SSB_SPROM_BASE1; + } + ssb_dprintk(KERN_INFO PFX "SPROM offset is 0x%x\n", bus->sprom_offset); + buf = kcalloc(SSB_SPROMSIZE_WORDS_R123, sizeof(u16), GFP_KERNEL); if (!buf) goto out; bus->sprom_size = SSB_SPROMSIZE_WORDS_R123; - sprom_do_read(bus, buf); + err = sprom_do_read(bus, buf); + if (err) + goto out_free; err = sprom_check_crc(buf, bus->sprom_size); if (err) { /* try for a 440 byte SPROM - revision 4 and higher */ kfree(buf); buf = kcalloc(SSB_SPROMSIZE_WORDS_R4, sizeof(u16), GFP_KERNEL); - if (!buf) + if (!buf) { + err = -ENOMEM; goto out; + } bus->sprom_size = SSB_SPROMSIZE_WORDS_R4; - sprom_do_read(bus, buf); + err = sprom_do_read(bus, buf); + if (err) + goto out_free; err = sprom_check_crc(buf, bus->sprom_size); if (err) { /* All CRC attempts failed. Index: linux-2.6.34-12/drivers/ssb/sprom.c =================================================================== --- linux-2.6.34-12.orig/drivers/ssb/sprom.c +++ linux-2.6.34-12/drivers/ssb/sprom.c @@ -176,3 +176,18 @@ const struct ssb_sprom *ssb_get_fallback { return fallback_sprom; } + +/* http://bcm-v4.sipsolutions.net/802.11/IsSpromAvailable */ +bool ssb_is_sprom_available(struct ssb_bus *bus) +{ + /* status register only exists on chipcomon rev >= 11 and we need check + for >= 31 only */ + /* this routine differs from specs as we do not access SPROM directly + on PCMCIA */ + if (bus->bustype == SSB_BUSTYPE_PCI && + bus->chipco.dev && /* can be unavailible! */ + bus->chipco.dev->id.revision >= 31) + return bus->chipco.capabilities & SSB_CHIPCO_CAP_SPROM; + + return true; +} Index: linux-2.6.34-12/include/linux/ssb/ssb.h =================================================================== --- linux-2.6.34-12.orig/include/linux/ssb/ssb.h +++ linux-2.6.34-12/include/linux/ssb/ssb.h @@ -306,6 +306,7 @@ struct ssb_bus { u16 chip_id; u16 chip_rev; u16 sprom_size; /* number of words in sprom */ + u16 sprom_offset; u8 chip_package; /* List of devices (cores) on the backplane. */ Index: linux-2.6.34-12/include/linux/ssb/ssb_driver_chipcommon.h =================================================================== --- linux-2.6.34-12.orig/include/linux/ssb/ssb_driver_chipcommon.h +++ linux-2.6.34-12/include/linux/ssb/ssb_driver_chipcommon.h @@ -46,6 +46,7 @@ #define SSB_PLLTYPE_7 0x00038000 /* 25Mhz, 4 dividers */ #define SSB_CHIPCO_CAP_PCTL 0x00040000 /* Power Control */ #define SSB_CHIPCO_CAP_OTPS 0x00380000 /* OTP size */ +#define SSB_CHIPCO_CAP_SPROM 0x40000000 /* SPROM present */ #define SSB_CHIPCO_CAP_OTPS_SHIFT 19 #define SSB_CHIPCO_CAP_OTPS_BASE 5 #define SSB_CHIPCO_CAP_JTAGM 0x00400000 /* JTAG master present */ @@ -564,6 +565,7 @@ struct ssb_chipcommon_pmu { struct ssb_chipcommon { struct ssb_device *dev; u32 capabilities; + u32 status; /* Fast Powerup Delay constant */ u16 fast_pwrup_delay; struct ssb_chipcommon_pmu pmu; Index: linux-2.6.34-12/include/linux/ssb/ssb_regs.h =================================================================== --- linux-2.6.34-12.orig/include/linux/ssb/ssb_regs.h +++ linux-2.6.34-12/include/linux/ssb/ssb_regs.h @@ -170,7 +170,8 @@ #define SSB_SPROMSIZE_WORDS_R4 220 #define SSB_SPROMSIZE_BYTES_R123 (SSB_SPROMSIZE_WORDS_R123 * sizeof(u16)) #define SSB_SPROMSIZE_BYTES_R4 (SSB_SPROMSIZE_WORDS_R4 * sizeof(u16)) -#define SSB_SPROM_BASE 0x1000 +#define SSB_SPROM_BASE1 0x1000 +#define SSB_SPROM_BASE31 0x0800 #define SSB_SPROM_REVISION 0x107E #define SSB_SPROM_REVISION_REV 0x00FF /* SPROM Revision number */ #define SSB_SPROM_REVISION_CRC 0xFF00 /* SPROM CRC8 value */ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Jul 11, 2010 at 05:07:19PM -0500, Larry Finger wrote:
<snip> That looks very reasonable. Care to resend it to stable@kernel.org so that I can apply it to the next -stable release? Note, I'm travelling at the moment, so it will be a few days before I can get to this. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Greg Freemyer <greg.freemyer@gmail.com> [2010-07-09 20:57]:
Use nomodeset instead. And you need to manually switch to the "intellegacy" X.org driver or you will get the VESA one by default. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Jul 9, 2010 at 4:33 PM, Guido Berhoerster <guido+opensuse.org@berhoerster.name> wrote:
Thanks Guido, it works. (At least I have X. Not sure about what happens after it sleeps yet, but no reason to doubt the legacy driver.) If you or anyone knows where to document this fix in the wiki, I'd be happy to do so. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
* Greg Freemyer <greg.freemyer@gmail.com> [2010-07-09 23:11]:
Can you file a bug against the release notes instead? It should contain something along the lines "if you experience problems with Intel graphics hardware you can try disabling KMS by adding 'nomodeset' to the kernel parameters and adding 'Driver "intellegacy"' to /etc/X11/xorg.conf.d/50-device.conf". I can't use KMS either due to two other bugs and probably a lot of people using Intel hardware will run into bugs/regressions which might be worked around by disabling KMS and/or using the 2.9.1 driver. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
There is an uncorrectable problem with kernel 2.6.34 for some Netbook computers with Broadcom BCM4313 802.11b/g wireless devices. As this is the kernel in openSUSE 11.3, some users will be affected. The driver problem is fixed in kernel 2.6.35; however, the fix is too invasive to be backported to 2.6.34. The main problem with this bug is that the system freezes with no clue as to why it happens. It will happen for NET CD, DVD, and Live CD media. The workaround to prevent the freeze is simple; however, it will need to be distributed to users. What is the best way to make this information available to users? Sample text for the workaround follows: ==================================================================== Netbook computers with Broadcom BCM4312 wireless cards may freeze when booting any openSUSE 11.3 media. The way to circumvent this problem is to prevent loading the ssb module by adding the text "brokenmodules=ssb" text to the boot line before booting any DVD, Live CD or NET install CD. In addition to preventing the bug from freezing the computer during the boot process, this addition will lead to blacklisting ssb when the installed system is booted. To permit usage of the Broadcom wireless device after the system is installed, there are several options: (1) Install a 2.6.35 or later kernel. (2) Use the compat-wireless package for your kernel. Or (3) Install the Broadcom-wl package for your kernel. For either of the latter two options, your wireless will break whenever your kernel is updated. ===================================================================== Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Jul 10, 2010 at 11:56:31PM -0500, Larry Finger wrote:
Time to create http://en.opensuse.org/Bugs:Most_Annoying_Bugs_11.3 Or branch it from http://en.opensuse.org/Bugs:Most_Annoying_Bugs_11.3_dev I'm not sure if "to branch" is the right wording in wiki sprech. a) Don't limit the article to netbook computers. Even other systems using this hardware will suffer from the issue. b) Suggest the easier solutions first. Getting a 2.6.35 based kernel for 11.3 might be the harder way for the majority of users. The "For either of the latter two options, your wireless will break whenever your kernel is updated." I suggest to change into a "might break". The kernel update approach tries to circumvent this as good as possible. Here one of the kernel dudes might jump in and point us to the backround of the story. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On 07/11/2010 07:37 AM, Lars Müller wrote:
It seems that the particular "feature" that shows this issue is limited to Netbook motherboard design where the wireless chip is built in. If there is a separate PCIe card, then the problem does not occur.
b) Suggest the easier solutions first. Getting a 2.6.35 based kernel for 11.3 might be the harder way for the majority of users.
Thanks for the suggestion.
I am one of the b43 dudes, in fact, I found the fix once I got my hands on a unit with the problem. Unfortunately, it was too late for 2.6.34 and too invasive for 2.6.34.Y. The only hope would be to put this patch in the openSUSE collection, but that will may not be possible. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (16)
-
Andreas Jaeger -
Atri Bhattacharya -
Bernhard Walle -
Daniel Rahn -
Greg Freemyer -
Greg KH -
Guido Berhoerster -
Hans Witvliet -
jdd -
Ken Schneider - openSUSE -
Larry Finger -
Lars Müller -
medwinz -
medwinz -
Peter Nikolic -
Roman Bysh