Intel 82595FX clone NIC problems

Intel 82595FX clone NIC problems

[James Miller]

I'm having some trouble getting an Intel 82595 clone ISA NIC working on a
computer on my small network.  I'm fairly new to networking, and not
especially experienced in computing in general, so I may be doing
something very simple wrong.  Let me provide a description of what I've
done, the context and the problem to see if anyone here might help.

The card is in an old 486 DX2 66 that I'm trying to get going on my
network.  The network consists of a machine with a fairly up-to-date
Debian variant installed on it, the 486 mentioned above, and another
older machine (more on that).  The gateway machine has an external modem,
and an onboard NIC (Realtek RTL 8XXX 10/100) that connects it to a DLink
10/100 switch.  On the network is another 486, a DX4 100, with another
Intel clone NIC, though this one is a PCI (forgot the chip #, but it's
irrelevant since that machine works great on the network).

All the research I've done on the Intel 82595FX ISA NIC indicates that it
should use the eepro.o module.  Thus, I got that module and have set up
the Slackish system on the DX2 66 to load the module by editing
/etc/rc.d/rc.S accordingly (insmod eepro.o io=0x300).  The boot time
report indicates that the card has been found and its irq, io, and MAC
address found.  It is also assigned its correct address.  Subsequently, I
can ping the gateway without problems - no dropped packets.  I can fire up
Links and surf the 'net - for a while.  I can also telnet into the gateway
successfully - for a while.  The problme is that, after about 1 minute,
the connection just dies.  Links stops, and will not load further pages.
The telnet session becomes immune to keystrokes (except keystrokes like
ctrl-c).  Opening another terminal session and trying to ping the gateway
results in the message "56 data bytes" and nothing more. Hitting ctrl-c
subsequently displays how many packets were sent, and notifies of 100%
packet loss.  In short, no further traffic can flow through the card.
Trying to ping the other computer on the network gives the same response
(56 data bytes . . . 100% packet loss).  I would guess that this means
that either the card has somehow frozen up, or there is some problem at
the switch.

Other possibly relevant factors.  The card can be tweaked with a utility
(switching IO's/IRQ's, disabling things like plug and play and "concurrent
processing" - whatever that is) that works under DOS called softset.  The
card tests fine using this utility (i.e., passes the util's integrity
test).  I've tried 2 different IRQ's (7 and 10) and 3 different IO's, but
to no avail.  I've fiddled with the other settings too, but the problem
persists (except disbaling plug and play, which I had to do to get the
card working to begin with).  I've also tried another, identical card
(I have several laying around), but with the same results.  The other 486
on the network works great.  I've used it both as an xterminal to get
xsessions from the gateway machine, as well as a standalone machine to
surf the 'net and such.  No problems whatever with it using the network.
I've tried switching cables between the two machines (the 2 486's), to no
avail: the problems persist on the machine with the 82595FX ISA card, while
the other one works fine.  Finally, I ran ifconfig on the gateway machine
to see what that would tell me.  It shows 11 overruns for the gateway's
interface (the Realtek onboard), though other things look normal (to my
very untrained eye).

Can someone give me some indication about the nature of this problem?
What can I do to locate the trouble spot?  What can I do to fix it?  Let
me know if I have left out any important details.

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Intel 82595FX clone NIC problems

[James Miller]

On Fri, 11 Apr 2003, James Miller wrote:
> network.  The network consists of a machine with a fairly up-to-date
> Debian variant installed on it, the 486 mentioned above, and another
> older machine (more on that).  The gateway machine has an external modem,
> and an onboard NIC (Realtek RTL 8XXX 10/100) that connects it to a DLink
> 10/100 switch.  On the network is another 486, a DX4 100, with another

A point of clarification: the machine with up-to-date Debian variant, the
external modem and the Realtek onboard NIC *is* the gateway. 3 machines
total, and one switch.
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Intel 82595FX clone NIC problems

[Ray Olszewski]

More information, please.

1. What Linux distro and what kernel? "the Slackish system" really is not 
very informative. Stock or custom-compiled kernel?

2. After the NIC seems to stop operating, what does "ifconfig" report about 
its interface (presumably eth0)?

3.  Might there be an IRQ conflict not obvious to the Linux kernel? (Even 
with the newer kernels that do IRQ sharing, I've heard reports of problems 
with NICs on IRQ3 that conflict with Winmodems.) Nothing comes to mind for 
IRQs 7 and 10, I admit.

4. What sot configuration does the mobo have? Might it be one of those 
late-486 mobos with both isa and pci slots? If so, could there be a 
"shared-slot" problem (these mobos typically had one pair of slots, one pci 
and one isa, that could not both be used simultaneously)?

5. You mention the possibility of "some problem at the switch". The usual 
way to check for that is to power-cycle the switch and see if that clears 
things. Have you tried that test? If so, to what effect? Have you tried 
different ports?

6. Are the problems you describe specific to the NIC's interface? That is, 
can you use the lo interface successfully (e.g., "ping localhost", "telnet 
localhost")? This one is a long shot, though.

7. Is anything relevant showing up in your logs?

8.You didn't say, but I'm assuming that this is a 10 Mbps card, not an 
10/100. If I'm wrong in that assumption, might there be some problem with 
speed detection between the card and the switch?

At 11:23 AM 4/11/2003 -0500, James Miller wrote:
>I'm having some trouble getting an Intel 82595 clone ISA NIC working on a
>computer on my small network.  I'm fairly new to networking, and not
>especially experienced in computing in general, so I may be doing
>something very simple wrong.  Let me provide a description of what I've
>done, the context and the problem to see if anyone here might help.
>
>The card is in an old 486 DX2 66 that I'm trying to get going on my
>network.  The network consists of a machine with a fairly up-to-date
>Debian variant installed on it, the 486 mentioned above, and another
>older machine (more on that).  The gateway machine has an external modem,
>and an onboard NIC (Realtek RTL 8XXX 10/100) that connects it to a DLink
>10/100 switch.  On the network is another 486, a DX4 100, with another
>Intel clone NIC, though this one is a PCI (forgot the chip #, but it's
>irrelevant since that machine works great on the network).
>
>All the research I've done on the Intel 82595FX ISA NIC indicates that it
>should use the eepro.o module.  Thus, I got that module and have set up
>the Slackish system on the DX2 66 to load the module by editing
>/etc/rc.d/rc.S accordingly (insmod eepro.o io=0x300).  The boot time
>report indicates that the card has been found and its irq, io, and MAC
>address found.  It is also assigned its correct address.  Subsequently, I
>can ping the gateway without problems - no dropped packets.  I can fire up
>Links and surf the 'net - for a while.  I can also telnet into the gateway
>successfully - for a while.  The problme is that, after about 1 minute,
>the connection just dies.  Links stops, and will not load further pages.
>The telnet session becomes immune to keystrokes (except keystrokes like
>ctrl-c).  Opening another terminal session and trying to ping the gateway
>results in the message "56 data bytes" and nothing more. Hitting ctrl-c
>subsequently displays how many packets were sent, and notifies of 100%
>packet loss.  In short, no further traffic can flow through the card.
>Trying to ping the other computer on the network gives the same response
>(56 data bytes . . . 100% packet loss).  I would guess that this means
>that either the card has somehow frozen up, or there is some problem at
>the switch.
>
>Other possibly relevant factors.  The card can be tweaked with a utility
>(switching IO's/IRQ's, disabling things like plug and play and "concurrent
>processing" - whatever that is) that works under DOS called softset.  The
>card tests fine using this utility (i.e., passes the util's integrity
>test).  I've tried 2 different IRQ's (7 and 10) and 3 different IO's, but
>to no avail.  I've fiddled with the other settings too, but the problem
>persists (except disbaling plug and play, which I had to do to get the
>card working to begin with).  I've also tried another, identical card
>(I have several laying around), but with the same results.  The other 486
>on the network works great.  I've used it both as an xterminal to get
>xsessions from the gateway machine, as well as a standalone machine to
>surf the 'net and such.  No problems whatever with it using the network.
>I've tried switching cables between the two machines (the 2 486's), to no
>avail: the problems persist on the machine with the 82595FX ISA card, while
>the other one works fine.  Finally, I ran ifconfig on the gateway machine
>to see what that would tell me.  It shows 11 overruns for the gateway's
>interface (the Realtek onboard), though other things look normal (to my
>very untrained eye).
>
>Can someone give me some indication about the nature of this problem?
>What can I do to locate the trouble spot?  What can I do to fix it?  Let
>me know if I have left out any important details.





-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Intel 82595FX clone NIC problems

[James Miller]

On Fri, 11 Apr 2003, Ray Olszewski wrote:

> More information, please.
>
> 1. What Linux distro and what kernel? "the Slackish system" really is not
> very informative. Stock or custom-compiled kernel?
>
Sorry.  This is a Basiclinux system.  Basiclinux is based on Slackware
(7.1 in this case), but is specialy tweaked for low-resource machines -
including having a custom kernel.  A configuration file for the kernel can
be viewed at:
http://www.ibiblio.org/pub/linux/distributions/baslinux/config.txt  It
uses the 2.2.16 kernel.

> 2. After the NIC seems to stop operating, what does "ifconfig" report about
> its interface (presumably eth0)?
>
eth0      Link encap:Ethernet  HWaddr 00:A0:C9:0C:79:13
          inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:137 errors:0 dropped:0 overruns:0 frame:0
          TX packets:95 errors:1 dropped:0 overruns:0 carrier:2
          collisions:8 txqueuelen:100
          RX bytes:155752 (152.1 kiB)  TX bytes:10745 (10.4 kiB)
          Interrupt:7 Base address:0x300

> 3.  Might there be an IRQ conflict not obvious to the Linux kernel? (Even
> with the newer kernels that do IRQ sharing, I've heard reports of problems
> with NICs on IRQ3 that conflict with Winmodems.) Nothing comes to mind for
> IRQs 7 and 10, I admit.
>
Don't know what to say here.  I presume you're sort of thinking out loud?

> 4. What sot configuration does the mobo have? Might it be one of those
> late-486 mobos with both isa and pci slots? If so, could there be a
> "shared-slot" problem (these mobos typically had one pair of slots, one pci
> and one isa, that could not both be used simultaneously)?
>
ISA only.  No PCI or shared slots.

> 5. You mention the possibility of "some problem at the switch". The usual
> way to check for that is to power-cycle the switch and see if that clears
> things. Have you tried that test? If so, to what effect? Have you tried
> different ports?
>
Just tried powering the switch off, then on again (after 5 seconds).  The
DX2 66 still won't ping or otherwise reach the network. I guess it's not
the switch?

> 6. Are the problems you describe specific to the NIC's interface? That is,
> can you use the lo interface successfully (e.g., "ping localhost", "telnet
> localhost")? This one is a long shot, though.
>
Yes, I can still ping localhost.  No dropped packets.

> 7. Is anything relevant showing up in your logs?
>
Can you give an indication of which logs to look at and where they're
located?  I haven't done much log analysis in my rather brief and
superficial Linux career.

> 8.You didn't say, but I'm assuming that this is a 10 Mbps card, not an
> 10/100. If I'm wrong in that assumption, might there be some problem with
> speed detection between the card and the switch?
>
Yes, 10Mbps (identified as 10baseT in boot messages)

Thanks much, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Intel 82595FX clone NIC problems

[Ray Olszewski]

Some detailed responses below. As a general matter, kernel 2.2.16 is pretty 
old (it's not even current for the 2.2.x series ... www.kernel.org is up to 
2.2.25, and Debian source is at 2.2.22), so it's always possible that the 
eepro driver you're using is simply too old for this card.

What happens if, after the interface fails, you restart networking (that 
is, bring eth0 down, then back up - not knowing the details of BasicLinux, 
I can't tell you exactly how to do this)? Or if you bring eth0 down, rmmod 
the driver, then insmod (or modprobe) it again, then bring eth0 back up?

At 12:52 PM 4/11/2003 -0500, James Miller wrote:
[...]
> > 2. After the NIC seems to stop operating, what does "ifconfig" report about
> > its interface (presumably eth0)?
> >
>eth0      Link encap:Ethernet  HWaddr 00:A0:C9:0C:79:13
>           inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:137 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:95 errors:1 dropped:0 overruns:0 carrier:2
>           collisions:8 txqueuelen:100
>           RX bytes:155752 (152.1 kiB)  TX bytes:10745 (10.4 kiB)
>           Interrupt:7 Base address:0x300

Just to be clear -- this is after the interface seems to have stopped 
responding? And after you try to use it again for something (like a ping)? 
Notice that there are no RX errors and only 1 TX error ... suggesting that 
the interface is *sending* properly but is not receiving replies.

This makes it sound to me like a hardware problem ... either the "clone" 
card has (so to speak) some transcription errors or there is an IRQ problem 
on the mobo (since you seem to have eliminated external sources like the 
cable and the switch).

Just to be sure ... run "ifconfig" after the interface stops working. Note 
the RX and TX packet totals. Then do a ping and let it run awhile. Then run 
"ifconfig" agains and check to see if the TX count has increased but not 
the RX count.

BTW, after the interface fails, what happens if the other machine (the 
sorta-Debian gateway) tries to ping this host? And just to be sure, are 
there any problems with the routing table on *either* host? And can each 
host arp the other (after you try a ping, for example, does each host 
appear in the listing of /proc/net/arp on the other host)?

> > 3.  Might there be an IRQ conflict not obvious to the Linux kernel? (Even
> > with the newer kernels that do IRQ sharing, I've heard reports of problems
> > with NICs on IRQ3 that conflict with Winmodems.) Nothing comes to mind for
> > IRQs 7 and 10, I admit.
> >
>Don't know what to say here.  I presume you're sort of thinking out loud?

A bit more than that, but I should have been explicit. What else do you 
have on the machine that uses IRQs? (Check this in the BIOS, not in Linux, 
because I'm wondering about a problem caused by a device that the kernel 
does not recognize ... a Winmodem is the poster-child for this problem, 
though, and WInmodems pretty reliably turn up on IRQ3.)

[...]
> > 7. Is anything relevant showing up in your logs?
> >
>Can you give an indication of which logs to look at and where they're
>located?  I haven't done much log analysis in my rather brief and
>superficial Linux career.

I don't use BasicLinux, but if it's standard in this respect, the logs will 
be in /var/log and viewable only by root. There is no real standard for how 
syslog messages are apportioned among specific logs, so I can't give you a 
good answer at that part ... but /var/log/messages is usually the catchall 
file.
[...]



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Intel 82595FX clone NIC problems

[James Miller]

On Fri, 11 Apr 2003, Ray Olszewski wrote:

> Some detailed responses below. As a general matter, kernel 2.2.16 is pretty
> old (it's not even current for the 2.2.x series ... www.kernel.org is up to
> 2.2.25, and Debian source is at 2.2.22), so it's always possible that the
> eepro driver you're using is simply too old for this card.
>
If it's a problem of an old module, I suppose I could search for a newer
one (maybe from a Slack8 or 8.1 CD I have).  I may be giving that a try.

> What happens if, after the interface fails, you restart networking (that
> is, bring eth0 down, then back up - not knowing the details of BasicLinux,
> I can't tell you exactly how to do this)? Or if you bring eth0 down, rmmod
> the driver, then insmod (or modprobe) it again, then bring eth0 back up?
>
I'll have to look into this further.  I'm drawing a blank at the moment.

> Just to be clear -- this is after the interface seems to have stopped
> responding? And after you try to use it again for something (like a ping)?

Yes, after trying a ping after the connection seems to die.

> Just to be sure ... run "ifconfig" after the interface stops working. Note
> the RX and TX packet totals. Then do a ping and let it run awhile. Then run
> "ifconfig" agains and check to see if the TX count has increased but not
> the RX count.
>
I'll go ahead and append the output here, since I don't trust my own very
limited experience in interpreting the output.  Apologies for unnecessary
length.  Here is the output before the ping subsequent to the connection
dieing:

eth0      Link encap:Ethernet  HWaddr 00:A0:C9:0C:79:13
          inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:153 errors:0 dropped:0 overruns:0 frame:0
          TX packets:98 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:100
          RX bytes:195141 (190.5 kiB)  TX bytes:9372 (9.1 kiB)
          Interrupt:7 Base address:0x300

Here is the output after trying the ping (for about a minute) after the
connection dies:

eth0      Link encap:Ethernet  HWaddr 00:A0:C9:0C:79:13
          inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:156 errors:0 dropped:0 overruns:0 frame:0
          TX packets:98 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:100
          RX bytes:195321 (190.7 kiB)  TX bytes:14151 (13.8 kiB)
          Interrupt:7 Base address:0x300

> BTW, after the interface fails, what happens if the other machine (the
> sorta-Debian gateway) tries to ping this host? And just to be sure, are

56 data bytes . . . 100% packet loss.  Same message as trying to ping the
gateway from the DX2 66.  It shows HWaddr as 00:00:00:00:00:00 for
the offending interface, btw.  Don't know if that's relevant, if it's
caused by the switch, normal, abnormal or what.

> there any problems with the routing table on *either* host? And can each
> host arp the other (after you try a ping, for example, does each host
> appear in the listing of /proc/net/arp on the other host)?
>
cat /proc/net/arp from each machine shows the correct relevant
network address for each in the other's /proc/net/arp.  I don't know much
about routing tables, so I'll have to think/read further on this.

> A bit more than that, but I should have been explicit. What else do you
> have on the machine that uses IRQs? (Check this in the BIOS, not in Linux,
> because I'm wondering about a problem caused by a device that the kernel
> does not recognize ... a Winmodem is the poster-child for this problem,
> though, and WInmodems pretty reliably turn up on IRQ3.)
>
No Winmodems for sure.  2 ISA HD controller cards (or whatever those cards
used to plug the HD into the mobo before the days of onboard IDE channels
are called).  Can't think of what else, other than serial or parallel
ports that might be using IRQ's.  But I'll have to take a look at the
BIOS, as you suggest.  I'm not quite sure what I'll be looking for, but I
will poke around a bit there.

> I don't use BasicLinux, but if it's standard in this respect, the logs will
> be in /var/log and viewable only by root. There is no real standard for how
> syslog messages are apportioned among specific logs, so I can't give you a
> good answer at that part ... but /var/log/messages is usually the catchall
> file.

I'll try and look into this a bit further too.  I also am not sure how
Basiclinux handles this, obviously.

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Intel 82595FX clone NIC problems

[Ray Olszewski]

James -- Based on the additional ifconfig info you provide here, it seems 
that my original guess was wrong. I may have been misinterpreting what you 
wrote before (doing some incorrect rading between the lines), so I'd like 
you to repost, this time with come complete output.

First, note that the attempted ping does NOT genreate any TX packets. The 
"before" ifconfig reads (in part): "TX packets:98 errors:0 dropped:0 
overruns:0 carrier:1". The "after" ifconfig is identical here: "X 
packets:98 errors:0 dropped:0 overruns:0 carrier:1". So the ping is not 
going out the interface.

To understand why, I'd like to see the exact ping command and all that 
results. For example, here is what an unsuccessful ping normally looks like 
(In this case, one to a unused LAN address):

autovcr@kuryakin:~$ ping 192.168.1.44
PING 192.168.1.44 (192.168.1.44): 56 data bytes
[... long wait here..., ended by pressing ^C]

--- 192.168.1.44 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss

Is this what you see when you ping unsuccessfully, or is anything different?

As to the arp table, a HW address of all 0s means the arp attempt failed 
... the querying host did not get a response. If it gets a response, you'll 
see non-0 hex values in the entry, something like this:

autovcr@kuryakin:~$ more /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
192.168.1.129    0x1         0x2         00:A0:CC:E6:76:7E     *        eth0


Checking the routing table means, in practice, looking at the output of 
"netstat -nr" (there are other ways as well, but I've never seen a Linux 
system that didn't have the netstat command).

Finally, modules have to be compiled for a specific kernel. You can't get a 
newer eepro.o module and expect it to work (or even load) with 2.2.16. If 
you need a newer module, you need a newer kernel. Maybe ichi can comment on 
this part?

Answers to these questions may give me (or someone else here) an idea to 
suggest. Right now, my best guess is that the module you are using does not 
work properly with the particular "clone" card you have (and that's no more 
than a guess).

At 02:29 PM 4/11/2003 -0500, James Miller wrote:
>On Fri, 11 Apr 2003, Ray Olszewski wrote:
>
> > Some detailed responses below. As a general matter, kernel 2.2.16 is pretty
> > old (it's not even current for the 2.2.x series ... www.kernel.org is up to
> > 2.2.25, and Debian source is at 2.2.22), so it's always possible that the
> > eepro driver you're using is simply too old for this card.
> >
>If it's a problem of an old module, I suppose I could search for a newer
>one (maybe from a Slack8 or 8.1 CD I have).  I may be giving that a try.
>
> > What happens if, after the interface fails, you restart networking (that
> > is, bring eth0 down, then back up - not knowing the details of BasicLinux,
> > I can't tell you exactly how to do this)? Or if you bring eth0 down, rmmod
> > the driver, then insmod (or modprobe) it again, then bring eth0 back up?
> >
>I'll have to look into this further.  I'm drawing a blank at the moment.
>
> > Just to be clear -- this is after the interface seems to have stopped
> > responding? And after you try to use it again for something (like a ping)?
>
>Yes, after trying a ping after the connection seems to die.
>
> > Just to be sure ... run "ifconfig" after the interface stops working. Note
> > the RX and TX packet totals. Then do a ping and let it run awhile. Then run
> > "ifconfig" agains and check to see if the TX count has increased but not
> > the RX count.
> >
>I'll go ahead and append the output here, since I don't trust my own very
>limited experience in interpreting the output.  Apologies for unnecessary
>length.  Here is the output before the ping subsequent to the connection
>dieing:
>
>eth0      Link encap:Ethernet  HWaddr 00:A0:C9:0C:79:13
>           inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:153 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:98 errors:0 dropped:0 overruns:0 carrier:1
>           collisions:0 txqueuelen:100
>           RX bytes:195141 (190.5 kiB)  TX bytes:9372 (9.1 kiB)
>           Interrupt:7 Base address:0x300
>
>Here is the output after trying the ping (for about a minute) after the
>connection dies:
>
>eth0      Link encap:Ethernet  HWaddr 00:A0:C9:0C:79:13
>           inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:156 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:98 errors:0 dropped:0 overruns:0 carrier:1
>           collisions:0 txqueuelen:100
>           RX bytes:195321 (190.7 kiB)  TX bytes:14151 (13.8 kiB)
>           Interrupt:7 Base address:0x300
>
> > BTW, after the interface fails, what happens if the other machine (the
> > sorta-Debian gateway) tries to ping this host? And just to be sure, are
>
>56 data bytes . . . 100% packet loss.  Same message as trying to ping the
>gateway from the DX2 66.  It shows HWaddr as 00:00:00:00:00:00 for
>the offending interface, btw.  Don't know if that's relevant, if it's
>caused by the switch, normal, abnormal or what.
>
> > there any problems with the routing table on *either* host? And can each
> > host arp the other (after you try a ping, for example, does each host
> > appear in the listing of /proc/net/arp on the other host)?
> >
>cat /proc/net/arp from each machine shows the correct relevant
>network address for each in the other's /proc/net/arp.  I don't know much
>about routing tables, so I'll have to think/read further on this.
>
> > A bit more than that, but I should have been explicit. What else do you
> > have on the machine that uses IRQs? (Check this in the BIOS, not in Linux,
> > because I'm wondering about a problem caused by a device that the kernel
> > does not recognize ... a Winmodem is the poster-child for this problem,
> > though, and WInmodems pretty reliably turn up on IRQ3.)
> >
>No Winmodems for sure.  2 ISA HD controller cards (or whatever those cards
>used to plug the HD into the mobo before the days of onboard IDE channels
>are called).  Can't think of what else, other than serial or parallel
>ports that might be using IRQ's.  But I'll have to take a look at the
>BIOS, as you suggest.  I'm not quite sure what I'll be looking for, but I
>will poke around a bit there.
>
> > I don't use BasicLinux, but if it's standard in this respect, the logs will
> > be in /var/log and viewable only by root. There is no real standard for how
> > syslog messages are apportioned among specific logs, so I can't give you a
> > good answer at that part ... but /var/log/messages is usually the catchall
> > file.
>
>I'll try and look into this a bit further too.  I also am not sure how
>Basiclinux handles this, obviously.
>
>Thanks, James




-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Intel 82595FX clone NIC problems

[James Miller]

Ray:

Thanks so much for your help on this.  Taking a bit of initiative based on
your second to last post, it seems I have determined the nature of the
problem.  It seems the module I'm trying to use is buggy.  Here's why I
think so.

I created a dir on the root called /module.  In that dir, I placed the
eepro.o module from the Slack 8.0 CD (2.2.19 kernel).  I edited
/etc/rc.d/rc.S to reflect the location of that module (insmod
/module/eepro.o io=0x300).  When I booted next I got, of course, a
complaint that this module was compiled for the 2.2.19 kernel (whereas I
am using 2.2.16).  So, I edited /etc/rc.d/rcS again to force the module to
load (insmod -f /module/eepro.o 0x300).  Next boot, I got an ominous
looking complaint, stating that this module would "taint" the kernel.
Undaunted, I tried the network.  No lockups.  It now works normally.  I
used it for about 5 minutes, surfing with Links and telnetting to the
gateway.  Hasn't locked up yet.  This is already much longer than I could
ever use the connection before without it dieing.  Sounds like a buggy
module I was using previously, no?

Questions, of course, remain.  What exactly does "tainting" the kernel
entail?  What risks am I taking by using this module?  Have I gone about
loading the new module correctly (putting it in that dir and loading it
with a comment including the -f switch in rc.S)?  What are other ways?

Further pointers would be appreciated.

Thanks, James
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: Intel 82595FX clone NIC problems

[ichi]

Ray Olszewski wrote:
> 
> modules have to be compiled for a specific kernel. You 
> can't get a newer eepro.o module and expect it to work 
> (or even load) with 2.2.16. If you need a newer module, 
> you need a newer kernel. Maybe ichi can comment on this part?

I agree.  The bare.i kernel (2.2) from Slackware 8.0 should 
work (with the eepro module from Slackware 8.0).  Of course, 
if James boots BasicLinux with the Slackware 8.0 kernel then
he will need to replace the 2.2.16 modules he normally uses 
with the equivalent modules from Slackware 8.0.

Cheers,
Steven

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

cloning a system

[Ray Olszewski]

What is the easiest way under Linux to make an EXACT duplicate of a hard 
disk (not a partition)? How does the answer differ if the geometry of the 
target drive is different from that of the source drive (but still big 
enough to hold the partitions)?

My actual problem: I have a Linux system that uses an 8 GB (or thereabouts) 
/dev/hda drive, partitioned as follows:

	hda1 is /boot
	hda2 is swap
	hda3 is the root (/) filesystem
	the MBR boots using lilo

Now I know how to make exact copies of the ./hda1 and ./hda3 filesystems, 
and making a swap partition is child's play. But if I do it that way, the 
MBR is not copied, and I have to boot the new system from a rescue disk, 
then run lilo to make the hard disk bootable.

is there a way, under Linux, to clone the complete drive -AND- have it be 
bootable out of the box? Does that method depend on the two drives being 
physically identical?

(BTW, the source and target systems are identical otherwise ... same mobo, 
same BIOS, same CPU, same add-in cards).


-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: cloning a system

[ichi]

Ray Olszewski wrote:
> 
> What is the easiest way under Linux to make an EXACT 
> duplicate of a hard disk (not a partition)? 
>
> is there a way, under Linux, to clone the complete 
> drive -AND- have it be bootable out of the box?  
> Does that method depend on the two drives being
> physically identical?

It seems strange telling Ray Olszewski (the Answer Man)
how to do something, but here goes:
--------------------------------
dd if=/dev/hdb of=/dev/hdc bs=2M
--------------------------------
That will clone the slave HD on the primary IDE interface
to the master HD on the secondary IDE interface.  Set bs
close to the size of the HD buffer.

The two HD do not have to be the same size.  The destination
drive can be larger, but then there will be space left-over
(which, I think, can be allocated with fdisk).

Cheers,
Steven

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: cloning a system

[Ray Olszewski]

Thanks for the quick feedback on this, Steve (and Hal).

BTW, Steve, I don't *really* know everything ... I just act like I do. 
Probably a habit from my days doing consulting work ....

OK. I tested Steve's suggestion, particularly wanting to determine two things:

(1) If I used a larger drive as a target, would the unused space be 
available via fdisk? (Steve's hedged "I think ...").

(2) If the source drive were bootable using lilo, would the target drive 
boot as well (my real concern)?

Here are the characteristics of the two drives as reported by fdisk:

SOURCE drive (on hda) --

         Disk /dev/hda: 8455 MB, 8455200768 bytes
         255 heads, 63 sectors/track, 1027 cylinders
         Units = cylinders of 16065 * 512 = 8225280 bytes

TARGET drive (on hdc) --

         Disk /dev/hdc: 10.2 GB, 10245537792 bytes
         255 heads, 63 sectors/track, 1245 cylinders
         Units = cylinders of 16065 * 512 = 8225280 bytes

The actual clone command and its result:

         maryann:~# dd if=/dev/hda of=/dev/hdc bs=2M
         4031+1 records in
         4031+1 records out
         8455200768 bytes transferred in 652.833982 seconds (12951533 
bytes/sec)

Afterwards, I could immediately

         -- mount /dev/hdc3
         -- fdisk the unused space as /dev/hdc4, and mke2fs that partition.
         -- mount /dev/hdc4

I halt'ed the system, swapped the cloned drive in as hda, and rebooted. 
lilo was able to boot the kernel (my biggest worry about this approach). 
The only (minor) problem I encountered was that the root filesystem was now 
seen as improperly umounted and required an e2fsck on the first boot ... a 
minor thing, easy to live with.

I'll watch for additional problems as I move this drive into its actual 
system (identical to the source system in all interesting ways) and use it. 
But this simple method seems to do everything I need. Thanks.

BTW, Hal, the issue with /proc involves trying to tar the root filesystem, 
not dd it ... tar will try to include all the pseudofiles in /proc unless 
you take steps to avoid this.

The easiest way is to umount /proc before you do it.

A clumsier one is to tar not the root filesystem itself but all of its 
parts (e.g., "tar -cvzf somename.tgz /etc /sbin /usr /lib ..."). Though 
clumsier, this has the advantage that you can easily skip /tmp, /var/log, 
/home. and other stuff you might also prefer not to transfer (conceivably 
/boot).

I've been told that there is a tar switch you can use too, but I forget the 
details of that one.


At 08:54 AM 4/12/2003 +0000, ichi@aggies.org wrote:
>Ray Olszewski wrote:
> >
> > What is the easiest way under Linux to make an EXACT
> > duplicate of a hard disk (not a partition)?
> >
> > is there a way, under Linux, to clone the complete
> > drive -AND- have it be bootable out of the box?
> > Does that method depend on the two drives being
> > physically identical?
>
>It seems strange telling Ray Olszewski (the Answer Man)
>how to do something, but here goes:
>--------------------------------
>dd if=/dev/hdb of=/dev/hdc bs=2M
>--------------------------------
>That will clone the slave HD on the primary IDE interface
>to the master HD on the secondary IDE interface.  Set bs
>close to the size of the HD buffer.
>
>The two HD do not have to be the same size.  The destination
>drive can be larger, but then there will be space left-over
>(which, I think, can be allocated with fdisk).



-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: cloning a system

[Hal MacArgle]

Greetings: Years ago when HD's were less than 1gB I used the dd route
to clone a drive for backup but never had the reason to check and see
if it was a valid idea.. Later, I think on this list, someone pointed
out that the dd route was not a good idea - think it may have been
Lawson IIRC..

I did note that the cloned drive, even though formatted larger than
the source drive ended up the "same" size as the source.. I can't
find my notes but seem to remember using the following:
dd if=/dev/hda of=/dev/hdc bs=8192

Approaching senility in the brain department I'm hoping someone will
pick up on this and write a mini-HOWTO as I think it's a needed
project.. At 0400 this morning I wondered if the best way would be to
boot the machine with BasicLinux, into ramdisk, and then invoke dd
from it - presuming Steven put dd in BL.. Not sure. 

Somewhere along my former testing I seem to remember /proc giving a
problem but that may have been using another routine.. Sometime in
the future someone may figure a way to RAID our normal brain. <grin>

I hope someone keeps this thread alive..

    Hal - in Terra Alta, WV - Slackware GNU/Linux 8.0   (2.4.18)
                Proprietary  Formats  Unacceptable

On 04-11, Ray Olszewski wrote:
> What is the easiest way under Linux to make an EXACT duplicate of a hard 
> disk (not a partition)? How does the answer differ if the geometry of the 
> target drive is different from that of the source drive (but still big 
> enough to hold the partitions)?
> 
> My actual problem: I have a Linux system that uses an 8 GB (or thereabouts) 
> /dev/hda drive, partitioned as follows:
> 
> 	hda1 is /boot
> 	hda2 is swap
> 	hda3 is the root (/) filesystem
> 	the MBR boots using lilo
> 
> Now I know how to make exact copies of the ./hda1 and ./hda3 filesystems, 
> and making a swap partition is child's play. But if I do it that way, the 
> MBR is not copied, and I have to boot the new system from a rescue disk, 
> then run lilo to make the hard disk bootable.
> 
> is there a way, under Linux, to clone the complete drive -AND- have it be 
> bootable out of the box? Does that method depend on the two drives being 
> physically identical?
> 
> (BTW, the source and target systems are identical otherwise ... same mobo, 
> same BIOS, same CPU, same add-in cards).
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: cloning a system

[whitnl73]

On Sat, 12 Apr 2003, Hal MacArgle/usr/local/bin/tartar wrote:

> Greetings: Years ago when HD's were less than 1gB I used the dd route
> to clone a drive for backup but never had the reason to check and see
> if it was a valid idea.. Later, I think on this list, someone pointed
> out that the dd route was not a good idea - think it may have been
> Lawson IIRC..

If your BIOS doesn't support the Enhanced BIOS call and the packet-call
interface (invented in 1998) lilo is going to have to use CHS
addressing, and differeces in geometry and bad sectors are liable to
play hob with it.
>
> I did note that the cloned drive, even though formatted larger than
> the source drive ended up the "same" size as the source.. I can't
> find my notes but seem to remember using the following:
> dd if=/dev/hda of=/dev/hdc bs=8192
>
> Approaching senility in the brain department I'm hoping someone will
> pick up on this and write a mini-HOWTO as I think it's a needed
> project.. At 0400 this morning I wondered if the best way would be to
> boot the machine with BasicLinux, into ramdisk, and then invoke dd
> from it - presuming Steven put dd in BL.. Not sure.

/usr/local/bin/tartar:
#!/bin/bash
##copy a directory or partition
tar -C "$1" -cOl . | tar -C "$2" -xpf -

mount <source device> /mnt/source
mount <target device> /mnt/targat

tartar /mnt/source /mnt/target
...
if your BIOS is old enough to need a /boot partition, mount it on the
target / (I'll call that /mnt/target) after you copy it, and install
lilo:

lilo -r /mnt/target
>
> Somewhere along my former testing I seem to remember /proc giving a
> problem but that may have been using another routine.. Sometime in
> the future someone may figure a way to RAID our normal brain. <grin>
>
> I hope someone keeps this thread alive..
>
>     Hal - in Terra Alta, WV - Slackware GNU/Linux 8.0   (2.4.18)
>                 Proprietary  Formats  Unacceptable
>

Lawson
--
---oops---



________________________________________________________________
Sign Up for Juno Platinum Internet Access Today
Only $9.95 per month!
Visit www.juno.com
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Re: cloning a system

[ichi]

Hal MacArgle wrote:
> 
> At 0400 this morning I wondered if the best way would 
> be to boot the machine with BasicLinux

Or tomsrtbt.

> into ramdisk, and then invoke dd from it - presuming 
> Steven put dd in BL.. Not sure.

Yes, I did.  It's also in tomsrtbt.

Cheers,
Steven

______________________________
http://www.volny.cz/basiclinux

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs