[FreeBSD 5.3] Reboots - probleem met NIC?

[Demo]

Een tijdje terug ben ik als *Nix-n00b begonnen om een FreeBSD-server op te zetten. Afgezien van wat f*ckups door mijzelf heeft die de afgelopen maanden super stabiel gedraaid, maar gisteravond kreeg ik ineens een spontane reboot Toen ie opnieuw gestart was, kreeg ik na een minuut of 10 wederom een reboot. Ik heb toen de server aan een monitor en toetsenbord gehangen (normaal staat ie in een hoekje en beheer ik hem via PuTTY) en heb gewacht tot ie weer vast liep. Dat leverde de volgende foutmelding op:

code:

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 00
fault virtual address = 0x8
fault code            = supervisor read, page not present
instruction pointer   = 0x8:0xc0494e89
stack pointer         = 0x10:0xd4008c74
frame pointer         = 0x10:0xd4008c74
code segment          = base 0x0, limit 0xfffff, type 0x1b
                      = DPL 0, pres 1, def32 1, gran 1
processor eflags      = interrupt enabled, resume, IOPL = 0
current process    = 21 (irc10: nge0)
trap number           = 12
panic: page fault
cpuid = 1
boot() called on cpu#1
Uptime: 9m58s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort

Nou heb ik er dus nog niet veel verstand van, maar door de regel current process = 21 (irc10: nge0) kreeg ik het idee dat de netwerkkaart de dader was, dus ben ik daar eens mee gaan rommelen. Het commando ifconfig geeft de volgende output:

code:

nge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=13<RXCSUM,TXCSUM,VLAN_HWTAGGING>
    inet 10.0.0.5 netmask 0xffffff00 broadcast 10.0.0.255
    inet6 fe80::204:5aff:fe51:33c9%nge0 prefixlen 64 scopeid 0x1
    ether 00:04:5a:51:33:c9
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    inet 127.0.0.1 netmask 0xff000000
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

echter als ik probeer om te pingen, zowel naar een andere PC in mijn netwerk als localhost dan krijg ik de melding "No route to host". Heeft iemand enig idee in welke hoek ik dit zou moeten zoeken? De hardware van mijn server is het volgende:

code:

HP NetServer LH3
Dual P2-400
512 MB PC100 SDRAM ECC Registered
4 x 18 GB SCSI hot-swappable RAID5
HP SureStore DAT24 tapedrive
Linksys EG1064 64-bit PCI 1000BaseT netwerkkaart

Allemaal oude meuk, behalve de netwerkkaart. Die heb ik er een paar maanden terug zelf in gezet.

[Verwijderd]

Hoe ziet je routing tabel eruit (netstat -rn) en draai je firewalling software?

[Demo]

Ik draai IPFilter, maar tot op heden bestaat mijn ipf.rules enkel uit:

code:

pass in quick all
pass out quick all

Dat kan dus haast niet het probleem zijn.

netstat -rn geeft mij het volgende:

code:

Internet:
Destination  Gateway    Flags  Refs  Use  Netif  Expire
10/24        link#2     UC        0    0   nge0
127.0.0.1    127.0.0.1  UH        0    0   lo0

En ook nog wat IPv6 meuk, maar daar maak ik geen gebruik van, dus ik neem aan dat ik dat weg kan laten..

edit:
Ik heb net dmv ipf -Fa -f /etc/ipf.rules de rules handmatig geladen en dan kan ik ineens wel pingen. Ik had alles dat via /etc/rc.conf automatisch opstart uitgeschakeld. Echter een minuut later krijg ik weer een foutmelding en bijbehorende reboot voor mijn neus

[ Voor 25% gewijzigd door Demo op 10-05-2005 16:48 ]

[Demo]

Ik heb gisteravond de RAID-controller een consistency check laten doen op de disk-array, maar daar kwamen geen fouten naar boven. MemTest86 heeft inmiddels 10 uur lang het geheugen gecontroleerd en ook nog steeds geen enkele error gevonden.

[r0b]

http://lists.freebsd.org/...2004-December/068059.html

Daar wordt gesproken over een driver probleem. Heb je dit al uitgesloten?

[Demo]

Het lijkt er heel erg op dat dit inderdaad hetzelfde probleem is.. helaas staat er in deze tekst niet echt een oplossing? Het probleem was toen blijkbaar al verholpen in 5.3-CURRENT, zal dat dan ook zo zijn in de nieuwe 5.4-RELEASE?
Ik zal de NIC er eens uit trekken en er een andere (Intel Pro100) in steken, dan kan ik de server in ieder geval weer online gooien. In ieder geval bedankt!

[Demo]

*schopje*
Ik heb inmiddels geüpgrade naar FreeBSD 5.4 en zojuist de netwerkkaart er weer in gezet, maar hij blijft kernel panic's geven Ik acht de kans zeer groot dat het hetzelfde probleem is als in de link die eXoR postte, maar daar werd niet echt een oplossing gegeven. Wat zou ik hier aan kunnen doen?

[AVL]

Ik zie dat er in -CURRENT een fix is doorgevoerd die wel eens de oplossing van jouw probleem zou kunnen zijn, zie de CVS commit log.

Ik weet niet hoe goed je thuis bent in C en het aanpassen van broncode, maar je zou eens moeten proberen om de veranderingen in versie 1.73 van if_nge.c (zie de diff) door te voeren in de if_nge.c die bij FreeBSD 5.4 zit. Hercompileer daarna je kernel, en kijk of het probleem is opgelost.

Ik maak het je nog wat makkelijker. Ik heb een diffje voorbereid met de sourcecode van 5.4. Gebruik het als volgt:

code:

# cd /usr/src/sys/dev/nge
# fetch http://www.piwebs.com/freebsd/if_ngc.c.diff
# patch < if_ngc.c.diff

Hercompileer dan je kernel.

[ Voor 23% gewijzigd door AVL op 19-05-2005 23:40 ]

[Demo]

Ik weet helemaal niks van C, maar ik zal dit eens proberen. Ik heb vandaag de sources door zitten kijken en het komt niet helemaal als abacadabra op me over (heb wel wat ervaring in andere talen ) dus het zal me wel lukken Alvast bedankt!

Overigens stond in die mailinglist ook dat het in 5.3-CURRENT waarschijnlijk al was verholpen, waarom is dat dan niet doorgevoerd in 5.4?

[AVL]

Demoniac schreef op vrijdag 20 mei 2005 @ 00:34:
Ik weet helemaal niks van C, maar ik zal dit eens proberen. Ik heb vandaag de sources door zitten kijken en het komt niet helemaal als abacadabra op me over (heb wel wat ervaring in andere talen ) dus het zal me wel lukken Alvast bedankt!

Overigens stond in die mailinglist ook dat het in 5.3-CURRENT waarschijnlijk al was verholpen, waarom is dat dan niet doorgevoerd in 5.4?

Nah, dat kan niet. 5.3-CURRENT bestaat niet en heeft nooit bestaan. Alle wijzigingen worden eerst doorgevoerd in -CURRENT (6-CURRENT op dit moment), en vallen na testen vaak door naar -STABLE (5-STABLE). Eens in de zoveel tijd wordt er een afsplitsing van -STABLE gemaakt, en dat is de -RELEASE.

De fix die je hier ziet zit al wel in -CURRENT, maar nog niet in -STABLE, en dus al helemaal niet in een -RELEASE . Als het werkt voor je, stuur dan een mailtje naar de maker van de patch of een relevante mailing list ([e-mail]) met de vraag of deze patch zo snel mogelijk ge'MFC-ed mag worden ('Merge From Current'). De fix komt dan terecht in -STABLE, en zal dan ook in de eerstvolgende -RELEASE zitten.

[Demo]

De nieuwe kernel is gebakken en geïnstalleerd, en het ziet er naar uit dat het allemaal werkt Heel erg bedankt