Qualquer outra coisa que não se encaixou em outro lugar é colocada aqui. Pode não ser relevante, e pode não ser de interesse geral mas está aqui de qualquer forma.
Aqui estão dois comandos genéricos do kernel que podem ser passados para o kernel durante o boot. Isto pode ser feito com LILO, loadlin ou qualquer outro utilitário de boot que aceite argumentos opcionais.
Por exemplo, se o comando era `blah' e ele esperava 3 argumentos (por exemplo 123, 456 e 789) então, com o LILO, você usaria:
LILO: linux blah=123,456,789
Note: placas PCI tem sua porta de i/o e IRQ atribuidos pelo BIOS durante o boot. Isto significa que quaisquer argumentos de tempo de boot para o IRQ ou porta de i/o para uma placa PCI são geralmente ignorados.
Para mais informações (e uma lista completa) sobre argumentos de tempo de boot, por favor veja o BootPrompt-HOWTO
ether
Em sua forma mais genérica, ele fica mais ou menos assim:
ether=IRQ,BASE_ADDR,PARAM_1,PARAM_2,NAME
Todos os argumentos são opcionais. O primeiro argumento não-numérico é tomado como sendo o NAME.
IRQ: Óbvio. Um valor de IRQ igual a `0' (Usualmente o default) significa autoIRQ. É um acidente histórico que a configuração de IRQ aparece primeiro, no lugar do BASE_ADDR -- isto será corrigido quando qualquer outra coisa mude.
BASE_ADDR: Também óbvio. Um valor igual a `0' (usualmente o default) significa tente detectar uma lista de endereços específicos de placa para uma placa ethernet.
PARAM_1: Foi originalmente usado como um valor alternativo para o início da memória em uma placa ethernet com memória compartilhada, como as WD80*3. Alguns drivers usam os últimos 4 bits deste valor para setar o nível de mensagens de debug. 0 -- default, 1-7 -- nível 1..7, (7 é o máximo de verbosidade) 8 -- nível 0 (sem mensagens). Outra coisa, o driver LANCE usa os últimos 4 bits deste valor para selecionar o canal de DMA. De outra forma ele usa auto-DMA.
PARAM_2: O driver 3c503 o usa para selecionar entre transceiver interno e externo. 0 -- default/interno, 1 -- AUI externo. A placa Cabletron E21XX também usa os últimos 4 bits do PARAM_2 para selecionar o meio de saida. De outra forma ele o detecta automaticamente.
NAME: Seleciona o dispositivo de rede que os valores referenciam. O kernel padrão usa os nomes `eth0', `eth1', `eth2' e `eth3' para placas conectadas ao bus, e `atp0' para o adaptador ethernet `pocket' de parta paralela. O driver arcnet usa `arc0' como seu nome. A configuração é que somente uma única placa ethernet será auto-detectada para ser a `eth0'. Um sistema com várias placas somente pode ser habilitado através da explícita configuração de seu endereço base através de parâmetros do LILO. O kernel 1.0 trata placas ethernet baseadas no chipset LANCE como um caso especial. Argumentos LILO são ignorados, e as placas LANCE sempre tem nomes `eth<n>' atribuidos, começando por `eth<0>'. Placas ethernet não LANCE adicionais devem ser atribuidas explícitamente a `eth<n+1>', e a tentativa de auto-detecção usual `eth0' deve ser desabilitada com alguma coisa como `ether=0,-1,eth0'. ( Sim, isto é um bug. )
reserve
Este comando lilo é usado da mesma forma que o `ether=' acima, ie. ele é adicionado ao nome do seletor de boot especificado no lilo.conf
reserve=IO-base,extent{,IO-base,extent...}
Em algumas máquinas pode ser necessário evitar que drivers de dispositivo chequem por dispositivos (auto-probing) em uma região específica. Isto pode ser devido a hardware mal projetado que causa o travamento durante o boot (como algumas placas ethernet), hardware que é identificado errôneamente, hardware cujo estado é mudado por uma tentatica de auto-detecção anterior, ou meramente hardware que você não quer que o kernel inicialize.
O argumento de tempo de boot reserve trata deste problema especificando
uma região de portas de I/O que não deve ser usada no processo de
auto-detecção. Esta região é reservada na tabela de registro de portas do
kernel como se um dispositivo já tivesse sido encontrado nesta região. Note
que este mecanismo não deve ser necessário para a maioria das máquinas.
Somente quando existe um problema ou caso especial será necessário usar isto.
As portas de I/O na região especificada são protegidas contra tentativas
de detecção de dispositivos. Isto foi implementado para ser usado quando
algum driver estava travando numa NE2000, ou identificando errôneamente
algum outro dispositivo como sendo um dos que controla. Um driver
de dispositivo correto não deve tentar auto detecção em uma região
reservada, a menos que outro argumento de boot explicitamente especifique
que ele assim deve fazer. Isto implica que reserve irá ser usado
na maioria das vezes com outro argumento de boot. Desta forma, se você
especifica um região com reserve para proteger um dispositivo
específico, você deve geralmente especificar uma tentativa de auto-detecção
explícita para este dispositivo. A maioria dos drivers ignora esta tabela
de registro de portas se recebem um endereço explícito.
Por exemplo, a linha de boot
LILO: linux reserve=0x300,32 ether=0,0x300,eth0
Faz com que todos os drivers de dispositivo não acessem a região 0x300-0x31f, exceto os drivers de placas ethernet.
Como usual com especificadores de tempo de boot existe um limite de
11 parâmetros, desta forma você só pode especificar 5 regiões reservadas
por cada reserve.
Múltiplos especificadores reserve funcionarão se você tem uma
requisição inusualmente complicada.
Veja o manual do utilitário insmod(8) para obter informações
sobre a passagem de argumentos para o módulo quando este está
sendo carregado. O comando lsmod lhe mostrará os módulos
que estão carregados, e rmmod irá removê-los.
Atualmente todos os módulos são colocados no subdiretório
modules nos fontes do kernel do linux (usualmente sob a forma
de links simbólicos). Para gerar os módulos, você terá que digitar
make modules após a construção do próprio kernel. Kernels
anteriores os construiam automaticamente, o que não era justo
para os que compilam o kernel em máquinas 386sx-16 com 4MB.
A maioria dos módulos aceitam parâmetros como io=0x340 e
irq=12 na linha de comando do insmod.
É MUITO ACONSELHÁVEL que você forneça estes parâmetros para evitar o
probing na placa. Diferentemente dos dispositivos PCI e EISA,
não existe maneira segura de fazer auto-detecção em dispositivos
ISA. e desta forma deve ser evitado quando se usa os drivers como
módulos.
Uma lista de todos os parâmetros que cada módulo aceita pode ser encontrada no arquivo:
/usr/src/linux/Documentation/networking/net-modules.txt
É recomendado que você leia este documento para descobrir que opções você pode usar para sua placa.
Uma vez que você tenha descoberto os argumentos/opções que você usará, você pode carregar o módulo, digitando o seguinte como root:
insmod mod_name.o [io=val1[,val2,...]] [irq=val7[,val8,...]]
Uma vez que o módulo tenha sido carregado, você poderá então usá-lo
normalmente, e executar comandos ifconfig. Se você configura sua
rede no boot, então certifique-se de que seus arquivos /etc/rc*/
rodam o(s) comando(s) insmod antes de chegar ao comando ifconfig.
Também note que um módulo que está sendo usado não pode ser removido.
Isto significa que você terá que executar ifconfig eth0 down (dar um
shutdown na placa ethernet) antes que você possa remover o(s) módulo(s).
A lista atual de drivers baseados em 8390 é: 3c503, ac3200, e2100, hp, hp-plus, ne, smc-ultra e wd. Estas placas não são suportadas como módulos para os kernels anteriores à versão 1.3.42. (Isto não inclue alguns dos drivers PCMCIA distribuidos separadamente (ex. de-650) que também são baseados no 8390, que tem suporte a módulos a bastante tempo.)
Se você tem uma placa baseada em 8390, você terá que carregar
dois módulos, 8390.o e depois o módulo para sua placa.
Se suporte a 8390 foi incluido na construção de seu kernel, você
não precisará carregar o módulo 8390. (O suporte a 8390 é incluido
sempre que uma placa baseada em 8390 é selecionada para ser incluida
na construção do kernel.) Executando cat /proc/ksyms | grep 8390
lhe dirá se você tem suporte a 8390 em seu kernel.
Para uma placa baseada no 8390, você terá que remoder o módulo da placa antes de remover o módulo 8390, pois como o módulo 8390 é usado pelo módulo da placa, ele é marcado como ocupado.
A série de drivers de rede 8390 agora suporta sistemas com várias placas sem recarregar o mesmo módulo várias vezes (eficiência no uso da memória!). Isto é feito especificando vários valores separados por vírgulas, como aqui:
insmod 3c503.o io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
O comando acima usará um único módulo controlando quatro placas 3c503m, com as placas 2 e 4 usando transceivers externos.
É *ALTAMENTE RECOMENDADO* que você forneça "io=" no lugar da auto-detecção. Se um argumento "io=" não é fornecido, então os drivers ISA 8390 vão reclamar que a auto-detecção não é recomendada, e vão tentar fazer auto-detecção para *SOMENTE UMA PLACA* -- se você quer usar várias placas você *tem* que fornecer um argumento "io=0xNNN,0xQQQ,...".
O módulo ne é uma excessão ao que foi dito acima. Uma NE2000
é essencialmente um chip 8390, com algum mecanismo de
conexão ao barramento ISA e alguma memória RAM. Por isso,
a tentativa de auto-detecção ne é mais invasiva do que os
demais, e desta forma durante o boot nos certificamos de
que a tentativa de auto-detecção ne é feita depos que
todos os das demais placas baseadas no 8390 ( de forma que ela
não passeie pelas outras placas baseadas no 8390). Usando
módulos nos não conseguimos garantir que todas as outras
placas não ne baseadas no 8390 já foram encontradas. Devido
a isso, o módulo ne EXIGE um argumento io=0xNNN lhe
seja fornecido via insmod. Ele recusará a tentativa
de auto-detecção.
ne
Também vale a pena notar que o processo de auto-IRQ provavelmente
não é confiável durante a evervescente atividade de interrupções
numa máquina em funcionamento. Placas como a ne2000 que não
conseguem obter a configuração de IRQ em uma EEPROM ou
registro de configuração são provalmente melhor configuradas com
um argumento irq=M. O arquivo
/usr/src/linux/Documentation/networking/net-modules.txt
também lista como a configuração de interrupcão é determinada
para as várias placas se um valor irq=N não é fornecido.
Se você tem questões sobre sua placa ethernet, por favor LEIA este
documento primeiro. Você pode também querer ingressar no canal
NET das listas de discussão sobre o Linux enviando uma mensagem
para majordomo@vger.rutgers.edu para conseguir ajuda sobre
que listas estão disponíveis e como se inscrever nelas.
Mais ainda, tenha em mente que o canal NET é somente para discussões sobre desenvolvimento. Questões gerais sobre como configurar seu sistema devem ser direcionadas para o newsgroup com.os.linux.setup a menos que você esteja ativamente envolvido no desenvolvimento de uma parte do suporte a redes do Linux. Nós pedimos que você por favor respeite esta regra geral para conteúdo de mensagens.
Também os newsgroups comp.sys.ibm.pc.hardware.networking e comp.dcom.lans.ethernet devem ser usados para questões que não sejam específicas ao Linux.
A maioria destas informações veio de mensagens salvas dos grupos comp.os.linux, o que mostra que estes são uma valiosa fonte de informações. Outras informações úteis vieram de um monte de pequenos arquivos escritos pelo próprio Donald. Naturalmente, se você está configurando uma placa ethernet, você irá querer ler o NET-2-HOWTO para que você possa configurar o software que irá usar. Também, se você se vê um hacker, você pode desencavar alguma informação adicional no próprio arquivo fonte do driver. Geralmente existem um parágrafo ou dois nele descrevendo quaisquer pontos importantes antes do código começar.
Para aqueles procurando por informações não específico ao Linux (i.e. o que é 10BaseT, o que é AUI, o que um hub faz, etc.) eu fortemente recomendo o Ethernet-FAQ que é postado regularmente no newsgroup comp.dcom.lans.ethernet. Você pode obtê-lo no RTFM que mantém todos os FAQs de newsgroups na seguinte URL:
You can also have a look at the `Ethernet-HomePage' so to speak, which is at the following URL:
Você também pode dar uma olhada na `Ethernet-HomePage' por assim dizer, que está na seguinte URL:
Outras pessoas que contribuiram (direta ou indiretamente) para o Ethernet-Howto são, em ordem alfabética:
Ross Biro <bir7@leland.stanford.edu>
Alan Cox <iialan@www.linux.org.uk>
David C. Davies <davies@wanton.enet.dec.com>
Bjorn Ekwall <bj0rn@blox.se>
David Hinds <dhinds@allegro.stanford.edu>
Michael Hipp <mhipp@student.uni-tuebingen.de>
Mike Jagdis <jaggy@purplet.demon.co.uk>
Duke Kamstra <kamstra@ccmail.west.smc.com>
Russell Nelson <nelson@crynwr.com>
Cameron Spitzer <camerons@NAD.3Com.com>
Dave Roberts <david.roberts@amd.com>
Glenn Talbott <gt@hprnd.rose.hp.com>
Muito obrigado às pessoas acima, e a todos os outros testadores não mencionados.
Este documento não é not gospel. Entretanto, é provavelmente a fonte de informações mais atualizada que você será capaz de encontrar. Ninguém é responsável pelo que acontece no seu hardware além de você. Se sua placa ethernet ou qualquer outro hardware se transformar em fumaça (...quase impossível!) nós não temos nenhuma responsabilidade. ie. OS AUTORES NÃO SÃO RESPONSÁVEIS POR QUAISQUER DANOS QUE OCORRAM DEVIDO A AÇÕES TOMADAS BASEADAS NAS INFORMAÇÕES PRESENTES NESTE DOCUMENTO.
n.t. NEM O TRADUTOR!
Este documento tem Copyright (c) 1993. 1994. 1995, 1996 de Donald Becker e Paul Gortmaker. Permissão é dada para fazer e distribuir cópias identicas deste manual, desde que a nota de copyright e esta nota de permissão sejam preservadas em todas as cópias.
Permissão é dada para copiar e distribuir versões modificadas deste documentos sob as condições de cópia sem modificações, desde que esta nota de copyright seja inclusa exatamente como no original, e que todo o trabalho resultante seja distribuida sob os termos de uma nota de permissão idêntica a esta.
Permissão é dada para copiar e distribuir traduções deste documento em outra língua, sob as condições acima para versões modificadas.
Se você pretente incorporar este documento em um trabalho publicado, por favor me contate, e irei fazer o esforço para certificar que você tenha as informações mais atualizadas disponíveis. No passado, versões desatualizadas de documentos howto do Linux foram publicados, o que causou aos desenvolvedores um incômodo não merecido de ser bombardeados com questões que já tinham sido respondidas nas versões mais atualizadas.
This document is not gospel. However, it is probably the most up to date info that you will be able to find. Nobody is responsible for what happens to your hardware but yourself. If your ethercard or any other hardware goes up in smoke (...nearly impossible!) we take no responsibility. ie. THE AUTHORS ARE NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THE INFORMATION INCLUDED IN THIS DOCUMENT.
This document is Copyright (c) 1993, 1994, 1995 1996 by Donald Becker and Paul Gortmaker. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided that this copyright notice is included exactly as in the original, and that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this document into another language, under the above conditions for modified versions.
If you are intending to incorporate this document into a published work, please contact me, and I will make an effort to ensure that you have the most up to date information available. In the past, out of date versions of the Linux howto documents have been published, which caused the developers undue grief from being plagued with questions that were already answered in the up to date versions.
Se você encontrou algum erro de digitação, ou informação desatualizada neste documento, por favor nos diga. Está se tornando grande, e é fácil ficar algo desapercebido.
Obrigado,
Paul Gortmaker, Paul.Gortmaker@anu.edu.au
Donald J. Becker, becker@cesdis.gsfc.nasa.gov
Se você encontrar algum erro de tradução ou mesmo sugerir uma tradução melhor para algum trecho, entre em contato comigo.
Obrigado,
Arnaldo Carvalho de Melo, acme@conectiva.com.br