Re: Whats the rvmalloc() story?

[Anton Blanchard]

 
> I note that at least 5 device drivers have similar implementations
> of rvmalloc()/rvfree() et al:
> 
>   ieee1394/video1394.c
>   usb/ibmcam.c
>   usb/ov511.c
>   media/video/bttv-driver.c
>   media/video/cpia.c
> 
> rvmalloc()/rvfree() are functions that are used to allocate large
> amounts of physically non-contiguous kernel virtual memory that will
> then be mmap()'ed into a user process.

I had to rewrite rvmalloc and friends in the bttv driver to support the
new pci dynamic mapping interface. This sounds like a good time to clean
up all these multiple definitions.

Anton
-
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: block ioctl to read/write last sector

[Andre Hedrick]

On Wed, 14 Feb 2001, David Balazic wrote:

> Did you try scsi-emulation on IDE disks ?

Don't be silly.
That emulation is from scsi-packet to atapi-packet.

Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com

-
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: [PROBLEM]: grep hanging with ReiserFS

[Keith Owens]

On Sat, 17 Feb 2001 02:12:40 -0500, 
Shawn Starr <[EMAIL PROTECTED]> wrote:
> grep -r "216.234.235.46" *
>Im using grep in /etc and its just waiting

grep -r follows symlinks and tries to open named pipes.  If you have
qmail installed then /etc/qmail is a symlink to /var/qmail and named
pipe /var/qmail/queue/lock/trigger lives down there.  grep hangs trying
to open the pipe.  Not a reiserfs problem, just a badly designed
application.

-
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: Linux stifles innovation...

[Mike Pontillo]

>
> For example, if there were six different companies that marketed ethernet
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> with different "features" that were of value to you. Instead, you have
> crappy GPL code that locks up under load, and its not worth spending
> corporate dollars to fix it because you have to give away your work for
> free under GPL. And since there is a "free" driver that most people can
> use, its not worth building a better mousetrap either because the market
is
> too small. So, the handful of users with problems get to "fit it
> themselves", most of whom cant of course.
>

 Assuming I am a corporate entity and I need to spend a few bucks to fix
a GPL driver, just because I fix it and deploy my fix on my corporation's
internal network machines -- and quite possibly benefit the hell out of
myself and my company -- that does not mean that I have to release my work
for free under the GPL. Of course, the *nice* thing to do would be to
release it under the GPL even if I was only using the fix internally -- but
I am under no obligation to do that, if, say, I just wanted to keep ahead of
my competitors. Maybe I was planning to wait awhile so I could get ahead in
my market. Maybe I'm just an IP freak and I want to keep my code to myself.
Whatever. My understanding is that the only restrictions I have is that I
can't sell or distribute the darned thing. If, say for example I needed to
fix that driver so that it would work on my new WhizBang 2001 Corporate
Server that is about to hit the market, then I would be making money on the
hardware, and as an added bonus my company looks good because it has an
"open" driver for its server. (no matter that it "had" to under the GPL)

Mike Pontillo


-
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: [PROBLEM]: grep hanging with ReiserFS - More info

[Shawn Starr]

Linux coredump 2.4.2-pre3 #1 Fri Feb 9 20:57:39 EST 2001 i586 unknown
Kernel modules 2.3.21
Gnu C  2.95.2
Gnu Make   3.79.1
Binutils   2.10.1
Linux C Library2.2.1
Dynamic linker ldd (GNU libc) 2.2.1
Procps 2.0.7
Mount  2.10r
Net-tools  1.58
Console-tools  0.2.3
Sh-utils   2.0j
Modules Loaded nls_cp437 vfat fat

Shawn Starr wrote:

>  grep -r "216.234.235.46" *
>
> ...waiting...
>
> ./debugps | more
> USER   PID COMMAND  WCHAN
> root 1 init do_select
> 
> root 7 [kreiserfsd] -
> .
>
> root 28438 grep -r 216.234. pipe_wait
>
> Im using grep in /etc and its just waiting
> it should have finished.
>
> Shawn.
>
> -
> 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/

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

[PROBLEM]: grep hanging with ReiserFS

[Shawn Starr]

 grep -r "216.234.235.46" *


...waiting...

./debugps | more
USER   PID COMMAND  WCHAN
root 1 init do_select

root 7 [kreiserfsd] -
.

root 28438 grep -r 216.234. pipe_wait

Im using grep in /etc and its just waiting
it should have finished.

Shawn.

-
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.1-ac16 - Loopback device seems broken

[Andr=E9]

I don't know if this is broken in 2.4.1-ac17 and
2.4.2-pre4, but, what happens when mounting a filesystem
using the loopback device is that the process 'dies' in some
way and there's no way I can kill it.
This is what I did:
mount /test-ext2-image.img /mnt/testimage -o loop,rw -t ext2
And after that there's no way I can get the process killed...
Please CC replies to this email-address:
[EMAIL PROTECTED]
As I'm not currently subscribed to the linux kernel mailing-list. :-)

Ole AndréFå deg en gratis webmail fra Hesbynett!
http://diamondhead.hesbynett.no

Re: Linux stifles innovation...

[Vesselin Atanasov]

Hahahaha.
Dennis, the only linux network drivers that I have had serious problems
with were yours. They caused kernel panic on 2.0.30+ every 6 hours. Of
course I did not have the source to fix them. In comparision eepro100
works rock solid on all of my machines that use it.

Will I use some binary only drivers again? No thanks!

On Fri, 16 Feb 2001, Dennis wrote:

> At 02:48 PM 02/16/2001, Jesse Pollard wrote:
> >On Fri, 16 Feb 2001, Andrew Scott wrote:
> > >On 15 Feb 2001, at 9:49, fsnchzjr wrote:
> > >
> > >> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> > >> Nice little article on how we're all going to die of herpes from our
> > >> repeated exposition to Linux...
> > >> 
> > http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
> > >> g=ltnc
> > >
> > >That's about as self-serving a statement as I've ever seen. If this
> > >'Jim Alchin' actually believes what he's saying, he's got to be one
> > >of the worlds biggest fools, and if he doesn't believe what he's
> > >saying, well there aren't too many words that would accurately
> > >describe what he is.
> > >
> > >It's pretty funny in some ways, e.g. "We can build a better product
> > >than Linux...", which begs the question, "Well, why don't you?".
> > >Perhaps it costs too much?
> 
> objective, arent we?
> 
> There is much truth to the concept, although Microsoft should not be ones 
> to comment on it as such.
> 
> For example, if there were six different companies that marketed ethernet 
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
> with different "features" that were of value to you. Instead, you have 
> crappy GPL code that locks up under load, and its not worth spending 
> corporate dollars to fix it because you have to give away your work for 
> free under GPL. And since there is a "free" driver that most people can 
> use, its not worth building a better mousetrap either because the market is 
> too small. So, the handful of users with problems get to "fit it 
> themselves", most of whom cant of course.
> 
> Theres also the propensity for mediocre stuff to get into the kernel 
> because some half-baked programmer was willing to contribute some code. The 
> 50% of the kernel that remains "experimental" ad infinitum is evidence of that.
> 
> The biggest thing that the linux community does to stifle innovation is to 
> bash commercial vendors trying to make a profit by whining endlessly about 
> "sourceless" distributions and recommending "open-source" solutions even 
> when they are wholly inferior. You're only hurting yourselves in the long 
> run. In that respect MS is correct, because those with the dollars to 
> innovate will stay away.
> 
> DB
> 
> -
> 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/
> 

-
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: XOR [ was: Linux stifles innovation... ]

[Dan Hollis]

On Fri, 16 Feb 2001, David Relson wrote:
> At 08:52 PM 2/16/01, you wrote:
>  > On Fri, 16 Feb 2001, Michael H. Warfield wrote:
>  > > > You know XOR is patented (yes, the logical bit operation XOR).
>  > >  But wasn't that Xerox that had that?
>  > US Patent #4,197,590 held by NuGraphics, Inc.
> The patent was for using the technique of using XOR for dragging/moving
> parts of a graphics image without erasing other parts.  Also, since the
> patent was granted in 1980, the inventors have had their 17 years of patent
> protection, and we're all free to use the technique - legally!

So you approve of 4,197,590 and think it was an innovative and non obvious
invention in 1980?

-Dan

-
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: XOR [ was: Linux stifles innovation... ]

[David Relson]

At 08:52 PM 2/16/01, you wrote:
 > On Fri, 16 Feb 2001, Michael H. Warfield wrote:
 > > > You know XOR is patented (yes, the logical bit operation XOR).
 > >But wasn't that Xerox that had that?
 >
 > US Patent #4,197,590 held by NuGraphics, Inc.

The patent was for using the technique of using XOR for dragging/moving 
parts of a graphics image without erasing other parts.  Also, since the 
patent was granted in 1980, the inventors have had their 17 years of patent 
protection, and we're all free to use the technique - legally!

David

P.S.  Given that XOR is a basic boolean operation, I don't think the USPTO 
would ever be so dumb as to grant a patent on it.  But, then the PTO has 
shown a creative ability to grant patents to questionable ideas, so who can 
say what they would/could/will do?

-
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: too long mac address for --mac-source netfilter option

[Mr. James W. Laferriere]

Hello Jack & All ,  Might this be an atm interface ?
If it is not then am I to assume that an atm interface
with its erroneous mac-address is going to have the same
difficulties .  That is of course as soon as the atm interface
actually put a valid ESI/mac-address into the interface table .
Tia ,  JimL

On Fri, 16 Feb 2001, Jack Bowling wrote:
>> I am trying to use the --mac-source option in the netfilter code to
>better refine access to my linux box. However, I have run up against
>something. The router through which my private subnet work box passes
>sends a 14-group "invalid" mac address, presumably as an attempt to
>conceal the real hextile mac address. However, the code for the
>--mac-source netfilter option is looking for a valid hextile mac address
>and complains loudly as such (numerals converted to x's):
> iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
> to the respective iptable line:
>> $IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source
>xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT
>> The idea here is to allow VNC access to my home box with the access
>filtered by both IP and mac address.
>> Is there a resolution to this other than a rewrite and recompile of the
>relevant sections of the iptable code? Or am I stuck? I know this option
>is tagged by Rusty as experimental still so I would assume that the code
>is open for feedback ;) The question could be rephrased as: is there any
>chance of allowing "invalid" mac addresses to be recognized by the
>--mac-source option of the netfilter code? Running Redhat v7/kernel
>2.4.1-ac15.

   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

-
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: Linux stifles innovation...

[Augustin Vidovic]

On Fri, Feb 16, 2001 at 05:27:31PM -0500, Dennis wrote:
> For example, if there were six different companies that marketed ethernet 
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
> with different "features" that were of value to you. Instead, you have 
> crappy GPL code that locks up under load, and its not worth spending 

1- GPL code is the opposite of crap
2- in that case, it's not the software, but the hardware which
   was locking up under load

In addition, it would have been impossible to fix the problem if the code
was not GPL.

-- 
Augustin Vidovic   http://www.vidovic.org/augustin/
"Nous sommes tous quelque chose de naissance, musicien ou assassin,
 mais il faut apprendre le maniement de la harpe ou du couteau."
-
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/

"PCI quirks" in kernel for ppc in 2.2

[Mike Fedyk]

Does this help for ppc?

The help talks about BIOS which I know is only on x86.

Does this code include anything that helps a non x86 comp?

Mike
-
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: Linux stifles innovation...

[Werner Almesberger]

Matt D. Robinson wrote:
> Actually I do.  Perhaps I should define enterprise as "big iron".  In
> that way, enterprise kernels would be far more innovative than a
> secure kernel (which cares less about performance gains and large
> features and more about just being "secure").

Hmm, and if you want a secure "big iron" ? Do you then start another
branch merging from both lines, or try to merge all the "enterprise"
enhancements into the "secure" system or vice versa ? If the latter
is easy, why was the split needed in the first place ? If it isn't
easy, will you succeed ? After all, you're facing the integration of
a large portion of code, and you only have a probably small "special
interest" group of people for it.

> In fact, I think
> if some of these vendors created their own kernel trees, it would
> inevitably lead to inclusion of the best features into the primary
> kernel tree.  Where's the harm in that?

Temporary splits or "private" add-ons are not a problem. In fact,
this happens all the time. If there are more fundamental and
permanent splits, I would expect it to become increasingly difficult
to maintain compatibility for components. This should affect drivers
first, then deeper regions of the kernel (e.g. networking, then MM).

Actually, there is a live experiment of this nature going on: with
BSD, you have several specialized lines. I'm not following their
development, but maybe somebody who does could comment on how they
compare in terms of compatibility among themselves, and in terms of
features/drivers with Linux.

Also, code that is supposed to run on multiple platforms easily
degenerates into a wild collection of #ifdefs, or requires the
addition of further abstraction layers. (*) Again, the quality of BSD
drivers (both in readability and efficiency) should be indicative for
whether my assumption is true.

(* Further abstraction layers can sometimes be very efficient, e.g.
   the UP/SMP support in Linux. The hard part is to put them at the
   right place. If your kernels are sufficiently different, you may
   end up with translation modules at fairly deep layers, e.g.
   instead of, say, VFS in all kernels providing the same set of
   functions, you'd translate between VFS variants in your file
   system driver, which is probably less efficient, and much more
   likely to result in bugs.)

In my personal experience, it's already painful enough to maintain
a piece of software that should run in 2.2 and 2.3 kernels, despite
rather good compatibility support.

> And I don't think that convergence happens quickly or efficiently
> enough, despite all the great work Linus and Alan do.

One of the largest obstacles to covergence that I've seen so far is
that some groups isolate their work too much. Rapid convergence is
only possible if all relevant parties understand what's going on, at
least at the point of what happens at interfaces. This means that
large projects should be done openly, with occasional announcements
on linux-kernel. Building that killer subsystem in-house until
perfection is reached, and then submitting a multi-megabyte patch
isn't going to make anybody happy.

- Werner

-- 
  _
 / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
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: Linux stifles innovation...

[Dan Hollis]

On Fri, 16 Feb 2001, Michael H. Warfield wrote:
> > You know XOR is patented (yes, the logical bit operation XOR).
>   But wasn't that Xerox that had that?

US Patent #4,197,590 held by NuGraphics, Inc.

> Yeah, the same ones that screwed us over with the compression patent
> that shot .gif images out of the sky.  There was inovation for you.

That wasn't Xerox. That was Unisys (due to LZW).

-Dan

-
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: kernel 2.4.0/1/1-ac15 and ncr53c810a

[Mr. James W. Laferriere]

Hello Wolfgang & J.A. ,

On Sat, 17 Feb 2001, J . A . Magallon wrote:
> On 02.17 Wolfgang Teichmann wrote:
> > Hello,
> > I have problems using my scanner (HP C6270A connected to ncr53c810a)
> > with xsane.
> > I always get the error message:
> > error during read: Error during device I/O
> > Feb 15 23:57:27 localhost kernel: Attached scsi generic sg2 at scsi0,
> > channel 0, id 4, lun 0, type 3
> Try disabling 'Initiate sync negotitation' in the card BIOS for the ID of
> the scanner.
There is no Bios on an 810/810a .  There is a way to tell the
driver not to 'initiate Sync' & I'd prolly recommend disabling
'disconnect' as well .  UNLESSS you have -any- other device on
the 810's scsi bus .  Please see :
linux/drivers/scsi/EADME.ncr53c8xx
Hth ,  JimL
   ++
   | James   W.   Laferriere | System  Techniques | Give me VMS |
   | NetworkEngineer | 25416  22nd So |  Give me Linux  |
   | [EMAIL PROTECTED] | DesMoines WA 98198 |   only  on  AXP |
   ++

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

too long mac address for --mac-source netfilter option

[Jack Bowling]

I am trying to use the --mac-source option in the netfilter code to better refine 
access to my linux box. However, I have run up against something. The router through 
which my private subnet work box passes sends a 14-group "invalid" mac address, 
presumably as an attempt to conceal the real hextile mac address. However, the code 
for the --mac-source netfilter option is looking for a valid hextile mac address and 
complains loudly as such (numerals converted to x's): 

iptables v1.1.1: Bad mac address `xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'

to the respective iptable line:

$IPT -A INPUT -p tcp -s xxx.xxx.xxx.xxx -d $NET -m mac --mac-source 
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx --dport 5900:5901 -j ACCEPT 

The idea here is to allow VNC access to my home box with the access filtered by both 
IP and mac address.

Is there a resolution to this other than a rewrite and recompile of the relevant 
sections of the iptable code? Or am I stuck? I know this option is tagged by Rusty as 
experimental still so I would assume that the code is open for feedback ;) The 
question could be rephrased as: is there any chance of allowing "invalid" mac 
addresses to be recognized by the --mac-source option of the netfilter code? Running 
Redhat v7/kernel 2.4.1-ac15.

Jack Bowling
mailto: [EMAIL PROTECTED]






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

SO_SNDTIMEO: 2.4 kernel bugs

[Chris Evans]

Hi,

I was glad to see Linux gain SO_SNDTIMEO in kernel 2.4. It is a very use
feature which can avoid complexity and pain in userspace programs.

Unfortunately, it seems to be very buggy. Here are two buggy scenarios.

1)
Create a socketpair(), PF_UNIX, SOCK_STREAM.
Set a 5 second SO_SNDTIMEO on the socket.
write() 100k down the socket in one write(), i.e. enough to cause the
write to have to block.
--> BUG!!! The call blocks indefinitely instead of returning after 5
seconds

(Note that the same test but with SO_RCVTIMEO and a read() works as
expected - I get EAGAIN after 5 seconds).


2)
Create a localhost listening socket - AF_INET, SOCK_STREAM.
Connect to the listening port
Set a 5 second SO_SNDTIMEO on the socket.
write() 1Mb down the socket in one write(), i.e. enough to cause it to
have to block
-> The write() will return after 5 seconds with a partial write count.
GOOD!
Repeat the write() - send another 1Mb.
--> BUG!! The call blocks indefinitely instead of returning with EAGAIN
after 5s.


I hope this is detailled enough. I'm trying to gain access to a FreeBSD
box to compare results..

Cheers
Chris


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

gcc-2.96 and kernel

[J . A . Magallon]

Hi,

(I suppose people track this info, but a remark never hurts...)

Just updated Mandrake gcc to gcc-2.96-0.37mdk. Interesting point:
* Thu Feb 15 2001 David BAUDENS <[EMAIL PROTECTED]> 2.96-0.37mdk

- Fix build on PPC :)

* Thu Feb 15 2001 Chmouel Boudjnah <[EMAIL PROTECTED]> 2.96-0.36mdk

- Break build on PPC ;).
- Red Hat patches, Jakub Jelinek (rel74) 5 new patches :
  - fix last cpp patch so that no whitespace is inserted at start of line
if last macro expansion resulted in no tokens (Neil Booth)
  - fix ICE during printing warning about overloading decisions (#23584)
  - honor no implicit extern "C" on linux in cpp
  - fix layout of __attribute((packed)) enums in bitfields (showing up
in Linux DAC960 driver)
^^^
..

The last thing remaining to recommend 2.96 ? Who knows...

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.1-ac14 #1 SMP Thu Feb 15 16:05:52 CET 2001 i686

-
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: Linux stifles innovation...

[LA Walsh]

"David D.W. Downey" wrote:
> 
> Seriously though folks, look at who's doing this!
> 
> They've already tried once to sue 'Linux', were told they couldn't because
> Linux is a non-entity (or at least one that they can not effectively sue
> due to the classification Linux holds), ...
---
Not having a long memory on these things, do you have an article
or reference on this -- I'd love to read about that one.  Sue Linux?  For
what?  Competing?  

Perhaps by saying Open Source is a threat to the "American Way", they
mean they can't effectively 'sue', buy up or destroy it?  

-l

-- 
L A Walsh| Trust Technology, Core Linux, SGI
[EMAIL PROTECTED]  | Voice: (650) 933-5338
-
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: kernel 2.4.0/1/1-ac15 and ncr53c810a

[J . A . Magallon]

On 02.17 Wolfgang Teichmann wrote:
> Hello,
> 
> I have problems using my scanner (HP C6270A connected to ncr53c810a)
> with xsane.
> 
> I always get the error message:
> 
> error during read: Error during device I/O
> 
> 
> Feb 15 23:57:27 localhost kernel: Attached scsi generic sg2 at scsi0,
> channel 0, id 4, lun 0, type 3

Try disabling 'Initiate sync negotitation' in the card BIOS for the ID of
the scanner.

-- 
J.A. Magallon  $> cd pub
mailto:[EMAIL PROTECTED]  $> more beer

Linux werewolf 2.4.1-ac14 #1 SMP Thu Feb 15 16:05:52 CET 2001 i686

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

IBM-DTLA-307045 very slow under 2.2.x

[Neil Booth]

I have a SOYO "SY-5EMA+ Super 7" motherboard, with a K6-2 processor.
The 45 Gig IBM drive hangs the BIOS if I let it autodetect it, so I
turn off autodetection for IDE2 primary where it sits.  This is probably
not relevant.

My problem is that "hdparm -tT dev/hdc" gives atrocious
performance:-

/dev/hdc:
 Timing buffered disk reads:  64 MB in 22.81 seconds =  2.81 MB/sec

with approximately 25% CPU usage.  By contrast, for /dev/hda it
gives:-

/dev/hda:
 Timing buffered disk reads:  64 MB in 11.49 seconds =  5.57 MB/sec

with 100% CPU, which is still poor, but somewhat better.  The relevant
part of my dmesg is

VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hda: QUANTUM FIREBALL CR13.0A, ATA DISK drive
hdb: CD-ROM 40X/AKU, ATAPI CDROM drive
hdc: IBM-DTLA-307045, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: QUANTUM FIREBALL CR13.0A, 12416MB w/418kB Cache, CHS=1582/255/63
hdc: IBM-DTLA-307045, 43979MB w/1916kB Cache, CHS=5606/255/63
hdb: ATAPI 40X CD-ROM drive, 128kB Cache

hdparm -i /dev/hdc gives:-

Model=IBM-DTLA-307045, FwRev=TX6OA50C, SerialNo=YM0YML23878
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=90069840
IORDY=on/off, tPIO={min:240,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 udma5 

Trying to set the DMA mode with -X34 and -d1 seems to have no effect.

Is this normal, or am I doing something wrong?

Thanks,

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

kernel 2.4.0/1/1-ac15 and ncr53c810a

[Wolfgang Teichmann]

Hello,

I have problems using my scanner (HP C6270A connected to ncr53c810a)
with xsane.

I always get the error message:

error during read: Error during device I/O


Feb 15 23:57:27 localhost kernel: Attached scsi generic sg2 at scsi0,
channel 0, id 4, lun 0, type 3
Feb 15 23:57:27 localhost kernel: ncr53c810a-0-<4,*>: target did not
report SYNC.
Feb 15 23:58:01 localhost kernel: scsi : aborting command due to timeout
: pid 0, scsi0, channel 0, id 4, lun 0 Read (6) 00 00 7b 66 00
Feb 15 23:58:01 localhost kernel: ncr53c8xx_abort: pid=0
serial_number=1099 serial_number_at_timeout=1099
Feb 15 23:58:04 localhost kernel: SCSI host 0 abort (pid 0) timed out -
resetting
Feb 15 23:58:04 localhost kernel: SCSI bus is being reset for host 0
channel 0.
Feb 15 23:58:04 localhost kernel: ncr53c8xx_reset: pid=0 reset_flags=2
serial_number=1099 serial_number_at_timeout=1099
Feb 15 23:58:04 localhost kernel: ncr53c810a-0: restart (scsi reset).

With kernel 2.2.x I have no problems accessing the scanner with xsane.

Any idea?




-
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 TCP(?) timeouts

[Simon Kirby]

On Fri, Feb 16, 2001 at 07:08:05PM -0500, Simon Kirby wrote:

> Hello,
> 
> Today we put 2.4.1 on our mail server after having see it perform well on
> some other boxes.  It seems now we are receiving a few calls every hour
> from customers reporting that the server tends to hang and eventually
> time out on them when downloading mail.  All customers that have reported
> this problem so far are on a didalup connection.  Apparently the server
> will stop transmitting data (or the client seems to think so), and then
> their mail client will time out.

We recorded a trace on the mail server end to one of the customers having
the problem.  At first they closed the connection because their mail
client was set to a timeout of 1 minute, but then when they changed it to
5 seconds, it seemed to limp along further.  It seems to me just like
there's a huge amount of packet loss, but pinging the machine just after
this shows 0% loss (just occasional jumps in response time).

During this trace, when long periods of nothing went by, "netstat -tan
|grep ip" showed nothing abnormal: a 0 byte receive queue and some
data in the send queue equal to what would be retransmitted and
eventually go through two minutes later.

nmap:
Remote operating system guess: Windows 2000 Professional, Build 2128

16:26:14.738836 < client.1104 > mail.pop3: S 1263956200:1263956200(0) win 8760  (DF)
16:26:14.73 > mail.pop3 > client.1104: S 26894293:26894293(0) ack 1263956201 win 
5840  (DF)
16:26:15.014145 < client.1104 > mail.pop3: . 1:1(0) ack 1 win 9112 (DF)
16:26:15.014866 > mail.pop3 > client.1104: P 1:92(91) ack 1 win 5840 (DF)
16:26:15.291998 < client.1104 > mail.pop3: P 1:16(15) ack 92 win 9021 (DF)
16:26:15.292199 > mail.pop3 > client.1104: . 92:92(0) ack 16 win 5840 (DF)
16:26:15.292305 > mail.pop3 > client.1104: P 92:115(23) ack 16 win 5840 (DF)
16:26:16.686295 > mail.pop3 > client.1104: P 92:115(23) ack 16 win 5840 (DF)
16:26:16.954563 < client.1104 > mail.pop3: P 16:30(14) ack 115 win 8998 (DF)
16:26:16.976908 > mail.pop3 > client.1104: P 115:137(22) ack 30 win 5840 (DF)
16:26:19.776322 > mail.pop3 > client.1104: P 115:137(22) ack 30 win 5840 (DF)
16:26:20.033951 < client.1104 > mail.pop3: P 30:36(6) ack 137 win 8976 (DF)
16:26:20.034063 > mail.pop3 > client.1104: P 137:149(12) ack 36 win 5840 (DF)
16:26:25.626301 > mail.pop3 > client.1104: P 137:149(12) ack 36 win 5840 (DF)
16:26:25.922151 < client.1104 > mail.pop3: P 36:42(6) ack 149 win 8964 (DF)
16:26:25.922254 > mail.pop3 > client.1104: P 149:219(70) ack 42 win 5840 (DF)
16:26:36.949499 < client.1104 > mail.pop3: P 36:42(6) ack 149 win 8964 (DF)
16:26:36.949533 > mail.pop3 > client.1104: . 219:219(0) ack 42 win 5840  (DF)
16:26:37.116302 > mail.pop3 > client.1104: P 149:219(70) ack 42 win 5840 (DF)
16:26:37.380554 < client.1104 > mail.pop3: P 42:50(8) ack 219 win 8894 (DF)
16:26:37.380645 > mail.pop3 > client.1104: . 219:219(0) ack 50 win 5840 (DF)
16:26:37.380709 > mail.pop3 > client.1104: P 219:231(12) ack 50 win 5840 (DF)
16:26:59.567440 < client.1104 > mail.pop3: P 42:50(8) ack 219 win 8894 (DF)
16:26:59.567476 > mail.pop3 > client.1104: . 231:231(0) ack 50 win 5840  (DF)
16:26:59.776301 > mail.pop3 > client.1104: P 219:231(12) ack 50 win 5840 (DF)
16:27:00.043125 < client.1104 > mail.pop3: P 50:59(9) ack 231 win 8882 (DF)
16:27:00.043186 > mail.pop3 > client.1104: . 231:231(0) ack 59 win 5840 (DF)
16:27:00.043475 > mail.pop3 > client.1104: . 231:767(536) ack 59 win 5840 (DF)
16:27:00.043491 > mail.pop3 > client.1104: P 767:1220(453) ack 59 win 5840 (DF)
16:27:44.399831 < client.1104 > mail.pop3: P 50:59(9) ack 231 win 8882 (DF)
16:27:44.399869 > mail.pop3 > client.1104: . 1220:1220(0) ack 59 win 5840  (DF)
16:27:44.836304 > mail.pop3 > client.1104: . 231:767(536) ack 59 win 5840 (DF)
16:27:45.295946 < client.1104 > mail.pop3: . 59:59(0) ack 767 win 9112 (DF)
16:27:45.296003 > mail.pop3 > client.1104: P 767:1220(453) ack 59 win 5840 (DF)
16:29:14.886322 > mail.pop3 > client.1104: P 767:1220(453) ack 59 win 5840 (DF)
16:29:15.264417 < client.1104 > mail.pop3: P 59:67(8) ack 1220 win 8659 (DF)
16:29:15.264479 > mail.pop3 > client.1104: . 1220:1220(0) ack 67 win 5840 (DF)
16:29:15.265127 > mail.pop3 > client.1104: . 1220:1756(536) ack 67 win 5840 (DF)
16:29:15.265145 > mail.pop3 > client.1104: . 1756:2292(536) ack 67 win 5840 (DF)
16:30:45.187652 < client.1104 > mail.pop3: P 59:67(8) ack 1220 win 8659 (DF)
16:30:45.187727 > mail.pop3 > client.1104: . 2292:2292(0) ack 67 win 5840  (DF)
16:31:16.326378 > mail.pop3 > client.1104: . 1220:1756(536) ack 67 win 5840 (DF)
16:31:17.513053 < client.1104 > mail.pop3: . 67:67(0) ack 1756 win 9112 (DF)
16:31:17.513129 > mail.pop3 > client.1104: . 1756:2292(536) ack 67 win 5840 (DF)
16:31:17.513143 > mail.pop3 > client.1104: . 2292:2828(536) ack 67 win 5840 (DF)
16:33:17.506376 > mail.pop3 > client.1104: . 1756:2292(536) ack 67 win 5840 (DF)
16:33:17.919146 < client.1104 > mail.pop3: . 67:67(0) ack 2292 win 9112 (DF)
16:33:17.919198 > 

Re: Linux stifles innovation...

[Matt D. Robinson]

Werner Almesberger wrote:
> 
> Matt D. Robinson wrote:
> > My feeling is we should splinter the kernel development for
> > different purposes (enterprise, UP, security, etc.).  I'm sure
> > it isn't a popular view, but I feel it would allow faster progression
> > of kernel functionality and features in the long run.
> 
> "enterprise" XOR security ? I think you understand the problem with
> your approach well ;-)

Actually I do.  Perhaps I should define enterprise as "big iron".  In
that way, enterprise kernels would be far more innovative than a
secure kernel (which cares less about performance gains and large
features and more about just being "secure").  Unless you meant
something else and I'm misinterpreting what you've stated. :)

> Linux scales well from PDAs to large clusters. This is quite an
> achievement. Other operating systems are not able to match this.
> So why do you think that Linux should try to mimic their flaws ?
> Out of pity ?

I always considered SGI's kernels, from the low-end system up to
the large server configurations, to scale well.  Certainly it didn't
work on PDAs. :)  If you consider it a flaw for vendors to be able
to create their own Linux kernels based on optimizations
for their hardware and their customers, then that's a horrible
perspective on overall open source progression.  In fact, I think
if some of these vendors created their own kernel trees, it would
inevitably lead to inclusion of the best features into the primary
kernel tree.  Where's the harm in that?

> BTW, parallel development does happen all the time. The point of
> convergence in a single "mainstream" kernel is that you benefit
> from all the work that's been going on while you did the stuff
> you care most about.

Agreed.  It's great to have a "primary" kernel.  I'd like to see
more splintered kernels (not smaller project efforts), that's all.
And I don't think that convergence happens quickly or efficiently
enough, despite all the great work Linus and Alan do.

> - Werner (having pity with the hungry looking trolls)

--Matt
-
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: Linux stifles innovation...

[Michael H. Warfield]

On Fri, Feb 16, 2001 at 04:35:02PM -0800, Dan Hollis wrote:
> On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote:
> > I did some research on the patent database and found nothing regarding such
> > a patent. There's patent on word processors (not the concept but related to)
> > and uses tab on the description...and that patent is from 1980.

> You know XOR is patented (yes, the logical bit operation XOR).

But wasn't that Xerox that had that?  Yeah, the same ones that
screwed us over with the compression patent that shot .gif images out
of the sky.  There was inovation for you.

> -Dan

Mike
-- 
 Michael H. Warfield|  (770) 985-6132   |  [EMAIL PROTECTED]
  (The Mad Wizard)  |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9  |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471|  possible worlds.  A pessimist is sure of it!

-
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: Linux stifles innovation...

[Dan Hollis]

On Fri, 16 Feb 2001, Carlos Fernandez Sanz wrote:
> I did some research on the patent database and found nothing regarding such
> a patent. There's patent on word processors (not the concept but related to)
> and uses tab on the description...and that patent is from 1980.

You know XOR is patented (yes, the logical bit operation XOR).

-Dan

-
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: "make dep" problem

[Keith Owens]

On Fri, 16 Feb 2001 17:44:27 +0100 (CET), 
Andrzej Krzysztofowicz <[EMAIL PROTECTED]> wrote:
>   While trying to compile 2.4.1-ac1[34] I noticed that the following error
>message appears sometimes:
>
>make[3]: *** No rule to make target 
>/home29/ankry/kernel/2.4/linux/drivers/pci/devlist.h', needed by `names.o'.

The mkdep patch in -ac12 was incorrect, fixed in -ac14.  You probably
need to do make mrproper to get rid of the incorrect file generated by
-ac12.

-
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: Linux stifles innovation...

[Werner Almesberger]

Matt D. Robinson wrote:
> My feeling is we should splinter the kernel development for
> different purposes (enterprise, UP, security, etc.).  I'm sure
> it isn't a popular view, but I feel it would allow faster progression
> of kernel functionality and features in the long run.

"enterprise" XOR security ? I think you understand the problem with
your approach well ;-)

Linux scales well from PDAs to large clusters. This is quite an
achievement. Other operating systems are not able to match this.
So why do you think that Linux should try to mimic their flaws ?
Out of pity ?

BTW, parallel development does happen all the time. The point of
convergence in a single "mainstream" kernel is that you benefit
from all the work that's been going on while you did the stuff
you care most about.

- Werner (having pity with the hungry looking trolls)

-- 
  _
 / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
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: Multiport NICs and ether channel?

[Christopher E. Brown]

On Sat, 17 Feb 2001, Willis L. Sarka wrote:

> Greetings,
> 
> Just a general question or two.. Please point me to a URL or tell me where
> to RTFM, or answer back ;-).
> 
> What is the status/condition of using muliport NICs  and bonding
> them together to form a larger pipe (i.e. a quad channel ethernet card for
> an Intel box, bonding all four interfaces together to get a theoretical
> 400Mbps pipe)?  Are there any highly recommended cards of this type?  Will
> the bonding work when connected to a Cisco catalyst switch with ether
> channel?



Linux bonding is compat with Sun EtherTrunking and Cisco
EtherChannel/FastEtherChannel.


On the Cisco side you follow their setup examples, *except*
you *must* trun keepalives off on the cisco.  These are a Cisco
extension.  If you fail to do this the Cisco will toggle the
onterfaces *off* every 10 - 30 seconds.

 ---
The roaches seem to have survived, but they are not routing packets
correctly.
--About the Internet and nuclear war.


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

Linux 2.4.1ac17

[Alan Cox]

Seems everyone has been busy innovating again, so here is ac17. This merges
2.4.2pre4 which includes more elevator changes so please treat ac17 with
caution.

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

2.4.1-ac17
o   Fix pegasus for bigendian   (Roman Weissgaerber)
o   Further smbfs fixes (Urban Widmark)
o   Update ISDN version tags(Kai Germaschewski)
o   Finish ISDN move to new style module_init   (Kai Germaschewski)
o   Small Eicon driver updates/fix license bug  (Armin Schindler)
o   Fix reiserfs tail packing problem   (Alexander Zarochentcev
 Chris Mason)
o   Export aci symbols from drivers/sound/aci.c (Alexandr Kanevskiy)
o   Merge Linus 2.4.2pre4
o   Starfire update (Ionu Badulescu)
o   Fix 3270 merge  (Richard Hitt)

2.4.1-ac16
o   Fix the exception table/unload race (me)
o   Further tulip fixup (Manfred Spraul)
o   Fix USB oops on traverse/delete race(Randy Dunlap)
o   Set max_sectors to 255 for hd/xd drivers(Paul Gortmaker)
| This should make them work again
o   Fix typo in USB makefile(Arjan van de Ven)
o   Fix accidental change to scsi_scan  (Steve Ralston)
o   Hid rollover/endian fixes   (Paul Mackerras)
o   Drop via pci fixup  (me)
o   Further hp5300 fixups   (Arjan van de Ven)
o   PCnet 32 init changes for non SEPROM cards  (Eli Carter)
o   Fix acpi idle reporting on SMP  (Philipp Hahn)
o   Add non PCI pci device list walk macro  (me)
| pointed out by Mikael Pettersson
o   IBM S/390 3270 drivers  (Richard Hitt)

2.4.1-ac15
o   Fix the non booting winchip/cyrix problem   (me)
| Nasty interaction with the vmalloc fix 
| wants a cleaner solution. This one is a hack
| to get people up and running again
o   Fix typo in vfat changes(OGAWA Hirofumi)
o   Update scsi blacklist table (Karsten Hopp)
o   dscc4 wan driver update (Francois Romieu)
o   Fix clgenfb warning (Bryan Headley)

2.4.1-ac14
o   Fix tulip problems introduced by in ac13(Manfred Spraul)
o   S/390x build fixes  (Ulrich Weigand)
o   Fix off by one error in octagon driver  (David Woodhouse)
o   Fix dasd driver for new queues  (Holger Smolinksi)
o   Networking standards compliance fixes
o   Fix binary layout assumptions in sym53c416  (Arjan van de Ven)
o   tmpfs timestamps(Christoph Rohland)
o   Further mkdep changes   (Keith Owens)
o   Fix 16bit vfat handling (OGAWA Hirofumi)
o   JIS nls fixes   (OGAWA Hirofumi)
o   Handle more than 8 luns (Eric Youngdale,
 Doug Gilbert)
o   Minor scsi clean ups(Eric Youngdale)

2.4.1-ac13
o   Fix pnic tulip problems (Manfred Spraul)
o   Fix USB printer read and poll problems  (Johannes Erdfelt)
o   Fix parport pci list corrupt bug(Tim Waugh)
o   Fix sbpcd driver crashes(Paul Gortmaker)
o   Clarify the locking doc (Rusty Russell)
o   i810 audio doesnt need OSS  (Jeff Garzik)
o   Fix vmalloc fault race  (Mark Hemment)
o   Makedep fixes   (Keith Owens)
o   Fix missing unlock_kernel on usb hub(Paul Mundt)
o   Fix smbfs+bigmem, buffer and listing bugs   (Urban Widmark)
o   Merge tms380 isa token ring support (Jochen Friedrich)
o   Sigmatel change didnt help, removed (Jeff Garzik)

2.4.1-ac12
o   Make tmpfs use link counts of 2 on directories  (Christoph Rohland)
o   Update Documentation/sound/Introductions(Wade Hampton)
o   Fix bug in new tlb shootdown code   (Ben LaHaise)
o   Add isa_* api to the Alpha  (Richard Henderson)
o   Export down_trylock on Alpha(Richard Henderson)
o   Fix maestro3 build on ia64  (Bill Nottingham)

2.4.1-ac11
o   Hack the setup code to do the right thing for   (me)
Cyrix processors. Cpuid on cyrix should now work
o   Change sigmatel codec inits (Jeff 

RE: 2.4.1-ac14 won't boot

[Laramie Leavitt]

>
> 2.4.1-ac8 worked great, 2.4.1-ac13 and ac14 oops
> in IDE initialisation. All 3 have ide.2.4.1-p8.all.01172001.patch
> applied too.  I'll try it without the ide patch today.
>
>
>   -Thomas
>
> ---kernel messages---
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
> idebus=xx
> AMD7409: IDE controller on PCI bus 00 dev 39
>: chipset revision 3
>: not 100% native mode: will probe irqs later
> AMD7409: disabling single-word DMA support (revision < C4)
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
> hda: IBM-DTTA-351010, ATA DISK drive
> hdb: IBM-DTTA-351010, ATA DISK drive
> hdc: WDC AC24300L,  ATA DISK drive
> hdd: ATAPI CDROM, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: status error: status=0x50 { DriveReady SeekComplete }
> hda: no DRQ after issuing WRITE
> hda:19807200 sectors (10141 MB) w/466KiB Cache, CHS=19650/16/63,
> UDMA(33)
> hda:ide_intr: hwgroup->busy was 0 ??
> Inable to handle kernel NULL pointer dereference at virtual address
> 0040
>  printing eip:
> c0192e86
> *pde = 
> Oops: 
> CPU:0
> EIP:0010:[]
> EFLAGS: 00010046
> eax:    ebx: c02cf820   ecx: c1461098   edx: 01f7
> esi: c02cf820   edi: 0282   ebp: c02cf7e0   esp: c145fe28
> ds: 0018   es: 0018   ss: 0018
> Process swaper (pid:1, stackpage=c145f000)
> stack: c02cf820 c1461080 c018fce0 c02cf820 c0192e70 c1449440 0401
> 000e
>c145fe90 c010a349 000e c1461080 c145fe90 c145fe90 000e
> c029fc80
>c1449440 c010a4b8 000e c145fe90 c1449440 0380 0212
> c029fc80
> Call Trace: [] [] [] []
> [] [] []
>[] [] [] [] []
> [] [] []
>[] []
>
> Code: 8b 58 40 ec e6 80 0f b6 c8 fb 89 c8 24 c9 3c 40 74 18 0f b6
> Kernel panic: Aiee, killing interrupt handler!
> In interrupt handler - not syncing
> spurious 8259A interrupt: IRQ7.

I have had a similar oops on my MSI-694D, but not always.  I think that mine
happens in the Promise FastTrack Lite driver (pdc...).  But since I have a
dual processor, the oops is interlaced with the other processor's boot
messages.  About the only thing that I can get from it is the following.

(painstakingly copied by hand.  I know, not run through ksymoops...)

E Flags 00010246
esp: c123ffb0
Call Trace: [][][]

I think that the change that caused mine is changing the Promise
driver to do a mdelay where it was doing that odd stuff.

But it boots more often than not, so I have ignored it.
Laramie

-
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: CONFIG_MODVERSIONS and same named files

[Keith Owens]

On Fri, 16 Feb 2001 08:19:28 -0700, 
Tom Rini <[EMAIL PROTECTED]> wrote:
>Hey all.  The modversions code has a slight problem with files of the same
>name, but in different directories.  eg: drivers/a/foo.c exports FOO, and
>drivers/b/foo.c exports BAR, include/linux/modules/foo.ver will only have the
>information about drivers/b/foo.c.  Anyone got an idea on how to fix this?

Files that export symbols must have unique names.  Which is why we have
abominations like this.

fs/msdos/msdosfs_syms.c
fs/proc/procfs_syms.c
fs/fat/fatfs_syms.c
fs/vfat/vfatfs_syms.c
fs/lockd/lockd_syms.c
kernel/ksyms.c
net/netsyms.c
net/sunrpc/sunrpc_syms.c
net/irda/irsyms.c

Module symbol versions is being completely redesigned for 2.5 and will
not have this problem.  In the meantime create a unique filename for
anything that exports symbols.

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

Multiport NICs and ether channel?

[Willis L. Sarka]

Greetings,

Just a general question or two.. Please point me to a URL or tell me where
to RTFM, or answer back ;-).

What is the status/condition of using muliport NICs  and bonding
them together to form a larger pipe (i.e. a quad channel ethernet card for
an Intel box, bonding all four interfaces together to get a theoretical
400Mbps pipe)?  Are there any highly recommended cards of this type?  Will
the bonding work when connected to a Cisco catalyst switch with ether
channel?

Again, thanks in advance.  If you need any further info, or if I need to
describe something in greater detail please let me know.

Cheers,
Will Sarka

-- 
-
Those, who would give up essential liberty to
purchase a little temporary safety, deserve
neither liberty nor safety.

-Ben Franklin
Historical Review of Constitution and
Government of Pennsylvania
-

-
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: Linux stifles innovation...

[rjd]

Dennis wrote:
...
> objective, arent we?
Nope. Are you claiming to be?

> For example, if there were six different companies that marketed ethernet 
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
... Rant deleted

I had a problem with eepro100.
It was fixed same night cause I had the source.
Don't even try to compare with MickyS**t.

> The biggest thing that the linux community does to stifle innovation is to 
> bash commercial vendors trying to make a profit by whining endlessly about 
> "sourceless" distributions and recommending "open-source" solutions even 
> when they are wholly inferior. You're only hurting yourselves in the long 
> run. In that respect MS is correct, because those with the dollars to 
> innovate will stay away.

When companys with less than a dozen people think it's worth while paying
someone like me to develop code exclusivly for Linux we've got to have a
chance. Source to binary ratio is probably 70/30 mainly because of code
tied up in previous companys but they are trying.

The project they're funding now is more like 90% GPL. Of course I could be
producing crap code. 20 years kernel hacking and a cybernetics degree can't
mean as much as being an MSCE.


ps. This is definately a message from home and a bottom of a glass of whisky.
-- 
Bob Dunlop  [EMAIL PROTECTED]
-
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: Linux stifles innovation...

[Matt D. Robinson]

"Mike A. Harris" wrote:
> On Fri, 16 Feb 2001, Matt D. Robinson wrote:
> 
> >The day the Linux kernel splinters into multiple, distinct efforts is the
> >day I'll believe the kernel is fully into progress over "preference".  Right
> >now, Alan accepts what he thinks should go into stable kernels, and Linus
> >accepts what he thinks should go into future kernels.  I'm not saying they
> >aren't doing the right things, or that the system doesn't work, but it's
> >hardly what I would call a progressive movement.  It's simply long,
> >drawn-out evolution at best.
> >
> >I'm surprised the major vendors haven't created their own consortium
> >by now to create a Linux kernel they think is best suited for their own
> >hardware.  But then again, they probably still spend all their time worrying
> >about whether their efforts will be "accepted" into the mainstream Linux
> >kernel.  Now _that's_ what I consider to be stifling innovation and
> >progression.
> >
> >Kind of off-topic, but whatever ...
> 
> Basically it boils down to this.. By continuing this thread here,
> I'm preaching to the choir, and I'd rather not waste my time on
> those with no clue of the open source movement.  The other
> alterative is to stick up for open source, and debate you until
> I'm blue in the face - and you wont change your mind anyways,
> and considering you're the minority here.. who cares?
> 
> Thread == dead.

Mike, next time, read someone's post before responding, okay?
If you think I don't care about open source, perhaps you weren't
paying enough attention.  I'd like to see open source evolve even
faster than it does now.  If you somehow missed that, then go back
and read what I wrote again.  And I'm sure you can find much
more positive ways to defend open source than responding in the
way you just did -- your tone projects the kind of animosity that
causes these closed vs. open source debates in the first place.

My feeling is we should splinter the kernel development for
different purposes (enterprise, UP, security, etc.).  I'm sure
it isn't a popular view, but I feel it would allow faster progression
of kernel functionality and features in the long run.  And that's
simply a different view than you have.  It's certainly not one
that is against the open source movement (as you've implied).

--Matt (http://oss.sgi.com/projects/lkcd)
-
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 TCP(?) timeouts

[Simon Kirby]

Hello,

Today we put 2.4.1 on our mail server after having see it perform well on
some other boxes.  It seems now we are receiving a few calls every hour
from customers reporting that the server tends to hang and eventually
time out on them when downloading mail.  All customers that have reported
this problem so far are on a didalup connection.  Apparently the server
will stop transmitting data (or the client seems to think so), and then
their mail client will time out.

I noticed that the 2.4.1 on my desktop seems to time out SSH connections
to servers that have become unreachable in about 10 seconds or so, which
is many times faster than 2.2 which used to sit for hours before it timed
out (if it all).  I'm not sure if this is related.  I would expect the
client to attempt to retransmit some ACKs and eventually get some RSTs
back if this were the case.

Has anybody seen similar problems?  The box was previously running
2.2.19pre8 and no customers reported such problems.

We're using cucipop w/ldap on a dual PIII 800 MHz box with 1.5 GB of RAM.

Simon-

[  Stormix Technologies Inc.  ][  NetNation Communications Inc. ]
[   [EMAIL PROTECTED]   ][   [EMAIL PROTECTED]]
[ Opinions expressed are not necessarily those of my employers. ]
-
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: Linux stifles innovation...

[Carlos Fernandez Sanz]

I did some research on the patent database and found nothing regarding such
a patent. There's patent on word processors (not the concept but related to)
and uses tab on the description...and that patent is from 1980.

- Original Message -
From: "James Sutherland" <[EMAIL PROTECTED]>
To: "David D.W. Downey" <[EMAIL PROTECTED]>
Cc: "Rik van Riel" <[EMAIL PROTECTED]>; "Alan Olsen"
<[EMAIL PROTECTED]>; "Mark Haney" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, February 16, 2001 15:18
Subject: RE: Linux stifles innovation...


> On Fri, 16 Feb 2001, David D.W. Downey wrote:
>
> > Would someone tell me where you get all this lovely information on
> > patents held by M$? I can't find anything.
>
> Sorry, it's *IBM* who are said to hold a patent on the tab key.
>
> Legend has it Microsoft once found a patent of theirs which IBM appeared
> to have infringed, and were very excited at the possibility of something
> to hold over IBM, so their lawyers met IBM's lawyers. The MS lawyers
> beamed "look at our patent you've infringed!" IBM's lawyers replied "look
> at this pile of our patents YOU'VE infringed... let's start with this
> one. A Tab key." MS suddenly realised they were outlawyered...
>
> No idea how accurate it is, but just the thought of MS's lawyers getting a
> nasty shock like that has a certain appeal :-)
>
>
> James.
>
> -
> 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/
>

-
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: Linux stifles innovation...

[Alan Olsen]

On Fri, 16 Feb 2001, Dennis wrote:

> objective, arent we?

Pot. Kettle. Black.

> There is much truth to the concept, although Microsoft should not be ones 
> to comment on it as such.

What truth?  I have seen more "innovation" in the Open Source movement
than I ever have in my 18+ years of being a professional programmer.

I don't see how having the source open removes "intelectual property",
except by showing that huge portions of the concept are flawed.

> For example, if there were six different companies that marketed ethernet 
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
> with different "features" that were of value to you. Instead, you have 
> crappy GPL code that locks up under load, and its not worth spending 
> corporate dollars to fix it because you have to give away your work for 
> free under GPL. And since there is a "free" driver that most people can 
> use, its not worth building a better mousetrap either because the market is 
> too small. So, the handful of users with problems get to "fit it 
> themselves", most of whom cant of course.

Strange.  I have not heard of any problems with that driver, except for
issues where the original hardware vendor kept implimentation details from
the open source community.  (Citeing "IP issues".)

> Theres also the propensity for mediocre stuff to get into the kernel 
> because some half-baked programmer was willing to contribute some code. The 
> 50% of the kernel that remains "experimental" ad infinitum is evidence of that.

You must be looking at a different kernel.

I have seen little in the kernel that was "half baked".  There have been
some things put in to test if they were good ideas.  That is far different
than half-baked.  Most of the bad ideas never get to the kernel.  Linus or
Alan kick them out before they ever get that far.

> The biggest thing that the linux community does to stifle innovation is to 
> bash commercial vendors trying to make a profit by whining endlessly about 
> "sourceless" distributions and recommending "open-source" solutions even 
> when they are wholly inferior. You're only hurting yourselves in the long 
> run. In that respect MS is correct, because those with the dollars to 
> innovate will stay away.

You claim that "open source solutions are wholely inferior to closed
source solutions".

H... 

Then why does everyone run with Apache instead of IIS?  Could it be that
IIS is a piece of crap?

Feature for feature I would rather use PHP 4 over ColdFusion any day.

Sendmail is MUCH more stable than Exchange.  (Even if it has config files
that look like they were designed by Carlos Castanada on a bad day.) If
not Sendmail, there are a couple of other Open Source mail programs that
are much superior in quality than the closed source counterparts.

As for the Linux kernel being "shoddy"...  

Since when?

I can leave my Linux box running over night and actually have it do
things!  I cannot say the same for Windows.  I leave that running (same
hardware, different OS) and it is usually dead by dawn.

But your argument is even more bogus than that.

It seems that you argument boils down to a couple of thing...

"Closed source is better because you pay money for it."  

"Closed source is superior because we have a company name and you don't."

Sorry, but most of the people who develop Open Source are profesional
programmers.  They just have a different motivation.  

Open Source is motivated by pride in what you can do and a desire to help
others by sharing that. They don't hide behind a wall of lawyers to keep
people from finding out what they did wrong.

I found out a long time ago that most "Trade Secret" claims were bogus.
It was either a common technique that had been adapted to a particular
purpose or it was being used as an excuse to hide how bad the code really
was.

But my experiences with Open Source, as well as the others I know who use
it are quite telling.

If I have a problem with an Open Source program I can look at the code and
fix it.  Or I can report the bug and it will get fixed soon after. The
programmers involved put the effort into it because their name is
attached.

My experiences with closed source companies are not as good.

In many cases, I was ignored because I did not represent a fortune 500
company.  If the problem got fixed at all, it would be months before I saw
it and usually in a later release that I would have to pay for.  (Usually
having features added that I neither wanted or would ever use.)  In some
cases (like Microsoft security bugs) it would be treated like a public
relations problem instead of a software and quality issue.

I have also seen cases where problems were buried in development because
"no one will find out and if they do, we will just blame Microsoft".

I understand your desire to make money off what you do for a living. I do
object to you taring what I do as somehow damaging to the software
industry as a whole.  (Especially since 

Re: Linux stifles innovation...

[Mike A. Harris]

On Fri, 16 Feb 2001, Matt D. Robinson wrote:

>The day the Linux kernel splinters into multiple, distinct efforts is the
>day I'll believe the kernel is fully into progress over "preference".  Right
>now, Alan accepts what he thinks should go into stable kernels, and Linus
>accepts what he thinks should go into future kernels.  I'm not saying they
>aren't doing the right things, or that the system doesn't work, but it's
>hardly what I would call a progressive movement.  It's simply long,
>drawn-out evolution at best.
>
>I'm surprised the major vendors haven't created their own consortium
>by now to create a Linux kernel they think is best suited for their own
>hardware.  But then again, they probably still spend all their time worrying
>about whether their efforts will be "accepted" into the mainstream Linux
>kernel.  Now _that's_ what I consider to be stifling innovation and
>progression.
>
>Kind of off-topic, but whatever ...

Basically it boils down to this.. By continuing this thread here,
I'm preaching to the choir, and I'd rather not waste my time on
those with no clue of the open source movement.  The other
alterative is to stick up for open source, and debate you until
I'm blue in the face - and you wont change your mind anyways,
and considering you're the minority here.. who cares?

Thread == dead.

--
Mike A. Harris  -  Linux advocate  -  Free Software advocate
  This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
--
Red Hat Linux:  http://www.redhat.com
Download for free:  ftp://ftp.redhat.com/pub/redhat/redhat-6.2/

-
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: Linux stifles innovation...

[Matt D. Robinson]

The day the Linux kernel splinters into multiple, distinct efforts is the
day I'll believe the kernel is fully into progress over "preference".  Right
now, Alan accepts what he thinks should go into stable kernels, and Linus
accepts what he thinks should go into future kernels.  I'm not saying they
aren't doing the right things, or that the system doesn't work, but it's
hardly what I would call a progressive movement.  It's simply long,
drawn-out evolution at best.

I'm surprised the major vendors haven't created their own consortium
by now to create a Linux kernel they think is best suited for their own
hardware.  But then again, they probably still spend all their time worrying
about whether their efforts will be "accepted" into the mainstream Linux
kernel.  Now _that's_ what I consider to be stifling innovation and
progression.

Kind of off-topic, but whatever ...

--Matt

"Mike A. Harris" wrote:
> On Fri, 16 Feb 2001, Dennis wrote:
> 
> >The biggest thing that the linux community does to stifle innovation is to
> >bash commercial vendors trying to make a profit by whining endlessly about
> >"sourceless" distributions and recommending "open-source" solutions even
> >when they are wholly inferior. You're only hurting yourselves in the long
> >run. In that respect MS is correct, because those with the dollars to
> >innovate will stay away.
> 
> Try telling that to IBM, Intel, Compaq, Hewlett Packard, Dell,
> SGI, and a handful of other _major_ computer companies that now
> realize the importance of open source.
> 
> Seriously, get a copy of Eric S. Raymond's book, "The Cathedral
> and the Bazaar" (or view it online at http://www.opensource.org),
> and read through it.  It is very well written and covers all
> aspects of what you are fearing - in a positive way.
> 
> Linux is one of the most stable operating systems ever written.
> That's not just advocacy, that is fact.  Drivers marked
> experimental are not just experimental - some are, but a lot are
> not, they just have not had anyone send in loud positive
> feedback, and so the maintainers left them that way.
> 
> If you think the various crud commercial OS's out there are
> stable and have no experimental code in them, and that drivers do
> not crash or have bugs, you haven't been computing for long.
> 
> At any rate, nobody has a gun to your head - go use something
> else that works for you.
-
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: Linux stifles innovation...

[Hristo Doichev]

On the surface you seem to make some good points.
In reality ... ?? 
Money doesn't buy the ability to innovate!
OSS doesn't, magically, enhance the ability to innovate, aither!
No one can predict where and why an innovation occurs.

The only thing that OSS does to MS is to prohibit them for capitalizing
on ideas that are born within the OSS community. This must hurt them (MS)
since there are a lot of cool ideas they (MS) would like to snatch. Just take
a look at the list of companies acquired by MS. Considering the amount of 
money MS puts into software R there should be nothing left for the rest of 
the world to discover or invent?! :-0 
If anything, MS is the prime example of immature and unreliable code 
(applications). Money doesn't even guarantee stability and usability of your
applications. Perhaps you are one of those rare souls that has absolutely 
no problems with MS products which, mind you, up until now were not 
experimental. On the other hand Windows XP stands, obviously, for Windows 
eXPeriment. 

Innovations by hackers that developed KDE and Gnome can change the way you 
use your computer. For instance, have you been to www.eazel.com? While
Nautilus is of no interest to me you can run an entire Linux Desktop over the 
internet by just using your browser. Try the demo ... pull up a console and 
fire off some commands, try GnuCash or something 
It is super cool and it is great technology that comes for free with just 
about all Linux distributions. I bet MS would like to be able to do the same 
...

regards.
Hristo Doichev



On Friday 16 February 2001 14:27, Dennis wrote:
> At 02:48 PM 02/16/2001, Jesse Pollard wrote:
> >On Fri, 16 Feb 2001, Andrew Scott wrote:
> > >On 15 Feb 2001, at 9:49, fsnchzjr wrote:
> > >> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> > >> Nice little article on how we're all going to die of herpes from our
> > >> repeated exposition to Linux...
> >
> > http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html
> >?ta
> >
> > >> g=ltnc
> > >
> > >That's about as self-serving a statement as I've ever seen. If this
> > >'Jim Alchin' actually believes what he's saying, he's got to be one
> > >of the worlds biggest fools, and if he doesn't believe what he's
> > >saying, well there aren't too many words that would accurately
> > >describe what he is.
> > >
> > >It's pretty funny in some ways, e.g. "We can build a better product
> > >than Linux...", which begs the question, "Well, why don't you?".
> > >Perhaps it costs too much?
>
> objective, arent we?
>
> There is much truth to the concept, although Microsoft should not be ones
> to comment on it as such.
>
> For example, if there were six different companies that marketed ethernet
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> with different "features" that were of value to you. Instead, you have
> crappy GPL code that locks up under load, and its not worth spending
> corporate dollars to fix it because you have to give away your work for
> free under GPL. And since there is a "free" driver that most people can
> use, its not worth building a better mousetrap either because the market is
> too small. So, the handful of users with problems get to "fit it
> themselves", most of whom cant of course.
>
> Theres also the propensity for mediocre stuff to get into the kernel
> because some half-baked programmer was willing to contribute some code. The
> 50% of the kernel that remains "experimental" ad infinitum is evidence of
> that.
>
> The biggest thing that the linux community does to stifle innovation is to
> bash commercial vendors trying to make a profit by whining endlessly about
> "sourceless" distributions and recommending "open-source" solutions even
> when they are wholly inferior. You're only hurting yourselves in the long
> run. In that respect MS is correct, because those with the dollars to
> innovate will stay away.
>
> DB
>
> -
> 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/
-
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: Linux stifles innovation...

[Mike A. Harris]

On Fri, 16 Feb 2001, Dennis wrote:

>The biggest thing that the linux community does to stifle innovation is to
>bash commercial vendors trying to make a profit by whining endlessly about
>"sourceless" distributions and recommending "open-source" solutions even
>when they are wholly inferior. You're only hurting yourselves in the long
>run. In that respect MS is correct, because those with the dollars to
>innovate will stay away.

Try telling that to IBM, Intel, Compaq, Hewlett Packard, Dell,
SGI, and a handful of other _major_ computer companies that now
realize the importance of open source.

Seriously, get a copy of Eric S. Raymond's book, "The Cathedral
and the Bazaar" (or view it online at http://www.opensource.org),
and read through it.  It is very well written and covers all
aspects of what you are fearing - in a positive way.

Linux is one of the most stable operating systems ever written.
That's not just advocacy, that is fact.  Drivers marked
experimental are not just experimental - some are, but a lot are
not, they just have not had anyone send in loud positive
feedback, and so the maintainers left them that way.

If you think the various crud commercial OS's out there are
stable and have no experimental code in them, and that drivers do
not crash or have bugs, you haven't been computing for long.

At any rate, nobody has a gun to your head - go use something
else that works for you.

--
Mike A. Harris  -  Linux advocate  -  Free Software advocate
  This message is copyright 2001, all rights reserved.
  Views expressed are my own, not necessarily shared by my employer.
--
Press every key to continue.

-
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: Linux stifles innovation... [way O.T.]

[John Cavan]

Dennis wrote:
> objective, arent we?

You might ask yourself the same question...

> For example, if there were six different companies that marketed ethernet
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> with different "features" that were of value to you. Instead, you have
> crappy GPL code that locks up under load, and its not worth spending
> corporate dollars to fix it because you have to give away your work for
> free under GPL. And since there is a "free" driver that most people can
> use, its not worth building a better mousetrap either because the market is
> too small. So, the handful of users with problems get to "fit it
> themselves", most of whom cant of course.

A large bulk of the investment in Linux is starting to come in from
hardware manufacturers, notably IBM. These companies see Linux as a
means to sell more hardware, not as a means to sell software. This is
critical, because it means that it IS worth the money to make the driver
perform correctly, GPL or not, because a bad driver means no sales.

You can't argue from the standpoint of "small market" and then the
destruction of the market itself. By definition, in order for the
software market to be significantly damaged, Linux (and other open
source projects) would have to hold more than a small percentage of the
market. Hence, your market just got big and if you make hardware, you
better make a good driver.

[snip general name calling and other sorts of bashing - remember,
objective?]

John
-
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: PROBLEM: virtual console corruption (2.4.1/p4/radeon/XFree86

[James Simmons]

>I believe you, although... why doesn't it happen with 2.2.17? vconsole
>buffers in a different place in memory, I suppose?

Vgacon has pretty much not changed. As for going from graphics mode and
back it is quite complex and the X server handles all of it.

-
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: Linux stifles innovation...

[David D.W. Downey]

ROTFL, man this guy is funny.



On Fri, 16 Feb 2001, Dennis wrote:

> At 02:48 PM 02/16/2001, Jesse Pollard wrote:
> >On Fri, 16 Feb 2001, Andrew Scott wrote:
> > >On 15 Feb 2001, at 9:49, fsnchzjr wrote:
> > >
> > >> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> > >> Nice little article on how we're all going to die of herpes from our
> > >> repeated exposition to Linux...
> > >>
> > http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
> > >> g=ltnc
> > >
> > >That's about as self-serving a statement as I've ever seen. If this
> > >'Jim Alchin' actually believes what he's saying, he's got to be one
> > >of the worlds biggest fools, and if he doesn't believe what he's
> > >saying, well there aren't too many words that would accurately
> > >describe what he is.
> > >
> > >It's pretty funny in some ways, e.g. "We can build a better product
> > >than Linux...", which begs the question, "Well, why don't you?".
> > >Perhaps it costs too much?
>
> objective, arent we?
>
> There is much truth to the concept, although Microsoft should not be ones
> to comment on it as such.
>
> For example, if there were six different companies that marketed ethernet
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps
> with different "features" that were of value to you. Instead, you have
> crappy GPL code that locks up under load, and its not worth spending
> corporate dollars to fix it because you have to give away your work for
> free under GPL. And since there is a "free" driver that most people can
> use, its not worth building a better mousetrap either because the market is
> too small. So, the handful of users with problems get to "fit it
> themselves", most of whom cant of course.
>
> Theres also the propensity for mediocre stuff to get into the kernel
> because some half-baked programmer was willing to contribute some code. The
> 50% of the kernel that remains "experimental" ad infinitum is evidence of that.
>
> The biggest thing that the linux community does to stifle innovation is to
> bash commercial vendors trying to make a profit by whining endlessly about
> "sourceless" distributions and recommending "open-source" solutions even
> when they are wholly inferior. You're only hurting yourselves in the long
> run. In that respect MS is correct, because those with the dollars to
> innovate will stay away.
>
> DB
>
> -
> 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/
>

-- 
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation - Sunnyvale, CA

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

Assistance in understanding this...?

[Tracy Camp]

I'm developing a driver that performs some 'formatting' of sorts on a scsi
block device as part of the initialization process.  This involves
writting a long series of non-contiguous blocks to a disk device -
something akin to:

for(i =0; i < NUM_BLOCKS; i++) {
bh = getblk(i * offset_size);
memcpy(bh->b_data,,sizeof(struct somestruct));
mark_buffer_dirty(bh);
ll_rw_block(bh, WRITE,1);
wait_on_buffer(bh);
brelse(bh);
}

the kernel here I should mention is stock 2.4.0

This all works fine it seems, except that after awhile the system becomes
very fragile and eventually panic's with a NULL pointer derefrence.  This
presumeably occurs because of a resource shortage.  Thing I'm not
understand is how doing the above even for a large value of NUM_BLOCKS
creates a resource shortage.  I'm obviously missing something here

This is typically triggered by running any external program, (ie. vi, top,
or gcc seem to work fine for this). and the only noticable thing is that
the memory allocated to buffers grows to be pretty much all memory except
for the last two megs - this seems normal?  I can capture some of the
panic/dumps if anyone thinks they might be of interest.  

Ideas?

t.

Tracy Camp
Product Development
Miralink Corp.PDX
Portland OR
503-223-3140

-
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: Linux stifles innovation...

[Neal Dias]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It's not about facts, it's not about the truth, it's not about Jim
Allchin being an idiot or deluded. It's about propaganda,
misinformation, and marketing. It's about business. Nothing new, nor
unexpected. And to the comment "It is not American to steal", well,
it may not be "American", but it's for sure been part of the way of
doing business in this country for years. It's not right, it's not
ideal, but it IS the way it's done in too many cases. 

Neal Dias
UNIX Systems Administrator, Sunglass Hut International, MIS Dept.
office: (305) 648-6479  wk. email:[EMAIL PROTECTED]
mobile: (786) 368-5742  pvt. email:[EMAIL PROTECTED]
**
Whoever fights monsters should see to it that in the process he does
not become a monster. And when you look into an abyss, the abyss also
looks into you. -Nietzsche

Any opinions expressed above or below are entirely my own and may not
reflect those of my employers. The information contained in this
e-mail message is confidential, intended only for the receipt and use
of the individual(s) or entity(s) named above. If the reader of this
email message is not the intended recipient, or the employee or agent
responsible for its delivery to the intended and or addressed
recipient, you are hereby notified that any review, dissemination,
distribution or copying of this communication is strictly prohibited
except at the express consent of its author.

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.8 for non-commercial use 

iQA/AwUBOo3VDsUVRGLQ1PaaEQKnWwCcCb+J3BbV/AQLCB20mzLn/1e8HmkAoK+u
zXoDl5pPc5Z1uihfhOMrQy+I
=wE+Z
-END PGP SIGNATURE-

-
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: Linux stifles innovation...

[Dan Hollis]

On Fri, 16 Feb 2001, Dennis wrote:
> The biggest thing that the linux community does to stifle innovation is to
> bash commercial vendors trying to make a profit by whining endlessly about
> "sourceless" distributions and recommending "open-source" solutions even
> when they are wholly inferior. You're only hurting yourselves in the long
> run. In that respect MS is correct, because those with the dollars to
> innovate will stay away.

So I take it you support M$ on the legislation bit also...

-Dan

-
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: Linux stifles innovation...

[Alan Cox]

> For example, if there were six different companies that marketed ethernet 
> drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
> with different "features" that were of value to you. Instead, you have 
> crappy GPL code that locks up under load, and its not worth spending 

Umm I find the driver very reliable. And actually I have choice of two
eepro100 drivers eepro100.c and e100.c so you cant even pick an example.

Of course your keenness to let people write alternative free drivers for
your etinc pci card is extremely well known. Fortunately despite your best
efforts there is now a choice in 2.4

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

[PATCH] starfire patch for 2.4.1-ac15

[Ion Badulescu]

Hi Alan,

This patch makes the 2.4 starfire driver essentially identical to the
version you added to 2.2.19pre. In addition, it also includes Manfred
Spraul's fixes (for problems which, although real, are very unlikely to
matter in real life).

Please apply.

Thanks,
Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.


--- /mnt/3/linux-2.4-ac/MAINTAINERS Thu Feb 15 17:21:38 2001
+++ linux-2.4/MAINTAINERS   Wed Feb  7 17:38:50 2001
@@ -1200,6 +1166,11 @@
 W: http://www.stallion.com
 S: Supported
 
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
 STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
 W: http://mosquitonet.Stanford.EDU/strip.html
 S: Unsupported ?
--- /mnt/3/linux-2.4-ac/Documentation/Configure.helpThu Feb 15 17:21:37 2001
+++ linux-2.4/Documentation/Configure.help  Thu Feb 15 16:57:01 2001
@@ -8754,7 +8491,7 @@
   If you want to compile this driver as a module ( = code which can be
   inserted in and removed from the running kernel whenever you want),
   say M here and read Documentation/modules.txt. This is recommended.
-  The module will be called starfile.o.
+  The module will be called starfire.o.
   
 Alteon AceNIC/3Com 3C985/NetGear GA620 Gigabit support
 CONFIG_ACENIC
--- /mnt/3/linux-2.4-ac/drivers/net/starfire.c  Thu Feb 15 17:22:15 2001
+++ linux-2.4/drivers/net/starfire.cFri Feb 16 12:54:32 2001
@@ -20,7 +20,7 @@
---
 
Linux kernel-specific changes:
-   
+
LK1.1.1 (jgarzik):
- Use PCI driver interface
- Fix MOD_xxx races
@@ -31,9 +31,30 @@
 
LK1.1.3 (Andrew Morton)
- Timer cleanups
-   
+
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
+
+   LK1.2.1 (Ion Badulescu <[EMAIL PROTECTED]>)
+   - Support hardware Rx/Tx checksumming
+   - Use the GFP firmware taken from Adaptec's Netware driver
+
+   LK1.2.2 (Ion Badulescu)
+   - Backported to 2.2.x
+
+   LK1.2.3 (Ion Badulescu)
+   - Fix the flaky mdio interface
+   - More compat clean-ups
+
+   LK1.2.4 (Ion Badulescu)
+   - More 2.2.x initialization fixes
+
+   LK1.2.5 (Ion Badulescu)
+   - Several fixes from Manfred Spraul
+
+TODO:
+   - implement tx_timeout() properly
+   - support ethtool
 */
 
 /* These identify the driver base version and may not be removed. */
@@ -43,11 +64,32 @@
 " Updates and info at http://www.scyld.com/network/starfire.html\n";
 
 static const char version3[] =
-" (unofficial 2.4.x kernel port, version 1.1.4, August 10, 2000)\n";
+" (unofficial 2.4.x kernel port, version 1.2.5, February 15, 2001)\n";
 
 /* The user-configurable values.
These may be modified when a driver module is loaded.*/
 
+/*
+ * Adaptec's license for their Novell drivers (which is where I got the
+ * firmware files) does not allow to redistribute them. Thus, we can't
+ * include them with this driver.
+ *
+ * However, an end-user is allowed to download and use them, after
+ * converting them to C header files using starfire_firmware.pl.
+ * Once that's done, the #undef must be changed into a #define
+ * for this driver to really use the firmware. Note that Rx/Tx
+ * hardware TCP checksumming is not possible without the firmware.
+ *
+ * I'm currently [Feb 2001] talking to Adaptec about this redistribution
+ * issue. Stay tuned...
+ */
+#undef HAS_FIRMWARE
+/*
+ * The current frame processor firmware fails to checksum a fragment
+ * of length 1. If and when this is fixed, the #define below can be removed.
+ */
+#define HAS_BROKEN_FIRMWARE
+
 /* Used for tuning interrupt latency vs. overhead. */
 static int interrupt_mitigation = 0x0;
 
@@ -55,12 +97,27 @@
 static int max_interrupt_work = 20;
 static int mtu = 0;
 /* Maximum number of multicast addresses to filter (vs. rx-all-multicast).
-   The Starfire has a 512 element hash table based on the Ethernet CRC.  */
+   The Starfire has a 512 element hash table based on the Ethernet CRC. */
 static int multicast_filter_limit = 32;
 
-/* Set the copy breakpoint for the copy-only-tiny-frames scheme.
-   Setting to > 1518 effectively disables this feature. */
+#define PKT_BUF_SZ 1536/* Size of each temporary Rx buffer.*/
+/*
+ * Set the copy breakpoint for the copy-only-tiny-frames scheme.
+ * Setting to > 1518 effectively disables this feature.
+ *
+ * NOTE:
+ * The ia64 doesn't allow for unaligned loads even of integers being
+ * misaligned on a 2 byte boundary. Thus always force copying of
+ * packets as the starfire doesn't allow for misaligned DMAs ;-(
+ * 23/10/2000 - Jes
+ *
+ * Neither does the Alpha. -Ion
+ */
+#if defined(__ia64__) || defined(__alpha__)
+static int rx_copybreak = PKT_BUF_SZ;
+#else
 static int rx_copybreak = 0;
+#endif
 
 /* Used to pass the media type, etc.
Both 

Re: [patchlet] One liner "fix" to mm/vmalloc.c

[Francis Galiegue]

On Fri, 16 Feb 2001, Burton Windle wrote:

> Date: Fri, 16 Feb 2001 17:10:27 -0500 (EST)
> From: Burton Windle <[EMAIL PROTECTED]>
> To: Francis Galiegue <[EMAIL PROTECTED]>
> Subject: Re: [patchlet] One liner "fix" to mm/vmalloc.c
> 
> What kernel is your patch against?
> 
> 

Oops! Sorry. That's against 2.4.1-ac16.

-- 
Francis Galiegue, [EMAIL PROTECTED] - Normand et fier de l'être
"Programming is a race between programmers, who try and make more and more
idiot-proof software, and universe, which produces more and more remarkable
idiots. Until now, universe leads the race"  -- R. Cook

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

[PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache

[Richard Jerrell]

2.4.1 has a memory leak (temporary) where anonymous memory pages that have
been moved into the swap cache will stick around after their vma has been
unmapped by the owning process.  These pages are not free'd in free_pte()
because they are still referenced by the page cache.  In addition, if the
pages are dirty, they will be written out to the swap device before they
are reclaimed even though the owning process no longer will be using the
pages.

free_pte in mm/memory.c has been modified to check to see if the page is
only being referenced by the swap cache (and possibly buffers).  If so,
the buffers (if existant) are free'd and the page and swap cache
entry are removed immediately.

Rich Jerrell
[EMAIL PROTECTED]


diff --recursive -u -N linux-2.4.1/mm/memory.c linux-2.4.1-paging-fix/mm/memory.c
--- linux-2.4.1/mm/memory.c Sat Jan 27 22:12:35 2001
+++ linux-2.4.1-paging-fix/mm/memory.c  Thu Feb 15 13:36:06 2001
@@ -281,6 +285,33 @@
return 1;
}
swap_free(pte_to_swp_entry(pte));
+   {
+   int num, target = 1;
+   struct page *page = lookup_swap_cache(pte_to_swp_entry(pte));
+   /* returns the page and takes a reference */
+   
+   if (!page || (!VALID_PAGE(page)) || PageReserved(page))
+   return 0;
+   
+   num = atomic_read(>count);
+   if(page->buffers) target++; /* 1 count if we have buffers 
+*/
+   if(PageSwapCache(page)) target++;   /* 1 count for the page cache 
+*/
+   /* 1 count for our reference  
+*/
+
+   if((num == target) && PageSwapCache(page)) {
+   /* SwapCache entry is the only thing referencing this page   
+*/
+   /* (and maybe buffers) asides from us, so to prevent it from 
+*/
+   /* sitting around and wasting time/memory, throw it away 
+*/
+   if((page->buffers)) {
+   if(!try_to_free_buffers(page,1)) {  /* Can't get 
+rid of buffers   */
+   page_cache_release(page);   /* get rid of 
+our reference   */
+   return 0;   /* and let 
+someone else do it */
+   }
+   }
+   free_page_and_swap_cache(page); /* Expects the page to be 
+mapped, so will */
+   return 1;   /* account for the reference 
+we have  */
+   }
+   }
return 0;
 }
 

Re: Linux stifles innovation...

[Dennis]

At 02:48 PM 02/16/2001, Jesse Pollard wrote:
>On Fri, 16 Feb 2001, Andrew Scott wrote:
> >On 15 Feb 2001, at 9:49, fsnchzjr wrote:
> >
> >> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> >> Nice little article on how we're all going to die of herpes from our
> >> repeated exposition to Linux...
> >> 
> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
> >> g=ltnc
> >
> >That's about as self-serving a statement as I've ever seen. If this
> >'Jim Alchin' actually believes what he's saying, he's got to be one
> >of the worlds biggest fools, and if he doesn't believe what he's
> >saying, well there aren't too many words that would accurately
> >describe what he is.
> >
> >It's pretty funny in some ways, e.g. "We can build a better product
> >than Linux...", which begs the question, "Well, why don't you?".
> >Perhaps it costs too much?

objective, arent we?

There is much truth to the concept, although Microsoft should not be ones 
to comment on it as such.

For example, if there were six different companies that marketed ethernet 
drivers for the eepro100, you'd have a choice of which one to buy..perhaps 
with different "features" that were of value to you. Instead, you have 
crappy GPL code that locks up under load, and its not worth spending 
corporate dollars to fix it because you have to give away your work for 
free under GPL. And since there is a "free" driver that most people can 
use, its not worth building a better mousetrap either because the market is 
too small. So, the handful of users with problems get to "fit it 
themselves", most of whom cant of course.

Theres also the propensity for mediocre stuff to get into the kernel 
because some half-baked programmer was willing to contribute some code. The 
50% of the kernel that remains "experimental" ad infinitum is evidence of that.

The biggest thing that the linux community does to stifle innovation is to 
bash commercial vendors trying to make a profit by whining endlessly about 
"sourceless" distributions and recommending "open-source" solutions even 
when they are wholly inferior. You're only hurting yourselves in the long 
run. In that respect MS is correct, because those with the dollars to 
innovate will stay away.

DB

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

[patchlet] One liner "fix" to mm/vmalloc.c

[Francis Galiegue]

Right above the "if (!pmd)" ret is also set to -ENOMEM...

--- mm/vmalloc.c.oldFri Feb 16 22:47:59 2001
+++ mm/vmalloc.cFri Feb 16 22:48:16 2001
@@ -151,7 +151,6 @@
if (!pmd)
break;

-   ret = -ENOMEM;
if (alloc_area_pmd(pmd, address, end - address, gfp_mask,
prot))
break;



-- 
Francis Galiegue, [EMAIL PROTECTED] - Normand et fier de l'être
"Programming is a race between programmers, who try and make more and more
idiot-proof software, and universe, which produces more and more remarkable
idiots. Until now, universe leads the race"  -- R. Cook

-
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: Samba performance / zero-copy network I/O

[Tom Sightler]

> > My testing showed that the lowlatency patches abosolutely destroy a
system
> > thoughput under heavy disk IO.
>
> I'm surprised - I've been keeping an eye on that.
>
> Here's the result of a bunch of back-to-back `dbench 12' runs
> on UP, alternating with and without LL:

It's interesting that your results seem to show an improvement in
performance, while mine show a consistent drop.  My tests were not very
scientific, and I was running much higher dbench processes, 'dbench 64' or
'dbench 128', and at those levels performance with lowlatency enabled fell
though the floor on my setup.

My system is a PIII 700Mhz, Adaptec 7892 Ultra-160, software RAID1,
reiserfs, 256MB RAM.

Under lower loads, like the 'dbench 12' lowlatency only showed only a few
percent loss, but once you approached the levels around 50 things really
went downhill.

I might try to do a more complete test, maybe there's something else in my
config that would make this be a problem, but it was definately quite
noticable.

Later,
Tom


-
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.1-ac15) Wont set using_dma = 1 with hdparm

[Jason Straight]

Doh, I forgot to turn on the DMA options in the kernel.
Thanks.


Mark Hahn wrote:

> you didn't mention what ide controller you're using,
> which sort of makes a big difference.  with modern kernels,
> it shouldn't be necessary to hdparm at all, since you 
> can select such config at compile time.
> 
>> 
> 
> which is normal when you haven't configured the chipset-specific
> ide code, and are using generic ide stuff.
> 
> 
> 

-- 
Jason Straight

-
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: out of memory?

[George]

On Fri, 16 Feb 2001, Alan Cox wrote:

>> VM: do_try_to_free_pages failed for myprog.pl
>> VM: do_try_to_free_pages failed for myprog.pl
>> VM: do_try_to_free_pages failed for kupdate (just saw this once)
>>
>> The kernel is compiled with the rh-7.0 kgcc (egcs-2.91.66), and I've
>> patched it to get raid 0.90 and reiserfs 3.5.29.
>> What's going on? How bad is this?
>
>The VM logs cases where it actually ends up having trouble getting free
>memory and sits around before it eventually gets life going again. Its mostly
>a debugging aid and in itself harmless.

I've had 2.2.18 go into an infinite kernel loop with that message when
running out of memory.  ALT+SysRq would respond and print what it tries to
do, but never actually accomplish it. (i.e., it'd say "Syncing disks." but
never actually do it.) Apparently userspace never ran again because sockets
would be accepted still but never progress.

-George Greer

-
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.1-ac15) pcmcia irq conflict

[Jason Straight]

Any suggestions of things I could try to help pinpoint the problem and 
let you know the results? Everything was fine before 2.4.1.

I've been using the pcmcia-cs without kernel pcmcia support up until it 
didn't work with 2.4.1, then I tried using the kernel pcmcia and no deal 
there either.

As soon as I try to start pcmcia my machine freezes. When using 
yenta_socket I can see that the TI pcmcia and eth0 (intel eepro100) are 
both on irq 11.

when using the pcmcia-cs way of it I tried "exclude irq 11" in 
config.opts and /etc/sysconfig/pcmcia set "PCIC_OPTS="irq_list=9,10,15 
pci_irq_list=9,10,15"
as was suggested in this post :
http://groups.google.com/groups?q=inspiron+8000+pcmcia+2.4.1=en==off=1=929215370=1

It didn't work for me - at least not with 2.4.1-ac13 to ac15

I didn't disable my minipci ethernet because I need it and if the IRQ's 
for pcmcia didn't use 11 now I wouldn't think I would need to.




Alan Cox wrote:

>> I have a Dell Inspiron 8000. Trying to use pcmcia with kernel
>> (yenta_socket) or pcmcia-cs only causes pcmcia card to take irq 11,
>> which my eth device is on also. This didn't happen with 2.2 or 2.4.0
>> kernels.
> 
> 
> Sharing a PCI irq is legal, so that isnt the cause. It could be that the
> irq routing isnt getting handled correctly however. 
> -
> 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/
> 
> 

-- 
Jason Straight

-
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: isapnp , 2.2.14 vs. 2.4.1 and awe_wave

[Bill Nottingham]

Alan Cox ([EMAIL PROTECTED]) said: 
> > Probing around with test code in awe_wave.c, it become clear to me
> > that the card was not being initialized properly by my isapnptools. 
> > Even more alarming was the fact that pnpdump would not see the SB card 
> > at all under 2.4.1, unless I used the -r option, but would show it 
> > just fine under 2.2.14.
> 
> Dont mix isapnp tools with a 2.4 kernel unless you disable ISA PnP support
> in the kernel. It needs to have one or the other do it, not both

Um, earlier he said:

>  Since I use isapnptools and did not compile in any kernel pnp support,

Bill
-
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: Linux stifles innovation...

[James Sutherland]

On Fri, 16 Feb 2001, David D.W. Downey wrote:

> Would someone tell me where you get all this lovely information on
> patents held by M$? I can't find anything.

Sorry, it's *IBM* who are said to hold a patent on the tab key.

Legend has it Microsoft once found a patent of theirs which IBM appeared
to have infringed, and were very excited at the possibility of something
to hold over IBM, so their lawyers met IBM's lawyers. The MS lawyers
beamed "look at our patent you've infringed!" IBM's lawyers replied "look
at this pile of our patents YOU'VE infringed... let's start with this
one. A Tab key." MS suddenly realised they were outlawyered...

No idea how accurate it is, but just the thought of MS's lawyers getting a
nasty shock like that has a certain appeal :-)


James.

-
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.1-ac15) pcmcia irq conflict

[Alan Cox]

> I have a Dell Inspiron 8000. Trying to use pcmcia with kernel
> (yenta_socket) or pcmcia-cs only causes pcmcia card to take irq 11,
> which my eth device is on also. This didn't happen with 2.2 or 2.4.0
> kernels.

Sharing a PCI irq is legal, so that isnt the cause. It could be that the
irq routing isnt getting handled correctly however. 
-
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: PROBLEM: virtual console corruption (2.4.1/p4/radeon/XFree864.0.2)

[John Cavan]

David Wood wrote:
> 
> I believe you, although... why doesn't it happen with 2.2.17? vconsole
> buffers in a different place in memory, I suppose?
> 
> I'll forward this to the XFree team. Thanks!
> -David

Known bug, they're working on it.

If you want to avoid the corruption, use the Vesa framebuffer driver for
the console for the time being, it works fine for the Radeon.

John
-
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: PROBLEM: virtual console corruption (2.4.1/p4/radeon/XFree864.0.2)

[David Wood]

I believe you, although... why doesn't it happen with 2.2.17? vconsole
buffers in a different place in memory, I suppose?

I'll forward this to the XFree team. Thanks!
-David

On Fri, 16 Feb 2001, James Simmons wrote:

>
> X server problem.
>


David Wood | Templar Studios LLC.
157 Ludlow Street N 600 | New York, NY 10002
tel 212.982.9360 x210 | fax 212.982.9370

-
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: Linux stifles innovation...

[Jesse Pollard]

On Fri, 16 Feb 2001, Andrew Scott wrote:
>On 15 Feb 2001, at 9:49, fsnchzjr wrote: 
>
>> Watch Microsoft's Jim Allchin go Linux-bashing!!!
>> Nice little article on how we're all going to die of herpes from our
>> repeated exposition to Linux...
>> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
>> g=ltnc
>
>That's about as self-serving a statement as I've ever seen. If this 
>'Jim Alchin' actually believes what he's saying, he's got to be one 
>of the worlds biggest fools, and if he doesn't believe what he's 
>saying, well there aren't too many words that would accurately 
>describe what he is. 
>
>It's pretty funny in some ways, e.g. "We can build a better product 
>than Linux...", which begs the question, "Well, why don't you?". 
>Perhaps it costs too much? 

Actually, the question should be "Well, why didn't you?"
-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
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: x86 ptep_get_and_clear question

[Ben LaHaise]

On Fri, 16 Feb 2001, Linus Torvalds wrote:

> This is, actually, a problem that I suspect ends up being _very_ similar
> to the zap_page_range() case. zap_page_range() needs to make sure that
> everything has been updated by the time the page is actually free'd. While
> filemap_sync() needs to make sure that everything has been updated before
> the page is written out (or marked dirty - which obviously also guarantees
> the ordering, and makes the problems look even more similar).

Ah, I see what I was missing.  So long as the tlb flush is in between the
ptep_test_and_clear_dirty and the set_page_dirty, we're fine (ie the
current code is good).  If we really want to reduce the number of tlb
flushes, yes, we can use the gather code and then just do the
set_page_dirty after a tlb_flush_range.

-ben

-
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: x86 ptep_get_and_clear question

[Linus Torvalds]

On Fri, 16 Feb 2001, Ben LaHaise wrote:
> 
> Actually, in the filemap_sync case, the flush_tlb_page is redundant --
> there's already a call to flush_tlb_range in filemap_sync after the dirty
> bits are cleared.

This is not enough. 

If another CPU has started write-out of one of the dirty pages (which, as
far as I can tell, is certainly unlikely but not impossible) while we were
still handling other dirty pages, that other CPU might clear the physical
dirty bit of that page while a third CPU (or the same writer, but that
makes the timing even _more_ unlikely) is still using a stale "dirty" TLB
entry and writing to the page (and not updating the virtual dirty bit
because it doesn't know that it has already been cleared).

So you have to somehow guarantee that you invalidate the TLB's before the
dirty bit from the "struct page" can be cleared (which in turn has to
happen before the writeout). That can obviously be done with the tlb range
flushing, but it needs more locking.

This is, actually, a problem that I suspect ends up being _very_ similar
to the zap_page_range() case. zap_page_range() needs to make sure that
everything has been updated by the time the page is actually free'd. While
filemap_sync() needs to make sure that everything has been updated before
the page is written out (or marked dirty - which obviously also guarantees
the ordering, and makes the problems look even more similar).

Linus

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

Can 2.2 Linux boot from an IDE ZIP?

[Dennis]

Can 2.2.x linux made to boot from an ide zip drive? If so, what is required?

DB

-
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: Linux stifles innovation...

[David D.W. Downey]

Would someone tell me where you get all this lovely information on
patents held by M$? I can't find anything.


On Fri, 16 Feb 2001, James Sutherland wrote:

> On Fri, 16 Feb 2001, Rik van Riel wrote:
>
> > On Thu, 15 Feb 2001, Alan Olsen wrote:
> >
> > > I expect the next thing that will happen is that they will get
> > > patents on key portions of their protocols and then start
> > > enforcing them.
> >
> > If Microsoft would start pissing off IBM and other major
> > companies which have big business interests in Linux by
> > invoking their patents, I can just imagine IBM coming down
> > on Microsoft with their own patents ...
> >
> > "Hey you!  Stop flipping those bits!  Hold it right there!
> >  ... Don't you flip any more bits, read this patent first..."
> >
> > (and I'm sure they must have patents on _setting_ bits as
> > well ;))
>
> Apparently they DO have a patent on the tab key - you thought Amazon's
> "one click shopping" patent was bad?!
>
>
> James.
>
> -
> 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/
>

-- 
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation - Sunnyvale, CA

-
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: Ingo's RAID patch for 2.2.18 final?

[David Mansfield]

Andrea Arcangeli wrote:
> 
> On Wed, Jan 24, 2001 at 04:05:12PM +0100, Sasi Peter wrote:
> > > This isn't obvious. Your working may not fit in cache and so the kernel
> > > understand it's worthless to swapout stuff to make space to a polluted
> > > cache.
> >
> > But your understanding agrees on that the larger chunks for each stream
> > we read into cache, the more efficient for this kind of RAID disk
> > structure the read is, thus basically the more cache we have, the more
> > bandwidth we can serve. (disks give more data in the same time with
> > fewer long reads than with several shorter ones)
> 
> The size of the I/O requests doesn't grow linearly with with the size of the
> cache, as far as you have some mbyte of cache you will also be able to sumbit
> full sized requests to disk (512K per req on 2.4). In your workload you just
> had enough memory for the readahead.
> 
> In general if your working set doesn't fit in cache, the size of the cache is
> unrelated to the bandwith you get out of your RAID, infact if your working set
> doesn't fit in cache you should not pass through the cache at all to get the
> best performance and to save CPU cycles and L1 dcache and L2 cache (O_DIRECT).
> 

This may be a bit OT, but when you say O_DIRECT, that implies that you
can pass that flag to open(2) and it will bypass the page cache, and
read directly into user-space buffers (zero-copy IO)?  Does this also
bypass the read-ahead mechanisms in the kernel?  Does it imply O_SYNC?

Lots of questions... no answers.  Sigh.

David

-- 
David Mansfield   (718) 963-2020
[EMAIL PROTECTED]
Ultramaster Group, LLC   www.ultramaster.com
-
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: PROBLEM: virtual console corruption (2.4.1/p4/radeon/XFree864.0.2)

[James Simmons]

X server problem.

-
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: [Xpert]Video drivers and the kernel

[James Simmons]

>(Aside, is this because X uses keyboard in raw mode?  would be nice to
>still be able to ctrl-alt-del to rebood from console)  Anyone know about
>using alt-sysrq to restore console?
>
>So, if the kernel had a card specific module that just knew enough
>to put the card back into text mode, or if it used the card's bios
>to do it like the int10.a module in XFree 4.0, we would lack for nothing.
>(hmm vesafb could be extended?)

Working on it. I already have it so you can go from vgacon to /dev/fb and
back to vgacon. It is in the works to have vgacon restore the text mode,
palette and fonts when switching away from the X server. One of the
problems I have seen is under heavy load switching away from X often
doesn't restore the text console properly. Vgacon could. This is also
handy when the X server dies :-) As for using the card's BIOS. Yuck yuck!!
We have other platforms to consider like PPC. PPC is a pretty popular platform.

-
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: mke2fs and kernel VM issues

[Samuel Flory]

Tigran Aivazian wrote:
> 
> On Thu, 15 Feb 2001, Samuel Flory wrote:
> 
> >   What is believed to be the current status of the typical mke2fs
> > crashes/hangs due to vm issues?  I can reliably reproduce the issue on a
> > heavily modifed VA kernel based on 2.2.18.  Is there a kernel which is
> > believed to be a known good kernel?  (both 2.2.x and 2.4.x)
> 
> I can mke2fs (successfully) on a 270G block device. Yes, of course, I also
> get various page allocation failures while this happens but they are not
> deadly, i.e. the thing (our volume manager) just retries until it works
> and after a while I have a valid (and a very big) ext2 filesystem with 0
> processes killed.
> 
> The kernel I use is 2.4.2-pre3. The machine has 6G RAM with the 3G given
> to kernel virtual. The amount of swap is massive (2G) but it is never
> used.

  I've never been able reliably reproduce any sort of mke2fs hang on
systems with more than 512M of RAM.  It would be interesting to know if
other people are seeing this under SW-RAID, and other controllers. 
(Currently everyone in direct contact with me uses a Mylex controller.) 
The key seems to be 512 or smaller amounts of RAM, and a 80G or larger
logical drive.

-- 
Solving people's computer problems always
requires more hardware be given to you.
(The Second Rule of Hardware Acquisition)
Samuel J. Flory  <[EMAIL PROTECTED]>
-
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: mke2fs and kernel VM issues

[Samuel Flory]

Alan Cox wrote:
> 
> > heavily modifed VA kernel based on 2.2.18.  Is there a kernel which is
> > believed to be a known good kernel?  (both 2.2.x and 2.4.x)
> 
> I've not seen the problem on unmodified 2.2.18. The 2.2.17/18 VM does have
> its problems but not these. 2.2.19pre3 and higher have the Andrea VM fixes which
> have worked wonders for everyone so far.


  Hmm I believe Chip got his VM patches from Andrea.  So the behavior
may be more 2.2.19pre3ish than 2.2.18ish.

-- 
Solving people's computer problems always
requires more hardware be given to you.
(The Second Rule of Hardware Acquisition)
Samuel J. Flory  <[EMAIL PROTECTED]>
-
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: x86 ptep_get_and_clear question

[Ben LaHaise]

On Fri, 16 Feb 2001, Manfred Spraul wrote:

> That leaves msync() - it currently does a flush_tlb_page() for every
> single dirty page.
> Is it possible to integrate that into the mmu gather code?
>
> tlb_transfer_dirty() in addition to tlb_clear_page()?

Actually, in the filemap_sync case, the flush_tlb_page is redundant --
there's already a call to flush_tlb_range in filemap_sync after the dirty
bits are cleared.  None of the cpus we support document having a writeback
tlb, and intel's docs explicitely state that they do not as they state
that the dirty bit is updated on the first write to dirty the pte.

-ben

-
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: x86 ptep_get_and_clear question

[Linus Torvalds]

On Fri, 16 Feb 2001, Manfred Spraul wrote:
> 
> That leaves msync() - it currently does a flush_tlb_page() for every
> single dirty page.
> Is it possible to integrate that into the mmu gather code?

Not even necessary.

The D bit does not have to be coherent. We need to make sure that we flush
the TLB before we start the IO on the pages which clears the per-physical
D bit (so that no CPU will have done any modifications that didn't show up
in one of the D bits - whther virtual in the page tables or physical in
the memory map), but there are no other real requirements.

So you don't strictly need to gather them at all, although right now with
the type of setup we have I suspect it's hard to actually implement any
other way (because msync doesn't necessarily know when the IO has been
physically started and has no good way of hooking into it..).

Linus

-
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: x86 ptep_get_and_clear question

[Manfred Spraul]

Linus wrote:
> 
> >
> > That second pass is what I had in mind.
> >
> > > * munmap(file): No. Second pass required for correct msync behaviour.
> >
> > It is?
> 
> Not now it isn't. We just do a msync() + fsync() for msync(MS_SYNC). Which
> is admittedly not optimal, but it works.
>

Ok, munmap() will be fixed by the tlb shootdown changes - it also uses
zap_page_range().

That leaves msync() - it currently does a flush_tlb_page() for every
single dirty page.
Is it possible to integrate that into the mmu gather code?

tlb_transfer_dirty() in addition to tlb_clear_page()?

--
Manfred
-
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: ServeRaid 4M with IBM netfinity and kernel 2.4.x

[Andrius Adomaitis]

On Friday 16 February 2001 03:29, Stéphane Borel wrote:

> I should add that the behaviour of serveraid under 2.4 is somehow
> strange : during fsck for instance, it seems to get stuck and won't
> go further if we don't strike a key on the keyboard.

It just a gues, but try disable write back cache. I had similar 
problems with intel crcu31 RAID controller. 

Good luck.
--
Andrius
[EMAIL PROTECTED]
-
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] [PATCH] reiserfs fix for null bytes in small files

[Vladimir V. Saveliev]

Hi

Chris Mason wrote:

> Hello everyone,
>
> I think Alexander Zarochentcev and I have finally figured out
> cause for null bytes in small reiserfs files.  reiserfs stores
> parts of these files packed together in the tree, and the
> packed bytes can shift around as the tree is balanced.
>
> When converting from the packed bytes to a full block, the
> full block is inserted, and the packed bytes are removed.  If
> the packed bytes are split between two tree blocks, and then
> merged by a different process balancing the tree, the conversion
> code might remove too many bytes from the file.  This creates
> a hole in the file, which is why people see null bytes.
>
> If anyone wants more details, drop a line to me or the reiserfs
> list ;-)  This patch against 2.4.1 (will work on any 2.4.1ac or
> 2.4.2pre as well) should fix it, please try it on your
> non-production machines, we are still running it through tests
> here.
>

Just to make things clear:
reiserfs for 2.2 does not have this bug, so there is nothing to fix.

Thanks,
vs


>
> -chris
>
> --- linux/fs/reiserfs/tail_conversion.c.old Thu Feb 15 13:16:47 2001
> +++ linux/fs/reiserfs/tail_conversion.c Thu Feb 15 13:10:23 2001
> @@ -92,7 +92,7 @@
>  /* Move bytes from the direct items to the new unformatted node
> and delete them. */
>  while (1)  {
> -   int item_len, first_direct;
> +   int tail_size;
>
> /* end_key.k_offset is set so, that we will always have found
> last item of the file */
> @@ -103,13 +103,11 @@
>  #ifdef CONFIG_REISERFS_CHECK
> if (!is_direct_le_ih (p_le_ih))
> reiserfs_panic (sb, "vs-14055: direct2indirect: "
> -   "direct item expected, found %h", p_le_ih);
> +   "direct item expected(%k), found %h",
> +   _key, p_le_ih);
>  #endif
> -   if ((le_ih_k_offset (p_le_ih) & (n_blk_size - 1)) == 1)
> -   first_direct = 1;
> -   else
> -   first_direct = 0;
> -   item_len = le16_to_cpu (p_le_ih->ih_item_len);
> +   tail_size = (le_ih_k_offset (p_le_ih) & (n_blk_size - 1))
> +   + ih_item_len(p_le_ih) - 1;
>
> /* we only send the unbh pointer if the buffer is not up to date.
> ** this avoids overwriting good data from writepage() with old data
> @@ -123,7 +121,7 @@
> n_retval = reiserfs_delete_item (th, path, _key, inode,
>  up_to_date_bh) ;
>
> -   if (first_direct && item_len == n_retval)
> +   if (tail_size == n_retval)
> // done: file does not have direct items anymore
> break;
>

-
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: x86 ptep_get_and_clear question

[Hugh Dickins]

On Fri, 16 Feb 2001, Jamie Lokier wrote:
> 
> > And check the Pentium III erratas. There is one with the tlb
> > that's only triggered if 4 instruction lie in a certain window and all
> > access memory in the same way of the tlb (EFLAGS incorrect if 'andl
> > mask,' causes page fault)).
> 
> Nasty, but I don't see what an obscure and impossible to work around
> processor bug has to do with this thread.  It doesn't actually change
> page fault handling, does it?

Obscure but not nasty: the copy of EFLAGS pushed onto the stack when
taking the fault is wrong, but once the instruction is restarted it
all sorts itself out (as I understand from the Spec Update).
Possible to work around, but just not worth the effort.

Nastier was its precursor, Pentium Pro Erratum #63, generated under
similar conditions: where the wrong (carry bit of) EFLAGS when faulting
in the middle of ADC, SBB, RCR or RCL could cause a wrong arithmetic
result when restarted.  Perfectly possible to work around (only lower
permissions of a pte visible on another CPU while that CPU is pulled
into the kernel with an IPI), and necessary to work around it back
then (4 years ago) when the Pentium Pro was at the leading edge;
but I doubt it's worth redesigning now to suit an old erratum.

These errata do make the point that, whatever x86 specs say should
happen, Intel sometimes fails to match them; and the SMP TLB area
was certainly prone to errata at the time of the Pentium Pro -
but hopefully that means Intel exercise greater care there now.

Hugh

-
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: Video drivers and the kernel

[James Simmons]

>I was wondering why video drivers are not part of the kernel like every
>other piece of hardware. I would think if video drivers were part of the
>kernel and had a nice API for X or any other windowing system, would not
>only improve performance but would allow competing windowing systems
>without having to develop drivers for each. Has anyone thought or
>rejected this idea.

Hi!

  Their are two schools of though which I have encountered. One is have
everything in userland. The second is have everything in the kernel. Well
both are wrong. What is really needed? Proper virtualization of the
graphics engine. This means the graphics hardware state is private to each
process and no other process can effect another process graphics hardware
state. This is all that is needed. DRI attemptes to address this. Will
their be more kernel support in the future. Yes if you every want to port
high end graphic servers. Here you end up dealing with with pipes on
different nodes in NUMA systems. Data is passed from node to node to allow
really fast parallel rendering. Note even in this case you don't have
the hardware programmed in the driver but only management of the pipe
state per process.


-
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.1-ac15) pcmcia irq conflict

[Jason Straight]

Upgrading from 2.2.18 and 2.4.0 to 2.4.1-ac15 broke pcmcia.

I have a Dell Inspiron 8000. Trying to use pcmcia with kernel
(yenta_socket) or pcmcia-cs only causes pcmcia card to take irq 11,
which my eth device is on also. This didn't happen with 2.2 or 2.4.0
kernels.

What param would I pass (how can I specify) to get yenta_socket to take
say IRQ 9 or 10 on startup?

Thanks

-- 
Jason Straight
-
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: x86 ptep_get_and_clear question

[Jamie Lokier]

Manfred Spraul wrote:
> A very simple test might be
> 
> cpu 1:
> cpu 2:

Ben's test uses only one CPU.

> Now start with variants:
> change to read only instead of not present
> a and b in the same way of the tlb, in a different way.
> change pte with write, change with lock;
> .
> .
> .
> 
> But you'll never prove that you tested every combination.

Indeed.

-- Jamie
-
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: x86 ptep_get_and_clear question

[Manfred Spraul]

Jamie Lokier wrote:
> 
> > > Ben, fancy writing a boot-time test?
> > >
> > I'd never rely on such a test - what if the cpu checks in 99% of the
> > cases, but doesn't handle some cases ('rep movd, everything unaligned,
> > ...'.
> 
> A good point.  The test results are inconclusive.
> 
> > And check the Pentium III erratas. There is one with the tlb
> > that's only triggered if 4 instruction lie in a certain window and all
> > access memory in the same way of the tlb (EFLAGS incorrect if 'andl
> > mask,' causes page fault)).
> 
> Nasty, but I don't see what an obscure and impossible to work around
> processor bug has to do with this thread.  It doesn't actually change
> page fault handling, does it?
>
Page fault handling is unchanged, but perhaps there are other races. And
note that these races wouldn't be processor bugs - the spec nowhere
guarantee the behaviour you assume.

Ben tries to prove that the current cpu _never_ sets the dirty bit
without checking the present bit.

A very simple test might be

cpu 1:
cli();
a = 0; b = 0; m = 0;
flush_local_tlb_page(a);
flush_local_tlb_page(b);
flush_local_tlb_page(a);
while(!m);
while (!a && !b);
a = 1;

cpu 2:

cli();
both ptes for a and b as writable, not dirty.
m = 1;
udelay(100);
change the pte of a to not present.
wmb();
b = 1;

Now start with variants:
change to read only instead of not present
a and b in the same way of the tlb, in a different way.
change pte with write, change with lock;
.
.
.

But you'll never prove that you tested every combination.

--
Manfred
-
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: x86 ptep_get_and_clear question

[Linus Torvalds]

On Fri, 16 Feb 2001, Manfred Spraul wrote:

> Jamie Lokier wrote:
> > 
> > Linus Torvalds wrote:
> > > So the only case that ends up being fairly heavy may be a case that is
> > > very uncommon in practice (only for unmapping shared mappings in
> > > threaded programs or the lazy TLB case).
> >
> The lazy tlb case is quite fast: lazy tlb thread never write to user
> space pages, we don't need to protect the dirty bits. And the first ipi
> clears mm->cpu_vm_mask, only one ipi.

This is NOT necessarily true in the generic case.

The lazy TLB thread itself may not write to the address space, but I can
in theory see a hardware implementation that delays writing out the dirty
bit from the TLB until it is invalidated. I agree that it is unlikely,
especially on an x86, but I think it's a case we should at least think
about for the generic kernel architecture.

Think of the TLB as a cache, and think of the dirty state as being either
write-through or write-back. Now, I will bet you that all current x86's
 (a) _do_ actually check the P bit when writing D (ie current Linux code
 is probably fine as-is, even if incorrect in theory)
and
  (b) the D bit is write-through.

But even so, I want people to at least consider the case of a write-back
TLB dirty bit, in which case the real state of the D bit might not be
known until a TLB flush has been done (even on a UP machine - which is why
I'm certain that no current x86 actually does this optimization).

(And because of (a), I don't think I'll necessarily fix this during 2.4.x
anyway unless it gets fixed as a result of the generic TLB shootdown issue
which has nothing at all to do with the D bit)

Don't get too hung up on implementation details when designing a good
architecture for this thing.

Linus

-
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.1-ac15) Wont set using_dma = 1 with hdparm

[Jason Straight]

With 2.2.18 I can set using_dma = 1 with hdparm on my Dell Inspiron
8000, I cannot with 2.4.1-ac15, so my HD works about 1/3 the speed with
2.4.1.

[root@jkd junfan]# hdparm -I /dev/hda

/dev/hda:

 Model=IHATHC_IKD32AB2- 0  , FwRev=000E0A2D,
SerialNo=  11S59T
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=36477, SectSize=579, ECCbytes=4
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=?0?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=39070080
 IORDY=yes, tPIO={min:400,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4 
 DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3
*udma4


/dev/hda:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Operation not permitted
 using_dma=  0 (off)

hdparm v3.9





-- 
Jason Straight
-
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: x86 ptep_get_and_clear question

[Ben LaHaise]

On Fri, 16 Feb 2001, Linus Torvalds wrote:

> How do you expect to ever see this in practice? Sounds basically
> impossible to test for this hardware race. The obvious "try to dirty as
> fast as possible on one CPU while doing an atomic get-and-clear on the
> other" thing is not valid - it's in fact quite likely to get into
> lock-step because of page table cache movement synchronization. And as
> such it could hide any race.

That's not the behaviour I'm testing, but whether the CPU is doing

lock
pte = *ptep
if (present && writable)
pte |= dirty
*ptep = pte
unlock

versus

lock
pte = *ptep
pte |= dirty
*ptep = pte
unlock

Which can be tested by means of getting the pte into the tlb then changing
the pte without flushing and observing the results (page fault vs changed
pte).  I'm willing to bet that all cpus are doing the first version.

-ben

-
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: Linux stifles innovation...

[Joseph Pingenot]

>> On the other hand:
>> ''I can't imagine something that could be worse than this 
>> for the software business and the intellectual-property business.''
>Linux IS (part of) the software business, though! That's like saying
>Walmart is bad for shops - it is bad for OTHER, COMPETING shops.

Actually, I'd contend that it's more like Wal-Mart (oder Aldi) claiming that 
  the Mom-n-Pop store (Tante Emma Laden) down the street is ruining their
  business.  It's the big Goliath coming out once again.

[Unfortunately, I only know the German equivalents of the xlat'ed phrases]
-- 
[EMAIL PROTECTED]
"I felt a great disturbance in the force.  As if a significant plot
  line suddenly cried out in terror... and was suddenly silenced."
-Torg in "Sluggy Freelance" www.sluggy.com.
-
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: x86 ptep_get_and_clear question

[Linus Torvalds]

On Fri, 16 Feb 2001, Ben LaHaise wrote:

> On Fri, 16 Feb 2001, Jamie Lokier wrote:
> 
> > It should be fast on known CPUs, correct on unknown ones, and much
> > simpler than "gather" code which may be completely unnecessary and
> > rather difficult to test.
> >
> > If anyone reports the message, _then_ we think about the problem some more.
> >
> > Ben, fancy writing a boot-time test?
> 
> Sure, I'll whip one up this afternoon.

How do you expect to ever see this in practice? Sounds basically
impossible to test for this hardware race. The obvious "try to dirty as
fast as possible on one CPU while doing an atomic get-and-clear on the
other" thing is not valid - it's in fact quite likely to get into
lock-step because of page table cache movement synchronization. And as
such it could hide any race.

Linus

-
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: x86 ptep_get_and_clear question

[Jamie Lokier]

> > Ben, fancy writing a boot-time test?
> > 
> I'd never rely on such a test - what if the cpu checks in 99% of the
> cases, but doesn't handle some cases ('rep movd, everything unaligned,
> ...'.

A good point.  The test results are inconclusive.

> And check the Pentium III erratas. There is one with the tlb
> that's only triggered if 4 instruction lie in a certain window and all
> access memory in the same way of the tlb (EFLAGS incorrect if 'andl
> mask,' causes page fault)).

Nasty, but I don't see what an obscure and impossible to work around
processor bug has to do with this thread.  It doesn't actually change
page fault handling, does it?

-- Jamie
-
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: x86 ptep_get_and_clear question

[Linus Torvalds]

On Fri, 16 Feb 2001, Jamie Lokier wrote:

> Manfred Spraul wrote:
> > Ok, Is there one case were your pragmatic solutions is vastly faster?
> 
> > * mprotect: No. The difference is at most one additional locked
> > instruction for each pte.
> 
> Oh, what instruction is that?

The "set_pte()" thing could easily be changed into

lock ; orl pte,(ptepointer)

which actually should work as-is. We do not allow "set_pte()" on anything
but "pte_none()" entries anyway, so in the trivial case the "orl" is
exactly equivalent to a "movl". And in the (so far theoretical) case where
another CPU might have set the dirty bit, the locked "or" will again do
the right thing, and preserve it.

So that would basically be a one-liner that removes the set_pte() race for
mprotect() (and the vmscan.c case of re-establishing the pte, but as
vmscan needs to do something more anyway that part is probably not
interesting).

> > * munmap(anon): No. We must handle delayed accessed anyway (don't call
> > free_pages_ok() until flush_tlb_ipi returned). The difference is that we
> > might have to perform a second pass to clear any spurious 0x40 bits.
> 
> That second pass is what I had in mind.
> 
> > * munmap(file): No. Second pass required for correct msync behaviour.
> 
> It is?

Not now it isn't. We just do a msync() + fsync() for msync(MS_SYNC). Which
is admittedly not optimal, but it works.

Linus

-
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: x86 ptep_get_and_clear question

[Ben LaHaise]

On Fri, 16 Feb 2001, Jamie Lokier wrote:

> It should be fast on known CPUs, correct on unknown ones, and much
> simpler than "gather" code which may be completely unnecessary and
> rather difficult to test.
>
> If anyone reports the message, _then_ we think about the problem some more.
>
> Ben, fancy writing a boot-time test?

Sure, I'll whip one up this afternoon.

-ben

-
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: Linux stifles innovation...

[Byron Albert]

A good article on linux today about this.
http://linuxtoday.com/news_story.php3?ltsn=2001-02-15-003-20-OP

Byron


fsnchzjr wrote:

> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> Nice little article on how we're all going to die of herpes from our
> repeated exposition to Linux...
> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
> g=ltnc
> -
> 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/

-
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: Linux stifles innovation...

[Wayne . Brown]

Actually, in today's "User Friendly" comic strip (http://www.userfriendly.org)
one of the characters asks exactly that same question.

Wayne




"Andrew Scott" <[EMAIL PROTECTED]> on 02/16/2001 08:25:20 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:(bcc: Wayne Brown/Corporate/Altec)

Subject:  Re: Linux stifles innovation...



On 15 Feb 2001, at 9:49, fsnchzjr wrote:

> Watch Microsoft's Jim Allchin go Linux-bashing!!!
> Nice little article on how we're all going to die of herpes from our
> repeated exposition to Linux...
> http://news.cnet.com/investor/news/newsitem/0-9900-1028-4825719-RHAT.html?ta
> g=ltnc

That's about as self-serving a statement as I've ever seen. If this
'Jim Alchin' actually believes what he's saying, he's got to be one
of the worlds biggest fools, and if he doesn't believe what he's
saying, well there aren't too many words that would accurately
describe what he is.

It's pretty funny in some ways, e.g. "We can build a better product
than Linux...", which begs the question, "Well, why don't you?".
Perhaps it costs too much?





--Mailed via Pegasus 3.12c & Mercury 1.48---
[EMAIL PROTECTED]Fax (617)373-2942
Andrew Scott   Tel (617)373-5278   _
Northeastern University--138 Meserve Hall / \   /
College of Arts & Sciences-Deans Office  / \ \ /
Boston, Ma. 02115   /   \_/

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







-
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: x86 ptep_get_and_clear question

[Jamie Lokier]

Manfred Spraul wrote:
> Ok, Is there one case were your pragmatic solutions is vastly faster?

> * mprotect: No. The difference is at most one additional locked
> instruction for each pte.

Oh, what instruction is that?

> * munmap(anon): No. We must handle delayed accessed anyway (don't call
> free_pages_ok() until flush_tlb_ipi returned). The difference is that we
> might have to perform a second pass to clear any spurious 0x40 bits.

That second pass is what I had in mind.

> * munmap(file): No. Second pass required for correct msync behaviour.

It is?

-- Jamie


-
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.1-ac14 won't boot

[Thomas Dodd]

2.4.1-ac8 worked great, 2.4.1-ac13 and ac14 oops
in IDE initialization. All 3 have ide.2.4.1-p8.all.01172001.patch
applied too.  I'll try it without the ide patch today.


-Thomas

---kernel messages---
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
AMD7409: IDE controller on PCI bus 00 dev 39
   : chipset revision 3
   : not 100% native mode: will probe irqs later
AMD7409: disabling single-word DMA support (revision < C4)
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: IBM-DTTA-351010, ATA DISK drive
hdb: IBM-DTTA-351010, ATA DISK drive
hdc: WDC AC24300L,  ATA DISK drive
hdd: ATAPI CDROM, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: status error: status=0x50 { DriveReady SeekComplete }
hda: no DRQ after issuing WRITE
hda:19807200 sectors (10141 MB) w/466KiB Cache, CHS=19650/16/63,
UDMA(33)
hda:ide_intr: hwgroup->busy was 0 ??
Inable to handle kernel NULL pointer dereference at virtual address
0040
 printing eip:
c0192e86
*pde = 
Oops: 
CPU:0
EIP:0010:[]
EFLAGS: 00010046
eax:    ebx: c02cf820   ecx: c1461098   edx: 01f7
esi: c02cf820   edi: 0282   ebp: c02cf7e0   esp: c145fe28
ds: 0018   es: 0018   ss: 0018
Process swaper (pid:1, stackpage=c145f000)
stack: c02cf820 c1461080 c018fce0 c02cf820 c0192e70 c1449440 0401
000e
   c145fe90 c010a349 000e c1461080 c145fe90 c145fe90 000e
c029fc80
   c1449440 c010a4b8 000e c145fe90 c1449440 0380 0212
c029fc80
Call Trace: [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   [] []

Code: 8b 58 40 ec e6 80 0f b6 c8 fb 89 c8 24 c9 3c 40 74 18 0f b6
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
spurious 8259A interrupt: IRQ7.

---run ksymoops 
ksymoops 2.3.4 on i686 2.4.0-ac12.  Options used
 -v ./vmlinux (specified)
 -K (specified)
 -L (specified)
 -o /lib/modules/2.4.1-ac14/ (specified)
 -m ./System.map (specified)

No modules in ksyms, skipping objects
c0192e86
*pde = 
Oops: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax:    ebx: c02cf820   ecx: c1461098   edx: 01f7
esi: c02cf820   edi: 0282   ebp: c02cf7e0   esp: c145fe28
ds: 0018   es: 0018   ss: 0018
Process swaper (pid:1, stackpage=c145f000)
stack: c02cf820 c1461080 c018fce0 c02cf820 c0192e70 c1449440 0401
000e
   c145fe90 c010a349 000e c1461080 c145fe90 c145fe90 000e
c029fc80
   c1449440 c010a4b8 000e c145fe90 c1449440 0380 0212
c029fc80
Call Trace: [] [] [] []
[] [] []
   [] [] [] [] []
[] [] []
   [] []
Code: 8b 58 40 ec e6 80 0f b6 c8 fb 89 c8 24 c9 3c 40 74 18 0f b6

>>EIP; c0192e86<=
Trace; c018fce0 
Trace; c0192e70 
Trace; c010a349 
Trace; c010a4b8 
Trace; c0109120 
Trace; c010a444 
Trace; c0192ba6 
Trace; c01949b3 
Trace; c0194c3a 
Trace; c0194ce4 
Trace; c0192353 
Trace; c019e56d 
Trace; c0105000 
Trace; c01070e9 
Trace; c0105000 
Trace; c01075e6 
Trace; c01070e0 
Code;  c0192e86 
 <_EIP>:
Code;  c0192e86<=
   0:   8b 58 40  mov0x40(%eax),%ebx   <=
Code;  c0192e89 
   3:   ecin (%dx),%al
Code;  c0192e8a 
   4:   e6 80 out%al,$0x80
Code;  c0192e8c 
   6:   0f b6 c8  movzbl %al,%ecx
Code;  c0192e8f 
   9:   fbsti
Code;  c0192e90 
   a:   89 c8 mov%ecx,%eax
Code;  c0192e92 
   c:   24 c9 and$0xc9,%al
Code;  c0192e94 
   e:   3c 40 cmp$0x40,%al
Code;  c0192e96 
  10:   74 18 je 2a <_EIP+0x2a> c0192eb0

Code;  c0192e98 
  12:   0f b6 00  movzbl (%eax),%eax

Kernel panic: Aiee, killing interrupt handler!

config file-
#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
CONFIG_MK7=y
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# 

Re: x86 ptep_get_and_clear question

[Manfred Spraul]

Jamie Lokier wrote:
> 
> Manfred Spraul wrote:
> > The other cpu writes the dirty bit - we just overwrite it ;-)
> > After the ptep_get_and_clear(), before the set_pte().
> 
> Ah, I see.  The other CPU does an atomic *pte |= _PAGE_DIRTY, without
> checking the present bit.  ('scuse me for temporary brain failure).
> 
> How about a pragmatic solution.
>
Ok, Is there one case were your pragmatic solutions is vastly faster?

* mprotect: No. The difference is at most one additional locked
instruction for each pte.

* munmap(anon): No. We must handle delayed accessed anyway (don't call
free_pages_ok() until flush_tlb_ipi returned). The difference is that we
might have to perform a second pass to clear any spurious 0x40 bits.

* munmap(file): No. Second pass required for correct msync behaviour.

* try_to_swap_out(): No. another memory read.

Any other cases?
> 
> Ben, fancy writing a boot-time test?
> 
I'd never rely on such a test - what if the cpu checks in 99% of the
cases, but doesn't handle some cases ('rep movd, everything unaligned,
...'. And check the Pentium III erratas. There is one with the tlb
that's only triggered if 4 instruction lie in a certain window and all
access memory in the same way of the tlb (EFLAGS incorrect if 'andl
mask,' causes page fault)).

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

"make dep" problem

[Andrzej Krzysztofowicz]

Hi,
   While trying to compile 2.4.1-ac1[34] I noticed that the following error
message appears sometimes:

make[3]: *** No rule to make target 
/home29/ankry/kernel/2.4/linux/drivers/pci/devlist.h', needed by `names.o'.
Stop.
make[3]: Leaving directory /home29/ankry/kernel/2.4/linux/drivers/pci'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory /home29/ankry/kernel/2.4/linux/drivers/pci'
make[1]: *** [_subdir_pci] Error 2
...

Most ofteen while compiling kernel multiple times using
  make oldconfig;make dep;make clean; make "MAKE=make -j2" bzImage
(with different configurations)

I also noticed that sometimes mode files is incleded in "mkdep" command line
than usually:

 make[4]: Entering directory /home29/ankry/kernel/2.4/linux/drivers/char'
-/home29/ankry/kernel/2.4/linux/scripts/mkdep -D__KERNEL__ 
-I/home29/ankry/kernel/2.4/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i586  -- acquirewdt.c 
adbmouse.c amigamouse.c amikeyb.c amiserial.c applicom.c applicom.h atarimouse.c 
atixlmouse.c busmouse.c busmouse.h cd1865.h conmakehash.c console.c console_macros.h 
consolemap.c cyclades.c defkeymap.c digi.h digi1.h digiFep1.h digiPCI.h digi_bios.h 
digi_fep.h dn_keyb.c ds1620.c dsp56k.c dtlk.c dz.c dz.h efirtc.c epca.c epca.h 
epcaconfig.h esp.c fep.h generic_serial.c h8.c h8.h hp600_keyb.c i810-tco.c i810-tco.h 
i810_rng.c ip2.c ip2main.c isicom.c istallion.c keyboard.c logibusmouse.c lp.c mem.c 
misc.c mixcomwd.c moxa.c msbusmouse.c mxser.c n_hdlc.c n_r3964.c n_tty.c nvram.c 
nwbutton.c nwbutton.h nwflash.c pc110pad.c pc110pad.h pc_keyb.c pcwd.c pcxx.c pcxx.h 
ppdev.c pty.c q40_keyb.c qpmouse.c random.c raw.c riscom8.c riscom8.h riscom8_reg.h 
rocket.c rocket_int.h rsf16fmi.h!
 rtc.c sbc60xxwdt.c scan_keyb.c scan_keyb.h scc.h selection.c serial.c serial167.c 
serial_21285.c serial_amba.c sh-sci.c sh-sci.h softdog.c specialix.c specialix_io8.h 
stallion.c sx.c sx.h sxboards.h sxwindow.h synclink.c sysrq.c toshiba.c tpqic02.c 
tty_io.c tty_ioctl.c vc_screen.c vino.h vme_scc.c vt.c wd501p.h wdt.c wdt285.c 
wdt977.c wdt_pci.c > .depend
+/home29/ankry/kernel/2.4/linux/scripts/mkdep -D__KERNEL__ 
+-I/home29/ankry/kernel/2.4/linux/include -Wall -Wstrict-prototypes -O2 
+-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i586  -- acquirewdt.c 
+adbmouse.c amigamouse.c amikeyb.c amiserial.c applicom.c applicom.h atarimouse.c 
+atixlmouse.c busmouse.c busmouse.h cd1865.h conmakehash.c console.c console_macros.h 
+consolemap.c consolemap_deftbl.c cyclades.c defkeymap.c digi.h digi1.h digiFep1.h 
+digiPCI.h digi_bios.h digi_fep.h dn_keyb.c ds1620.c dsp56k.c dtlk.c dz.c dz.h 
+efirtc.c epca.c epca.h epcaconfig.h esp.c fep.h generic_serial.c h8.c h8.h 
+hp600_keyb.c i810-tco.c i810-tco.h i810_rng.c ip2.c ip2main.c isicom.c istallion.c 
+keyboard.c logibusmouse.c lp.c mem.c misc.c mixcomwd.c moxa.c msbusmouse.c mxser.c 
+n_hdlc.c n_r3964.c n_tty.c nvram.c nwbutton.c nwbutton.h nwflash.c pc110pad.c 
+pc110pad.h pc_keyb.c pcwd.c pcxx.c pcxx.h ppdev.c pty.c q40_keyb.c qpmouse.c random.c 
+raw.c riscom8.c riscom8.h riscom8_reg.h rocket.c roc!
ket_int.h rsf16fmi.h rtc.c sbc60xxwdt.c scan_keyb.c scan_keyb.h scc.h selection.c 
serial.c serial167.c serial_21285.c serial_amba.c sh-sci.c sh-sci.h softdog.c 
specialix.c specialix_io8.h stallion.c sx.c sx.h sxboards.h sxwindow.h synclink.c 
sysrq.c toshiba.c tpqic02.c tty_io.c tty_ioctl.c vc_screen.c vino.h vme_scc.c vt.c 
wd501p.h wdt.c wdt285.c wdt977.c wdt_pci.c > .depend

 make[4]: Entering directory /home29/ankry/kernel/2.4/linux/drivers/pci'
-/home29/ankry/kernel/2.4/linux/scripts/mkdep -D__KERNEL__ 
-I/home29/ankry/kernel/2.4/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i586  -- compat.c 
gen-devlist.c names.c pci.c proc.c quirks.c setup-bus.c setup-irq.c setup-res.c 
syscall.c > .depend
+/home29/ankry/kernel/2.4/linux/scripts/mkdep -D__KERNEL__ 
+-I/home29/ankry/kernel/2.4/linux/include -Wall -Wstrict-prototypes -O2 
+-fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i586  -- classlist.h compat.c 
+devlist.h gen-devlist.c names.c pci.c proc.c quirks.c setup-bus.c setup-irq.c 
+setup-res.c syscall.c > .depend
 make[4]: Leaving directory /home29/ankry/kernel/2.4/linux/drivers/pci'

(Note  consolemap_deftbl.c in drivers/char and 
   classlist.h devlist.h   in drivers/pci )

Could any Makefile expert check whether it is not a Makefile problem ?

Is it now necessary to do  "make mrproper"  before each make dep ???

-- 
===
  Andrzej M. Krzysztofowicz   [EMAIL PROTECTED]
  phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math.,   Technical University of Gdansk
-
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 

Re: x86 ptep_get_and_clear question

[Jamie Lokier]

Manfred Spraul wrote:
> The other cpu writes the dirty bit - we just overwrite it ;-)
> After the ptep_get_and_clear(), before the set_pte().

Ah, I see.  The other CPU does an atomic *pte |= _PAGE_DIRTY, without
checking the present bit.  ('scuse me for temporary brain failure).

How about a pragmatic solution.

Given that Ben's found that "checks pte_present on dirtying" works in
practice, and it is _much_ simpler to do things that way, perhaps we
could write a boot time test for this?

If the boot time test fails, we

 (a) printk("Sorry we've never seen a CPU like this, please report");

 (b) Put this in ptep_get_and_clear:

  if (tlb_dirty_doesnt_sync)
flush_tlb_page(page)

It should be fast on known CPUs, correct on unknown ones, and much
simpler than "gather" code which may be completely unnecessary and
rather difficult to test.

If anyone reports the message, _then_ we think about the problem some more.

Ben, fancy writing a boot-time test?

-- Jamie
-
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: Linux stifles innovation...

[Mark Haney]

Oh God.  You're right.  But who's going to patent the patent on the patent?
*ad infinitum*


-Original Message-
From: David Woodhouse [mailto:[EMAIL PROTECTED]]On Behalf Of David
Woodhouse
Sent: Friday, February 16, 2001 11:26 AM
To: Mark Haney
Cc: James Sutherland; Rik van Riel; Alan Olsen; David D.W. Downey;
[EMAIL PROTECTED]
Subject: Re: Linux stifles innovation...



[EMAIL PROTECTED] said:
> Okay, so if we are going to get real stupid about the whole thing, I
> wonder if Microsloth is going to patent the patent?

Filing nuisance patents for obvious stuff which shouldn't ever get granted
is a viable business method and as such is patentable in the US.

After all, what patent officer is going to point out the prior art?

:)

--
dwmw2



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