3COM 3c905c again

3COM 3c905c again

[Jonathan Lane]

Okay, I swapped cards around, and it turns out that *anything* in
PCI slots 3-6 are not correctly configured (this is on a UMAX S900).
I moved the USB card and NIC to slots 1 and 2, and my video card
to slot 4, which appears to be working (although I've not tried
using X yet, as XF86 4.0.1 is currently broken...).

However, now I am having another problem:  When I ping the machine,
I see the RX light on the NIC flash, but the source machine doesn't
get any responses.

A few things to note:  Every once in a while, I see the following
message:

	eth1: Setting promiscuous mode.

Also, in my syslog, dhcpd complains with:

Aug 27 16:42:20 colour dhcpd-2.2.x: DHCPDISCOVER from 08:00:46:05:9c:c8 via eth1
Aug 27 16:42:20 colour dhcpd-2.2.x: no free leases on subnet 192.168.1.0

(Ignore the date, my clock had yet to be set).  But this indicates that
packets *are* getting thru, as the MAC address shown above is correct.

If anyone can shed some light on this matter, I'd greatly appreciate it.
I'd also like to know why the last four PCI slots don't work properly,
although it appears it's not incredibly important now, unless X doesn't
work...

TIA,
Jonathan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 3COM 3c905c again

[Tony Mantler]

At 6:49 PM -0600 12/3/2000, Jonathan Lane wrote:
>(although I've not tried
>using X yet, as XF86 4.0.1 is currently broken...).

X4 works for me[tm] on my 9600 with debian. Of course, I seem to be the
only person on the planet who's got X working in a 9600, with an imstt, in
the bottom slots, without offb, etc etc etc, so ymmv.


>However, now I am having another problem:  When I ping the machine,
>I see the RX light on the NIC flash, but the source machine doesn't
>get any responses.
>
>A few things to note:  Every once in a while, I see the following
>message:
>
>	eth1: Setting promiscuous mode.

Probably from dhcpcd sending out a broadcast to find a DHCP server.


>Also, in my syslog, dhcpd complains with:
>
>Aug 27 16:42:20 colour dhcpd-2.2.x: DHCPDISCOVER from 08:00:46:05:9c:c8
>via eth1
>Aug 27 16:42:20 colour dhcpd-2.2.x: no free leases on subnet 192.168.1.0
>
>(Ignore the date, my clock had yet to be set).  But this indicates that
>packets *are* getting thru, as the MAC address shown above is correct.

Check your DHCP server configuration and logfiles. It would appear your
server doesn't want to give your client an IP address.

Note that when dhcpcd doesn't get an IP address, it will deconfigure the
interface it's on, thus not allowing any traffic through.


>If anyone can shed some light on this matter, I'd greatly appreciate it.
>I'd also like to know why the last four PCI slots don't work properly,
>although it appears it's not incredibly important now, unless X doesn't
>work...

I think there's some PCI bogosity in the standard 2.2 kernels when it comes
to PCI-PCI bridges. I've had fairly good luck with 2.2 with a PCI patchset
that I don't recall the URL of, and more recently, with 2.4 rsynced from
penguinppc.

Someone else can answer with more authority on the subject.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 3COM 3c905c again

[Eric Reischer]

As for the PCI slots, I'm afraid I can't be much of any help.  The error
you are describing in your syslog, that basically means that your DHCP
server does not have any more IP addresses to give out to clients.  If you
administer this server, then you might want to consider adding more
addresses to the scope.  When the machine comes up, I'll bet if you do an
ifconfig, and take a look at your eth1 adapter settings (if it's there), it
won't have an IP address, which explains why packets aren't bouncing back
to your ping source.

Eric



At 07:49 PM 12/3/00 , Jonathan Lane wrote:
>Okay, I swapped cards around, and it turns out that *anything* in
>PCI slots 3-6 are not correctly configured (this is on a UMAX S900).
>I moved the USB card and NIC to slots 1 and 2, and my video card
>to slot 4, which appears to be working (although I've not tried
>using X yet, as XF86 4.0.1 is currently broken...).
>
>However, now I am having another problem:  When I ping the machine,
>I see the RX light on the NIC flash, but the source machine doesn't
>get any responses.
>
>A few things to note:  Every once in a while, I see the following
>message:
>
>         eth1: Setting promiscuous mode.
>
>Also, in my syslog, dhcpd complains with:
>
>Aug 27 16:42:20 colour dhcpd-2.2.x: DHCPDISCOVER from 08:00:46:05:9c:c8
>via eth1
>Aug 27 16:42:20 colour dhcpd-2.2.x: no free leases on subnet 192.168.1.0
>
>(Ignore the date, my clock had yet to be set).  But this indicates that
>packets *are* getting thru, as the MAC address shown above is correct.
>
>If anyone can shed some light on this matter, I'd greatly appreciate it.
>I'd also like to know why the last four PCI slots don't work properly,
>although it appears it's not incredibly important now, unless X doesn't
>work...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 3COM 3c905c again

[Jonathan Lane]

> >Also, in my syslog, dhcpd complains with:
> >
> >Aug 27 16:42:20 colour dhcpd-2.2.x: DHCPDISCOVER from 08:00:46:05:9c:c8
> >via eth1
> >>Aug 27 16:42:20 colour dhcpd-2.2.x: no free leases on subnet 192.168.1.0
> >
> >(Ignore the date, my clock had yet to be set).  But this indicates that
> >packets *are* getting thru, as the MAC address shown above is correct.
>
>
> Check your DHCP server configuration and logfiles. It would appear your
> server doesn't want to give your client an IP address.

Actually, I think it had something to do with the date not being set, as
this went away just after I reset the clock.

> >I'd also like to know why the last four PCI slots don't work properly,
> >although it appears it's not incredibly important now, unless X doesn't
> >work...
>
> I think there's some PCI bogosity in the standard 2.2 kernels when it comes
> to PCI-PCI bridges. I've had fairly good luck with 2.2 with a PCI patchset

This was the problem.  I moved the NIC to slot 2, and moved my video board
to slot 4.  Everything works fine now.  The actual problem with packets
not making it to the other machine had to do with my homemade cable (works
over 10BT, but not 100BT... probably either due to length and/or quality).

Also, if you or anyone else can ever recall the source for the PCI patch,
I'd appreciate it.  Wonder why it hasn't been rolled into the 2.2 kernels
yet, though...?

Thanks for everyone's help.  Also, just to summarize, here are the cards
I tried, just in case anyone else here attempts to add a second NIC and
runs into the same problems I did:

Netgear FA311 -- not recognized at all; link light didn't even light up.

Linksys NC100 & LNE100TX -- both seemed to function, as I was able to
   send a couple packets out, but seemed flaky; however, this was
   most likely due to my crummy cable, so I'd say give these cards a
   shot since they're significantly cheaper than the 3com...

3COM 3c905c-tx-m -- works beautifully, if you're cables don't suck :)

Regards,
Jonathan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 3COM 3c905c again

[Michel Lanners]

Hi,

On   4 Dec, this message from Jonathan Lane echoed through cyberspace:
>> >I'd also like to know why the last four PCI slots don't work properly,
>> >although it appears it's not incredibly important now, unless X doesn't
>> >work...
>>
>> I think there's some PCI bogosity in the standard 2.2 kernels when it comes
>> to PCI-PCI bridges. I've had fairly good luck with 2.2 with a PCI patchset

For PCI-to-PCI bridges, it's only regarding IRQs. For multiple host
bridges (like 9x00 machines), it's more complex.

> This was the problem.  I moved the NIC to slot 2, and moved my video board
> to slot 4.  Everything works fine now.  The actual problem with packets
> not making it to the other machine had to do with my homemade cable (works
> over 10BT, but not 100BT... probably either due to length and/or quality).

Cables for 100BT need to be _very_ good quality, if you go by handmade
standards. I've had some bad luck with homemade cables as well; they
tested perfectly fine with a 10BaseT tester, but didn't work with
100BaseT.

> Also, if you or anyone else can ever recall the source for the PCI patch,
> I'd appreciate it.  Wonder why it hasn't been rolled into the 2.2 kernels
> yet, though...?

The PCI patch Tony talked about was probably mine, and can be found
here:

http://www.cpu.lu/~mlan/linux/dev/pci.html

The reason it's not in 2.2 is that for one, it's not good enough for
2.2, plus it is sometimes extremely hard to get patches into the more
official kernels... that can be frustrating, at times. Which eats up
some of the motivation to work harder...

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 3COM 3c905c again

[Benjamin Herrenschmidt]

>>Okay, I swapped cards around, and it turns out that *anything* in
>>PCI slots 3-6 are not correctly configured (this is on a UMAX S900).
>>I moved the USB card and NIC to slots 1 and 2, and my video card
>>to slot 4, which appears to be working (although I've not tried
>>using X yet, as XF86 4.0.1 is currently broken...).

This might work better with current bitkeeper _2_3 kernels (currently
at 2.4test12-pre-something). There's some new PCI code there that should
handle multiple PCI busses more gracefully.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/