Linux 2.4.3, Debian Woody. 2.4.2 works without problems. However, in
2.4.3, pcnet32 loads, gives an error message:
Mar 30 18:45:09 obsidian kernel: pcnet32_probe_pci: found device
0x001022.0x002000
Mar 30 18:45:09 obsidian kernel: ioaddr=0x00b800
resource_flags=0x000101
Mar 30 18:45:09 obsidian kernel: <
Mar 30 18:45:09 obsidian kernel: 6>eth0: PCnet/FAST 79C971 at 0xb800,
warning: PROM address does not match CSR address 00 00 00 00 00 00
Mar 30 18:45:09 obsidian kernel: tx_start_pt(0x0c00):~220 bytes,
BCR18(9861):BurstWrEn BurstRdEn NoUFlow
Mar 30 18:45:09 obsidian kernel: SRAMSIZE=0x7f00, SRAM_BND=0x3f00,
Mar 30 18:45:09 obsidian kernel: pcnet32: pcnet32_private lp=c3173000
lp_dma_addr=0x3173000 assigned IRQ 5.
Mar 30 18:45:09 obsidian kernel: pcnet32.c:v1.25kf 26.9.1999
[email protected]
Though it does still load.
However, the interface does not come up. (DHCP doesn't work, can't even
assign a manual address).
Worse, I get multiple entries for the driver in /proc/interrupts. Each
time I attempt to bring the interface up another is added so I have:
5: 11276 11416 IO-APIC-level aic7xxx, PCnet/FAST 79C971,
PCnet/FAST 79C971, PCnet/FAST 79C971
When I attempt to rmmod the driver, even if there is only one, I get a
Kernel OOPS (in the interrupt handler, so it wasn't written
anywhere). I'll attempt to copy it down by hand and post to the list in a
bit.
Scott
On Fri, 30 Mar 2001, Scott G. Miller wrote:
> Linux 2.4.3, Debian Woody. 2.4.2 works without problems. However, in
> 2.4.3, pcnet32 loads, gives an error message:
hrm, can you try 2.4.2-acXX as well?
I pretty much just merged pcnet32 patches from there.
I should be getting a pcnet32 test card on Tuesday, maybe I can knock
out the bug and avoid having to revert the merge.
Regards,
Jeff
On Fri, 30 Mar 2001, Scott G. Miller wrote:
> Linux 2.4.3, Debian Woody. 2.4.2 works without problems. However, in
> 2.4.3, pcnet32 loads, gives an error message:
2.4.3 (and -ac's) are also broken as guest in VMWware due to the pcnet32
changes [doing 32 bit IO on 16 bit regs on the 79C970A controller].
Reverting this part of patch-2.4.3 below made things work again.
Szaka
@@ -528,11 +535,13 @@
pcnet32_dwio_reset(ioaddr);
pcnet32_wio_reset(ioaddr);
- if (pcnet32_wio_read_csr (ioaddr, 0) == 4 && pcnet32_wio_check (ioaddr)) {
- a = &pcnet32_wio;
+ /* Important to do the check for dwio mode first. */
+ if (pcnet32_dwio_read_csr(ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) {
+ a = &pcnet32_dwio;
} else {
- if (pcnet32_dwio_read_csr (ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) {
- a = &pcnet32_dwio;
+ if (pcnet32_wio_read_csr(ioaddr, 0) == 4 &&
+ pcnet32_wio_check(ioaddr)) {
+ a = &pcnet32_wio;
} else
return -ENODEV;
}
Carsten,
seems your pcnet32 changes which made it into 2.4.3 are causing trouble
on i386 machines. Can you try to solve that problem?
On Sat, Mar 31, 2001 at 03:58:11PM +0200, Szabolcs Szakacsits wrote:
> On Fri, 30 Mar 2001, Scott G. Miller wrote:
>
> > Linux 2.4.3, Debian Woody. 2.4.2 works without problems. However, in
> > 2.4.3, pcnet32 loads, gives an error message:
>
> 2.4.3 (and -ac's) are also broken as guest in VMWware due to the pcnet32
> changes [doing 32 bit IO on 16 bit regs on the 79C970A controller].
> Reverting this part of patch-2.4.3 below made things work again.
>
> Szaka
>
> @@ -528,11 +535,13 @@
> pcnet32_dwio_reset(ioaddr);
> pcnet32_wio_reset(ioaddr);
>
> - if (pcnet32_wio_read_csr (ioaddr, 0) == 4 && pcnet32_wio_check (ioaddr)) {
> - a = &pcnet32_wio;
> + /* Important to do the check for dwio mode first. */
> + if (pcnet32_dwio_read_csr(ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) {
> + a = &pcnet32_dwio;
> } else {
> - if (pcnet32_dwio_read_csr (ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) {
> - a = &pcnet32_dwio;
> + if (pcnet32_wio_read_csr(ioaddr, 0) == 4 &&
> + pcnet32_wio_check(ioaddr)) {
> + a = &pcnet32_wio;
> } else
> return -ENODEV;
> }
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Ralf
I'm not sure what the problem is, but the whole deal about checking whether the
controller runs in 16 bit or 32 bit mode, is a little bit tricky.
There doesn't seem to be a clean way to do the check, so it's done by writing a certain
pattern to a register and read it back again.
Doing the check for 32 bit mode first seems to be the right thing to do, but it's
apparently breaks thing for some people with older chipsets.
It work fine on my site in both 16 bit and 32 bit mode, though (I'm using an AMD
Am97C973 chipset).
I can't remember exactly if that part of the fix really was necessary to get the driver
work in 32 bit mode, but at least the rest of the patch is necessary (it has been some
time since I made this fix and I originally did it in the 2.2.12 sources).
So I guess reverting the suggested part of the patch is appropriate.
I'm terrible sorry for causing any inconvenience.
/Carsten
Ralf Baechle wrote:
> Carsten,
>
> seems your pcnet32 changes which made it into 2.4.3 are causing trouble
> on i386 machines. Can you try to solve that problem?
>
> On Sat, Mar 31, 2001 at 03:58:11PM +0200, Szabolcs Szakacsits wrote:
>
> > On Fri, 30 Mar 2001, Scott G. Miller wrote:
> >
> > > Linux 2.4.3, Debian Woody. 2.4.2 works without problems. However, in
> > > 2.4.3, pcnet32 loads, gives an error message:
> >
> > 2.4.3 (and -ac's) are also broken as guest in VMWware due to the pcnet32
> > changes [doing 32 bit IO on 16 bit regs on the 79C970A controller].
> > Reverting this part of patch-2.4.3 below made things work again.
> >
> > Szaka
> >
> > @@ -528,11 +535,13 @@
> > pcnet32_dwio_reset(ioaddr);
> > pcnet32_wio_reset(ioaddr);
> >
> > - if (pcnet32_wio_read_csr (ioaddr, 0) == 4 && pcnet32_wio_check (ioaddr)) {
> > - a = &pcnet32_wio;
> > + /* Important to do the check for dwio mode first. */
> > + if (pcnet32_dwio_read_csr(ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) {
> > + a = &pcnet32_dwio;
> > } else {
> > - if (pcnet32_dwio_read_csr (ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) {
> > - a = &pcnet32_dwio;
> > + if (pcnet32_wio_read_csr(ioaddr, 0) == 4 &&
> > + pcnet32_wio_check(ioaddr)) {
> > + a = &pcnet32_wio;
> > } else
> > return -ENODEV;
> > }
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> Ralf
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected]
|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527
| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555
TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556
Denmark http://www.mips.com
Carsten Langgaard wrote:
>
> I'm not sure what the problem is, but the whole deal about checking whether the
> controller runs in 16 bit or 32 bit mode, is a little bit tricky.
>[snip]
Without the changes listed in this thread, 2.4.3 crashed vmware 2.0.3
Linux. It did not OOPS the kernel, it caused vmware to go down in
flames.... Changing the code per the previous mail fixed it and
my VM now works fine. THANKS!
Is this list non-causal? The answer was posted to the list as I
was getting ready to build 2.4.3 on my VM, before I found the
problem or even had to ask the question!
Cheers,
--
W. Wade, Hampton <[email protected]>
If Microsoft Built Cars: Every time they repainted the
lines on the road, you'd have to buy a new car.
Occasionally your car would just die for no reason, and
you'd have to restart it, but you'd just accept this.
Wade Hampton wrote:
>
> Carsten Langgaard wrote:
> >
> > I'm not sure what the problem is, but the whole deal about checking whether the
> > controller runs in 16 bit or 32 bit mode, is a little bit tricky.
> >[snip]
> Without the changes listed in this thread, 2.4.3 crashed vmware 2.0.3
> Linux. It did not OOPS the kernel, it caused vmware to go down in
> flames.... Changing the code per the previous mail fixed it and
> my VM now works fine. THANKS!
>
> Is this list non-causal? The answer was posted to the list as I
> was getting ready to build 2.4.3 on my VM, before I found the
> problem or even had to ask the question!
VMware is working on implementation PCnet 32bit mode in emulation (there
is no such thing now because of no OS except FreeBSD needs it). But
my question is - is there some real benefit in running chip in
32bit mode? All registers except CSR88 use only low 16 bits anyway,
so is 32bit mode needed for bigendian ports, or what's reasoning
behind it? AFAIK all chips support 16bit mode, and having only 16bit
mode in code could save at least one indirect jump on each chip access.
Thanks,
Petr Vandrovec
[email protected]
On Wed, Apr 04, 2001 at 01:14:16PM -0700, Petr Vandrovec wrote:
> VMware is working on implementation PCnet 32bit mode in emulation (there
> is no such thing now because of no OS except FreeBSD needs it). But
> my question is - is there some real benefit in running chip in
> 32bit mode?
probably not.
> so is 32bit mode needed for bigendian ports, or what's reasoning
> behind it?
I've added 32bit mode for some IBM PowerPC machines. The firmware
on this machines setup the chip to DWIO and I haven't found a way
to switch it back to WIO.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ Alexander Viro on linux-kernel ]
Thomas Bogendoerfer wrote:
>
> On Wed, Apr 04, 2001 at 01:14:16PM -0700, Petr Vandrovec wrote:
> > VMware is working on implementation PCnet 32bit mode in emulation (there
> > is no such thing now because of no OS except FreeBSD needs it). But
> > my question is - is there some real benefit in running chip in
> > 32bit mode?
>
> probably not.
>
> > so is 32bit mode needed for bigendian ports, or what's reasoning
> > behind it?
>
> I've added 32bit mode for some IBM PowerPC machines. The firmware
> on this machines setup the chip to DWIO and I haven't found a way
> to switch it back to WIO.
Current Linux driver switches them to 16bit mode in pcnet_probe1:
pcnet_dwio_reset(); // reset to 16bit mode when in 32bit, ignore in
16bit mode
pcnet_wio_reset(); // device is for sure in 16bit mode, but reset it
again to
// get it into known state if we were in 16bit mode
already
So you should find hardware always in 16bit mode at this point. If it
does not work, maybe you need to xor PCNET32_WIO_* values with 2 on
PowerPC...
Best regards,
Petr Vandrovec
[email protected]
Thomas Bogendoerfer wrote:
> On Wed, Apr 04, 2001 at 01:14:16PM -0700, Petr Vandrovec wrote:
> > VMware is working on implementation PCnet 32bit mode in emulation (there
> > is no such thing now because of no OS except FreeBSD needs it). But
> > my question is - is there some real benefit in running chip in
> > 32bit mode?
>
> probably not.
In some 32bit bigendian systems you need to do address-swapping before doing any
16 bit (or 8 bit) PCI accesses, whereas 32 bit (full bus width) doesn't need any
swapping, and therefor it would be more efficient.
>
> > so is 32bit mode needed for bigendian ports, or what's reasoning
> > behind it?
>
> I've added 32bit mode for some IBM PowerPC machines. The firmware
> on this machines setup the chip to DWIO and I haven't found a way
> to switch it back to WIO.
I got the same issue on one of my platforms, the firmware setup the chip to DWIO
and the only thing that will bring it back to WIO is a hardware reset.
>
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessary a
> good idea. [ Alexander Viro on linux-kernel ]
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected]
|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527
| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555
TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556
Denmark http://www.mips.com
Petr Vandrovec wrote:
> Thomas Bogendoerfer wrote:
> >
> > On Wed, Apr 04, 2001 at 01:14:16PM -0700, Petr Vandrovec wrote:
> > > VMware is working on implementation PCnet 32bit mode in emulation (there
> > > is no such thing now because of no OS except FreeBSD needs it). But
> > > my question is - is there some real benefit in running chip in
> > > 32bit mode?
> >
> > probably not.
> >
> > > so is 32bit mode needed for bigendian ports, or what's reasoning
> > > behind it?
> >
> > I've added 32bit mode for some IBM PowerPC machines. The firmware
> > on this machines setup the chip to DWIO and I haven't found a way
> > to switch it back to WIO.
>
> Current Linux driver switches them to 16bit mode in pcnet_probe1:
>
> pcnet_dwio_reset(); // reset to 16bit mode when in 32bit, ignore in
> 16bit mode
> pcnet_wio_reset(); // device is for sure in 16bit mode, but reset it
> again to
> // get it into known state if we were in 16bit mode
> already
>
> So you should find hardware always in 16bit mode at this point. If it
> does not work, maybe you need to xor PCNET32_WIO_* values with 2 on
> PowerPC...
I'm afraid that's not true.
The above only do a software reset and that doesn't effect the I/O mode.
Only a hardware reset effects the I/O mode.
An because any firmware might changes to 32bit mode after reset (of the whole
system), we need to support both modes.
>
> Best regards,
> Petr Vandrovec
> [email protected]
--
_ _ ____ ___ Carsten Langgaard Mailto:[email protected]
|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527
| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555
TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556
Denmark http://www.mips.com
Carsten Langgaard wrote:
>
> Petr Vandrovec wrote:
> > Current Linux driver switches them to 16bit mode in pcnet_probe1:
> >
> > pcnet_dwio_reset(); // reset to 16bit mode when in 32bit, ignore in
> > 16bit mode
> > pcnet_wio_reset(); // device is for sure in 16bit mode, but reset it
> > again to
> I'm afraid that's not true.
> The above only do a software reset and that doesn't effect the I/O mode.
> Only a hardware reset effects the I/O mode.
> An because any firmware might changes to 32bit mode after reset (of the whole
> system), we need to support both modes.
Oops. I misinterpreted what code does. Really stupid hardware.
Thanks,
Petr Vandrovec
[email protected]