Meu hardware precisa de um módulo para ser colocado na lista negra para funcionar, como posso obter essa correção enviada?

Question

Eu tenho uma Acer Timeline 1830T. Quando eu instalar o 10.10 e o 11.04, ele precisa ter o módulo acer-wmi na lista negra para que o wireless funcione .

Eu acho que preciso registrar um bug no kernel do Linux, mas não tenho certeza. Eu ouvi o termo "peculiar" sendo jogado por desenvolvedores quando se trata de consertar algo para que funcione em certas peças de hardware.

Isso é realmente um bug do kernel? Que medidas devo tomar para garantir que isso seja relatado para que todos os usuários do meu laptop não precisem passar por isso repetidas vezes?

    

Answer 1

Este é um bug do kernel¹, então você gostaria de usar ubuntu-bug linux em um Terminal. Em seguida, você deseja modificar o relatório de erros criado para adicionar que você precisa colocar blacklist acer-wmi como uma solução alternativa para o chipset sem fio não funcionar como suspeito.

¹ Tecnicamente não é um bug do kernel, mas provavelmente uma combinação de hardware quebrado, BIOS e drivers do kernel. No lado positivo, provavelmente ele pode ser hackeado no kernel, daí o uso frouxo do "bug do kernel".

    

Answer 2

Se você quiser ir a qualquer lugar, não apenas registre um bug . É claro que você deve registrar um bug no Launchpad, mas isso é apenas o começo do processo de algo inerentemente como este.

• Descubra o que faz

  Veja o código descubra o que ele deve fazer. Se você não precisa, por que está lá? Alguma outra coisa está fazendo o seu trabalho agora? Se é algo que ainda está em demanda, por que não está funcionando para você?

  Você frequentemente verá softwares específicos de hardware escritos para casos de borda como uma única gama de laptops (por exemplo, há dezenas de vários drivers de hardware do Thinkpad).

  De acordo com seu readme , o driver cobre wireless, LEDs, bluetooth, 3G e a luz de fundo. Para mim, soa como algo que você (ou outros) pode querer, por isso, tê-lo despejado ou na lista negra por padrão pode não ser desejável.

• Descubra como ele foi instalado no seu computador

  De onde veio isso? É puxado para o kernel? É um puxão do Ubuntu? Em última análise, isso decidirá onde você precisa fazer sua reclamação.

  Com problemas no nível do kernel, ele realmente ajuda a testar o kernel vanilla estável mais recente. Você pode pegar uma cópia do repositório da linha principal , embora você provavelmente descubra que existem incompatibilidades na versão do GCC com determinados drivers somente binários (eu tenho, com nvidia), então não é algo que você vai querer rodar o tempo todo em IMO.

  Se o problema persistir com um kernel vanilla, inclua um bug no upstream e vincule-o ao bug do Launchpad e rastreie-o de volta também. Um bom bug de link duplo ajudará todos a ficarem na mesma página.

  Neste caso, parece que é um driver de kernel na árvore (ou seja, sua origem é inserida no repositório do kernel e incorporada).

• Encontre a pessoa ou pessoas responsáveis por ela

  Não é razoável apenas descarregar um bug no Launchpad e esperar que ele encontre a pessoa certa. Eu diria que apenas uma pequena parte dos desenvolvedores rastreiam seus bugs, então você precisa encontrar os mantenedores do software e entrar em contato.

  Pode parecer indelicado começar a enviar emails por e-mail, mas o software é o bebê deles. Se não estiver funcionando, acho que eles gostariam de saber. Nove vezes em dez, eles ajudarão você a identificar o problema também.

  Se ainda for mantido, obtenha instruções de depuração. Verifique se o seu hardware é compatível.

  Se não for mantido, e você pode confirmar isso com o antigo mantenedor, arquive um bug no kernel alertando as pessoas que há uma parte do código em decomposição e que está causando problemas.

• Sugira uma ação para as pessoas certas

  Quando você sabe qual é o problema, não guarde para si mesmo. Certifique-se de agir em seus bugs.

  Se é algo que pode ser corrigido no driver, persiga as pessoas no kernel para que a nova versão seja puxada para a versão de desenvolvimento. Pergunte sobre tê-lo backported para 2.6.35 para usuários existentes do Ubuntu. Fale com a equipe do Kernel sobre as mudanças no kernel do Maverick (embora você não tenha tido sorte).

  Se estiver em apodrecimento, pressione os desenvolvedores do núcleo para despejá-lo de seu repositório. Peça aos desenvolvedores da equipe de kernel do Ubuntu para removê-lo do repositório deles . No mínimo, peça que esteja na lista negra (como alguns módulos foram removidos à força pelo Ubuntu no passado).

  Se você tiver uma boa recuperação para consertar / destruir o driver, deverá ser possível obter sua correção no kernel Natty final (que ainda está no estágio -next no repositório correto do kernel) .

O ponto que estou tentando transmitir é quando você faz sua própria triagem e fala com as pessoas certas, as coisas recebem muito mais atenção e têm uma chance maior de um bom resultado final.

E de jeito nenhum pare se você vir outra pessoa com o mesmo problema. Inscreva-se, comente sobre o bug deles, pergunte o que eles encontraram, pergunte o que eles fizeram sobre isso ... E então continue. Não confie neles para resolver seu problema.

É assim que o código aberto deve funcionar. Colaboração através de uma comunicação boa e aberta. Comunique bem seu problema, ajude onde puder e você terá uma boa chance de obter um software de melhor qualidade.

    

Answer 3

Falando como um membro da Equipe do Kernel do Ubuntu, especificamente como o 'Kernel Bug Guy', eu concordo com Resposta de Daniel , pois é a soma do que os Engenheiros veem como sendo o problema total. Isso não é para desconto Oli's answer .

No campo do usuário final altamente técnico, a resposta de Oli é completamente verdadeira, pois é um conjunto de passos que esperamos que uma pessoa de considerável perspicácia técnica use, no entanto, nossa intenção (e de fato o objetivo inteiro de este site) é orientar os menos técnicos.

Nosso principal objetivo deve ser fornecer respostas rápidas e precisas que permitam que eles continuem usando o software que criamos. Meu ditado favorito é: "Se não for simples, eles não farão isso". O 'they' aqui se refere a quem quer que seja o usuário no momento.

Tendo dito isto, e dado a minha admiração pessoal pela integridade do seu post Oli, tenho que ser honesto e dizer que há muito poucos leitores deste site que lerão tudo isso. Eles provavelmente não vão ler todos os meus, e está tudo bem.

No final, a resposta de Daniel é exatamente o que precisamos aqui. Ela transmite a impressão da minha equipe e da equipe sobre esses problemas, bem como nosso método preferido de abordar.