On Fri, 6 Apr 2001, Andre Hedrick wrote:
You really ought to rename this parameter to pcibus. Even though it doesn't
do justice to the VLB bus, the potential for user error is much smaller.
Until today you had a vaild point!
Promise Ultra100TX2 (20268 chipset).
This is a 66MHz
On Thu, 5 Apr 2001, Andreas Dilger wrote:
> Why do it from user space? Simply add a printk() to sys_init_module() or
> similar.
Agreed, but at that point the solution has absolutely nothing to do with
insmod anymore. :-)
Besides, as you said, I don't really see the point. It certainly
On Thu, 5 Apr 2001 17:57:48 -0700 (PDT), Andrew Daviel <[EMAIL PROTECTED]> wrote:
> Is there a good reason why insmod should not call syslog() to log
> any module that gets installed ?
Simple: you'll have quite a bit of a problem if you are trying to insmod
the module with support for AF_UNIX
On Thu, 5 Apr 2001 12:52:28 -0400 (EDT), Richard B. Johnson <[EMAIL PROTECTED]>
wrote:
> Only an observation:
>
>
> main()
> {
>nice(19);
>for(;;)
>sched_yield();
> }
>
> does...
>
[...]
>
> It consumes 99.1 percent CPU, just spinning.
And, umm, what *exactly* would you
On Thu, 5 Apr 2001 12:52:28 -0400 (EDT), Richard B. Johnson [EMAIL PROTECTED]
wrote:
Only an observation:
main()
{
nice(19);
for(;;)
sched_yield();
}
does...
[...]
It consumes 99.1 percent CPU, just spinning.
And, umm, what *exactly* would you expect it to do?
On Thu, 5 Apr 2001 17:57:48 -0700 (PDT), Andrew Daviel [EMAIL PROTECTED] wrote:
Is there a good reason why insmod should not call syslog() to log
any module that gets installed ?
Simple: you'll have quite a bit of a problem if you are trying to insmod
the module with support for AF_UNIX
On Thu, 5 Apr 2001, Andreas Dilger wrote:
Why do it from user space? Simply add a printk() to sys_init_module() or
similar.
Agreed, but at that point the solution has absolutely nothing to do with
insmod anymore. :-)
Besides, as you said, I don't really see the point. It certainly
On Wed, 4 Apr 2001 20:00:29 +0100 (BST), Alan Cox <[EMAIL PROTECTED]> wrote:
>> Been running this configuration over more than 2 years now without such
>> major problems.
>> Could this be the cause?
>
> Quite possibly. There are reasons we ignore bug reports from overclockers
Perhaps. But,
On Wed, 4 Apr 2001 16:43:14 -0700 (PDT), Andre Hedrick <[EMAIL PROTECTED]> wrote:
> The subject says it all
Use the latest snapshot of am-utils (6.0.6s1), which fixes the problem.
Ion
am-utils co-maintainer
--
It is better to keep your mouth shut and be thought a fool,
than to
On Wed, 4 Apr 2001 16:43:14 -0700 (PDT), Andre Hedrick [EMAIL PROTECTED] wrote:
The subject says it all
Use the latest snapshot of am-utils (6.0.6s1), which fixes the problem.
Ion
am-utils co-maintainer
--
It is better to keep your mouth shut and be thought a fool,
than to
On Wed, 4 Apr 2001 20:00:29 +0100 (BST), Alan Cox [EMAIL PROTECTED] wrote:
Been running this configuration over more than 2 years now without such
major problems.
Could this be the cause?
Quite possibly. There are reasons we ignore bug reports from overclockers
Perhaps. But,
ide_dmaproc:
On Tue, 3 Apr 2001 16:56:57 -0500, Matthew Fredrickson <[EMAIL PROTECTED]> wrote:
>
> I have decided to leave lkml because everybody else is doing it too.
I have decided to switch to Windows because everybody else is doing it too.
Oh, wait.. wrong mailing list. It's not hosted on aol.com. :-)
On Tue, 3 Apr 2001 16:56:57 -0500, Matthew Fredrickson [EMAIL PROTECTED] wrote:
I have decided to leave lkml because everybody else is doing it too.
I have decided to switch to Windows because everybody else is doing it too.
Oh, wait.. wrong mailing list. It's not hosted on aol.com. :-)
Ion
On Fri, 23 Mar 2001 09:34:36 -0800, Jun Sun <[EMAIL PROTECTED]> wrote:
> BTW, does the eepro100 patch for 2.2.19pre apply to 2.4.2? Or it is already
> in it?
It was backported from 2.4.1, so yes, it's already in.
Ion
--
It is better to keep your mouth shut and be thought a fool,
On Fri, 23 Mar 2001 09:34:36 -0800, Jun Sun [EMAIL PROTECTED] wrote:
BTW, does the eepro100 patch for 2.2.19pre apply to 2.4.2? Or it is already
in it?
It was backported from 2.4.1, so yes, it's already in.
Ion
--
It is better to keep your mouth shut and be thought a fool,
On Fri, 23 Mar 2001 23:59:09 +0100, J . A . Magallon <[EMAIL PROTECTED]> wrote:
>
>
> On 03.23 Linus Torvalds wrote:
>>
>> I agree. I'd much prefer that syntax also.
>>
>> Or just remove the "default:" altogether, when it doesn't make any
>> difference.
>>
>
> Well, at last some sense. The
On Thu, 22 Mar 2001 11:30:46 -0800 (PST), Alan Olsen <[EMAIL PROTECTED]> wrote:
> He found out what happens when you mix Penguin bars and Penguin Mints and
> he has been in detox since. ];>
Wouldn't that be de-tux, though? :-)
Ion
--
It is better to keep your mouth shut and be thought a
On Thu, 22 Mar 2001 11:30:46 -0800 (PST), Alan Olsen [EMAIL PROTECTED] wrote:
He found out what happens when you mix Penguin bars and Penguin Mints and
he has been in detox since. ];
Wouldn't that be de-tux, though? :-)
Ion
--
It is better to keep your mouth shut and be thought a fool,
On Fri, 23 Mar 2001 23:59:09 +0100, J . A . Magallon [EMAIL PROTECTED] wrote:
On 03.23 Linus Torvalds wrote:
I agree. I'd much prefer that syntax also.
Or just remove the "default:" altogether, when it doesn't make any
difference.
Well, at last some sense. The same is with that
On Tue, 20 Mar 2001 15:19:37 -0500, Doug Ledford <[EMAIL PROTECTED]> wrote:
> Why would esd get a short write() unless it is opening the file in non
> blocking mode (which I didn't see when I was working on the i810 sound
> driver)? If esd is writing to a file in blocking mode and that write is
On Tue, 20 Mar 2001 15:19:37 -0500, Doug Ledford [EMAIL PROTECTED] wrote:
Why would esd get a short write() unless it is opening the file in non
blocking mode (which I didn't see when I was working on the i810 sound
driver)? If esd is writing to a file in blocking mode and that write is
On Mon, 12 Mar 2001 22:02:12 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> It is highly recommended to always compile with CONFIG_ISAPNP=y due to
> these differences. If you grep around for CONFIG_ISAPNP versus
> CONFIG_ISAPNP_MODULE, you'll see that many drivers are woefully
> unprepared for
On Mon, 12 Mar 2001 22:02:12 -0500, Jeff Garzik [EMAIL PROTECTED] wrote:
It is highly recommended to always compile with CONFIG_ISAPNP=y due to
these differences. If you grep around for CONFIG_ISAPNP versus
CONFIG_ISAPNP_MODULE, you'll see that many drivers are woefully
unprepared for
On Sat, 10 Mar 2001 01:21:25 +1100, Andrew Morton <[EMAIL PROTECTED]> wrote:
> +/**
> + * enable_nmi_watchdog - enables/disables NMI watchdog checking.
> + * @yes: If zero, disable
Ugh. I have a feeling that your chances to get Linus to accept this are
extremely slim.
Just have two functions,
On Sat, 10 Mar 2001 01:21:25 +1100, Andrew Morton [EMAIL PROTECTED] wrote:
+/**
+ * enable_nmi_watchdog - enables/disables NMI watchdog checking.
+ * @yes: If zero, disable
Ugh. I have a feeling that your chances to get Linus to accept this are
extremely slim.
Just have two functions,
On Wed, 28 Feb 2001, Alexander Viro wrote:
> > And disadvantages: you can't have broken symlinks.
> >
> > This actually turns out to be quite a bit of a problem when one tries
> > to use bind mounts with autofs. For one thing, it's perfectly legal
> > to have /autofs/foo as a symlink to
On Wed, 28 Feb 2001 13:07:29 -0500 (EST), Alexander Viro <[EMAIL PROTECTED]> wrote:
> On Wed, 28 Feb 2001, David L. Parsley wrote:
>> Yeah, mount --bind is cool, I've been using it on one of my projects
>> today. But - maybe I'm just not thinking creatively enough - what are
>> the advantages
On Wed, 28 Feb 2001, Alexander Viro wrote:
And disadvantages: you can't have broken symlinks.
This actually turns out to be quite a bit of a problem when one tries
to use bind mounts with autofs. For one thing, it's perfectly legal
to have /autofs/foo as a symlink to /autofs/bar/foo,
On Wed, 28 Feb 2001 13:07:29 -0500 (EST), Alexander Viro [EMAIL PROTECTED] wrote:
On Wed, 28 Feb 2001, David L. Parsley wrote:
Yeah, mount --bind is cool, I've been using it on one of my projects
today. But - maybe I'm just not thinking creatively enough - what are
the advantages of mount
a fool,
than to open it and remove all doubt.
---
--- /mnt/3/linux-2.2.19pre/drivers/net/starfire.c Mon Feb 26 21:56:30 2001
+++ linux-2.2.18/drivers/net/starfire.c Mon Feb 26 21:51:06 2001
@@ -49,6 +49,16 @@
LK1.2.4 (Ion Badulescu
On Mon, 26 Feb 2001 23:18:37 + (GMT), Alan Cox <[EMAIL PROTECTED]> wrote:
> 2.2.19pre15
[...]
> o EEpro100 posted writes fix (Ion Badulescu)
All the credit goes to Andrey Savochkin and Don Becker -- I only applied
their 2.4.1 patch to 2.2.x..
On Mon, 26 Feb 2001 23:18:37 + (GMT), Alan Cox [EMAIL PROTECTED] wrote:
2.2.19pre15
[...]
o EEpro100 posted writes fix (Ion Badulescu)
All the credit goes to Andrey Savochkin and Don Becker -- I only applied
their 2.4.1 patch to 2.2.x..
Thanks,
Ion
a fool,
than to open it and remove all doubt.
---
--- /mnt/3/linux-2.2.19pre/drivers/net/starfire.c Mon Feb 26 21:56:30 2001
+++ linux-2.2.18/drivers/net/starfire.c Mon Feb 26 21:51:06 2001
@@ -49,6 +49,16 @@
LK1.2.4 (Ion Badulescu
.
--
--- /mnt/3/linux-2.4-ac/drivers/net/starfire.c Mon Feb 19 14:35:01 2001
+++ linux-2.4/drivers/net/starfire.cThu Feb 22 14:19:33 2001
@@ -52,6 +52,9 @@
LK1.2.5 (Ion Badulescu)
- Several fixes from Manfred Spraul
+ LK1.2.6 (Ion Badulescu
.
--
--- /mnt/3/linux-2.4-ac/drivers/net/starfire.c Mon Feb 19 14:35:01 2001
+++ linux-2.4/drivers/net/starfire.cThu Feb 22 14:19:33 2001
@@ -52,6 +52,9 @@
LK1.2.5 (Ion Badulescu)
- Several fixes from Manfred Spraul
+ LK1.2.6 (Ion Badulescu
On Tue, 20 Feb 2001, CaT wrote:
> > patched, old removed, new installed, waiting for fubar. :)
>
> Ok. this is what I got in my kern.log. this is on a fresh reboot.
>
> Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout
>with(0x70)!
> Feb 20 18:31:49 theirongiant
On Tue, 20 Feb 2001, CaT wrote:
patched, old removed, new installed, waiting for fubar. :)
Ok. this is what I got in my kern.log. this is on a fresh reboot.
Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout
with(0x70)!
Feb 20 18:31:49 theirongiant kernel:
On Mon, 19 Feb 2001 14:49:35 -0800, Andrey Savochkin <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 20, 2001 at 09:21:06AM +1100, CaT wrote:
>>
>> It happened again. Same deal. Once was after a reboot and this time
>> was after a resume. :/
>
> In my experiments wait_for_cmd timeouts almost always
On Mon, 19 Feb 2001 14:49:35 -0800, Andrey Savochkin [EMAIL PROTECTED] wrote:
On Tue, Feb 20, 2001 at 09:21:06AM +1100, CaT wrote:
It happened again. Same deal. Once was after a reboot and this time
was after a resume. :/
In my experiments wait_for_cmd timeouts almost always were related
://www.stallion.com
S: Supported
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
W: http://mosquitonet.Stanford.EDU/strip.html
S: Unsupported ?
--- /mnt/3/linux-2.4-ac/Documentation
://www.stallion.com
S: Supported
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
W: http://mosquitonet.Stanford.EDU/strip.html
S: Unsupported ?
--- /mnt/3/linux-2.4-ac/Documentation
On Thu, 15 Feb 2001 15:57:09 -0500 (EST), Richard A Nelson <[EMAIL PROTECTED]> wrote:
> The machine boots and runs for some time without problems, but then
> something makes the clock *very* jittery:
>
> * xscreensaver kicks in after almost no time (even betwixt quick
>keystrokes and in the
On Thu, 15 Feb 2001 15:57:09 -0500 (EST), Richard A Nelson [EMAIL PROTECTED] wrote:
The machine boots and runs for some time without problems, but then
something makes the clock *very* jittery:
* xscreensaver kicks in after almost no time (even betwixt quick
keystrokes and in the middle
On Wed, 14 Feb 2001, Alan Cox wrote:
> > The way I understand it, IA64 and Alpha cope with it, but at the expense
> > of taking an exception for each packet -- so it's not worth it.
>
> You want to copy_checksum the frame on these platforms,
That's what we're doing...
> or better yet use
>
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Wed, 14 Feb 2001, Alan Cox wrote:
> > It does. It does so on IA64 now as well. The only architecture which has troubles
> > with alignment on IP frames now is ARM2
>
> So the IA64-specific PKT_CAN_COPY code in starfire can go away
> completely? Jes,
On Wed, 14 Feb 2001, Jeff Garzik wrote:
On Wed, 14 Feb 2001, Alan Cox wrote:
It does. It does so on IA64 now as well. The only architecture which has troubles
with alignment on IP frames now is ARM2
So the IA64-specific PKT_CAN_COPY code in starfire can go away
completely? Jes, can you
On Wed, 14 Feb 2001, Alan Cox wrote:
The way I understand it, IA64 and Alpha cope with it, but at the expense
of taking an exception for each packet -- so it's not worth it.
You want to copy_checksum the frame on these platforms,
That's what we're doing...
or better yet use
a decent
On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu <[EMAIL PROTECTED]> wrote:
> On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
><[EMAIL PROTECTED]> wrote:
>
>> On 12 Feb 2001, Jes Sorensen wrote:
>>> In fact one has to look out for this and d
On 12 Feb 2001, Jes Sorensen wrote:
> Ion> Yes, but I'd rather let people turn off the always-copy behavior
> Ion> by simply changing rx_copybreak. The unused code is not really
> Ion> that much of a deal, it's only a few lines.
>
> However, it is in the hot path code where it hurts the most.
On Tue, 13 Feb 2001 12:09:32 + (GMT), Michèl Alexandre Salim
<[EMAIL PROTECTED]> wrote:
> Currently running the XFree 4.0.2 from RH 7.0.90 (7.1
> beta, Fisher) on top of my RH 7 + Ximian system and
> when using aviplay it doesn't use any acceleration
> features at all, consequently choppy
On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
<[EMAIL PROTECTED]> wrote:
> On 12 Feb 2001, Jes Sorensen wrote:
>> In fact one has to look out for this and disable the feature in some
>> cases. On the acenic not disabling Memory Write and Invalidate costs
>> ~20% on performance on some
On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
[EMAIL PROTECTED] wrote:
On 12 Feb 2001, Jes Sorensen wrote:
In fact one has to look out for this and disable the feature in some
cases. On the acenic not disabling Memory Write and Invalidate costs
~20% on performance on some systems.
On 12 Feb 2001, Jes Sorensen wrote:
Ion Yes, but I'd rather let people turn off the always-copy behavior
Ion by simply changing rx_copybreak. The unused code is not really
Ion that much of a deal, it's only a few lines.
However, it is in the hot path code where it hurts the most.
I
On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu [EMAIL PROTECTED] wrote:
On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
[EMAIL PROTECTED] wrote:
On 12 Feb 2001, Jes Sorensen wrote:
In fact one has to look out for this and disable the feature in some
cases. On the acenic
On Mon, 12 Feb 2001, Ion Badulescu wrote:
> Here is an incremental patch from the version in 2.2.19pre10 to the latest
> version of starfire.c. Please apply, the 2219pre10 version doesn't work if
> compiled-in (because drivers/net builds net.a not net.o). It also fixes
> the M
1,7 @@
LK1.1.3 (Andrew Morton)
- Timer cleanups
-
+
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
@@ -41,6 +41,17 @@
LK1.2.2 (Ion Badulescu)
- Backported to 2.2.x
+
+ LK1.2.3 (Ion Badulescu)
+ - Fix the flaky mdio interface
+ - M
On Mon, 12 Feb 2001, Alan Cox wrote:
> No resolution to firmware fiasco, no driver in kernel
But the driver _does_ work without the firmware, it only loses the
hardware TCP checksum on Rx capability. That's what we have in 2.4.x right
now, why should 2.2.x be pickier and *demand* to have the
On Sat, 10 Feb 2001, Ion Badulescu wrote:
> Hi Alan,
>
> This is basically the same driver I sent to Jeff Garzik and you yesterday,
> for 2.4.1. Only one byte is different, in the version string. :-) The
> patch was generated against 2.2.18, it applies cleanly to 2.2.19
On Mon, 12 Feb 2001, Andrey Savochkin wrote:
> I've just checked: "Sending a multicast list set command" is printed only on
> high debug levels, so Augustin might not see them.
I could have sworn that I saw the message being printed unconditionally.
But you're right, so we're back to square
On Sat, 10 Feb 2001, Ion Badulescu wrote:
Hi Alan,
This is basically the same driver I sent to Jeff Garzik and you yesterday,
for 2.4.1. Only one byte is different, in the version string. :-) The
patch was generated against 2.2.18, it applies cleanly to 2.2.19pre9.
And here is a new
On Mon, 12 Feb 2001, Alan Cox wrote:
No resolution to firmware fiasco, no driver in kernel
But the driver _does_ work without the firmware, it only loses the
hardware TCP checksum on Rx capability. That's what we have in 2.4.x right
now, why should 2.2.x be pickier and *demand* to have the
@@
LK1.1.3 (Andrew Morton)
- Timer cleanups
-
+
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
@@ -41,6 +41,17 @@
LK1.2.2 (Ion Badulescu)
- Backported to 2.2.x
+
+ LK1.2.3 (Ion Badulescu)
+ - Fix the flaky mdio interface
+ - More
On Sun, 11 Feb 2001 16:20:47 -0200, Rogerio Brito <[EMAIL PROTECTED]> wrote:
>> >ioctl(cd_fd, CDROM_SELECT_SPEED, speed);
Yes: pass 0 as the speed, in the ioctl() above.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Sun, 11 Feb 2001 16:20:47 -0200, Rogerio Brito [EMAIL PROTECTED] wrote:
ioctl(cd_fd, CDROM_SELECT_SPEED, speed);
Yes: pass 0 as the speed, in the ioctl() above.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To
On Sat, 10 Feb 2001 16:46:01 -0600, Nathan Neulinger <[EMAIL PROTECTED]> wrote:
> Any ideas on how I can correct this symptom?
This seems to be Donald Becker's driver, right? Please try with the
starfire driver for 2.2.x I posted a few hours ago to the list. If you
don't have it, contact me
):
+ - Merge Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu <[EMAIL PROTECTED]>)
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
+
+ LK1.2.3 (Ion Bad
On Sat, 10 Feb 2001 16:46:01 -0600, Nathan Neulinger [EMAIL PROTECTED] wrote:
Any ideas on how I can correct this symptom?
This seems to be Donald Becker's driver, right? Please try with the
starfire driver for 2.2.x I posted a few hours ago to the list. If you
don't have it, contact me
On Fri, 9 Feb 2001, Alan Cox wrote:
> > It's amusing that a full receive copy is added without any concern, in
> > the same discussion where zero-copy transmit is treated as a holy grail!
>
> For non routing paths its virtually free because the DMA forced the lines
> from cache anyway.
Are
On 9 Feb 2001, Jes Sorensen wrote:
> Manfred> What about changing the default for rx_copybreak instead?
> Manfred> Set it to 1536 on ia64 and Alpha, 0 for the rest. tulip and
> Manfred> eepro100 use that aproach.
>
> Inefficient, my patch will make the unused code path disappear during
>
On Fri, 9 Feb 2001, Jeff Garzik wrote:
> For 2.2, define SET_MODULE_OWNER to null.
>
> Define STAR_MOD_INC_USE_COUNT and STAR_MOD_DEC_USE_COUNT. For 2.4,
> these are null. For 2.2, these point to MOD_{INC,DEC}_USE_COUNT.
... and use both SET_MODULE_OWNER and STAR_MOD_*_USE_COUNT. It's along
On Fri, 9 Feb 2001, Jeff Garzik wrote:
> I would prefer that zerocopy code remain out of all official kernels
> until zerocopy itself is in said kernels. It's experimental code that
> simply cannot work in its present form, due to lack of infrastructure in
> the general kernel. And being based
On Fri, 9 Feb 2001, Jeff Garzik wrote:
I would prefer that zerocopy code remain out of all official kernels
until zerocopy itself is in said kernels. It's experimental code that
simply cannot work in its present form, due to lack of infrastructure in
the general kernel. And being based on
On Fri, 9 Feb 2001, Jeff Garzik wrote:
For 2.2, define SET_MODULE_OWNER to null.
Define STAR_MOD_INC_USE_COUNT and STAR_MOD_DEC_USE_COUNT. For 2.4,
these are null. For 2.2, these point to MOD_{INC,DEC}_USE_COUNT.
... and use both SET_MODULE_OWNER and STAR_MOD_*_USE_COUNT. It's along the
On 9 Feb 2001, Jes Sorensen wrote:
Manfred What about changing the default for rx_copybreak instead?
Manfred Set it to 1536 on ia64 and Alpha, 0 for the rest. tulip and
Manfred eepro100 use that aproach.
Inefficient, my patch will make the unused code path disappear during
compilation,
On Fri, 9 Feb 2001, Alan Cox wrote:
It's amusing that a full receive copy is added without any concern, in
the same discussion where zero-copy transmit is treated as a holy grail!
For non routing paths its virtually free because the DMA forced the lines
from cache anyway.
Are you
On Thu, 8 Feb 2001, Donald Becker wrote:
> > Or we can just tell people, "hey, don't use this 64-bit PCI card on a real
> > 64-bit system, it's broken by design"? I don't think that's a good
> > solution either.
>
> This is not a 64 bit PCI issue.
I know. It was just an ironic comment: we
On Thu, 8 Feb 2001, Ion Badulescu wrote:
> >The MII read code is no longer reliable. I spent twenty minutes at
> >the show, but couldn't figure out the problem. I haven't been able
> >reproduce the problem locally with my 2.2 code and someone older
> >
On Thu, 8 Feb 2001, Donald Becker wrote:
> > > The align-copy should *never* be required because the alignment differs
> > > between DIX and E-II encapsulated packets. The machine shouldn't crash
> > > because someone sends you a different encapsulation type!
>
> This is true for a number of
On Thu, 8 Feb 2001, Jeff Garzik wrote:
> Well at least let's do it the Linux Kernel Way(tm): separate out the
> zerocopy stuff such that there are minimal ifdefs in the code... For
> example:
>
> /* add these functions... */
> #ifdef ZEROCOPY
> static inline
On Thu, 8 Feb 2001, Manfred Spraul wrote:
> What about changing the default for rx_copybreak instead?
> Set it to 1536 on ia64 and Alpha, 0 for the rest.
> tulip and eepro100 use that aproach.
That makes a lot of sense, thanks for the suggestion. I'll do so in the
next version.
Ion
--
It
On Thu, 8 Feb 2001, Jeff Garzik wrote:
> I would prefer that the zerocopy changes stay in DaveM's external patch
> until they are ready to be merged.
I would actually prefer to have a single source for all the driver
versions. The 2.2.x version I sent to Alan later on actually compiles on
On Thu, 8 Feb 2001, Augustin Vidovic wrote:
> This suppression of thousands of lines was described as a DOS-protection
> in the docs I read.
Still, there should be something before these suppressed messages started.
> With my patch, the test becomes (eeprom[3] & 0x03), which is not null
> for
On Thu, 8 Feb 2001 20:15:39 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
>> So what _were_ those messages? Can you post them?
>
> No I can't because they were suppressed by the syslogd (DOS protection), only
> their number being reported (several thousands every few seconds).
syslogd
On Thu, 8 Feb 2001 19:41:56 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
> You can see a kind of sudden blackout which lasts about 3 hours, and then the
> situation resumes to normality.
>
> At the same time, the /var/log/messages receives thousands of messages from the
> NET: subsystem.
On Thu, 8 Feb 2001 20:15:39 +0900, Augustin Vidovic [EMAIL PROTECTED] wrote:
So what _were_ those messages? Can you post them?
No I can't because they were suppressed by the syslogd (DOS protection), only
their number being reported (several thousands every few seconds).
syslogd does not
On Thu, 8 Feb 2001, Augustin Vidovic wrote:
This suppression of thousands of lines was described as a DOS-protection
in the docs I read.
Still, there should be something before these suppressed messages started.
With my patch, the test becomes (eeprom[3] 0x03), which is not null
for every
On Thu, 8 Feb 2001, Jeff Garzik wrote:
I would prefer that the zerocopy changes stay in DaveM's external patch
until they are ready to be merged.
I would actually prefer to have a single source for all the driver
versions. The 2.2.x version I sent to Alan later on actually compiles on
On Thu, 8 Feb 2001, Manfred Spraul wrote:
What about changing the default for rx_copybreak instead?
Set it to 1536 on ia64 and Alpha, 0 for the rest.
tulip and eepro100 use that aproach.
That makes a lot of sense, thanks for the suggestion. I'll do so in the
next version.
Ion
--
It is
On Thu, 8 Feb 2001, Jeff Garzik wrote:
Well at least let's do it the Linux Kernel Way(tm): separate out the
zerocopy stuff such that there are minimal ifdefs in the code... For
example:
/* add these functions... */
#ifdef ZEROCOPY
static inline setup_txrx_rings(...) {
On Thu, 8 Feb 2001, Donald Becker wrote:
The align-copy should *never* be required because the alignment differs
between DIX and E-II encapsulated packets. The machine shouldn't crash
because someone sends you a different encapsulation type!
This is true for a number of drivers --
On Thu, 8 Feb 2001, Ion Badulescu wrote:
The MII read code is no longer reliable. I spent twenty minutes at
the show, but couldn't figure out the problem. I haven't been able
reproduce the problem locally with my 2.2 code and someone older
hardware.
Yes, I've noticed
On Thu, 8 Feb 2001, Donald Becker wrote:
Or we can just tell people, "hey, don't use this 64-bit PCI card on a real
64-bit system, it's broken by design"? I don't think that's a good
solution either.
This is not a 64 bit PCI issue.
I know. It was just an ironic comment: we have a
On Thu, 8 Feb 2001, Alan Cox wrote:
> > It's the printk that gets it wrong, although that's harmless.
> > Intel's documentation states that the bug does NOT exist if the
> > bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
> > the printk is wrong.
>
> So why does it fix the
On Thu, 8 Feb 2001 14:53:55 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
> --- linux-2.4.1/drivers/net/eepro100.c Sun Jan 28 03:40:14 2001
> +++ linux-2.4.1-vido1/drivers/net/eepro100.cThu Feb 8 14:08:49 2001
> @@ -815,7 +815,7 @@
>
> sp->phy[0] = eeprom[6];
>
@@ -916,6 +916,11 @@
W: http://www.stallion.com
S: Supported
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
W: http://mosquitonet.Stanford.EDU/strip.html
S: Unsupported ?
diff -urNX
/MAINTAINERSWed Feb 7 17:38:50 2001
@@ -1166,6 +1166,11 @@
W: http://www.stallion.com
S: Supported
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
W: http://mosquitonet.Stanford.EDU/s
On Wed, 07 Feb 2001 11:48:32 +0100, Stefan Majer <[EMAIL PROTECTED]> wrote:
> Hi All
>
> I installed a Adaptec Quad Port Ethernet Adapter called Quartet64 and
> after compiling 2.4.1
> with starfire support i got the following messages in syslog
>
> after
>
> ifconfig eth2 172.17.1.4
On Wed, 07 Feb 2001 11:48:32 +0100, Stefan Majer [EMAIL PROTECTED] wrote:
Hi All
I installed a Adaptec Quad Port Ethernet Adapter called Quartet64 and
after compiling 2.4.1
with starfire support i got the following messages in syslog
after
ifconfig eth2 172.17.1.4 netmask
Feb 7 17:38:50 2001
@@ -1166,6 +1166,11 @@
W: http://www.stallion.com
S: Supported
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
W: http://mosquitonet.Stanford.EDU/strip.html
S
@@ -916,6 +916,11 @@
W: http://www.stallion.com
S: Supported
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
W: http://mosquitonet.Stanford.EDU/strip.html
S: Unsupported ?
diff -urNX
101 - 200 of 302 matches
Mail list logo
