On Fri, Jan 11, 2008 at 06:07:18PM +0300, Denis Kirienko wrote: > 2: eth3: mtu 1500 qdisc noop qlen 1000 > link/ether 00:1b:fc:5a:2d:34 brd ff:ff:ff:ff:ff:ff [...] > Теперь загружаем ядро 2.6.18-alt7: [...] > 2: eth3: mtu 1500 qdisc noop qlen 1000 > link/ether 00:13:74:00:5c:38 brd ff:ff:ff:ff:ff:ff [...] > У интерфейса eth3 mac-адрес ДРУГОЙ! А он вписан в /etc/net/iftab, > соответственно, после замены mac-адреса в iftab ядро 2.6.8-alt10 c > модулем atl1 заработало. > > Но я не понимаю, почему у интерфейса меняется mac-адрес в зависимости от > загружаемого ядра? Адрес 00:13:74:00:5c:38 был прошит в драйвере atl1 1.0.41.0 (который был собран для ядра 2.6.18-std-smp-alt7) в качестве адреса по умолчанию, если при попытке чтения MAC-адреса обнаруживалась ошибка: if (get_permanent_address(hw)) { // for test hw->perm_mac_addr[0] = 0x00; hw->perm_mac_addr[1] = 0x13; hw->perm_mac_addr[2] = 0x74; hw->perm_mac_addr[3] = 0x00; hw->perm_mac_addr[4] = 0x5c; hw->perm_mac_addr[5] = 0x38; } К моменту сборки ядра 2.6.18-std-smp-alt10 драйвер atl1 был обновлён до 1.2.40.0; в этой версии аналогичный код тоже есть, но адрес по каким-то причинам был изменён на 00:13:74:00:11:08. Однако новая версия драйвера, похоже, теперь читает адрес правильно - во всяком случае, OUI 00:1b:fc принадлежит ASUSTek COMPUTER INC. На всякий случай посмотрите, какой MAC-адрес написан на наклейке на материнской плате, или хотя бы сравните адрес с тем, который определяется в Windows. Вероятно, на этой плате отсутствует чип EEPROM, подключенный к сетевому контроллеру, в котором должен был бы храниться MAC-адрес, а вместо этого настройки хранятся где-то в другом месте, известном только BIOS. Новая версия драйвера atl1 при невозможности прочитать EEPROM или SPI FLASH пытается использовать текущий адрес, установленный в регистрах чипа - в данном случае это срабатывает, но может дать неверный результат, если сменить MAC-адрес утилитой ip, после чего выгрузить и вновь загрузить модуль (вероятно, в этом случае исходный адрес будет потерян).