Re: [2.6 patch] the scheduled eepro100 removal
Sounds sane to me. My overall opinion on eepro100 removal is that we're not there yet. Rare problem cases remain where e100 fails but eepro100 works, and it's older drivers so its low priority for everybody. Needs to happen, though... It seems that several Tyan Opteron base system that were using IPMI add on card. the IPMI card share intel 100Mhz nic onboard. you need to use eepro100 instead of e100 otherwise the e100 will shutdown OOB (out of Band) connection for IPMI when shut down the OS. I find it hard to believe that something as common as IPMI in conjunction with the IPMI technology wasn't tested in Intel's lab. From my experience with Intel Server boards, onboard IPMI (all offered versions) and e100/e1000 NICs, I've never ever experienced any problems operating the BMC over the NIC. Also, I don't quite understand you point about the "IPMI card sharing the 100Mbit/s NIC" onboard? What exactly is shared? Best regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc - 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/
Re: [2.6 patch] the scheduled eepro100 removal
Sounds sane to me. My overall opinion on eepro100 removal is that we're not there yet. Rare problem cases remain where e100 fails but eepro100 works, and it's older drivers so its low priority for everybody. Needs to happen, though... It seems that several Tyan Opteron base system that were using IPMI add on card. the IPMI card share intel 100Mhz nic onboard. you need to use eepro100 instead of e100 otherwise the e100 will shutdown OOB (out of Band) connection for IPMI when shut down the OS. I find it hard to believe that something as common as IPMI in conjunction with the IPMI technology wasn't tested in Intel's lab. From my experience with Intel Server boards, onboard IPMI (all offered versions) and e100/e1000 NICs, I've never ever experienced any problems operating the BMC over the NIC. Also, I don't quite understand you point about the IPMI card sharing the 100Mbit/s NIC onboard? What exactly is shared? Best regards, Roberto Nibali, ratz -- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc - 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/
Re: [PATCH] MPT FUSION: Delete unused header files.
Certainly appropriate content for something on your website,
and vendors who
provide programs like dmidecode and parsemce are always
welcome. I could
probably be convinced that such info should have at least a
pointer somewhere
in Documentation/lsi_debug.txt or some such. But quite
frankly, if I'm reduced
to wading through *.h files to figure out what some
recalcitrant hardware is
upset about, there's been a failure in documentation.
*ESPECIALLY* if I
go look at drivers/whatever/source.c and it doesn't even
*reference* the *.h
file in question.
Its apparent to me that you don't have our hardware, nor have you
actually waded thru this driver source code.
Allow me to shortly chime in here:
I'm the author of the mpt-status user space tool (a simple alternative
to your Java GUI tool), which queries LSI controllers and reports back
the RAID status and the synchronization state; so I have waded through
the driver source code quite a lot. My question:
If you did, you would of noticed that the header you want to delete, is
actually referenced in the *.c source code. The file "mpi_log_fc.h",
is indeed mentioned in mptbase.c, in the function called
mpt_fc_log_info, in the documention section above the function.This
header file is very helpful to those supporting our hardware, and those
using it
For SAS(mpi_log_sas.h), I have broken out each loginfo in the strings
you will find defined in originator_str, iop_code_str, pl_code_str, etc,
I probably do that with fibre.
If its that important to you to have the header files included, I will
provide a patch that does that.
I would really like to see "sanitized" kernel headers, so is it possible
to have your headers inside ../drivers/message/fusion{,/lsi} somehow
inserted into the process of the headers_install target?
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
-
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/
Re: [PATCH] MPT FUSION: Delete unused header files.
Certainly appropriate content for something on your website,
and vendors who
provide programs like dmidecode and parsemce are always
welcome. I could
probably be convinced that such info should have at least a
pointer somewhere
in Documentation/lsi_debug.txt or some such. But quite
frankly, if I'm reduced
to wading through *.h files to figure out what some
recalcitrant hardware is
upset about, there's been a failure in documentation.
*ESPECIALLY* if I
go look at drivers/whatever/source.c and it doesn't even
*reference* the *.h
file in question.
Its apparent to me that you don't have our hardware, nor have you
actually waded thru this driver source code.
Allow me to shortly chime in here:
I'm the author of the mpt-status user space tool (a simple alternative
to your Java GUI tool), which queries LSI controllers and reports back
the RAID status and the synchronization state; so I have waded through
the driver source code quite a lot. My question:
If you did, you would of noticed that the header you want to delete, is
actually referenced in the *.c source code. The file mpi_log_fc.h,
is indeed mentioned in mptbase.c, in the function called
mpt_fc_log_info, in the documention section above the function.This
header file is very helpful to those supporting our hardware, and those
using it
For SAS(mpi_log_sas.h), I have broken out each loginfo in the strings
you will find defined in originator_str, iop_code_str, pl_code_str, etc,
I probably do that with fibre.
If its that important to you to have the header files included, I will
provide a patch that does that.
I would really like to see sanitized kernel headers, so is it possible
to have your headers inside ../drivers/message/fusion{,/lsi} somehow
inserted into the process of the headers_install target?
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
-
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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
Jeff Garzik wrote:
>
> Roberto Nibali wrote:
> >
> > > This was a special case, which btw had nothing to do with the starfire
> > > driver itself. The user needed to support more than 8 eth ports, which
> > > 2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't
> > > allow without further changes.
> >
> > I made the changes and I was able to load 4 quadboards, 2 3com cards and
> > 1 eepro100 (onboard) and I did some tests and it works fine. However the
> > starfire driver seems not to initialize more then 4 quadboards. I put in
> > 5 and he doesn't initialize it and the others don't work although they
> > get initialized.
>
> If all five show up in 'lspci', then starfire driver should be able to
> register all five. [if it doesn't, it is probably a starfire bug]
No, it's not a bug but thank you for this tip. It's just a put-on limitation
in the driver itself:
--- starfire.c~ Fri Apr 20 18:48:05 2001
+++ starfire.c Fri Apr 20 18:27:20 2001
@@ -308,7 +308,7 @@
void (*resume)(struct pci_dev *dev);/* Device woken up */
};
-#define PCI_MAX_MAPPINGS 16
+#define PCI_MAX_MAPPINGS 32
static struct pci_driver_mapping drvmap [PCI_MAX_MAPPINGS] = { { NULL, } , };
#define __devinit __init
This cures my problem. I've checked this and it seems as if Ion copied
this from the sound/emu10k1/emu_wrapper.c code, where I understand that
nobody will have more then 16 times the same soundcard. Ion, do I break
something with this? If not, could you please adjust your driver?
Thanks to all of you for your help. I learned a lot today.
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
> This was a special case, which btw had nothing to do with the starfire > driver itself. The user needed to support more than 8 eth ports, which > 2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't > allow without further changes. I made the changes and I was able to load 4 quadboards, 2 3com cards and 1 eepro100 (onboard) and I did some tests and it works fine. However the starfire driver seems not to initialize more then 4 quadboards. I put in 5 and he doesn't initialize it and the others don't work although they get initialized. Is there a trivial way to get more then 4 NIC's of the same manufacturer running in one box. I also start believing that this is a motherboard problem since when I put in more the 4 3Com cards, the boot freezes after the SCSI BIOS init and before the lilo. Does anybody have the same problem? Roberto Nibali, ratz -- mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'` - 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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
Hi Ion, > I think the UP-APIC support was added primarily to support the NMI oopser > on UP systems. I might be wrong, though. You're right, at least from the perspective of this patch: http://www.csd.uu.se/~mikpe/linux/upapic/upapic-2.4.1 > You can safely disregard the "early initialization deferred" messages. > They are essentially harmless. Thanks for the info. I can sleep now :) > As for the 16 eth ports limit, if you want to increase it, simply edit > drivers/net/net_init.c and change the value of MAX_ETH_CARDS. This limit > appears to also affect modules, so my earlier suggestion of using modules > wouldn't have helped. Thanks a lot. And sorry I don't know the kernel sources and documentations good enough yet. > If the only thing you need from your boxes is networking-related, than > it's probably ok. Otherwise I'd wait a bit longer before putting 2.4 on > production servers... It is only network related (packetfiltering and load balancing with QoS) and I like the improved mm. I've been testing 2.4 since its early days and f.e. on the Intel L440GX+ boards it runs like hell, also with SMP. Only the CPU numbering is incorrect if the kernel is SMP and you only put in one processor. But I read somewhere that also this feature is normal since it seems to be impossible to give the CPUs the correct numbers because there is no defined order of initialization. > Yeah, I guess I'll submit a patch to remove the experimental bit, after > the current code changes are accepted.. Good. Yes, I saw the patches. I might try it out back here with a 2.4.x kernel and 4 quadboards. > You shouldn't need to do that, it's just wasted memory. The ethX_dev was > used mostly to avoid probing for ISA cards, which is completely irrelevant > when using PCI cards. As for the 4 quadboards limit, see above -- all you > need to change is MAX_ETH_CARDS. Will certainly do that. And thank you again for this information. Best regards, Roberto Nibali, ratz -- mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'` - 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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
> The UP-APIC wouldn't help much since there really aren't other processors
> available to share the load.
Hmm, but doesn't the code in 2.4.x improve the hard IRQ signal delivery
even for UP systems with a local APIC table? I have an APIC aware board
but I have only got 1 CPU on it and I currently need to run 2.2 kernel.
But if you tell me that there is not much help, I'm ok with that, as
long as it wouldn't be better with APIC support :)
> On the other hand, this is not as bad as it looks. In fact, it will
> function rather well and with relatively little overhead if all configured
> interfaces are seeing traffic on a regular basis. The IRQ dispatcher will
> simply call all registered interrupt routines, and most of them will end
> up doing something useful.
Aha, thanks for the information. Indeed you're right because I'm running
boxes with such a configuration which have already 100+ days uptime under
heavy network load.
> Well.. Space.c is a dinozaur. However, this is the 2.2 series and no more
> surgery will happen on this kernel, at least normally.
So, what is your suggestion: Does this limitation do any harm or can I
live with that and still run 16 eth devices and safely disregard the
"early initialization ..." ?
> Have you tried loading the drivers as modules? You might have more luck
> with that approach. Space.c was designed at a time when having 4 NIC's in
> a PC was "pushing the limits"...
Yes, I've tried it but the problem is, that I've hundreds of nodes and about
a dozen of different node setups, some with 1 NIC, some with 1 NIC and 1 quad
board, up to some with 3 NICs and 3 quadboards. I've developed an own distro
which has one kernel. Since I can't make the correct modules get loaded without
mucking around with the /etc/modules.conf, I need to compile-in the drivers.
I'd be happy if the ethif_probe() could call the request_module() and load the
correct module and initialize the ethX. As of now I would need to adjust the
/etc/modules.conf according to the amount of quadboards I have put into my
node. Or did I miss the concept of /etc/modules.conf?
> Because, again, this is legacy code. It works, it does the job, that's it.
> All this crap is gone in 2.4.
I'll be porting my distribution to 2.4.x soon I think :)
> Like I said, try the modules approach. If that doesn't work, I'll take a
> closer look (and maybe borrow a few quads from work so I can actually test
> the code...)
Your driver works now and for me now need to mark it experimental. It also
works statically built into the kernel up to 4 quadboards. I hacked Space.c
and enhanced the ``static struct device ethX_dev = { };'' stuff.
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
The UP-APIC wouldn't help much since there really aren't other processors
available to share the load.
Hmm, but doesn't the code in 2.4.x improve the hard IRQ signal delivery
even for UP systems with a local APIC table? I have an APIC aware board
but I have only got 1 CPU on it and I currently need to run 2.2 kernel.
But if you tell me that there is not much help, I'm ok with that, as
long as it wouldn't be better with APIC support :)
On the other hand, this is not as bad as it looks. In fact, it will
function rather well and with relatively little overhead if all configured
interfaces are seeing traffic on a regular basis. The IRQ dispatcher will
simply call all registered interrupt routines, and most of them will end
up doing something useful.
Aha, thanks for the information. Indeed you're right because I'm running
boxes with such a configuration which have already 100+ days uptime under
heavy network load.
Well.. Space.c is a dinozaur. However, this is the 2.2 series and no more
surgery will happen on this kernel, at least normally.
So, what is your suggestion: Does this limitation do any harm or can I
live with that and still run 16 eth devices and safely disregard the
"early initialization ..." ?
Have you tried loading the drivers as modules? You might have more luck
with that approach. Space.c was designed at a time when having 4 NIC's in
a PC was "pushing the limits"...
Yes, I've tried it but the problem is, that I've hundreds of nodes and about
a dozen of different node setups, some with 1 NIC, some with 1 NIC and 1 quad
board, up to some with 3 NICs and 3 quadboards. I've developed an own distro
which has one kernel. Since I can't make the correct modules get loaded without
mucking around with the /etc/modules.conf, I need to compile-in the drivers.
I'd be happy if the ethif_probe() could call the request_module() and load the
correct module and initialize the ethX. As of now I would need to adjust the
/etc/modules.conf according to the amount of quadboards I have put into my
node. Or did I miss the concept of /etc/modules.conf?
Because, again, this is legacy code. It works, it does the job, that's it.
All this crap is gone in 2.4.
I'll be porting my distribution to 2.4.x soon I think :)
Like I said, try the modules approach. If that doesn't work, I'll take a
closer look (and maybe borrow a few quads from work so I can actually test
the code...)
Your driver works now and for me now need to mark it experimental. It also
works statically built into the kernel up to 4 quadboards. I hacked Space.c
and enhanced the ``static struct device ethX_dev = { };'' stuff.
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
Hi Ion, I think the UP-APIC support was added primarily to support the NMI oopser on UP systems. I might be wrong, though. You're right, at least from the perspective of this patch: http://www.csd.uu.se/~mikpe/linux/upapic/upapic-2.4.1 You can safely disregard the "early initialization deferred" messages. They are essentially harmless. Thanks for the info. I can sleep now :) As for the 16 eth ports limit, if you want to increase it, simply edit drivers/net/net_init.c and change the value of MAX_ETH_CARDS. This limit appears to also affect modules, so my earlier suggestion of using modules wouldn't have helped. Thanks a lot. And sorry I don't know the kernel sources and documentations good enough yet. If the only thing you need from your boxes is networking-related, than it's probably ok. Otherwise I'd wait a bit longer before putting 2.4 on production servers... It is only network related (packetfiltering and load balancing with QoS) and I like the improved mm. I've been testing 2.4 since its early days and f.e. on the Intel L440GX+ boards it runs like hell, also with SMP. Only the CPU numbering is incorrect if the kernel is SMP and you only put in one processor. But I read somewhere that also this feature is normal since it seems to be impossible to give the CPUs the correct numbers because there is no defined order of initialization. Yeah, I guess I'll submit a patch to remove the experimental bit, after the current code changes are accepted.. Good. Yes, I saw the patches. I might try it out back here with a 2.4.x kernel and 4 quadboards. You shouldn't need to do that, it's just wasted memory. The ethX_dev was used mostly to avoid probing for ISA cards, which is completely irrelevant when using PCI cards. As for the 4 quadboards limit, see above -- all you need to change is MAX_ETH_CARDS. Will certainly do that. And thank you again for this information. Best regards, Roberto Nibali, ratz -- mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'` - 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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
This was a special case, which btw had nothing to do with the starfire driver itself. The user needed to support more than 8 eth ports, which 2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't allow without further changes. I made the changes and I was able to load 4 quadboards, 2 3com cards and 1 eepro100 (onboard) and I did some tests and it works fine. However the starfire driver seems not to initialize more then 4 quadboards. I put in 5 and he doesn't initialize it and the others don't work although they get initialized. Is there a trivial way to get more then 4 NIC's of the same manufacturer running in one box. I also start believing that this is a motherboard problem since when I put in more the 4 3Com cards, the boot freezes after the SCSI BIOS init and before the lilo. Does anybody have the same problem? Roberto Nibali, ratz -- mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'` - 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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
Jeff Garzik wrote:
Roberto Nibali wrote:
This was a special case, which btw had nothing to do with the starfire
driver itself. The user needed to support more than 8 eth ports, which
2.2 complains about, and more than 16 eth ports, which 2.2 simply doesn't
allow without further changes.
I made the changes and I was able to load 4 quadboards, 2 3com cards and
1 eepro100 (onboard) and I did some tests and it works fine. However the
starfire driver seems not to initialize more then 4 quadboards. I put in
5 and he doesn't initialize it and the others don't work although they
get initialized.
If all five show up in 'lspci', then starfire driver should be able to
register all five. [if it doesn't, it is probably a starfire bug]
No, it's not a bug but thank you for this tip. It's just a put-on limitation
in the driver itself:
--- starfire.c~ Fri Apr 20 18:48:05 2001
+++ starfire.c Fri Apr 20 18:27:20 2001
@@ -308,7 +308,7 @@
void (*resume)(struct pci_dev *dev);/* Device woken up */
};
-#define PCI_MAX_MAPPINGS 16
+#define PCI_MAX_MAPPINGS 32
static struct pci_driver_mapping drvmap [PCI_MAX_MAPPINGS] = { { NULL, } , };
#define __devinit __init
This cures my problem. I've checked this and it seems as if Ion copied
this from the sound/emu10k1/emu_wrapper.c code, where I understand that
nobody will have more then 16 times the same soundcard. Ion, do I break
something with this? If not, could you please adjust your driver?
Thanks to all of you for your help. I learned a lot today.
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
,
ethif_probe };
static struct device eth2_dev = {
"eth2", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev,
ethif_probe };
static struct device eth1_dev = {
"eth1", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, _dev,
ethif_probe };
static struct device eth0_dev = {
"eth0", 0, 0, 0, 0, ETH0_ADDR, ETH0_IRQ, 0, 0, 0, _dev, ethif_probe };
# undef NEXT_DEV
# define NEXT_DEV (_dev)
Would it make sense to extend this structure? Andrew Morgan made such a
suggestion
but why is that eth7 limitation? And why can't I use more then 16 ethernet
interfaces?
eth15: Adaptec Starfire 6915 at 0x90612000, 00:00:d1:ed:e8:c5, IRQ 7.
eth15: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device is deferred
: Adaptec Starfire 6915 at 0x90693000, 00:00:d1:ed:e8:c6, IRQ 11.
: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device is deferred
: Adaptec Starfire 6915 at 0x90714000, 00:00:d1:ed:e8:c7, IRQ 11.
: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device is deferred
: Adaptec Starfire 6915 at 0x90795000, 00:00:d1:ed:e8:c8, IRQ 11.
: MII PHY found at address 1, status 0x7809 advertising 01e1.
Why isn't it possible to put the "probed" counter into the Space.c for all
network drivers? So people would not need to care about and the driver
code would yet be more generic (at least a little bit). I refer to the code:
int __init starfire_probe(struct net_device *dev)
{
static int __initdata probed = 0;
if (probed)
return -ENODEV;
probed++;
return pci_module_init(_driver);
}
Any pointers, sources are welcome and in hope for some further wisdom,
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
Hello, > True, I plead guilty to the "replying at 3:30am" sin. :-) I meant to reply > to Roberto's mail, and accidentally replied to yours.. That's what I thought ... > Anyway, Roberto, if you could give the starfire driver in 2.2.19 a try, > I'd appreciate it. You mentioned looking at the code, did you actually > test it? Today I started testing it and indeed, as the code shows, I works now. The main problem was that if you compiled the driver into the kernel and only had one Quadboard, it would get initialized twice. It worked but was nasty to configure ;). Now I started my tests with the new driver from plain vanilla 2.2.19 kernel and it worked for my problem above. I've you're interested I could send you some dmesg and proc-fs outputs. I'm working on a Intel L440GX+ SMP board but with one processor, a stopper card and SMP disabled. Unfortunately a guy back here destroyed the board by trying to hotplug the Quadboard and touching the motherboard's voltage regulator. I have to get a new one to continue my tests with 3 or 4 Quadboards. Will be back in a few hours with the remaining results. Best regards, Roberto Nibali, ratz -- mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'` - 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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
Hello, True, I plead guilty to the "replying at 3:30am" sin. :-) I meant to reply to Roberto's mail, and accidentally replied to yours.. That's what I thought ... Anyway, Roberto, if you could give the starfire driver in 2.2.19 a try, I'd appreciate it. You mentioned looking at the code, did you actually test it? Today I started testing it and indeed, as the code shows, I works now. The main problem was that if you compiled the driver into the kernel and only had one Quadboard, it would get initialized twice. It worked but was nasty to configure ;). Now I started my tests with the new driver from plain vanilla 2.2.19 kernel and it worked for my problem above. I've you're interested I could send you some dmesg and proc-fs outputs. I'm working on a Intel L440GX+ SMP board but with one processor, a stopper card and SMP disabled. Unfortunately a guy back here destroyed the board by trying to hotplug the Quadboard and touching the motherboard's voltage regulator. I have to get a new one to continue my tests with 3 or 4 Quadboards. Will be back in a few hours with the remaining results. Best regards, Roberto Nibali, ratz -- mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'` - 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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
ice eth2_dev = {
"eth2", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth3_dev,
ethif_probe };
static struct device eth1_dev = {
"eth1", 0,0,0,0,ETH_NOPROBE_ADDR /* I/O base*/, 0,0,0,0, eth2_dev,
ethif_probe };
static struct device eth0_dev = {
"eth0", 0, 0, 0, 0, ETH0_ADDR, ETH0_IRQ, 0, 0, 0, eth1_dev, ethif_probe };
# undef NEXT_DEV
# define NEXT_DEV (eth0_dev)
Would it make sense to extend this structure? Andrew Morgan made such a
suggestion
but why is that eth7 limitation? And why can't I use more then 16 ethernet
interfaces?
eth15: Adaptec Starfire 6915 at 0x90612000, 00:00:d1:ed:e8:c5, IRQ 7.
eth15: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device is deferred
: Adaptec Starfire 6915 at 0x90693000, 00:00:d1:ed:e8:c6, IRQ 11.
: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device is deferred
: Adaptec Starfire 6915 at 0x90714000, 00:00:d1:ed:e8:c7, IRQ 11.
: MII PHY found at address 1, status 0x7809 advertising 01e1.
early initialization of device is deferred
: Adaptec Starfire 6915 at 0x90795000, 00:00:d1:ed:e8:c8, IRQ 11.
: MII PHY found at address 1, status 0x7809 advertising 01e1.
Why isn't it possible to put the "probed" counter into the Space.c for all
network drivers? So people would not need to care about and the driver
code would yet be more generic (at least a little bit). I refer to the code:
int __init starfire_probe(struct net_device *dev)
{
static int __initdata probed = 0;
if (probed)
return -ENODEV;
probed++;
return pci_module_init(starfire_driver);
}
Any pointers, sources are welcome and in hope for some further wisdom,
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
> I have no idea - I haven't been able to get in touch with him :(
> (The fix was urgently required, and this did the job).
I just realized I had this old patch for 2.2.17 and that in 2.2.19
series this problem is addressed correctly by Donald. Apologies to
him and sorry about the confusion. His or Ion's code from the starfire.c:
int __init starfire_probe(struct net_device *dev)
{
static int __initdata probed = 0;
if (probed)
return -ENODEV;
probed++;
return pci_module_init(_driver);
}
> Not sure - I've never tried initing more than 3 of the DP83815 cards in a
> single machine. (I am using Cobalt Qube 3's, which have 2 DP83815's on
> the motherboard, and a single PCI slot which I have installed a DP38315 in
> for testing purposes).
I think this is not the problem of the driver specifically but more of the
limitation of Space.c. I haven't yet found a clean way around it. I always
get "early initialization of device eth14 is deferred" messages.
Regards,
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
Steve Hill wrote:
>
> The attached patch fixes the following problems with the DP83815 driver
> (natsemi.c):
>
> 1. When compiled into the kernel, the cards would be registered multiple
> times.
I assume this code fragment fixes this:
+ static int done = 0;
+
+ if (done) return -ENODEV;
if (pci_drv_register(_drv_id, dev) < 0)
return -ENODEV;
+ done = 1;
My 2 questions are:
Is this an acceptable fix for Donald? Because if so, I'd like to submit it
for the starfire quardboard driver.
--- starfire.c-old Tue Apr 17 18:11:07 2001
+++ starfire.c Tue Apr 17 18:12:37 2001
@@ -378,8 +378,12 @@
#ifndef MODULE
int starfire_probe(struct net_device *dev)
{
+ static int done = 0;
+
+ if (done) return -ENODEV;
if (pci_drv_register(_drv_id, dev) < 0)
return -ENODEV;
+ done = 1;
printk(KERN_INFO "%s" KERN_INFO "%s", version1, version2);
return 0;
}
Is there no implication with PCI latencies if multiple such cards
are loaded? I'm still having problems initializing more then 4
Quadboards.
Regards,
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
Steve Hill wrote:
The attached patch fixes the following problems with the DP83815 driver
(natsemi.c):
1. When compiled into the kernel, the cards would be registered multiple
times.
I assume this code fragment fixes this:
+ static int done = 0;
+
+ if (done) return -ENODEV;
if (pci_drv_register(natsemi_drv_id, dev) 0)
return -ENODEV;
+ done = 1;
My 2 questions are:
Is this an acceptable fix for Donald? Because if so, I'd like to submit it
for the starfire quardboard driver.
--- starfire.c-old Tue Apr 17 18:11:07 2001
+++ starfire.c Tue Apr 17 18:12:37 2001
@@ -378,8 +378,12 @@
#ifndef MODULE
int starfire_probe(struct net_device *dev)
{
+ static int done = 0;
+
+ if (done) return -ENODEV;
if (pci_drv_register(starfire_drv_id, dev) 0)
return -ENODEV;
+ done = 1;
printk(KERN_INFO "%s" KERN_INFO "%s", version1, version2);
return 0;
}
Is there no implication with PCI latencies if multiple such cards
are loaded? I'm still having problems initializing more then 4
Quadboards.
Regards,
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
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/
Re: Fix for Donald Becker's DP83815 network driver (v1.07)
I have no idea - I haven't been able to get in touch with him :(
(The fix was urgently required, and this did the job).
I just realized I had this old patch for 2.2.17 and that in 2.2.19
series this problem is addressed correctly by Donald. Apologies to
him and sorry about the confusion. His or Ion's code from the starfire.c:
int __init starfire_probe(struct net_device *dev)
{
static int __initdata probed = 0;
if (probed)
return -ENODEV;
probed++;
return pci_module_init(starfire_driver);
}
Not sure - I've never tried initing more than 3 of the DP83815 cards in a
single machine. (I am using Cobalt Qube 3's, which have 2 DP83815's on
the motherboard, and a single PCI slot which I have installed a DP38315 in
for testing purposes).
I think this is not the problem of the driver specifically but more of the
limitation of Space.c. I haven't yet found a clean way around it. I always
get "early initialization of device eth14 is deferred" messages.
Regards,
Roberto Nibali, ratz
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
-
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/
