Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

I have an Acer Timeline 1830T. When I install 10.10 and 11.04 it needs to have the acer-wmi module blacklisted for wireless to work.

I think I need to file a bug on the linux kernel but I am not sure. I've heard the term "quirk" being thrown around by developers when it comes to fixing something so that it works on certain pieces of hardware.

Is this indeed a kernel bug? What steps should I take to ensure that this gets reported so that everyone with my laptop doesn't have to go through this over and over?

share|improve this question
1  
Before filling a new bug please check if you your issue is related to bugs.launchpad.net/ubuntu/+source/linux/+bug/560464 . –  João Pinto Dec 9 '10 at 19:19
    
Thanks for the pointer, I am glad this is actually already been reported. –  Jorge Castro Dec 14 '10 at 15:49
    
the reason they don't just blacklist acer_wmi is that on some boards it works until you blacklist it...on other boards it doesn't work until you blacklist it - seemingly without rhyme or reason (note to Daniel's combination of factors statement). I believe they are trying to get it sorted out so it works with all combinations..or at least with latest BIOS and all HW combinations. Probably won't see it blacklisted out of the box. –  hbdgaf Jan 16 '11 at 3:45

3 Answers 3

up vote 9 down vote accepted

This is a kernel bug¹, so you'd want to use ubuntu-bug linux in a Terminal. You'd then want to modify the created bug report to add that you need to blacklist acer-wmi as a workaround for the wireless chipset not working as suspected.


¹ Technically it isn't a kernel bug but probably a combination of broken hardware, BIOS, and kernel drivers. On the upside, it probably can be hacked around in the kernel, hence the loose use of "kernel bug."

share|improve this answer

If you want it to go anywhere, don't just file a bug. Of course you should file a bug on Launchpad but that's really just the start of the process of something inherently upstream like this.

  • Find out what it does

    Look at the code find out what it's supposed to do. If you don't need it, why is it there? Is something else doing its job now? If it's something that's still in demand, why isn't it working for you?

    You'll quite often see hardware-specific software written for edge cases like a single range of laptops (eg there are dozens of various Thinkpad hardware drivers).

    According to its readme, the driver covers wireless, LEDs, bluetooth, 3g and the backlight. To me, it sounds like something you (or others) might want so having it dumped or blacklisted by default might not be desirable.

  • Find out how it got installed on your computer

    Where did it come from? Is it pulled into the kernel? Is it an Ubuntu pull? This will ultimately decide where you need to make your complaint.

    With kernel-level issues, it really helps to test the latest stable vanilla kernel. You can grab a copy from the mainline repository although you'll probably find there are GCC version mismatches with certain binary-only drivers (I have, with nvidia) so it's not something you'll want to run on all the time IMO.

    If the problem persists with a vanilla kernel, add a bug upstream and link it to the Launchpad bug and track it backwards too. A nice double-linked bug will help everybody stay on the same page.

    In this case, it sounds like it's an in-tree kernel driver (ie its source is pulled into the kernel repository and built in).

  • Find the person or people responsible for it

    It's not reasonable to just to dump a bug on Launchpad and hope it finds the right person. I would say only a small portion of developers track their bugs through it so you need to find the maintainers of the software and get in touch.

    It might feel rude to start cold-emailing people but the software is their baby. If it's not working, I think they'd like to know. Nine times in ten, they'll help you identify the problem too.

    If it's still maintained, get debugging instructions. Check to make sure your hardware is compatible.

    If it's not maintained, and you can confirm that with the old maintainer, file a bug in the kernel alerting people that there's a portion of code rotting and that it's causing you issues.

  • Suggest action to the right people

    When you know what the problem is, don't keep it to yourself. Make sure you take action on your bugs.

    If it's something that can be fixed in the driver, chase people in the kernel up to get the new version pulled into the development release. Ask about having it backported to 2.6.35 for existing Ubuntu users. Talk to the Kernel team about pulling in the changes to the Maverick kernel (though you might not have any luck there).

    If it's rotting, push the core kernel developers to dump it from their repo. Ask the Ubuntu kernel team developers to remove it from their repo. At the least, ask for it to be blacklisted (how some modules have been forcibly been removed by Ubuntu in the past).

    If you get good turnaround on fixing/destroying the driver, it should be possible to get its fix into the final Natty kernel (which is still at -next stage in the proper kernel repo).

The point I'm trying to get across is when you do your own triage and talk to the right people, things get so much more attention and have such a higher chance of a good end result.

And by no means stop if you see another person with the same problem. Subscribe to it, comment on their bug, ask what they've found, ask what they've done about it... And then carry on. Don't rely on them to get your problem solved.

This is how open source is supposed to work. Collaboration through good, open communication. Communicate your problem well, help where you can and you stand a good chance of getting better quality software.

share|improve this answer
    
Thanks for the formatting — it allowed me to just read the headers and skip most of the text. :P –  ulidtko Feb 13 '11 at 23:21

Speaking as a member of the Ubuntu Kernel Team, specifically as the 'Kernel Bug Guy', I agree with Daniel's answer as it is the sum of what the Engineers see being the total issue. This is not to discount Oli's answer.

In the realm of the highly technical end user, Oli's answer is completely true in that it is a set of the steps we would expect a person of considerable technical acumen to use, however, our intent (and indeed the entire purpose of this site) is to guide the less technical.

Our main goal must be to provide them with quick and accurate answers that allow them to continue using the software that we build. My favorite saying is, "If it isn't simple 'they' won't do it." The 'they' here referring to whomever the user is at the time.

Having said that, and given my personal admiration for the completeness of your post Oli, I have to be honest and say that there are very few readers of this site that will read all of it. They will likely not read all of mine, and that is fine.

In the end, Daniel's response is exactly what we need here. It conveys both my and the Team's impression of these issues as well as our preferred method to address.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.