Re: very poor ext3 write performance on big filesystems?

[David Rees]

On Wed, Feb 20, 2008 at 2:57 AM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>  But GNU tar does not handle acls and xattrs. So back to rsync/cp/mv.

Huh? The version of tar on my Fedora 8 desktop (tar-1.17-7) does. Just
add the --xattrs option (which turns on --acls and --selinux).

-Dave
--
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: very poor ext3 write performance on big filesystems?

[David Rees]

On Wed, Feb 20, 2008 at 2:57 AM, Jan Engelhardt [EMAIL PROTECTED] wrote:
  But GNU tar does not handle acls and xattrs. So back to rsync/cp/mv.

Huh? The version of tar on my Fedora 8 desktop (tar-1.17-7) does. Just
add the --xattrs option (which turns on --acls and --selinux).

-Dave
--
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: random wedges with 2.6.25-rc*

[David Rees]

On Feb 19, 2008 10:10 AM, Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Somewhere post 2.6.24, the kernel started getting very
> temperamentful. I experience random hangs and wedges very often.

FWIW, on my Fedora 8 Dell Vostro 1000 notebook, ever since updating to
kernel 2.6.23.15-137 I am getting frequent udev startup lockups on
boot.  Resetting and rebooting will get things past udev startup some
of the time, so it doesn't always hang. I'd guess it hangs about half
the time. Once past udev startup, everything works fine, no hangs. I
haven't seen this on a half dozen other desktops/servers running
Fedora 8.

Aside from that, everything else works fine. The previous kernel was
2.6.23.14-115, so I suspect that if these were related, the changes
were backported into the 2.6.23 stable tree in 2.6.23.15?

You can view the reported list of differences between the two kernels
in the package announcement:
https://www.redhat.com/archives/fedora-package-announce/2008-February/msg00255.html

-Dave
--
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: random wedges with 2.6.25-rc*

[David Rees]

On Feb 19, 2008 10:10 AM, Pierre Ossman [EMAIL PROTECTED] wrote:
 Somewhere post 2.6.24, the kernel started getting very
 temperamentful. I experience random hangs and wedges very often.

FWIW, on my Fedora 8 Dell Vostro 1000 notebook, ever since updating to
kernel 2.6.23.15-137 I am getting frequent udev startup lockups on
boot.  Resetting and rebooting will get things past udev startup some
of the time, so it doesn't always hang. I'd guess it hangs about half
the time. Once past udev startup, everything works fine, no hangs. I
haven't seen this on a half dozen other desktops/servers running
Fedora 8.

Aside from that, everything else works fine. The previous kernel was
2.6.23.14-115, so I suspect that if these were related, the changes
were backported into the 2.6.23 stable tree in 2.6.23.15?

You can view the reported list of differences between the two kernels
in the package announcement:
https://www.redhat.com/archives/fedora-package-announce/2008-February/msg00255.html

-Dave
--
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: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)

[David Rees]

On 8/27/07, Daniel Walker <[EMAIL PROTECTED]> wrote:
> Now that I'm looking at the kernel bugzilla .. If you set the kernel
> version to 2.6.22 and set the "Regression" check box you could denote
> the fact that it's a regression in that kernel version ..
>
> I don't know if this URL is going to come out right,
>
> 
>
> That should be open bugs , kernel version 2.6.22, with the regression
> check box set ..
>
> So you may not need a master tracking bug ..

Yep, that's another way to do it. The method I described earlier is
commonly used when you don't have the handy regression field in
bugzilla. The technique is handy for creating lists for tracking other
types of issues which don't necessarily fall into a component and you
don't want to bother customizing bugzilla.

I also suspect that there will be a number of common searches that
many people will find useful. With recent versions of bugzilla (3.0+)
you can share searches within groups, but it may be helpful to have a
wiki or some other page where useful searches can be stored, or one of
the templates edited to include those common searches.

-Dave
-
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: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)

[David Rees]

On 8/26/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> Bugzilla sucks when it comes to tracking things. There is
> a regression field, but there are no difference between
> 2.6.22 and 2.6.23 regression.

Here's how to use Bugzilla to track regressions between different
kernel versions:

Create a 2.6.22 regression bug and a 2.6.23 regression bug. All
regression bugs which are 2.6.22 regression bugs should block the
2.6.22 regression bug. All regression bugs which are 2.6.23 regression
bugs should block the 2.6.23 regression bug.

For example, say your master 2.6.22 regression bug tracking bug is #1.
When someone comes and files a new bug #2 which is a regression of
2.6.22, make bug #2 block bug #1. Then it is easy to see to track all
the 2.6.22 regressions.

To make it easier to remember what bug number tracks regressions for a
specific kernel, use a naming convention to create aliases for those
bugs.

-Dave
-
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: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)

[David Rees]

On 8/26/07, Michal Piotrowski [EMAIL PROTECTED] wrote:
 Bugzilla sucks when it comes to tracking things. There is
 a regression field, but there are no difference between
 2.6.22 and 2.6.23 regression.

Here's how to use Bugzilla to track regressions between different
kernel versions:

Create a 2.6.22 regression bug and a 2.6.23 regression bug. All
regression bugs which are 2.6.22 regression bugs should block the
2.6.22 regression bug. All regression bugs which are 2.6.23 regression
bugs should block the 2.6.23 regression bug.

For example, say your master 2.6.22 regression bug tracking bug is #1.
When someone comes and files a new bug #2 which is a regression of
2.6.22, make bug #2 block bug #1. Then it is easy to see to track all
the 2.6.22 regressions.

To make it easier to remember what bug number tracks regressions for a
specific kernel, use a naming convention to create aliases for those
bugs.

-Dave
-
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: Who wants to maintain KR list for stable releases? (was Re: nmi_watchdog=2 regression in 2.6.21)

[David Rees]

On 8/27/07, Daniel Walker [EMAIL PROTECTED] wrote:
 Now that I'm looking at the kernel bugzilla .. If you set the kernel
 version to 2.6.22 and set the Regression check box you could denote
 the fact that it's a regression in that kernel version ..

 I don't know if this URL is going to come out right,

 snip url

 That should be open bugs , kernel version 2.6.22, with the regression
 check box set ..

 So you may not need a master tracking bug ..

Yep, that's another way to do it. The method I described earlier is
commonly used when you don't have the handy regression field in
bugzilla. The technique is handy for creating lists for tracking other
types of issues which don't necessarily fall into a component and you
don't want to bother customizing bugzilla.

I also suspect that there will be a number of common searches that
many people will find useful. With recent versions of bugzilla (3.0+)
you can share searches within groups, but it may be helpful to have a
wiki or some other page where useful searches can be stored, or one of
the templates edited to include those common searches.

-Dave
-
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: Postgrey experiment at VGER

[David Rees]

On 12/13/06, Giacomo A. Catenazzi <[EMAIL PROTECTED]> wrote:

So a challange to the kernel hackers: build a mail filtering/proxy
system, a' la BSD.
I don't remember the specification and features, but IIRC the
netfilter is not enough to do the graylisting (but pf was).
Someone has some hints what kernel can do in the fight against
spam?


I've gone through a number of anti-spam measures over the years. I
started with SpamAssassin, then bogofilter, greylisting, various RBLs
and most recently DSPAM.

SpamAssassin an bogofilter used to work pretty well, but over time
they let more and more spam through so I stopped using them.

Greylisting used to work very well, but recently more and more
spammers are retrying not to mention I kept on running across broken
mail servers that either wouldn't retry or would take forever to
retry. My users would also complain that email was broken when a
message would take hours to deliver instead of being delivered almost
immediately. They found it better to get spam than to occasionally
miss email or have to wait for email.

RBLs work pretty well as long as you choose the right ones that aren't
too aggressive with their lists. sbl-xbl.spamhaus.org is pretty
reliable and I have found it good at not blocking legitimate sources
of email.

DSPAM's learning ability seems to be very good (better than SA and
bogofilter) once trained and the web interface for training mail makes
it a snap to do (you can also do it via command line). It's also
flexible enough that it's easy to plug it into just about any mail
server configuration out there.

-Dave
-
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: Postgrey experiment at VGER

[David Rees]

On 12/13/06, Giacomo A. Catenazzi [EMAIL PROTECTED] wrote:

So a challange to the kernel hackers: build a mail filtering/proxy
system, a' la BSD.
I don't remember the specification and features, but IIRC the
netfilter is not enough to do the graylisting (but pf was).
Someone has some hints what kernel can do in the fight against
spam?


I've gone through a number of anti-spam measures over the years. I
started with SpamAssassin, then bogofilter, greylisting, various RBLs
and most recently DSPAM.

SpamAssassin an bogofilter used to work pretty well, but over time
they let more and more spam through so I stopped using them.

Greylisting used to work very well, but recently more and more
spammers are retrying not to mention I kept on running across broken
mail servers that either wouldn't retry or would take forever to
retry. My users would also complain that email was broken when a
message would take hours to deliver instead of being delivered almost
immediately. They found it better to get spam than to occasionally
miss email or have to wait for email.

RBLs work pretty well as long as you choose the right ones that aren't
too aggressive with their lists. sbl-xbl.spamhaus.org is pretty
reliable and I have found it good at not blocking legitimate sources
of email.

DSPAM's learning ability seems to be very good (better than SA and
bogofilter) once trained and the web interface for training mail makes
it a snap to do (you can also do it via command line). It's also
flexible enough that it's easy to plug it into just about any mail
server configuration out there.

-Dave
-
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: temperature standard - global config option?

[David Rees]

On Thu, Jun 07, 2001 at 03:20:03PM +0300, L. K. wrote:
> On Thu, 7 Jun 2001, Philips wrote:
> 
> > Kelvins good idea in general - it is always positive ;-)
> > 
> > 0.01*K fits in 16 bits and gives reasonable range.
> > 
> > but may be something like K<<6 could be a option? (to allow use of shifts
> > instead of muls/divs). It would be much more easier to extract int part.
> > 
> > just my 2 eurocents.
> 
> Why not make it in Celsius ? Is more easy to read it this way.

It's easier for you as a user to read, but slightly harder to deal with inside the 
code.  
It's really a user-space issue, inside the kernel should be as standardized as 
possible, and
Kelvins make the most sense there.

-Dave
-
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: temperature standard - global config option?

[David Rees]

On Thu, Jun 07, 2001 at 03:20:03PM +0300, L. K. wrote:
 On Thu, 7 Jun 2001, Philips wrote:
 
  Kelvins good idea in general - it is always positive ;-)
  
  0.01*K fits in 16 bits and gives reasonable range.
  
  but may be something like K6 could be a option? (to allow use of shifts
  instead of muls/divs). It would be much more easier to extract int part.
  
  just my 2 eurocents.
 
 Why not make it in Celsius ? Is more easy to read it this way.

It's easier for you as a user to read, but slightly harder to deal with inside the 
code.  
It's really a user-space issue, inside the kernel should be as standardized as 
possible, and
Kelvins make the most sense there.

-Dave
-
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: Network Performance Testing Summary

[David Rees]

On Wed, Jun 06, 2001 at 02:52:03AM +, John William wrote:
> 
> The curse of the HP Vectra XU 5/90 strikes again!
> 
> What is interesting is that I tried the NetGear FA310, FA311, 3COM 3cSOHO 
> and 3C905C-TX cards and both the receive and transmit speeds (measured with 
> both iperf and netperf) were so close to each other as to be a non-issue.
> 
> Several people e-mailed me to let me know that "card 'X' performance is 
> terrible, I can only get good performance with card 'Y'". So, I just thought 
> I should send this message out to set things a bit straight.

Did you monitor CPU usage during these tests?

I did some throughput comparing a DLink RTL8139 based card to a 3C905C-TX card on a 
K6-2 450.  
Both managed to fully saturate 100Mbps.  However, the DLink used up ~90% CPU, and the 
3Com 
only used about 50% CPU.  This was on 2.4.5, with the 8139too driver from 2.4.3.

-Dave
-
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: Network Performance Testing Summary

[David Rees]

On Wed, Jun 06, 2001 at 02:52:03AM +, John William wrote:
 
 The curse of the HP Vectra XU 5/90 strikes again!
 
 What is interesting is that I tried the NetGear FA310, FA311, 3COM 3cSOHO 
 and 3C905C-TX cards and both the receive and transmit speeds (measured with 
 both iperf and netperf) were so close to each other as to be a non-issue.
 
 Several people e-mailed me to let me know that card 'X' performance is 
 terrible, I can only get good performance with card 'Y'. So, I just thought 
 I should send this message out to set things a bit straight.

Did you monitor CPU usage during these tests?

I did some throughput comparing a DLink RTL8139 based card to a 3C905C-TX card on a 
K6-2 450.  
Both managed to fully saturate 100Mbps.  However, the DLink used up ~90% CPU, and the 
3Com 
only used about 50% CPU.  This was on 2.4.5, with the 8139too driver from 2.4.3.

-Dave
-
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.4.5 VM

[David Rees]

I don't know myself, (it sounds like other bigmem problems), but setting up a
2GB swap file is easy enough to test.  :-)

-Dave

On Fri, Jun 01, 2001 at 10:29:39AM +0200, Marcin Kowalski wrote:
> 
> I found this post of interest. I have 1.1 Gig of RAM but only 800mb of
> Swap as I expect NOT to use that much memory... Could this be the cause of
> the machines VERY erratic behaviour??? Kernel Panics, HUGE INOde and
> Dcache ??
> 
> On Thu, 31 May 2001 [EMAIL PROTECTED] wrote:
> 
> > > My system has 128 Meg of Swap and RAM.
> > 
> > Linus 2.4.0 notes are quite clear that you need at least twice RAM of swap
> > with 2.4.
> > 
> > Marcelo is working to change that but right now you are running something 
> > explicitly explained as not going to work as you want
-
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.4.5 VM

[David Rees]

I don't know myself, (it sounds like other bigmem problems), but setting up a
2GB swap file is easy enough to test.  :-)

-Dave

On Fri, Jun 01, 2001 at 10:29:39AM +0200, Marcin Kowalski wrote:
 
 I found this post of interest. I have 1.1 Gig of RAM but only 800mb of
 Swap as I expect NOT to use that much memory... Could this be the cause of
 the machines VERY erratic behaviour??? Kernel Panics, HUGE INOde and
 Dcache ??
 
 On Thu, 31 May 2001 [EMAIL PROTECTED] wrote:
 
   My system has 128 Meg of Swap and RAM.
  
  Linus 2.4.0 notes are quite clear that you need at least twice RAM of swap
  with 2.4.
  
  Marcelo is working to change that but right now you are running something 
  explicitly explained as not going to work as you want
-
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.4.5 still breaks dhcpcd with 8139too

[David Rees]

On Wed, May 30, 2001 at 01:05:04AM -0400, Jeff Garzik wrote:
> 
> I've got one of the two problems fixed here at the test lab, and am
> working on the second.  Hopefully this week I'll have this sorted out,
> and a driver for you guys to test.

Sounds great, let me know when you have it sorted out and I'll give it a whirl 
over here.

-Dave
-
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/

2.4.5 still breaks dhcpcd with 8139too

[David Rees]

Hi,

dhcpcd is still broken in 2.4.5 when using the stock 8139too driver as
referenced in this thread:
http://marc.theaimsgroup.com/?t=9884722973=2=1

Going back to the 8139too driver in 2.4.3 fixes it.

I see that Alan has reverted back to the 2.4.3 driver for his ac-series for
other reasons, hopefully either the old driver will going in to 2.4.6 or the 
new one will get fixed?

-Dave
-
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/

2.4.5 still breaks dhcpcd with 8139too

[David Rees]

Hi,

dhcpcd is still broken in 2.4.5 when using the stock 8139too driver as
referenced in this thread:
http://marc.theaimsgroup.com/?t=9884722973w=2r=1

Going back to the 8139too driver in 2.4.3 fixes it.

I see that Alan has reverted back to the 2.4.3 driver for his ac-series for
other reasons, hopefully either the old driver will going in to 2.4.6 or the 
new one will get fixed?

-Dave
-
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.4.5 still breaks dhcpcd with 8139too

[David Rees]

On Wed, May 30, 2001 at 01:05:04AM -0400, Jeff Garzik wrote:
 
 I've got one of the two problems fixed here at the test lab, and am
 working on the second.  Hopefully this week I'll have this sorted out,
 and a driver for you guys to test.

Sounds great, let me know when you have it sorted out and I'll give it a whirl 
over here.

-Dave
-
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: Dying disk and filesystem choice.

[David Rees]

On Thu, May 24, 2001 at 09:53:45AM -0700, Hans Reiser wrote:
> 
> No, reiserfs does have badblock support
> 
> You just have to get it as a separate patch from us because it was written after
> code freeze.

Any chance that you'll be putting them on www.namesys.com for easy download?

-Dave
-
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: Dying disk and filesystem choice.

[David Rees]

On Thu, May 24, 2001 at 09:53:45AM -0700, Hans Reiser wrote:
 
 No, reiserfs does have badblock support
 
 You just have to get it as a separate patch from us because it was written after
 code freeze.

Any chance that you'll be putting them on www.namesys.com for easy download?

-Dave
-
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: SW-RAID0 Performance problems

[David Rees]

On Fri, Apr 13, 2001 at 06:28:20PM +0200, Andreas Peter wrote:
> Am Freitag, 13. April 2001 18:07 schrieb David Rees:
> 
> > Cconfig and setup looks OK.
> >
> > What happens if your run hdparm -t /dev/hda and /dev/hdc at the same time?
> 
> Good idea!
> The performance is only ~11MB/sec per disk
> There is a bottleneck somewhere...

OK, so it's not the RAID setup.  There's two things that can cause this.  
One is that DMA is turned off  (what does hdparm /dev/hda and hdparm 
/dev/hdc show?), the second was that the drives are on the same channel 
(which obviously isn't the case here).  Can you verify that the drives are 
in DMA mode?

-Dave
-
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: SW-RAID0 Performance problems

[David Rees]

On Fri, Apr 13, 2001 at 06:28:20PM +0200, Andreas Peter wrote:
 Am Freitag, 13. April 2001 18:07 schrieb David Rees:
 
  Cconfig and setup looks OK.
 
  What happens if your run hdparm -t /dev/hda and /dev/hdc at the same time?
 
 Good idea!
 The performance is only ~11MB/sec per disk
 There is a bottleneck somewhere...

OK, so it's not the RAID setup.  There's two things that can cause this.  
One is that DMA is turned off  (what does hdparm /dev/hda and hdparm 
/dev/hdc show?), the second was that the drives are on the same channel 
(which obviously isn't the case here).  Can you verify that the drives are 
in DMA mode?

-Dave
-
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: SW-RAID0 Performance problems

[David Rees]

On Fri, Apr 13, 2001 at 05:36:55PM +0200, Andreas Peter wrote:
> Mark Hahn schrieb:
> > > hdparm -t /dev/md0 : 20.25 MB/sec
> > > hdparm -t /dev/hda : 20.51 MB/sec
> > > hdaprm -t /dev/hdc : 20.71 MB/sec
> >
> > md0 is composed of partitions located where on hda and hdc?
> > also, what's your CPU?
> 
> This is my raidtab file:



Cconfig and setup looks OK.

What happens if your run hdparm -t /dev/hda and /dev/hdc at the same time?

-Dave
-
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: SW-RAID0 Performance problems

[David Rees]

On Fri, Apr 13, 2001 at 05:36:55PM +0200, Andreas Peter wrote:
 Mark Hahn schrieb:
   hdparm -t /dev/md0 : 20.25 MB/sec
   hdparm -t /dev/hda : 20.51 MB/sec
   hdaprm -t /dev/hdc : 20.71 MB/sec
 
  md0 is composed of partitions located where on hda and hdc?
  also, what's your CPU?
 
 This is my raidtab file:

snip

Cconfig and setup looks OK.

What happens if your run hdparm -t /dev/hda and /dev/hdc at the same time?

-Dave
-
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.2.18, Intel i815 chipset and DMA

[David Rees]

On Fri, Mar 09, 2001 at 05:21:36PM +, Alan Cox wrote:
> > I've got a Gateway here with a Intel 815 chipset running 2.2.18.  Inside
> > it's a PIII 733 with 512MB and a Quantum lct15 drive.
> 
> The UDMA100 on the i810/815 is supported by 2.4
> 
> > turn it on?  The drive should be capable of 10-20MB/s, but I'm
> > only getting about 4MB/s with hdparm.  :-(
> 
> /dev/hda:
>  Timing buffered disk reads:  64 MB in  2.62 seconds = 24.43 MB/sec
> 
> [2.4.2ac17]

OK, I moved the machine to 2.4.2, hdparm is now reading 20MB/sec from
each disk as expected.

Thanks for the tips,
Dave
-
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.2.18, Intel i815 chipset and DMA

[David Rees]

On Fri, Mar 09, 2001 at 12:12:07PM -0500, Mark Hahn wrote:
> > I've got a Gateway here with a Intel 815 chipset running 2.2.18.  Inside
> 
> why?  2.2 is obsolete, and will not receive new drivers.

Hmm, so the Intel 815 and DMA doesn't mix with 2.2.x?  What about
Andre's IDE patches?

> > The problem is that the IDE driver doesn't recognize the IDE
> > conroller, so DMA isn't enabled leading to some poor drive
> 
> the controller is fine in the current 2.4.

I was hoping to stay off the 2.4 series until it stabilises a bit more,
although I may have to upgrade to get any sort of decent performance
out of this machine.  There's a reason no distributions aren't shipping
a 2.4.x kernel yet.

Thanks,
Dave
-
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/

2.2.18, Intel i815 chipset and DMA

[David Rees]

I've got a Gateway here with a Intel 815 chipset running 2.2.18.  Inside
it's a PIII 733 with 512MB and a Quantum lct15 drive.

The problem is that the IDE driver doesn't recognize the IDE
conroller, so DMA isn't enabled leading to some poor drive
performance.  Here's the relevant sections from lspci -v and the boot
logs, any chance of getting DMA working?  Is it safe to use hdparm to
turn it on?  The drive should be capable of 10-20MB/s, but I'm
only getting about 4MB/s with hdparm.  :-(

-Dave

00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory 
Controller Hub (rev 02)
Flags: bus master, fast devsel, latency 0
Memory at f800 (32-bit, prefetchable)
Capabilities: 

00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) (prog-if 00 
[Normal decode])
Flags: bus master, 66Mhz, fast devsel, latency 64
Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
Memory behind bridge: fca0-feaf
Prefetchable memory behind bridge: f070-f47f

00:1e.0 PCI bridge: Intel Corporation: Unknown device 244e (rev 01) (prog-if 00 
[Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: d000-dfff
Memory behind bridge: fc90-fc9f
Prefetchable memory behind bridge: f060-f06f

00:1f.0 ISA bridge: Intel Corporation: Unknown device 2440 (rev 01)
Flags: bus master, medium devsel, latency 0

00:1f.1 IDE interface: Intel Corporation: Unknown device 244b (rev 01) (prog-if 80 
[Master])
Subsystem: Gateway 2000: Unknown device 0058
Flags: bus master, medium devsel, latency 0
I/O ports at ffa0

00:1f.2 USB Controller: Intel Corporation: Unknown device 2442 (rev 01) (prog-if 00 
[UHCI])
Subsystem: Gateway 2000: Unknown device 0058
Flags: bus master, medium devsel, latency 0, IRQ 3
I/O ports at ef40

00:1f.3 SMBus: Intel Corporation: Unknown device 2443 (rev 01)
Subsystem: Gateway 2000: Unknown device 0058
Flags: medium devsel, IRQ 10
I/O ports at efa0

00:1f.4 USB Controller: Intel Corporation: Unknown device 2444 (rev 01) (prog-if 00 
[UHCI])
Subsystem: Gateway 2000: Unknown device 0058
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at ef80



PCI_IDE: unknown IDE controller on PCI bus 00 device f9, VID=8086, DID=244b
PCI_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: QUANTUM FIREBALLlct15 15, ATA DISK drive
hdb: QUANTUM FIREBALLlct20 20, ATA DISK drive
hdc: _NEC DV-5700A, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: QUANTUM FIREBALLlct15 15, 14324MB w/418kB Cache, CHS=1826/255/63
hdb: QUANTUM FIREBALLlct20 20, 19470MB w/418kB Cache, CHS=2482/255/63
hdc: ATAPI 40X DVD-ROM drive, 256kB Cache



# hdparm /dev/hda

/dev/hda:
 multcount=  0 (off)
 I/O support  =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  0 (off)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 1826/255/63, sectors = 29336832, start = 0

# hdparm -i /dev/hda

/dev/hda:

 Model=QUANTUM FIREBALLlct15 15, FwRev=A01.0F00, SerialNo=612020812285
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
 BuffType=DualPortCache, BuffSize=418kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=29336832
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 

# hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.90 seconds =142.22 MB/sec
 Timing buffered disk reads:  64 MB in 15.84 seconds =  4.04 MB/sec


-
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/

2.2.18, Intel i815 chipset and DMA

[David Rees]

I've got a Gateway here with a Intel 815 chipset running 2.2.18.  Inside
it's a PIII 733 with 512MB and a Quantum lct15 drive.

The problem is that the IDE driver doesn't recognize the IDE
conroller, so DMA isn't enabled leading to some poor drive
performance.  Here's the relevant sections from lspci -v and the boot
logs, any chance of getting DMA working?  Is it safe to use hdparm to
turn it on?  The drive should be capable of 10-20MB/s, but I'm
only getting about 4MB/s with hdparm.  :-(

-Dave

00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory 
Controller Hub (rev 02)
Flags: bus master, fast devsel, latency 0
Memory at f800 (32-bit, prefetchable)
Capabilities: available only to root

00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) (prog-if 00 
[Normal decode])
Flags: bus master, 66Mhz, fast devsel, latency 64
Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
Memory behind bridge: fca0-feaf
Prefetchable memory behind bridge: f070-f47f

00:1e.0 PCI bridge: Intel Corporation: Unknown device 244e (rev 01) (prog-if 00 
[Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: d000-dfff
Memory behind bridge: fc90-fc9f
Prefetchable memory behind bridge: f060-f06f

00:1f.0 ISA bridge: Intel Corporation: Unknown device 2440 (rev 01)
Flags: bus master, medium devsel, latency 0

00:1f.1 IDE interface: Intel Corporation: Unknown device 244b (rev 01) (prog-if 80 
[Master])
Subsystem: Gateway 2000: Unknown device 0058
Flags: bus master, medium devsel, latency 0
I/O ports at ffa0

00:1f.2 USB Controller: Intel Corporation: Unknown device 2442 (rev 01) (prog-if 00 
[UHCI])
Subsystem: Gateway 2000: Unknown device 0058
Flags: bus master, medium devsel, latency 0, IRQ 3
I/O ports at ef40

00:1f.3 SMBus: Intel Corporation: Unknown device 2443 (rev 01)
Subsystem: Gateway 2000: Unknown device 0058
Flags: medium devsel, IRQ 10
I/O ports at efa0

00:1f.4 USB Controller: Intel Corporation: Unknown device 2444 (rev 01) (prog-if 00 
[UHCI])
Subsystem: Gateway 2000: Unknown device 0058
Flags: bus master, medium devsel, latency 0, IRQ 9
I/O ports at ef80



PCI_IDE: unknown IDE controller on PCI bus 00 device f9, VID=8086, DID=244b
PCI_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: QUANTUM FIREBALLlct15 15, ATA DISK drive
hdb: QUANTUM FIREBALLlct20 20, ATA DISK drive
hdc: _NEC DV-5700A, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: QUANTUM FIREBALLlct15 15, 14324MB w/418kB Cache, CHS=1826/255/63
hdb: QUANTUM FIREBALLlct20 20, 19470MB w/418kB Cache, CHS=2482/255/63
hdc: ATAPI 40X DVD-ROM drive, 256kB Cache



# hdparm /dev/hda

/dev/hda:
 multcount=  0 (off)
 I/O support  =  0 (default 16-bit)
 unmaskirq=  0 (off)
 using_dma=  0 (off)
 keepsettings =  0 (off)
 nowerr   =  0 (off)
 readonly =  0 (off)
 readahead=  8 (on)
 geometry = 1826/255/63, sectors = 29336832, start = 0

# hdparm -i /dev/hda

/dev/hda:

 Model=QUANTUM FIREBALLlct15 15, FwRev=A01.0F00, SerialNo=612020812285
 Config={ HardSect NotMFM HdSw15uSec Fixed DTR10Mbs }
 RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
 BuffType=DualPortCache, BuffSize=418kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=29336832
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 

# hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.90 seconds =142.22 MB/sec
 Timing buffered disk reads:  64 MB in 15.84 seconds =  4.04 MB/sec


-
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.2.18, Intel i815 chipset and DMA

[David Rees]

On Fri, Mar 09, 2001 at 12:12:07PM -0500, Mark Hahn wrote:
  I've got a Gateway here with a Intel 815 chipset running 2.2.18.  Inside
 
 why?  2.2 is obsolete, and will not receive new drivers.

Hmm, so the Intel 815 and DMA doesn't mix with 2.2.x?  What about
Andre's IDE patches?

  The problem is that the IDE driver doesn't recognize the IDE
  conroller, so DMA isn't enabled leading to some poor drive
 
 the controller is fine in the current 2.4.

I was hoping to stay off the 2.4 series until it stabilises a bit more,
although I may have to upgrade to get any sort of decent performance
out of this machine.  There's a reason no distributions aren't shipping
a 2.4.x kernel yet.

Thanks,
Dave
-
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.2.18, Intel i815 chipset and DMA

[David Rees]

On Fri, Mar 09, 2001 at 05:21:36PM +, Alan Cox wrote:
  I've got a Gateway here with a Intel 815 chipset running 2.2.18.  Inside
  it's a PIII 733 with 512MB and a Quantum lct15 drive.
 
 The UDMA100 on the i810/815 is supported by 2.4
 
  turn it on?  The drive should be capable of 10-20MB/s, but I'm
  only getting about 4MB/s with hdparm.  :-(
 
 /dev/hda:
  Timing buffered disk reads:  64 MB in  2.62 seconds = 24.43 MB/sec
 
 [2.4.2ac17]

OK, I moved the machine to 2.4.2, hdparm is now reading 20MB/sec from
each disk as expected.

Thanks for the tips,
Dave
-
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: [NFS] Re: :Redhat [Bug 30944] - Kernel 2.4.0 and Kernel 2.2.18:with some programs

[David Rees]

On Wed, 7 Mar 2001, Alan Cox wrote:

> > Unfortunately the missing files in directory listings from SGI Irix
> > 6.5.9f NFS servers still persists with the  2.4 kernel - we used the
> > kernel 2.4.0 kernel that came with the Redhat 7.1beta
> > uname -a tells Linux test-ah1 2.4.0-0.99.11 #1 Wed Jan 24 16:07:17 EST
> > 2001 i686 unknown
>
> That is something I'd expect. I don't plan to merge the NFS changes into -ac
> just yet. There are simply too many other things in 2.4 more important than
> an Irix corner case right now.
>
> Irix at least used to have an export option to do mappings to keep clients that
> had 32/64bit inode problems happy. Do those help ?

The 32bitclients option?  In my testing, it didn't change a thing.

Interestingly, unlike the original bug report, I can't reproduce the bug
on all systems, but once it's triggered, I can reliably reproduce it.  On
one 2.4.2 system, one directory always fails to show up, on another, I
can't reproduce the bug in any directory.  Sometimes no files end up
missing, 1 file is missing, or 5-6 files are missing when doing a `ls *`
vs `ls`.

On 2.2.18, mounting with nfsvers=2 seems to fix the problem, on 2.4.2
mounting with nfsvers=2 makes no difference.

-Dave



-
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: [NFS] Re: :Redhat [Bug 30944] - Kernel 2.4.0 and Kernel 2.2.18:with some programs

[David Rees]

On Wed, 7 Mar 2001, Alan Cox wrote:

  Unfortunately the missing files in directory listings from SGI Irix
  6.5.9f NFS servers still persists with the  2.4 kernel - we used the
  kernel 2.4.0 kernel that came with the Redhat 7.1beta
  uname -a tells Linux test-ah1 2.4.0-0.99.11 #1 Wed Jan 24 16:07:17 EST
  2001 i686 unknown

 That is something I'd expect. I don't plan to merge the NFS changes into -ac
 just yet. There are simply too many other things in 2.4 more important than
 an Irix corner case right now.

 Irix at least used to have an export option to do mappings to keep clients that
 had 32/64bit inode problems happy. Do those help ?

The 32bitclients option?  In my testing, it didn't change a thing.

Interestingly, unlike the original bug report, I can't reproduce the bug
on all systems, but once it's triggered, I can reliably reproduce it.  On
one 2.4.2 system, one directory always fails to show up, on another, I
can't reproduce the bug in any directory.  Sometimes no files end up
missing, 1 file is missing, or 5-6 files are missing when doing a `ls *`
vs `ls`.

On 2.2.18, mounting with nfsvers=2 seems to fix the problem, on 2.4.2
mounting with nfsvers=2 makes no difference.

-Dave



-
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: [UPDATE] zerocopy patch against 2.4.2-pre2

[David Rees]

On Wed, Feb 14, 2001 at 12:27:10AM +1100, Andrew Morton wrote:
> 
> It's getting very lonely testing this stuff. It would be useful if
> someone else could help out - at least running the bw_tcp tests. It's
> pretty simple:
> 
>   bw_tcp -s ; bw_tcp 0

OK, here's my bw_tcp results on a K6-2 450. I ran bw_tcp 10 times, then
averaged the results.

bw_tcp
2.4.2-pre3   57.0
2.4.2-pre3zc 52.6

-Dave
-
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: [UPDATE] zerocopy patch against 2.4.2-pre2

[David Rees]

On Wed, Feb 14, 2001 at 12:27:10AM +1100, Andrew Morton wrote:
 
 It's getting very lonely testing this stuff. It would be useful if
 someone else could help out - at least running the bw_tcp tests. It's
 pretty simple:
 
   bw_tcp -s ; bw_tcp 0

OK, here's my bw_tcp results on a K6-2 450. I ran bw_tcp 10 times, then
averaged the results.

bw_tcp
2.4.2-pre3   57.0
2.4.2-pre3zc 52.6

-Dave
-
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: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1

[David Rees]

On Wed, Feb 07, 2001 at 10:47:09AM -0500, Chris Mason wrote:
> 
> Ok, how about we list the known bugs:
> 
> zeros in log files, apparently only between bytes 2048 and 4096 (not
> reproduced yet).

Could this bug be related to the reported corruption that people with
new VIA chipsets have been also reporting on ext2?  It seems similar
because of the location of the corruption:

http://marc.theaimsgroup.com/?l=linux-kernel=98147483712620=2

Anyway, it can't hurt to ask the bug reported if they're using a
newer VIA chipset and see if they will upgrade their BIOS which seems
to fix the problem.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1

[David Rees]

On Wed, Feb 07, 2001 at 10:47:09AM -0500, Chris Mason wrote:
 
 Ok, how about we list the known bugs:
 
 zeros in log files, apparently only between bytes 2048 and 4096 (not
 reproduced yet).

Could this bug be related to the reported corruption that people with
new VIA chipsets have been also reporting on ext2?  It seems similar
because of the location of the corruption:

http://marc.theaimsgroup.com/?l=linux-kernelm=98147483712620w=2

Anyway, it can't hurt to ask the bug reported if they're using a
newer VIA chipset and see if they will upgrade their BIOS which seems
to fix the problem.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre10 -> 2.4.1 klogd at 100% CPU ; 2.4.0 OK

[David Rees]

On Wed, Jan 31, 2001 at 06:00:09PM +, Padraig Brady wrote:
> Chris Hanson wrote:
> 
> >Date: Wed, 31 Jan 2001 17:48:50 +
> >From: Padraig Brady <[EMAIL PROTECTED]>
> > 
> >Are you using the 3c59x driver?
> > 
> > Yes.
> 
> Can we sort this out once and for all? There are a few emails
> everyday relating to this bug.
> 
> The following patch posted by "Troels Walsted Hansen" <[EMAIL PROTECTED]>
> on Jan 11th fixes this. The problem is that when 2 consequtive
> NULLs are sent to klogd it goes into a busy loop. Andrew Mortons
> 3c59x driver does this, but also on Jan 11th he replied that he had
> fixed it. I'm using 2.4ac4 with no problems, so I presume some
> of these patches have been lost along the way?


And if you are using RedHat, you can also grab the latest sysklogd
from rawhide which includes the patch:
ftp://ftp.redhat.com/rawhide/i386/RedHat/RPMS/sysklogd-1.4-5.i386.rpm

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.1-pre10 - 2.4.1 klogd at 100% CPU ; 2.4.0 OK

[David Rees]

On Wed, Jan 31, 2001 at 06:00:09PM +, Padraig Brady wrote:
 Chris Hanson wrote:
 
 Date: Wed, 31 Jan 2001 17:48:50 +
 From: Padraig Brady [EMAIL PROTECTED]
  
 Are you using the 3c59x driver?
  
  Yes.
 
 Can we sort this out once and for all? There are a few emails
 everyday relating to this bug.
 
 The following patch posted by "Troels Walsted Hansen" [EMAIL PROTECTED]
 on Jan 11th fixes this. The problem is that when 2 consequtive
 NULLs are sent to klogd it goes into a busy loop. Andrew Mortons
 3c59x driver does this, but also on Jan 11th he replied that he had
 fixed it. I'm using 2.4ac4 with no problems, so I presume some
 of these patches have been lost along the way?
snip of patch

And if you are using RedHat, you can also grab the latest sysklogd
from rawhide which includes the patch:
ftp://ftp.redhat.com/rawhide/i386/RedHat/RPMS/sysklogd-1.4-5.i386.rpm

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: klogd is acting strange with 2.4

[David Rees]

On Tue, Jan 30, 2001 at 08:53:59AM -0800, David Rees wrote:
> On Tue, Jan 30, 2001 at 09:30:36AM -0500, [EMAIL PROTECTED] wrote:
> > celeron 433 intel i810.  320MB ram.
> > 
> > Before 2.2.18.  Now I've tested with both
> > 2.4.1-pre12 and 2.4.1.  2.4 kernel klogd is
> > always using 99% cpu.  What gives?
> > 
> > I've three other less powerful boxes running
> > 2.4.x kernels and none of them behave
> > like this.  This server isn't taking any
> > more hits than it usually does.
> > 
> > What more information I should post here?
> > I've two apache servers, pgsql and sendmail
> > and some other processes running on this
> > server.
> 
> Can you try 2.4.0?  Are you using the 3c59x ethernet driver?  I've got the 
> same problem on one of my machines, (see message with subject "2.4.1-pre10 
> -> 2.4.1 klogd at 100% CPU ; 2.4.0 OK") and the last thing that is logged 
> is a message from the 3c59x ethernet driver.
> 
> I'm doing a bit more digging to see what changed in the driver between 
> revisions.  /proc/pci lists my 3c905B as this:
> 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 48)

After digging through the archive, it seems that the klogd program doesn't
handle nulls very nicely.  Anyway, by commenting out one of the
initialization printks introduced in the 3c59x driver in 2.4.1, I can run
2.4.1 without having klogd suck up all my CPU time.  The patch is below.

-Dave

--- linux/drivers/net/3c59x.c.orig  Sat Jan  6 09:27:42 2001
+++ linux/drivers/net/3c59x.c   Tue Jan 30 09:05:20 2001
@@ -1049,9 +1049,11 @@
 
EL3WINDOW(4);
step = (inb(ioaddr + Wn4_NetDiag) & 0x1e) >> 1;
+/*
printk(KERN_INFO "  product code '%c%c' rev %02x.%d date %02d-"
   "%02d-%02d\n", eeprom[6]&0xff, eeprom[6]>>8, eeprom[0x14],
   step, (eeprom[4]>>5) & 15, eeprom[4] & 31, eeprom[4]>>9);
+*/
 
 
if (pdev && vci->drv_flags & HAS_CB_FNS) {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: klogd is acting strange with 2.4

[David Rees]

On Tue, Jan 30, 2001 at 09:30:36AM -0500, [EMAIL PROTECTED] wrote:
> celeron 433 intel i810.  320MB ram.
> 
> Before 2.2.18.  Now I've tested with both
> 2.4.1-pre12 and 2.4.1.  2.4 kernel klogd is
> always using 99% cpu.  What gives?
> 
> I've three other less powerful boxes running
> 2.4.x kernels and none of them behave
> like this.  This server isn't taking any
> more hits than it usually does.
> 
> What more information I should post here?
> I've two apache servers, pgsql and sendmail
> and some other processes running on this
> server.

Can you try 2.4.0?  Are you using the 3c59x ethernet driver?  I've got the 
same problem on one of my machines, (see message with subject "2.4.1-pre10 
-> 2.4.1 klogd at 100% CPU ; 2.4.0 OK") and the last thing that is logged 
is a message from the 3c59x ethernet driver.

I'm doing a bit more digging to see what changed in the driver between 
revisions.  /proc/pci lists my 3c905B as this:
3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 48)

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.1-pre10 -> 2.4.1 klogd at 100% CPU ; 2.4.0 OK

[David Rees]

I've been trying different 2.4.1-pre kernels trying to find one that 
doesn't end up with klogd pegging the CPU.  2.4.0 is OK, but 
2.4.1-pre10 to 2.4.1 all leave klogd sitting at 100% CPU.

The machine in question is a Gateway E-3200, a basic PIII-500 running RH 
7.0 with all the latest updates as well as the recommended updates 
documented in the Changes file.  The kernel is compiled with kgcc 
(egcs-1.1.2).

Below is the output from various files to hopefully give some hits as to 
what may be the problem:

> sh scripts/ver_linux
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux shooter.ebetinc.com 2.4.0-c1 #1 Tue Jan 30 02:08:19 PST 2001 i686 
unknown
Kernel modules 2.4.1
Gnu C  2.96
Gnu Make   3.79.1
Binutils   2.10.0.33
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.7
Mount  2.10m
Net-tools  1.56
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded 


.config is at http://spoke.nols.com/~drees/config.txt
cpuinfo is at http://spoke.nols.com/~drees/cpuinfo.txt
dmesg is at   http://spoke.nols.com/~drees/dmesg.txt

Thanks,
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.4.1-pre10 - 2.4.1 klogd at 100% CPU ; 2.4.0 OK

[David Rees]

I've been trying different 2.4.1-pre kernels trying to find one that 
doesn't end up with klogd pegging the CPU.  2.4.0 is OK, but 
2.4.1-pre10 to 2.4.1 all leave klogd sitting at 100% CPU.

The machine in question is a Gateway E-3200, a basic PIII-500 running RH 
7.0 with all the latest updates as well as the recommended updates 
documented in the Changes file.  The kernel is compiled with kgcc 
(egcs-1.1.2).

Below is the output from various files to hopefully give some hits as to 
what may be the problem:

 sh scripts/ver_linux
-- Versions installed: (if some fields are empty or look
-- unusual then possibly you have very old versions)
Linux shooter.ebetinc.com 2.4.0-c1 #1 Tue Jan 30 02:08:19 PST 2001 i686 
unknown
Kernel modules 2.4.1
Gnu C  2.96
Gnu Make   3.79.1
Binutils   2.10.0.33
Linux C Library libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.7
Mount  2.10m
Net-tools  1.56
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded 


.config is at http://spoke.nols.com/~drees/config.txt
cpuinfo is at http://spoke.nols.com/~drees/cpuinfo.txt
dmesg is at   http://spoke.nols.com/~drees/dmesg.txt

Thanks,
Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: klogd is acting strange with 2.4

[David Rees]

On Tue, Jan 30, 2001 at 09:30:36AM -0500, [EMAIL PROTECTED] wrote:
 celeron 433 intel i810.  320MB ram.
 
 Before 2.2.18.  Now I've tested with both
 2.4.1-pre12 and 2.4.1.  2.4 kernel klogd is
 always using 99% cpu.  What gives?
 
 I've three other less powerful boxes running
 2.4.x kernels and none of them behave
 like this.  This server isn't taking any
 more hits than it usually does.
 
 What more information I should post here?
 I've two apache servers, pgsql and sendmail
 and some other processes running on this
 server.

Can you try 2.4.0?  Are you using the 3c59x ethernet driver?  I've got the 
same problem on one of my machines, (see message with subject "2.4.1-pre10 
- 2.4.1 klogd at 100% CPU ; 2.4.0 OK") and the last thing that is logged 
is a message from the 3c59x ethernet driver.

I'm doing a bit more digging to see what changed in the driver between 
revisions.  /proc/pci lists my 3c905B as this:
3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 48)

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: klogd is acting strange with 2.4

[David Rees]

On Tue, Jan 30, 2001 at 08:53:59AM -0800, David Rees wrote:
 On Tue, Jan 30, 2001 at 09:30:36AM -0500, [EMAIL PROTECTED] wrote:
  celeron 433 intel i810.  320MB ram.
  
  Before 2.2.18.  Now I've tested with both
  2.4.1-pre12 and 2.4.1.  2.4 kernel klogd is
  always using 99% cpu.  What gives?
  
  I've three other less powerful boxes running
  2.4.x kernels and none of them behave
  like this.  This server isn't taking any
  more hits than it usually does.
  
  What more information I should post here?
  I've two apache servers, pgsql and sendmail
  and some other processes running on this
  server.
 
 Can you try 2.4.0?  Are you using the 3c59x ethernet driver?  I've got the 
 same problem on one of my machines, (see message with subject "2.4.1-pre10 
 - 2.4.1 klogd at 100% CPU ; 2.4.0 OK") and the last thing that is logged 
 is a message from the 3c59x ethernet driver.
 
 I'm doing a bit more digging to see what changed in the driver between 
 revisions.  /proc/pci lists my 3c905B as this:
 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 48)

After digging through the archive, it seems that the klogd program doesn't
handle nulls very nicely.  Anyway, by commenting out one of the
initialization printks introduced in the 3c59x driver in 2.4.1, I can run
2.4.1 without having klogd suck up all my CPU time.  The patch is below.

-Dave

--- linux/drivers/net/3c59x.c.orig  Sat Jan  6 09:27:42 2001
+++ linux/drivers/net/3c59x.c   Tue Jan 30 09:05:20 2001
@@ -1049,9 +1049,11 @@
 
EL3WINDOW(4);
step = (inb(ioaddr + Wn4_NetDiag)  0x1e)  1;
+/*
printk(KERN_INFO "  product code '%c%c' rev %02x.%d date %02d-"
   "%02d-%02d\n", eeprom[6]0xff, eeprom[6]8, eeprom[0x14],
   step, (eeprom[4]5)  15, eeprom[4]  31, eeprom[4]9);
+*/
 
 
if (pdev  vci-drv_flags  HAS_CB_FNS) {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] Invalid Netfilter URL in Documentation/Changes in 2.4.0

[David Rees]

The link to http://www.samba.org/netfilter/iptables-1.1.1.tar.bz2 is 
invalid in 2.4.0, this patch simply removes the link.

-Dave

--- linux/Documentation/Changes.origMon Jan  1 10:00:04 2001
+++ linux/Documentation/Changes Tue Jan  9 09:37:20 2001
@@ -336,7 +336,6 @@
 Netfilter
 -
 o  
-o  
 o  
 
 Ip-route2



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] Invalid Netfilter URL in Documentation/Changes in 2.4.0

[David Rees]

The link to http://www.samba.org/netfilter/iptables-1.1.1.tar.bz2 is 
invalid in 2.4.0, this patch simply removes the link.

-Dave

--- linux/Documentation/Changes.origMon Jan  1 10:00:04 2001
+++ linux/Documentation/Changes Tue Jan  9 09:37:20 2001
@@ -336,7 +336,6 @@
 Netfilter
 -
 o  http://netfilter.filewatcher.org/iptables-1.1.1.tar.bz2
-o  http://www.samba.org/netfilter/iptables-1.1.1.tar.bz2
 o  http://netfilter.kernelnotes.org/iptables-1.1.1.tar.bz2
 
 Ip-route2



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18pre17: usb-uhci verbosity

[David Rees]

On Fri, Oct 20, 2000 at 08:59:00PM -0400, Martin Hicks wrote:
> 
> I moved from 2.2.18pre15 to 2.2.18pre17 and now I get the following
> usb-uhci stuff being spewed to my terminal:
> 
> Oct 20 20:54:19 plato kernel: usb-uhci.c: interrupt, status 3, frame# 704
> Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 3, frame# 1088
> Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 3, frame# 1472
> Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 3, frame# 1856
> 
> Everything seems to be functioning correctly though.  Reason?

Not sure, but I saw the same thing on my machine.  No one had any ideas,
but I moved to the altertative uhci driver and things work great and no
more messages.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18pre17: usb-uhci verbosity

[David Rees]

On Fri, Oct 20, 2000 at 08:59:00PM -0400, Martin Hicks wrote:
 
 I moved from 2.2.18pre15 to 2.2.18pre17 and now I get the following
 usb-uhci stuff being spewed to my terminal:
 
 Oct 20 20:54:19 plato kernel: usb-uhci.c: interrupt, status 3, frame# 704
 Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 3, frame# 1088
 Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 3, frame# 1472
 Oct 20 20:54:20 plato kernel: usb-uhci.c: interrupt, status 3, frame# 1856
 
 Everything seems to be functioning correctly though.  Reason?

Not sure, but I saw the same thing on my machine.  No one had any ideas,
but I moved to the altertative uhci driver and things work great and no
more messages.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18pre16 and USB_UHCI_ALT

[David Rees]

On Wed, Oct 18, 2000 at 11:02:27PM -0700, Greg KH wrote:
> 
> > I'll give the usb-uhci driver in 2.2.18pre17 another shot tonight.
> 
> Let me know how it goes.

Same thing.  Now I only have my Intellimouse plugged into the USB port.

The messages seem to start appearing when gpm starts up...

Oct 19 09:07:54 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 19 09:07:54 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 901
Oct 19 09:07:54 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 19 09:07:54 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:2.0
Oct 19 09:07:54 spoke kernel: hub.c: already running port 1 disabled by
hub (EMI?), re-enabling...
Oct 19 09:07:54 spoke kernel: usb.c: USB disconnect on device 2
Oct 19 09:07:54 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 19 09:07:54 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1244
Oct 19 09:07:54 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 19 09:07:54 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:2.0
Oct 19 09:07:54 spoke kernel: hub.c: already running port 1 disabled by
hub (EMI?), re-enabling...
Oct 19 09:07:54 spoke kernel: usb.c: USB disconnect on device 2
Oct 19 09:07:54 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 19 09:07:54 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1757
Oct 19 09:07:54 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 19 09:07:54 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:2.0
Oct 19 09:07:54 spoke kernel: usb.c: USB new device connect, assigned
device number 3
Oct 19 09:07:54 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 49
Oct 19 09:07:54 spoke kernel: mouse1: PS/2 mouse device for input1
Oct 19 09:07:54 spoke kernel: input1: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:3.0   

Oct 19 09:07:58 spoke gpm: gpm startup succeeded
Oct 19 09:07:58 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 860
Oct 19 09:07:58 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 884
Oct 19 09:07:58 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 908
Oct 19 09:07:58 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 932
Oct 19 09:07:59 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 956
Oct 19 09:07:59 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 980

These messages don't happen with the uhci.c ALT driver and USB works
great.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18pre16 and USB_UHCI_ALT

[David Rees]

On Wed, Oct 18, 2000 at 11:02:27PM -0700, Greg KH wrote:
 
  I'll give the usb-uhci driver in 2.2.18pre17 another shot tonight.
 
 Let me know how it goes.

Same thing.  Now I only have my Intellimouse plugged into the USB port.

The messages seem to start appearing when gpm starts up...

Oct 19 09:07:54 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 19 09:07:54 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 901
Oct 19 09:07:54 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 19 09:07:54 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:2.0
Oct 19 09:07:54 spoke kernel: hub.c: already running port 1 disabled by
hub (EMI?), re-enabling...
Oct 19 09:07:54 spoke kernel: usb.c: USB disconnect on device 2
Oct 19 09:07:54 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 19 09:07:54 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1244
Oct 19 09:07:54 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 19 09:07:54 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:2.0
Oct 19 09:07:54 spoke kernel: hub.c: already running port 1 disabled by
hub (EMI?), re-enabling...
Oct 19 09:07:54 spoke kernel: usb.c: USB disconnect on device 2
Oct 19 09:07:54 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 19 09:07:54 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1757
Oct 19 09:07:54 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 19 09:07:54 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:2.0
Oct 19 09:07:54 spoke kernel: usb.c: USB new device connect, assigned
device number 3
Oct 19 09:07:54 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 49
Oct 19 09:07:54 spoke kernel: mouse1: PS/2 mouse device for input1
Oct 19 09:07:54 spoke kernel: input1: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:3.0   
snip
Oct 19 09:07:58 spoke gpm: gpm startup succeeded
Oct 19 09:07:58 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 860
Oct 19 09:07:58 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 884
Oct 19 09:07:58 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 908
Oct 19 09:07:58 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 932
Oct 19 09:07:59 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 956
Oct 19 09:07:59 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 980

These messages don't happen with the uhci.c ALT driver and USB works
great.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18pre16 and USB_UHCI_ALT

[David Rees]

On Wed, Oct 18, 2000 at 11:02:27PM -0700, Greg KH wrote:
> On Wed, Oct 18, 2000 at 10:47:16PM -0700, David Rees wrote:
> > 
> > This is on a Tyan Trinity 1598 Socket 7 motherboard.  No hubs of any sort.
> 
> No external hubs?  Then why is the hub driver seeing both a 2 port root
> hub, and a 4 port "normal" hub?  Does this motherboard have more than 2
> external USB connectors on it?
> 
> Odd.

Well, according to /proc/pci there's two USB controllers:

  Bus  0, device   7, function  2:
USB Controller: VIA Technologies VT 82C586 Apollo USB (rev 6).
  Medium devsel.  IRQ 10.  Master Capable.  Latency=32.
  I/O at 0xd400 [0xd401].
  Bus  0, device   7, function  3:
USB Controller: VIA Technologies VT 82C586 Apollo USB (rev 6).
  Medium devsel.  IRQ 10.  Master Capable.  Latency=32.
  I/O at 0xd800 [0xd801].

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18pre16 and USB_UHCI_ALT

[David Rees]

On Wed, Oct 18, 2000 at 10:51:05PM -0700, Greg KH wrote:
> On Wed, Oct 18, 2000 at 08:21:53AM -0700, David Rees wrote:
> > 
> > Nothing else odd changed.  Here's the boot sequence and messages which
> > repeated endlessly after booting 2.2.18pre16 with the usb-uhci driver:
> 
> This kinda looks like you have a flaky hub.  It is a self powered hub?
> If so, try making it a external powered hub if you can.
> Or is this the root hub on a laptop?

This is on a Tyan Trinity 1598 Socket 7 motherboard.  No hubs of any sort.

I'll give the usb-uhci driver in 2.2.18pre17 another shot tonight.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18pre16 and USB_UHCI_ALT

[David Rees]

On Tue, Oct 17, 2000 at 01:46:46PM -0700, Greg KH wrote:
> On Mon, Oct 16, 2000 at 10:49:56PM -0700, David Rees wrote:
> > 
> > Well, the real interesting part is that I was using the usb-uhci.c driver
> > in 2.2.18pre15, and now in 2.2.18pre16 it stopped working for my mouse
> > with no apparent change to either of the uhci drivers.
> 
> Kernel debug messages?
> Anything else odd change?

Nothing else odd changed.  Here's the boot sequence and messages which
repeated endlessly after booting 2.2.18pre16 with the usb-uhci driver:

Oct 15 23:35:12 spoke kernel: usb.c: registered new driver hid
Oct 15 23:35:12 spoke kernel: mice: PS/2 mouse device common for all mice
Oct 15 23:35:12 spoke kernel: usb.c: registered new driver hub
Oct 15 23:35:12 spoke kernel: usb-uhci.c: $Revision: 1.237 $ time 23:19:11
Oct 15 2000
Oct 15 23:35:12 spoke kernel: usb-uhci.c: High bandwidth mode enabled
Oct 15 23:35:12 spoke kernel: usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 10
Oct 15 23:35:12 spoke kernel: usb-uhci.c: Detected 2 ports
Oct 15 23:35:12 spoke kernel: usb.c: new USB bus registered, assigned bus
number 1
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 1
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 2 ports detected
Oct 15 23:35:12 spoke kernel: usb-uhci.c: USB UHCI at I/O 0xd800, IRQ 10
Oct 15 23:35:12 spoke kernel: usb-uhci.c: Detected 2 ports
Oct 15 23:35:12 spoke kernel: usb.c: new USB bus registered, assigned bus
number 2
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 1
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 2 ports detected
Oct 15 23:35:12 spoke kernel: VFS: Mounted root (ext2
filesystem) readonly.
Oct 15 23:35:12 spoke kernel: Freeing unused kernel memory: 48k freed
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 4 ports detected
Oct 15 23:35:12 spoke kernel: hub.c: already running port 1 disabled by
hub (EMI?), re-enabling...
Oct 15 23:35:12 spoke kernel: usb.c: USB disconnect on device 2
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 4 ports detected
Oct 15 23:35:12 spoke kernel: hub.c: already running port 1 disabled by
hub (EMI?), re-enabling...
Oct 15 23:35:12 spoke kernel: usb.c: USB disconnect on device 2
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 4 ports detected
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 3
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 4 ports detected
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1984
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 320
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 4
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 479
Oct 15 23:35:12 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 15 23:35:12 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:4.0
Oct 15 23:35:12 spoke kernel: hub.c: already running port 2 disabled by
hub (EMI?), re-enabling...
Oct 15 23:35:12 spoke kernel: usb.c: USB disconnect on device 4
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 704
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 4
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1029
Oct 15 23:35:12 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 15 23:35:12 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:4.0
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1088
Oct 15 23:35:12 spoke kernel: usb.c: USB disconnect on device 4
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 4
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1359
Oct 15 23:35:12 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 15 23:35:12 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:4.0
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1472
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1856
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 5
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1948
Oct 15 23:35:12 spoke kernel: mouse1: PS/2 mouse device for input1
Oct 15 23:35:12 spoke kernel: input1: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMous

Re: 2.2.18pre16 and USB_UHCI_ALT

[David Rees]

On Tue, Oct 17, 2000 at 01:46:46PM -0700, Greg KH wrote:
 On Mon, Oct 16, 2000 at 10:49:56PM -0700, David Rees wrote:
  
  Well, the real interesting part is that I was using the usb-uhci.c driver
  in 2.2.18pre15, and now in 2.2.18pre16 it stopped working for my mouse
  with no apparent change to either of the uhci drivers.
 
 Kernel debug messages?
 Anything else odd change?

Nothing else odd changed.  Here's the boot sequence and messages which
repeated endlessly after booting 2.2.18pre16 with the usb-uhci driver:

Oct 15 23:35:12 spoke kernel: usb.c: registered new driver hid
Oct 15 23:35:12 spoke kernel: mice: PS/2 mouse device common for all mice
Oct 15 23:35:12 spoke kernel: usb.c: registered new driver hub
Oct 15 23:35:12 spoke kernel: usb-uhci.c: $Revision: 1.237 $ time 23:19:11
Oct 15 2000
Oct 15 23:35:12 spoke kernel: usb-uhci.c: High bandwidth mode enabled
Oct 15 23:35:12 spoke kernel: usb-uhci.c: USB UHCI at I/O 0xd400, IRQ 10
Oct 15 23:35:12 spoke kernel: usb-uhci.c: Detected 2 ports
Oct 15 23:35:12 spoke kernel: usb.c: new USB bus registered, assigned bus
number 1
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 1
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 2 ports detected
Oct 15 23:35:12 spoke kernel: usb-uhci.c: USB UHCI at I/O 0xd800, IRQ 10
Oct 15 23:35:12 spoke kernel: usb-uhci.c: Detected 2 ports
Oct 15 23:35:12 spoke kernel: usb.c: new USB bus registered, assigned bus
number 2
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 1
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 2 ports detected
Oct 15 23:35:12 spoke kernel: VFS: Mounted root (ext2
filesystem) readonly.
Oct 15 23:35:12 spoke kernel: Freeing unused kernel memory: 48k freed
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 4 ports detected
Oct 15 23:35:12 spoke kernel: hub.c: already running port 1 disabled by
hub (EMI?), re-enabling...
Oct 15 23:35:12 spoke kernel: usb.c: USB disconnect on device 2
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 4 ports detected
Oct 15 23:35:12 spoke kernel: hub.c: already running port 1 disabled by
hub (EMI?), re-enabling...
Oct 15 23:35:12 spoke kernel: usb.c: USB disconnect on device 2
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 2
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 4 ports detected
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 3
Oct 15 23:35:12 spoke kernel: hub.c: USB hub found
Oct 15 23:35:12 spoke kernel: hub.c: 4 ports detected
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1984
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 320
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 4
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 479
Oct 15 23:35:12 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 15 23:35:12 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:4.0
Oct 15 23:35:12 spoke kernel: hub.c: already running port 2 disabled by
hub (EMI?), re-enabling...
Oct 15 23:35:12 spoke kernel: usb.c: USB disconnect on device 4
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 704
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 4
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1029
Oct 15 23:35:12 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 15 23:35:12 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:4.0
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1088
Oct 15 23:35:12 spoke kernel: usb.c: USB disconnect on device 4
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 4
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1359
Oct 15 23:35:12 spoke kernel: mouse0: PS/2 mouse device for input0
Oct 15 23:35:12 spoke kernel: input0: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:4.0
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1472
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1856
Oct 15 23:35:12 spoke kernel: usb.c: USB new device connect, assigned
device number 5
Oct 15 23:35:12 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 1948
Oct 15 23:35:12 spoke kernel: mouse1: PS/2 mouse device for input1
Oct 15 23:35:12 spoke kernel: input1: USB HID v1.00 Mouse [Microsoft
Microsoft IntelliMouse® Optical] on usb1:5.0
Oct 15 23:35:12 spoke

Re: 2.2.18pre16 and USB_UHCI_ALT

[David Rees]

On Wed, Oct 18, 2000 at 10:51:05PM -0700, Greg KH wrote:
 On Wed, Oct 18, 2000 at 08:21:53AM -0700, David Rees wrote:
  
  Nothing else odd changed.  Here's the boot sequence and messages which
  repeated endlessly after booting 2.2.18pre16 with the usb-uhci driver:
 
 This kinda looks like you have a flaky hub.  It is a self powered hub?
 If so, try making it a external powered hub if you can.
 Or is this the root hub on a laptop?

This is on a Tyan Trinity 1598 Socket 7 motherboard.  No hubs of any sort.

I'll give the usb-uhci driver in 2.2.18pre17 another shot tonight.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.2.18pre16 and USB_UHCI_ALT

[David Rees]

On Mon, Oct 16, 2000 at 01:32:01PM -0400, Johannes Erdfelt wrote:
> On Mon, Oct 16, 2000, David Rees <[EMAIL PROTECTED]> wrote:
> > In 2.2.18pre16 an alternative USB_UHCI driver under the option
> > CONFIG_USB_UHCI_ALT was added.  Only this one works for me, and
> > CONFIG_USB_UHCI throws up 50 messages a second like this one:
> > 
> > Oct 16 00:12:22 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 188
> > 
> > and leaves my mouse in an unusable state.
> > 
> > This is on a VIA Technologies VT 82C586 Apollo USB (rev 6).  I have two
> > USB devices connected to it:
> > Microsoft Microsoft IntelliMouse® Optical
> > Microsoft Natural Keyboard Pro
> > 
> > What is supposed to be the difference between the two drivers, anyway?  It
> > is not clear from the docs what is different besides the fact that they
> > are different.
> 
> Just that. It's an alternative implementation. It's a long story why
> there's 2 drivers for the same device, and you can check the USB
> archives to learn the whole story.
> 
> The short of it is that I didn't like the usb-uhci.c driver so I wrote a
> different one. It looks like it was worth the effort since it works for
> you whereas usb-uhci.c doesn't.
> 
> I'm sure the usb-uhci.c guys will be interested to follow up with you
> about the problems you are seeing.

Well, the real interesting part is that I was using the usb-uhci.c driver
in 2.2.18pre15, and now in 2.2.18pre16 it stopped working for my mouse
with no apparent change to either of the uhci drivers.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.2.18pre16 and USB_UHCI_ALT

[David Rees]

In 2.2.18pre16 an alternative USB_UHCI driver under the option
CONFIG_USB_UHCI_ALT was added.  Only this one works for me, and
CONFIG_USB_UHCI throws up 50 messages a second like this one:

Oct 16 00:12:22 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 188

and leaves my mouse in an unusable state.

This is on a VIA Technologies VT 82C586 Apollo USB (rev 6).  I have two
USB devices connected to it:
Microsoft Microsoft IntelliMouse® Optical
Microsoft Natural Keyboard Pro

What is supposed to be the difference between the two drivers, anyway?  It
is not clear from the docs what is different besides the fact that they
are different.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Problems with Tulip driver in 2.2 and 2.4

[David Rees]

On Mon, Oct 16, 2000 at 08:16:53AM +0100, Alan Cox wrote:
> > I've noticed this behavior for a few kernel revisions now, up to and
> > including 2.2.17.  It would be nice to get this bug worked out before
> > 2.2.18.
> 
> I dont think that is likely to happen. Every time someone touches the tulip 
> driver close to release they fix one card and break another 8(

It's a good thing I wasn't holding my breath, then.  ;-)  Maybe 2.2.19,
then, especially since 2.2.18 seems to be right around the corner.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Problems with Tulip driver in 2.2 and 2.4

[David Rees]

On Mon, Oct 16, 2000 at 08:16:53AM +0100, Alan Cox wrote:
  I've noticed this behavior for a few kernel revisions now, up to and
  including 2.2.17.  It would be nice to get this bug worked out before
  2.2.18.
 
 I dont think that is likely to happen. Every time someone touches the tulip 
 driver close to release they fix one card and break another 8(

It's a good thing I wasn't holding my breath, then.  ;-)  Maybe 2.2.19,
then, especially since 2.2.18 seems to be right around the corner.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

2.2.18pre16 and USB_UHCI_ALT

[David Rees]

In 2.2.18pre16 an alternative USB_UHCI driver under the option
CONFIG_USB_UHCI_ALT was added.  Only this one works for me, and
CONFIG_USB_UHCI throws up 50 messages a second like this one:

Oct 16 00:12:22 spoke kernel: usb-uhci.c: interrupt, status 3, frame# 188

and leaves my mouse in an unusable state.

This is on a VIA Technologies VT 82C586 Apollo USB (rev 6).  I have two
USB devices connected to it:
Microsoft Microsoft IntelliMouse® Optical
Microsoft Natural Keyboard Pro

What is supposed to be the difference between the two drivers, anyway?  It
is not clear from the docs what is different besides the fact that they
are different.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Problems with Tulip driver in 2.2 and 2.4

[David Rees]

On Sun, Oct 15, 2000 at 06:25:34PM -0700, J. S. Connell wrote:
> Any time I disconnect and then reconnect the ethernet cable from my Netgear
> FA310TX cards, the card appears to not notice and doesn't reestablish the
> link.  Under 2.2.17pre4, the link light comes on, but until I do ifconfig
> ethX down; ifconfig ethX up, the kernel ignores any traffic on that
> interface (tcpdump on both an affected machine and a nonaffected machine
> show the kernel ignoring all incoming traffic, and not sending any traffic
> out.)

I've seen similar behavior on the same cards, but it only seems to affect
100Mbps operation, plugging it into a 10Mbps hub instead of our 3Com
100Mbps switch will also get things working as does running ifup/ifdown on
the interface.

The tulip driver recognizes it as a "Lite-On 82c168 PNIC rev 32".

I've noticed this behavior for a few kernel revisions now, up to and
including 2.2.17.  It would be nice to get this bug worked out before
2.2.18.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Problems with Tulip driver in 2.2 and 2.4

[David Rees]

On Sun, Oct 15, 2000 at 06:25:34PM -0700, J. S. Connell wrote:
 Any time I disconnect and then reconnect the ethernet cable from my Netgear
 FA310TX cards, the card appears to not notice and doesn't reestablish the
 link.  Under 2.2.17pre4, the link light comes on, but until I do ifconfig
 ethX down; ifconfig ethX up, the kernel ignores any traffic on that
 interface (tcpdump on both an affected machine and a nonaffected machine
 show the kernel ignoring all incoming traffic, and not sending any traffic
 out.)

I've seen similar behavior on the same cards, but it only seems to affect
100Mbps operation, plugging it into a 10Mbps hub instead of our 3Com
100Mbps switch will also get things working as does running ifup/ifdown on
the interface.

The tulip driver recognizes it as a "Lite-On 82c168 PNIC rev 32".

I've noticed this behavior for a few kernel revisions now, up to and
including 2.2.17.  It would be nice to get this bug worked out before
2.2.18.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Newer motherboards / CPU's / hardware with Linux

[David Rees]

On Sat, Oct 07, 2000 at 02:10:31PM -0400, Mark Hahn wrote:
> > kernel proper and working.  If it *IS* ready now, what sort of
> > Athlon hardware is recommended for a developmental machine?
> 
> I HIGHLY recommend duron/thunderbird, KT133, PC133, UDMA machines;
> they work very well with modern (2.4) kernels.  K6-2 machines are 
> not anywhere close to the same performance, and even low-end Durons
> embarass FSB100-overclocked Celeron machines quite neatly.
> a Duron/600 makes a great development workstation; 
> I haven't seen a reason to pay extra for a thunderbird.

Agreed.  The only difficulty I had was while attempting to set up a recent
system was getting the ATA100 chipset to work on a Asus A7V, but all that
required was a patch with Andre's IDE patches to 2.2.17 and things the
Promise ATA100 chipset was detected fine.  We're using the Via controller,
though, our disk is only a ATA33 drive.

The Durons are GREAT values, we did a few benchmarks on a Duron 600 system
vs an Athlon 700 (slot, not TBird), and in most cases it was about 10-15%
slower, but while timing how long it took to unpack the kernel sources, it
was something like 5-10% FASTER!

Now if they made Durons in the higher clock speeds, I wouldn't hesitate to
pick one of those up over a TBird, but if you want something over 700Mhz,
you're stuck.

Keep in mind that AMD will be significantly dropping prices around the end
of the month, so you may want to wait a bit before picking one up.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Newer motherboards / CPU's / hardware with Linux

[David Rees]

On Sat, Oct 07, 2000 at 02:10:31PM -0400, Mark Hahn wrote:
  kernel proper and working.  If it *IS* ready now, what sort of
  Athlon hardware is recommended for a developmental machine?
 
 I HIGHLY recommend duron/thunderbird, KT133, PC133, UDMA machines;
 they work very well with modern (2.4) kernels.  K6-2 machines are 
 not anywhere close to the same performance, and even low-end Durons
 embarass FSB100-overclocked Celeron machines quite neatly.
 a Duron/600 makes a great development workstation; 
 I haven't seen a reason to pay extra for a thunderbird.

Agreed.  The only difficulty I had was while attempting to set up a recent
system was getting the ATA100 chipset to work on a Asus A7V, but all that
required was a patch with Andre's IDE patches to 2.2.17 and things the
Promise ATA100 chipset was detected fine.  We're using the Via controller,
though, our disk is only a ATA33 drive.

The Durons are GREAT values, we did a few benchmarks on a Duron 600 system
vs an Athlon 700 (slot, not TBird), and in most cases it was about 10-15%
slower, but while timing how long it took to unpack the kernel sources, it
was something like 5-10% FASTER!

Now if they made Durons in the higher clock speeds, I wouldn't hesitate to
pick one of those up over a TBird, but if you want something over 700Mhz,
you're stuck.

Keep in mind that AMD will be significantly dropping prices around the end
of the month, so you may want to wait a bit before picking one up.

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre12

[David Rees]

On Sat, Sep 30, 2000 at 12:52:07AM +0100, Alan Cox wrote:
> 
> o USB build bug fix   (Arjan van de Ven)

It looks like the wrong USB build bug fix got included into
2.2.18pre12.  Jeff Garzik and Greg KH commented that because the uhci_init
function uses initcalls, the proper fix is to remove the call to uhci_init
in drivers/usb/usb-core.c and to convert the function ohci_hcd_init to use
init calls.

Below is the patch agains 2.2.18pre12 to take out the call to uhci_init
and revert the original compile fix, Greg KH should be finishing up
ohci_hcd_init soon.

-Dave

--- linux/drivers/usb/uhci.cSat Sep 30 01:56:24 2000
+++ linux-2.2.18pre11/drivers/usb/uhci.cThu Sep 28 08:44:59 2000
@@ -2426,7 +2426,7 @@
return 0;
 }
 
-int __init uhci_init(void)
+static int __init uhci_init(void)
 {
int retval;
struct pci_dev *dev;
--- linux/drivers/usb/usb-uhci.cSat Sep 30 01:56:24 2000
+++ linux-2.2.18pre11/drivers/usb/usb-uhci.cThu Sep 28 08:44:59 2000
@@ -2822,7 +2822,7 @@
return -1;
 }
 
-int __init uhci_init (void)
+static int __init uhci_init (void)
 {
int retval = -ENODEV;
struct pci_dev *dev = NULL;
--- linux/drivers/usb/usb-core.cSat Sep 30 01:56:24 2000
+++ linux-2.2.18pre11/drivers/usb/usb-core.cThu Sep 28 08:47:13 2000
@@ -60,12 +60,6 @@
usb_hub_init();
 
 #ifndef CONFIG_USB_MODULE
-#ifdef CONFIG_USB_UHCI
-   uhci_init();
-#endif
-#ifdef CONFIG_USB_UHCI_ALT
-   uhci_init();
-#endif
 #ifdef CONFIG_USB_OHCI
ohci_hcd_init(); 
 #endif

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre12

[David Rees]

On Sat, Sep 30, 2000 at 12:52:07AM +0100, Alan Cox wrote:
 
 o USB build bug fix   (Arjan van de Ven)

It looks like the wrong USB build bug fix got included into
2.2.18pre12.  Jeff Garzik and Greg KH commented that because the uhci_init
function uses initcalls, the proper fix is to remove the call to uhci_init
in drivers/usb/usb-core.c and to convert the function ohci_hcd_init to use
init calls.

Below is the patch agains 2.2.18pre12 to take out the call to uhci_init
and revert the original compile fix, Greg KH should be finishing up
ohci_hcd_init soon.

-Dave

--- linux/drivers/usb/uhci.cSat Sep 30 01:56:24 2000
+++ linux-2.2.18pre11/drivers/usb/uhci.cThu Sep 28 08:44:59 2000
@@ -2426,7 +2426,7 @@
return 0;
 }
 
-int __init uhci_init(void)
+static int __init uhci_init(void)
 {
int retval;
struct pci_dev *dev;
--- linux/drivers/usb/usb-uhci.cSat Sep 30 01:56:24 2000
+++ linux-2.2.18pre11/drivers/usb/usb-uhci.cThu Sep 28 08:44:59 2000
@@ -2822,7 +2822,7 @@
return -1;
 }
 
-int __init uhci_init (void)
+static int __init uhci_init (void)
 {
int retval = -ENODEV;
struct pci_dev *dev = NULL;
--- linux/drivers/usb/usb-core.cSat Sep 30 01:56:24 2000
+++ linux-2.2.18pre11/drivers/usb/usb-core.cThu Sep 28 08:47:13 2000
@@ -60,12 +60,6 @@
usb_hub_init();
 
 #ifndef CONFIG_USB_MODULE
-#ifdef CONFIG_USB_UHCI
-   uhci_init();
-#endif
-#ifdef CONFIG_USB_UHCI_ALT
-   uhci_init();
-#endif
 #ifdef CONFIG_USB_OHCI
ohci_hcd_init(); 
 #endif

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre11

[David Rees]

On Thu, Sep 28, 2000 at 09:39:22AM -0700, Dunlap, Randy wrote:
> 
> Yes, that looks like 2.4.0-test9 now, except that it should
> be done for ohci also, although you don't need it for your
> config.

Right, but it doesn't look like the usb-ohci driver uses initcalls like
the other functions.  I could be wrong, new at kernel hacking.  :-)

-Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre11

[David Rees]

On Thu, Sep 28, 2000 at 04:13:24AM -0500, Jeff Garzik wrote:
> 
> On Thu, 28 Sep 2000, Arjan van de Ven wrote:
> 
> > In article <[EMAIL PROTECTED]> you wrote:
> > > I'm getting this compile time error on 2.2.18pre11:
> > 
> > > drivers/usb/usbdrv.o: In function `usb_init':
> > > drivers/usb/usbdrv.o(.text+0x6deb): undefined reference to `uhci_init'
> > 
> > The patch below should fix that.
> 
> No it doesn't  read the usb/uhci code.  It uses initcalls.  The
> solution is to remove call to uhci_init() in usb_init().

Ah, is this the correct fix, then?  I actually booted this one (I never
booted the other patch, just compiled it, and it works for me.  :-)

-Dave

--- linux/drivers/usb/usb-core.c.orig   Thu Sep 28 08:44:59 2000
+++ linux/drivers/usb/usb-core.cThu Sep 28 08:47:13 2000
@@ -60,12 +60,6 @@
usb_hub_init();

 #ifndef CONFIG_USB_MODULE
-#ifdef CONFIG_USB_UHCI
-   uhci_init();
-#endif
-#ifdef CONFIG_USB_UHCI_ALT
-   uhci_init();
-#endif
 #ifdef CONFIG_USB_OHCI
ohci_hcd_init();
 #endif

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre11

[David Rees]

Thanks,

This does the trick.

-Dave

On Thu, Sep 28, 2000 at 09:23:29AM +0200, Arjan van de Ven wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > I'm getting this compile time error on 2.2.18pre11:
> 
> > drivers/usb/usbdrv.o: In function `usb_init':
> > drivers/usb/usbdrv.o(.text+0x6deb): undefined reference to `uhci_init'
> 
> The patch below should fix that.
> 
> Greetings,
>Arjan van de Ven
> 
> --- linux/drivers/usb/uhci.c~ Wed Sep 27 18:21:25 2000
> +++ linux/drivers/usb/uhci.c  Wed Sep 27 18:52:06 2000
> @@ -2426,7 +2426,7 @@
>   return 0;
>  }
>  
> -static int __init uhci_init(void)
> +int __init uhci_init(void)
>  {
>   int retval;
>   struct pci_dev *dev;
> --- linux/drivers/usb/usb-uhci.c~ Wed Sep 27 18:21:25 2000
> +++ linux/drivers/usb/usb-uhci.c  Wed Sep 27 18:52:09 2000
> @@ -2822,7 +2822,7 @@
>   return -1;
>  }
>  
> -static int __init uhci_init (void)
> +int __init uhci_init (void)
>  {
>   int retval = -ENODEV;
>   struct pci_dev *dev = NULL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre11

[David Rees]

I'm getting this compile time error on 2.2.18pre11:

drivers/usb/usbdrv.o: In function `usb_init':
drivers/usb/usbdrv.o(.text+0x6deb): undefined reference to `uhci_init'

Complete .config is located at
http://spoke.nols.com/~drees/config-2.2.18pre11
USB related config is below.

-Dave

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
# CONFIG_USB_DEVICEFS is not set
# CONFIG_USB_BANDWIDTH is not set

#
# USB Controllers
#
CONFIG_USB_UHCI=y
# CONFIG_USB_OHCI is not set

#
# USB Devices
#
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_PLUSB is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_BLUETOOTH is not set
# CONFIG_USB_KAWETH is not set

#
# USB HID
#
CONFIG_USB_HID=y
# CONFIG_USB_WACOM is not set
# CONFIG_USB_WMFORCE is not set
CONFIG_INPUT_KEYBDEV=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1152
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=864
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre11

[David Rees]

I'm getting this compile time error on 2.2.18pre11:

drivers/usb/usbdrv.o: In function `usb_init':
drivers/usb/usbdrv.o(.text+0x6deb): undefined reference to `uhci_init'

Complete .config is located at
http://spoke.nols.com/~drees/config-2.2.18pre11
USB related config is below.

-Dave

#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
# CONFIG_USB_DEVICEFS is not set
# CONFIG_USB_BANDWIDTH is not set

#
# USB Controllers
#
CONFIG_USB_UHCI=y
# CONFIG_USB_OHCI is not set

#
# USB Devices
#
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_PLUSB is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_BLUETOOTH is not set
# CONFIG_USB_KAWETH is not set

#
# USB HID
#
CONFIG_USB_HID=y
# CONFIG_USB_WACOM is not set
# CONFIG_USB_WMFORCE is not set
CONFIG_INPUT_KEYBDEV=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1152
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=864
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre11

[David Rees]

Thanks,

This does the trick.

-Dave

On Thu, Sep 28, 2000 at 09:23:29AM +0200, Arjan van de Ven wrote:
 In article [EMAIL PROTECTED] you wrote:
  I'm getting this compile time error on 2.2.18pre11:
 
  drivers/usb/usbdrv.o: In function `usb_init':
  drivers/usb/usbdrv.o(.text+0x6deb): undefined reference to `uhci_init'
 
 The patch below should fix that.
 
 Greetings,
Arjan van de Ven
 
 --- linux/drivers/usb/uhci.c~ Wed Sep 27 18:21:25 2000
 +++ linux/drivers/usb/uhci.c  Wed Sep 27 18:52:06 2000
 @@ -2426,7 +2426,7 @@
   return 0;
  }
  
 -static int __init uhci_init(void)
 +int __init uhci_init(void)
  {
   int retval;
   struct pci_dev *dev;
 --- linux/drivers/usb/usb-uhci.c~ Wed Sep 27 18:21:25 2000
 +++ linux/drivers/usb/usb-uhci.c  Wed Sep 27 18:52:09 2000
 @@ -2822,7 +2822,7 @@
   return -1;
  }
  
 -static int __init uhci_init (void)
 +int __init uhci_init (void)
  {
   int retval = -ENODEV;
   struct pci_dev *dev = NULL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre11

[David Rees]

On Thu, Sep 28, 2000 at 04:13:24AM -0500, Jeff Garzik wrote:
 
 On Thu, 28 Sep 2000, Arjan van de Ven wrote:
 
  In article [EMAIL PROTECTED] you wrote:
   I'm getting this compile time error on 2.2.18pre11:
  
   drivers/usb/usbdrv.o: In function `usb_init':
   drivers/usb/usbdrv.o(.text+0x6deb): undefined reference to `uhci_init'
  
  The patch below should fix that.
 
 No it doesn't  read the usb/uhci code.  It uses initcalls.  The
 solution is to remove call to uhci_init() in usb_init().

Ah, is this the correct fix, then?  I actually booted this one (I never
booted the other patch, just compiled it, and it works for me.  :-)

-Dave

--- linux/drivers/usb/usb-core.c.orig   Thu Sep 28 08:44:59 2000
+++ linux/drivers/usb/usb-core.cThu Sep 28 08:47:13 2000
@@ -60,12 +60,6 @@
usb_hub_init();

 #ifndef CONFIG_USB_MODULE
-#ifdef CONFIG_USB_UHCI
-   uhci_init();
-#endif
-#ifdef CONFIG_USB_UHCI_ALT
-   uhci_init();
-#endif
 #ifdef CONFIG_USB_OHCI
ohci_hcd_init();
 #endif

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/