[Samba] machine hangt tijdens kopieren naar share

[Verwijderd]

Ik heb Samba 2.2.8a op een Redhat 7.1 machine draaien.

Zodra ik vanaf een XP machine files kopier naar een Samba share hangt de redhat 7.2 machine als het ware iedere paar seconde. Als ik een ping open zie je ook de timeouts. Na een paar seconde komt de ping terug, en gaat de kopie door tot de volgende timeout, enz.

Reply from 192.168.0.5: bytes=32 time=2ms TTL=255
Reply from 192.168.0.5: bytes=32 time=5ms TTL=255
Reply from 192.168.0.5: bytes=32 time<1ms TTL=255
Reply from 192.168.0.5: bytes=32 time=2ms TTL=255
Reply from 192.168.0.5: bytes=32 time<1ms TTL=255
Request timed out.
Reply from 192.168.0.5: bytes=32 time=513ms TTL=255
Request timed out.
Reply from 192.168.0.5: bytes=32 time=1490ms TTL=255
Reply from 192.168.0.5: bytes=32 time<1ms TTL=255
Reply from 192.168.0.5: bytes=32 time=1208ms TTL=255
Reply from 192.168.0.5: bytes=32 time=1ms TTL=255
Reply from 192.168.0.5: bytes=32 time=4ms TTL=255
Reply from 192.168.0.5: bytes=32 time=3ms TTL=255
Request timed out.
Reply from 192.168.0.5: bytes=32 time=965ms TTL=255
Reply from 192.168.0.5: bytes=32 time=51ms TTL=255
Reply from 192.168.0.5: bytes=32 time=401ms TTL=255
Reply from 192.168.0.5: bytes=32 time<1ms TTL=255
Reply from 192.168.0.5: bytes=32 time=2ms TTL=255
Reply from 192.168.0.5: bytes=32 time=1ms TTL=255
Reply from 192.168.0.5: bytes=32 time=3ms TTL=255

smb.conf:

[global]
workgroup = Domain
netbios name = Redhat
security = DOMAIN
encrypt passwords = Yes
password server = DC01
log level = 3
log file = /usr/local/samba/var/samba.log
socket options = TCP_NODELAY IPTOS_LOWDELAY
wins server = DC01
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind separator = +

[users]
path = /data
writeable = yes
comment = Data
valid users = DC+rednar


Ik heb ook deze opties al geprobeerd:

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=16384
read raw = yes

[imdos]

Wat voor machine is het qua hardware? En zit er toevallig een realtek netwerkkaartje in?

[_JGC_]

socket options=SO_RCVBUF=8192 SO_SNDBUF=8192 TCP_NODELAY

daarmee blaast Samba hier met gemak een stel NT4 servers met veel meer en snellere hardware eruit (lees: serveren vanaf een 5400RPM disk in een P3 733 met 128MB gaat sneller dan vanaf een 7200RPM disk in een Athlon XP 1800+ met 512MB )
Verder denk ik dat je netwerkkaart ook een rol kan spelen, of iig de drivers ervan. Welke netwerkkaart gebruik je, en welke kerneldrivers gebruik je daarbij. Verder: is die kernel zelf gebouwd, of is het zo'n brakke redhat standaardkernel.

[|orion]

probeer eens

code:

hdparm -cd /dev/hda

en tik de restultaten eens over. Ik heb zo'n idee dat je dma uit staat. Ik had dezelfde problemen en toen ik

code:

hdparm -c1 -d1 /dev/hda

deed was alles ineens over, en (ook niet onbelangrijk) de transfer speeds gingen omhoog van 1 MB/sec naar 5 MB/sec

_{Was overigens wel linux-->linux}

[Verwijderd]

Het gaat om een Dual PIII 866 op een Intel bordje. De netwerkkaarten zijn Intel.

Ik zal straks HDParm en de socket option suggesties proberen en posten hoe dat ging.

[_JGC_]

kernel 2.4.20 downloaden en compilen, kiezen voor de e100 driver ipv de eepro driver. Die normale eepro driver zuigt. e100 is door Intel zelf gemaakt en zit sinds 2.4.20 bij de kernel.

[Arzie]

_JGC_ schreef op 18 april 2003 @ 15:34:
kiezen voor de e100 driver ipv de eepro driver. Die normale eepro driver zuigt. e100 is door Intel zelf gemaakt en zit sinds 2.4.20 bij de kernel.

Heb je hier ook argumenten voor? Ik draai al tijden met de eepro driver, en ik heb er eigenlijk geen enkel probleem mee gehad. SMB acties van en naar een Windows-PC gaan met iets van 9 MB/sec max.

[Verwijderd]

HD Parm resultaten:

hdparm -cd /dev/hda:

/dev/hda:
I/O support = 0 (default 16-bit)
using_dma = 0 (off)

hdparm -c1 -d1 /dev/hda

/dev/hda:
setting 32-bit I/O support flag to 1
setting using_dma to 1 (on)
I/O support = 1 (32-bit)
using_dma = 1 (on)

DMA staat nu aan. Zal nog eens proberen. Heb ook de socket options aangepast.
Als dit nog niet verbeterd zal ik eens een 3com 90x kaartje proberen.

[_JGC_]

Arzie schreef op 18 April 2003 @ 17:34:
[...]


Heb je hier ook argumenten voor? Ik draai al tijden met de eepro driver, en ik heb er eigenlijk geen enkel probleem mee gehad. SMB acties van en naar een Windows-PC gaan met iets van 9 MB/sec max.

Tis maar net wat voor switches je ze mee gebruikt. Op school hebben we 10Mbit 3COM Superstack 19" switches, als je daar met de eepro100 driver je NIC aan hangt doet ie nix, sluit je em aan op 100Mbit of gebruik je de e100 driver, dan ist wel goed.

[Verwijderd]

Ik heb DMA nu aanstaan en ook de sockets aangepast zoals suggested en het probleem is opgelost.
De server blijft responden en is gewoon bereikbaar.

Alleen nu heb ik een ander problem.
Ik heb een NTFS partitie als READ-Only gemount. Zodra ik deze benader vanaf een werkstation als share via samba klapt de server er helemaal uit.

Ping responces wel maar alle applicties zijn niet meer beschikbaar, local console is zwart, etc. Enige wat helpt is een reboot.

[Verwijderd]

iemand enig idea voor het NTFS probleem?

[_JGC_]

Gewoon niet die NTFS brut gebruiken. NTFS is voor windows machines, niet voor windows. Waarschijnlijk probeert Samba iets te locken of een of andere accesstime te schrijven wat die kernelmodule niet leuk vindt: je netwerkstack blijft draaien, maar de rest van't systeem is plat.

[LollieStick]

Ik heb een dergelijk probleem ook gehad met een 3Com kaart. Het is bij mij opgelost door de netwerkkaart geforceerd op 100 mbp/s full-duplex te zetten.

[EXX]

Even een ander vraagje in dezelfde richting. Ik heb een Samba server draaien op een P1 200 MHz machine met een 430VX chipset en een intel pro100 NIC.

Op zich werkt het prima, maar de throughput bij het copieeren van de Win98 machine naar de Samba share gaat met +- 1.1 MB/s.

hdparm -cd /dev/hda:

/dev/hda:
I/O support = 0 (default 16-bit)
using_dma = 1 (on)

hdparm -cd /dev/hdc:

/dev/hdc:
I/O support = 0 (default 16-bit)
using_dma = 1 (on)

Is het veilig om I/O support op 32 bit te zetten? Is dat afhankelijk van je chipset?

[Zwelgje]

EXX schreef op 21 April 2003 @ 10:54:
Even een ander vraagje in dezelfde richting. Ik heb een Samba server draaien op een P1 200 MHz machine met een 430VX chipset en een intel pro100 NIC.

Op zich werkt het prima, maar de throughput bij het copieeren van de Win98 machine naar de Samba share gaat met +- 1.1 MB/s.

hdparm -cd /dev/hda:

/dev/hda:
I/O support = 0 (default 16-bit)
using_dma = 1 (on)

hdparm -cd /dev/hdc:

/dev/hdc:
I/O support = 0 (default 16-bit)
using_dma = 1 (on)

Is het veilig om I/O support op 32 bit te zetten? Is dat afhankelijk van je chipset?

die nic staat niet op full duplex terwijl je maar een 100mb hub hebt?, haal je dezelfde snelheden als je een ftp sessie start naar die machine?

[EXX]

De NIC staat op full duplex, ik gebruik een switch (die geeft ook aan 100 Mbps / FD) . FTP heb ik niet draaien, dus nog niet geprobeerd.

De 430VX chipset ondersteunt zover ik weet geen UDMA, dus alle hdd's lopen in PIO4 mode.

[ Voor 26% gewijzigd door EXX op 21-04-2003 11:03 ]

[Zwelgje]

EXX schreef op 21 April 2003 @ 11:01:
De NIC staat op full duplex, ik gebruik een switch (die geeft ook aan 100 Mbps / FD) . FTP heb ik niet draaien, dus nog niet geprobeerd.

De 430VX chipset ondersteunt zover ik weet geen UDMA, dus alle hdd's lopen in PIO4 mode.

die chipset heeft geen UltraDMA nee, maar wel 'Multi-Word DMA' dan een soort van pio mode 4 (16mb) maar dan met DMA transfers zeg maar

vandaar ook dat ie wel aangeeft dat ie DMA gebruikt

je kan ook eens 'netio' proberen om je snelheid te meten

[EXX]

Ik heb net eens even 32 bit I/O-support aangezet, maar het scheelt nix. De hdparm benchmark gaat er wel op vooruit: van 5.56 MB/s naar 8.26 MB/s


16 bits:

# hdparm -Tt /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 3.61 seconds = 35.46 MB/sec
Timing buffered disk reads: 64 MB in 8.39 seconds = 7.63 MB/sec

# hdparm -Tt /dev/hdc

/dev/hdc:
Timing buffer-cache reads: 128 MB in 3.58 seconds = 35.75 MB/sec
Timing buffered disk reads: 64 MB in 11.52 seconds = 5.56 MB/sec

32 bits:

# hdparm -Tt /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 3.57 seconds = 35.85 MB/sec
Timing buffered disk reads: 64 MB in 9.39 seconds = 6.82 MB/sec

# hdparm -Tt /dev/hdc

/dev/hdc:
Timing buffer-cache reads: 128 MB in 3.66 seconds = 34.97 MB/sec
Timing buffered disk reads: 64 MB in 7.87 seconds = 8.13 MB/sec

hda = 6 GB Quantum Fireball, 512 KB cache, 5400 RMP
hdc = 120 GB IBM 120GXP, 2 MB cache, 7200 RPM

netio, hoe werkt dat, ik kan geen man pages vinden en linux kent het command ook niet.

[ Voor 5% gewijzigd door EXX op 21-04-2003 11:15 ]

[_JGC_]

code:

hdparm -u1d1a64W1c3 /dev/hda

Probeer die eens:
unmaskirq, dma, readahead van 64 sectors, write cache, 32bit IO met sync

Haal hierdoor iets van 7MB/s extra bij een hdparm test met een Maxtor DiamondMax Plus 9 80GB op een SiS746, maar voor oude bordjes met oude diskjes zal het ook zeker wel helpen.

[Zwelgje]

EXX schreef op 21 April 2003 @ 11:14:
Ik heb net eens even 32 bit I/O-support aangezet, maar het scheelt nix. De hdparm benchmark gaat er wel op vooruit: van 5.56 MB/s naar 8.26 MB/s


16 bits:

# hdparm -Tt /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 3.61 seconds = 35.46 MB/sec
Timing buffered disk reads: 64 MB in 8.39 seconds = 7.63 MB/sec

# hdparm -Tt /dev/hdc

/dev/hdc:
Timing buffer-cache reads: 128 MB in 3.58 seconds = 35.75 MB/sec
Timing buffered disk reads: 64 MB in 11.52 seconds = 5.56 MB/sec

32 bits:

# hdparm -Tt /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 3.57 seconds = 35.85 MB/sec
Timing buffered disk reads: 64 MB in 9.39 seconds = 6.82 MB/sec

# hdparm -Tt /dev/hdc

/dev/hdc:
Timing buffer-cache reads: 128 MB in 3.66 seconds = 34.97 MB/sec
Timing buffered disk reads: 64 MB in 7.87 seconds = 8.13 MB/sec

hda = 6 GB Quantum Fireball, 512 KB cache, 5400 RMP
hdc = 120 GB IBM 120GXP, 2 MB cache, 7200 RPM

netio, hoe werkt dat, ik kan geen man pages vinden en linux kent het command ook niet.

netio moet je even downloaden (www.google.com)

http://freshmeat.net/proj...c_id=87%2C138%2C150%2C152

[ Voor 4% gewijzigd door Zwelgje op 21-04-2003 11:18 ]

[EXX]

zwelgje schreef op 21 april 2003 @ 11:17:
[...]


netio moet je even downloaden (www.google.com)

http://freshmeat.net/proj...c_id=87%2C138%2C150%2C152

Ah, ok. Ik was er even van uitgegaan dat het een deel is van Linux.

Tooltje gedowned. OK als ik het goed begrijp moet ik het op de linux machine als server zetten en op de Win98 machine als client en dan de benchmark draaien. Voor op de linux machine moet ik eerst compileren etc., Er staat ook een binary bij zie ik net: kan ik die gewoon draaien op SuSE Linux 7.2?

[EXX]

Benchmark gedraaid met server = linux en client is Win98 machine:

NETIO - Network Throughput Benchmark, Version 1.16
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size 1 KByte: 508 KByte/s Tx, 510 KByte/s Rx.
Packet size 2 KByte: 1009 KByte/s Tx, 1049 KByte/s Rx.
Packet size 4 KByte: 2107 KByte/s Tx, 1744 KByte/s Rx.
Packet size 8 KByte: 5101 KByte/s Tx, 2736 KByte/s Rx.
Packet size 16 KByte: 3929 KByte/s Tx, 4843 KByte/s Rx.
Packet size 32 KByte: 5186 KByte/s Tx, 6525 KByte/s Rx.
Done.

[Zwelgje]

EXX schreef op 21 April 2003 @ 11:28:
Benchmark gedraaid met server = linux en client is Win98 machine:

NETIO - Network Throughput Benchmark, Version 1.16
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size 1 KByte: 508 KByte/s Tx, 510 KByte/s Rx.
Packet size 2 KByte: 1009 KByte/s Tx, 1049 KByte/s Rx.
Packet size 4 KByte: 2107 KByte/s Tx, 1744 KByte/s Rx.
Packet size 8 KByte: 5101 KByte/s Tx, 2736 KByte/s Rx.
Packet size 16 KByte: 3929 KByte/s Tx, 4843 KByte/s Rx.
Packet size 32 KByte: 5186 KByte/s Tx, 6525 KByte/s Rx.
Done.

niet echt snel voor een 100mb kaartj, je zou toch iets ronde 11mb moeten halen (dat haal ik ook met mijn intel pro 100 nics onder linux (ook een p200mmx overigens)

zet die kaart voor de grap eens op half duplex, en kijk eens wat het resultaat dan is

of je kernel hercompileren met de Intel driver (ipv de standaard linux driver die meegeleverd wordt), zou niet veel moeten uitmaken maar toch

[EXX]

Zou het niet ook aan de Windows client kunnen liggen (PIII-800E machine, BX chipset, Realtek 8139 NIC)?

Voor gedetailleerde specs: zie sig

[ Voor 16% gewijzigd door EXX op 21-04-2003 11:35 ]

[Zwelgje]

EXX schreef op 21 April 2003 @ 11:34:
Zou het niet ook aan de Windows client kunnen liggen (PIII-800E machine, BX chipset, Realtek 8139 NIC)?

Voor gedetailleerde specs: zie sig

mm ja, realtek niet geheel onbelanrijke faktor in deze kwestie, heb je de optie om deze kaart (tijdelijk) te vervangen door een ander model? (lees: intel/3com)

resultaten van een halfduplex setting heb je ook al

[EXX]

Ik heb helaas geen andere NIC. Enne, zo een linux expert ben ik (nog) niet, hoe zet ik die kaart tijdelijk op HD? Bij de yast->network device configuration->module options?

Overigens heb ik de benchmark ook eens omgekeerd gedraaid: de Win98 machine als server en de Linux machine als client:

NETIO - Network Throughput Benchmark, Version 1.16
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size 1 KByte: 343 KByte/s Tx, 504 KByte/s Rx.
Packet size 2 KByte: 951 KByte/s Tx, 1013 KByte/s Rx.
Packet size 4 KByte: 1754 KByte/s Tx, 2003 KByte/s Rx.
Packet size 8 KByte: 2766 KByte/s Tx, 5349 KByte/s Rx.
Packet size 16 KByte: 3569 KByte/s Tx, 3957 KByte/s Rx.
Packet size 32 KByte: 6799 KByte/s Tx, 5752 KByte/s Rx.
Done.

Ziet er gelijk uit, alleen gespiegeld.

edit:

Ga binnenkort een slot-T adaptor bestellen met een Celly 1.3 GHz Tualatin. Dan gaan we gelijk merken of het de Win98 machine is.

[ Voor 15% gewijzigd door EXX op 21-04-2003 11:59 ]

[Zwelgje]

EXX schreef op 21 april 2003 @ 11:45:
Ik heb helaas geen andere NIC. Enne, zo een linux expert ben ik (nog) niet, hoe zet ik die kaart tijdelijk op HD? Bij de yast->network device configuration->module options?

Overigens heb ik de benchmark ook eens omgekeerd gedraaid: de Win98 machine als server en de Linux machine als client:

NETIO - Network Throughput Benchmark, Version 1.16
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size 1 KByte: 343 KByte/s Tx, 504 KByte/s Rx.
Packet size 2 KByte: 951 KByte/s Tx, 1013 KByte/s Rx.
Packet size 4 KByte: 1754 KByte/s Tx, 2003 KByte/s Rx.
Packet size 8 KByte: 2766 KByte/s Tx, 5349 KByte/s Rx.
Packet size 16 KByte: 3569 KByte/s Tx, 3957 KByte/s Rx.
Packet size 32 KByte: 6799 KByte/s Tx, 5752 KByte/s Rx.
Done.

Ziet er gelijk uit, alleen gespiegeld.

met deze tool: http://www.netadmintools.com/html/mii-tool.man.html of onder windows met proset tools (bij intel downloaden)

[EXX]

mii-tool geeft :

# mii-tool
SIOCGMIIPHY on 'eth0' failed: Operation not supported

Gaat nog ff duren ben ik bang...

[ Voor 18% gewijzigd door EXX op 21-04-2003 11:59 ]

[Zwelgje]

EXX schreef op 21 April 2003 @ 11:58:
mii-tool geeft :

# mii-tool
SIOCGMIIPHY on 'eth0' failed: Operation not supported

Gaat nog ff duren ben ik bang...

code:

root@slackware:/etc/rc.d# mii-tool eth0
eth0: negotiated 100baseTx-FD flow-control, link ok
root@slackware:/etc/rc.d#

hier werkt het gewoon op mijn intel pro 100,

je bent wel als root ingelogged op dat moment toch , net even gecheck, moet niks uitmaken om de status uit te lezen

[ Voor 8% gewijzigd door Zwelgje op 21-04-2003 12:03 ]

[EXX]

Ja, ik ben als root ingelogd.

Heb overigens ff de Win98 machine op half duplex gezet (switch geeft dit ook aan). resultaat (win98 cient, Linux server):

NETIO - Network Throughput Benchmark, Version 1.16
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size 1 KByte: 207 KByte/s Tx, 205 KByte/s Rx.
Packet size 2 KByte: 463 KByte/s Tx, 504 KByte/s Rx.
Packet size 4 KByte: 863 KByte/s Tx, 971 KByte/s Rx.
Packet size 8 KByte: 4821 KByte/s Tx, 1633 KByte/s Rx.
Packet size 16 KByte: 3182 KByte/s Tx, 4388 KByte/s Rx.
Packet size 32 KByte: 3701 KByte/s Tx, 6730 KByte/s Rx.
Done.

[EXX]

IK ga de drivers van intel eens downen en installeren. Ik zie net dat Yast als gebruikte driver aangeeft:

Intel Pro/100 / EtherExpress Pro 100

Wellicht is dit niet de optimale driver.

edit:

Verdorie, gedowned, op de linux machine gezet, gunzipped en nou werkt tar niet. tar -t geeft geen inhoud en tar -xv doet ook nix

file: e100-2.2.21.tar.gz
na gunzip: e100-2.2.21.tar

als ik tar -t doe gebeurt er nix, dan onderbreek ik met crtl+D:

gemini:/dsk2/temp # tar -t e100-2.2.21.tar
tar: e100-2.2.21.tar: Not found in archive
tar: Error exit delayed from previous errors
gemini:/dsk2/temp #

edit:
Ja, tar is gelukt. Volgende keer beter de readme.txt lezen
hup: make install en aaaarrrgghhhh, de linux kernel source not found. De kernel source staat er niet op. Morgen de CD's te pakken zien te krijgen en alsnog erop zetten.

[ Voor 76% gewijzigd door EXX op 21-04-2003 12:44 ]

[Verwijderd]

offtopic:
Ik wil je toch even wijzen op het gebruik van de edit knop

[Pantagruel]

In t verleden ook Realtek gebruikt, zowel in de linux doos (Intel Pentium 233 MMX/96 MB/Seagate Barracuda I 7200 rpm 6.5 GB) als in de windows doos (p3-650/512/30 GB Seagat Barracuda II 7200 rpm 30 GB) en dan had ik gemiddeld 6 a 8 MB/sec over t netwerk (Soho 10/100 Mbit switch).

Inmiddels is de boel wel wat veranderd, de switch is er nog steeds enekel nu:

Windows dozen:

1) P 4 2 Ghz/intel 850/1024/RAID-0 120 GB/ 3Com 3c905 / XP Pro SP-1
2) P2-400 MHz/Intel BX/256/10 GB/Realtek 8139 /WIn2k SP3

Linux doos, RedHat 8, Samba ver 2.2.7-sec-roll-up-fix
3) P3-866/Intel i815/384/
2x30 GB on mobo /dev/hda + hdb
4x 60 GB on ATA-100 /dev/hde t/m h

mii-tool output: eth0: negotiated 100baseTx-FD flow-control, link ok

hdparm -Tt /dev/ (16 bit)

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.86 seconds =148.95 MB/sec
Timing buffered disk reads: 64 MB in 2.51 seconds = 25.54 MB/sec

/dev/hdh:
Timing buffer-cache reads: 128 MB in 0.86 seconds =149.64 MB/sec
Timing buffered disk reads: 64 MB in 1.41 seconds = 45.51 MB/sec


van 1 naar 3 ca 9 MB/sec (XP -> Linux)
van 1 naar 3 ca 10-11 MB/sec (linux -> Linux)
van 2 naar 3 ca 7-8 MB/sec (Win2K => linux)

Oftewel, lekkere throughput, maar linux is beter qua verkeer onderling.

En na wat gefrunnik:

sys 4:
Intel Pentium 200/Intel TX/64 MB/20 GB Maxtor/3Com 3c905/Redhat 8 not patched
4 naar 3, ca 7 MB/sec

Mijn ervaring met Intel nic's is dat deze net zo goed als de 3com's werken, Windows of tux is om t even.

Update:

Een hint voor t probleem !!!!

Even in de ouwe harde waren doos gezocht en nog een andere NIC gevonden.
Een Macronix MXIC-100, MX987xx family en vlgs de linux doos doet tie t met de Tulip.o module. Dus effu verwisseld, netwerk migratie gedaan en testje.
Errrh NO GO, time outs, disconnected from network, hosts not reachable and all in the effect to state that this networkdevice is now inoperative.
Naar de macronix site gegaan (wazige taiwan site) en voor dot stuk antiek de drivers gehaald. Hercompilatie met de nieuwe compiler en insmod gedaan.
MMMM lijkt er meer op, boel werkt en DU-meter schommelt tussen de 5 en 8 MB/sec. De kaart werkt, maar dus duidelijk minder stabiel dan de 3com's die ik heb.

Jouw probleem kan dus zeer zeker een slechte of minder goede driver zijn.

[ Voor 22% gewijzigd door Pantagruel op 21-04-2003 12:58 ]

[Pantagruel]

EXX schreef op 21 april 2003 @ 12:18:
IK ga de drivers van intel eens downen en installeren. Ik zie net dat Yast als gebruikte driver aangeeft:

Intel Pro/100 / EtherExpress Pro 100

Wellicht is dit niet de optimale driver.

edit:

Verdorie, gedowned, op de linux machine gezet, gunzipped en nou werkt tar niet. tar -t geeft geen inhoud en tar -xv doet ook nix

file: e100-2.2.21.tar.gz
na gunzip: e100-2.2.21.tar

als ik tar -t doe gebeurt er nix, dan onderbreek ik met crtl+D:

gemini:/dsk2/temp # tar -t e100-2.2.21.tar
tar: e100-2.2.21.tar: Not found in archive
tar: Error exit delayed from previous errors
gemini:/dsk2/temp #

edit:
Ja, tar is gelukt. Volgende keer beter de readme.txt lezen
hup: make install en aaaarrrgghhhh, de linux kernel source not found. De kernel source staat er niet op. Morgen de CD's te pakken zien te krijgen en alsnog erop zetten.

tar -xvzf tar file

[Zwelgje]

EXX schreef op 21 April 2003 @ 12:18:
IK ga de drivers van intel eens downen en installeren. Ik zie net dat Yast als gebruikte driver aangeeft:

Intel Pro/100 / EtherExpress Pro 100

Wellicht is dit niet de optimale driver.

edit:

Verdorie, gedowned, op de linux machine gezet, gunzipped en nou werkt tar niet. tar -t geeft geen inhoud en tar -xv doet ook nix

file: e100-2.2.21.tar.gz
na gunzip: e100-2.2.21.tar

als ik tar -t doe gebeurt er nix, dan onderbreek ik met crtl+D:

gemini:/dsk2/temp # tar -t e100-2.2.21.tar
tar: e100-2.2.21.tar: Not found in archive
tar: Error exit delayed from previous errors
gemini:/dsk2/temp #

edit:
Ja, tar is gelukt. Volgende keer beter de readme.txt lezen
hup: make install en aaaarrrgghhhh, de linux kernel source not found. De kernel source staat er niet op. Morgen de CD's te pakken zien te krijgen en alsnog erop zetten.

waarom niet gewoon gelijk even de nieuwste stabiele kernel downloaden daar zit die intel driver gewoon in...

[Verwijderd]

Geen oplossing voor mijn NTFS probleem?
Thread is de laatste 2 dagen een beetje op een side track gekomen..

[deadinspace]

Je weet zeker dat je NTFS partitie read-only is gemount? Geef evt de output van "mount" of de inhoud van /proc/mounts.

Verder: welke kernel-versie gaat het om?
Van welke windows versie is die NTFS partitie afkomstig?
Als je zelf (dus zonder gebruik van samba) door die NTFS mount browsed (find /mountpoint/ is wel effectief, dat doorloopt alle directories ), wat gebeurt er dan? Andere pogingen om het te reproduceren?
Er hangt neem ik aan een monitor aan. Wat verschijnt daarop als het gebeurt? Raak evt voordat je het probeert een toets aan, zodat de console blanking uitstaat.

[Verwijderd]

Kernel version 2.4.9 deze stond al in het begin van de thread.

Ook als ik lokaal via de console naar de folder cd en dan een ls doe hangt de machine. Het scherm wordt meteen zwart.

Heb de content nu naar een ext3 volume gekopieerd. Een ls op deze content werkt gewoon, dus het is niet de amount of data.

Kopieren naar een ext3 volume is geen oplossing. Ik moet wekelijks een NTFS schijf er aan hangen en de content importeren. Gaat om een W2k NTFS paritie.

[Verwijderd]

el cheapo netwerkkaart, heb ik ook last van gehad
realtek is dan nog niet eens de slechtste,
moet je eens als root ping -f <andere ip> doen
als hij dan hangt, is het de netwerkkaart