Re: Severe trashing in 2.4.4

[Mike Galbraith]

On Sun, 29 Apr 2001, Alexander Viro wrote:

> On Sun, 29 Apr 2001, Frank de Lange wrote:
>
> > On Sun, Apr 29, 2001 at 12:27:29PM -0400, Alexander Viro wrote:
> > > What about /proc/slabinfo? Notice that 2.4.4 (and couple of the 2.4.4-pre)
> > > has a bug in prune_icache() that makes it underestimate the amount of
> > > freeable inodes.
> >
> > Gotcha, wrt. slabinfo. Seems 2.4.4 (at least on my box) only knows how to
> > allocate skbuff_head_cache entries, not how to free them. Here's the last
> > /proc/slabinfo entry before I sysRQ'd the box:
>
> > skbuff_head_cache 341136 341136160 14214 142141 :  252  126
> > size-2048  66338  66338   2048 33169 331691 :   60   30
>
> Hmm... I'd say that you also have a leak in kmalloc()'ed stuff - something
> in 1K--2K range. From your logs it looks like the thing never shrinks and
> grows prettu fast...

If it turns out to be difficult to track down, holler and I'll expedite
updating my IKD tree to 2.4.4.

-Mike  (memleak maintenance weenie)

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

DMI deactivated - why?

[Michael Reinelt]

Hi there,

I found a quite interesting file: arch/i386/kernel/dmi_scan.c

It should print some DMI values at boot. As far as I remember, I've seen
these at times of 2.4.0 or so. Now these outputs are deactivated with a 
#define dmi_printk(x)

Can someone explain why this has been deactivated? I would find these
values quite useful!

TIA, Michael

-- 
netWorks  Vox: +43 316  692396
Michael Reinelt   Fax: +43 316  692343
Geisslergasse 4   GSM: +43 676 3079941
A-8045 Graz, Austria  e-mail: [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: CML2 1.3.1, aka "I stick my neck out a mile..."

[David Emory Watson]

Oh.  Well in hindsight, I guess your are right.  After all I wouldn't
want to be a luser, much less associated with AOL.  Gosh  I never
realized.  Maybe I just didn't read the right standards manual when I
started using the internet.  Where did you learn all of this?  No,
nevermind I don't care.  I'm sorry for contributing to this silly flame
war.

I think my points been made.  Sorry Al, but this is a bit too silly

On 30 Apr 2001 01:50:49 -0400, Alexander Viro wrote:
> 
> 
> On Sun, 29 Apr 2001, David Emory Watson wrote:
> 
> > Al,
> > 
> > I really don't know why you must complain about Eric's sig.  I
> 
> Because violating the common standards is a bad thing?  You know, like
> 4-lines limit on sig size...  And no, I don't care how many AOL and
> WebTV lusers do the same thing. 
> 

-
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: deregister?

[Jonathan Lundell]

At 10:39 PM -0700 2001-04-29, Steve VanDevender wrote:
>Jonathan Lundell writes:
>  > At 10:03 PM -0400 2001-04-29, Andres Salomon wrote:
>  > >Americans can spell?  Since when?
>  >

Shouldn't that be 'Sinse when'?

>  > OED 2nd Ed:
>  >
>  > deregister. v. trans. To remove from a register. Hence
>  > deregistration. (first citation 1925)
>  >
>  > unregistered. ppl. a. Not entered in a register; unrecorded. (first
>  > citation 1604)
>  >
>  > The OED has no entry for "unregister".
>
>That's proving that the British can spell (it's the Oxford English
>Dictionary, after all),

Hmm. Just a *somewhat* circular argument!

>and that Andreas Salomon doesn't know standard
>English verb morphology.  I rather suspect that there are quite a few
>verbs prefixed with "de-" in common use that aren't in dictionaries,
>since it's well understood how "de-" changes the meaning of a verb.


-- 
/Jonathan Lundell.
-
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/

HPNA

[nervlord]

Hello sorry to interupt ur work, i was a subscriber to the kernel mailing 
list before and realise how much traffic you get.

My friend has a DIAMOND homefree network card using HPNA
i was wondering what hte status of HPNA is in the kernel?
to refresh HPNA allows you to network ur machines via the phone lines  in 
america.

Kind Regards
Peter Revilll
-
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: CML2 1.3.1, aka "I stick my neck out a mile..."

[Alexander Viro]

On Sun, 29 Apr 2001, David Emory Watson wrote:

> Al,
> 
> I really don't know why you must complain about Eric's sig.  I

Because violating the common standards is a bad thing?  You know, like
4-lines limit on sig size...  And no, I don't care how many AOL and
WebTV lusers do the same thing. 

-
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: X15 alpha release: as fast as TUX but in user space

[dean gaudet]

On Sun, 29 Apr 2001, Fabio Riccardi wrote:

> I can disable header caching and see what happens, I'll add an option
> for this in the next X15 release.

heh, well to be honest, i'd put the (permanent) caching of the Date header
into the very slimy, benchmark-only trick category.  (right up there
alongside running the HTTP and TCP stacks inside the NIC interrupt
handler, which folks have done to get even better scores.)

> Nevertheless I don't know how much this is interesting in real life,
> since on the internet most static pages are cached on proxies. I agree
> that the RFC asks for a date for the original response, but once the
> response is cached what does this date mean?

the Date is always the time the response was generated on the origin
server.  (there are exceptions for clockless servers, but such servers
have other limitations you wouldn't want -- notably they MUST NOT generate
Last-Modified.)

one example oddity you might experience with a non-increasing Date
surrounds Last-Modified and Date, see section 13.3.3.  note that the rfc
indicates that if Last-Modified is less than 60 seconds earlier than Date
then Last-Modified is only a weak validator rather than a strong
validator.  this would complicate range requests -- because weak
validators can't be used with range requests.  if your server never
updates the Date after the first time it serves an object then you'd
potentially never get out of this 60 second window.

(strong validators are guaranteed to change whenever the object changes...
and Last-Modified isn't strong until some time has passed -- consider NFS
mounted docroots, clock skew in the origin network, multiple file updates
within a second, etc.)

there are a bunch of other things that Date is used for, all of them are
related to caching heuristics and rules.

in theory you could claim that you're implementing a cache server rather
than an origin server... i dunno what the SPEC committee will think when
you try to submit results though :)

so way back when sendfile() was being created i brought up the Date issue
and pointed out that we needed more than a single "void *, size_t" to take
care of headers.  eventually this discussion lead creation of TCP_CORK --
so that a http server could use writev() to send a two element iov for the
headers -- one element with everything that doesn't need to change, the
next element with the Date.

i also kind of expected the high performance servers to rebuild a Date:
header every second for all of its threads to use.  (of course it's not
that simple, you really want to keep a circular list of N dates... and
just assume that after N seconds no thread could still be accessing an old
Date.)

is this too slow for some reason?  (does it play well with zero-copy?)

-dean








-
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: CML2 1.3.1, aka "I stick my neck out a mile..."

[David Emory Watson]

Al,

I really don't know why you must complain about Eric's sig.  I
personally like them just as they are, but thats strictly besides the
point.  IMHO, it is just not very intresting to hear you say:

> Eric, it's getting tiresome.  Kindly learn what the fsck McQ is, OK?

Especially after all of the brilliant things I have heard you say.  It
really seems like a childish move.  Let the man have his freakin sig for
crying out loud!!  At any rate, I'm just throwin' in my 2 cents.  OK,
now can we get back on  topic?  Good.

I hope no offense is taken and no reply necessary..  But if I mistaken,
then I look forward to your, in all probablity, entertaining reply
(maybe off this list though).  :)

Regards,
David

On 29 Apr 2001 22:24:58 -0400, Alexander Viro wrote:
> 
> 
> On Sun, 29 Apr 2001, Eric S. Raymond quoted:
> 
> > Anton Altaparmakov <[EMAIL PROTECTED]>:
> > > I don't know about whether this is possible with Tcl but have you tried A) 
> > > invisible text and/or B) white space character text (e.g. one or more 
> > > spaces)? That's the kind of thing I usually try in this situation... Just 
> > > an idea...
> 
> wrote
> 
> > I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> > do you do invisible text?
> 
> and sigged
> > -- 
> > http://www.tuxedo.org/~esr/;>Eric S. Raymond
> > 
> > ..every Man has a Property in his own Person. This no Body has any
> > Right to but himself.  The Labour of his Body, and the Work of his
> > Hands, we may say, are properly his.  The great and chief end
> > therefore, of Mens uniting into Commonwealths, and putting themselves
> > under Government, is the Preservation of their Property.
> > -- John Locke, "A Treatise Concerning Civil Government"
> 
> Eric, it's getting tiresome.  Kindly learn what the fsck McQ is, OK?
> 
> /me abstains from attaching Kibo's .sig - 1Mb of PDF is unfortunately
> over the top for l-k...
> 
> -
> 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: deregister?

[Steve VanDevender]

Jonathan Lundell writes:
 > At 10:03 PM -0400 2001-04-29, Andres Salomon wrote:
 > >Americans can spell?  Since when?
 > 
 > OED 2nd Ed:
 > 
 > deregister. v. trans. To remove from a register. Hence 
 > deregistration. (first citation 1925)
 > 
 > unregistered. ppl. a. Not entered in a register; unrecorded. (first 
 > citation 1604)
 > 
 > The OED has no entry for "unregister".

That's proving that the British can spell (it's the Oxford English
Dictionary, after all), and that Andreas Salomon doesn't know standard
English verb morphology.  I rather suspect that there are quite a few
verbs prefixed with "de-" in common use that aren't in dictionaries,
since it's well understood how "de-" changes the meaning of a verb.

-
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: deregister?

[Jonathan Lundell]

At 10:40 PM -0600 2001-04-29, Paul Fulghum wrote:
>Andres Salomon wrote:
>
>>I'm kind of curious; "deregister" is used quite often in the kernel:
>>
>>pcmcia_deregister_client
>...
>
>>matroxfb_dh_deregisterfb
>>
>>Not to mention in various comments and documentation.  Deregister,
>>according to www.m-w.com (and many other dictionaries), is not a word.
>>Is there some sort of historical significance to this being used, in
>>place of "unregister"?
>
>Linux kernel source vs. the English language.
>One of them will have to bend...
>let's get ready to rumble!
>
>Now that it has been pointed out it will mildly
>irritate people (myself included) until it
>*is* corrected (I guess ignorance was bliss :-)

At 10:03 PM -0400 2001-04-29, Andres Salomon wrote:
>Americans can spell?  Since when?

OED 2nd Ed:

deregister. v. trans. To remove from a register. Hence 
deregistration. (first citation 1925)

unregistered. ppl. a. Not entered in a register; unrecorded. (first 
citation 1604)

The OED has no entry for "unregister".


-- 
/Jonathan Lundell.
-
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.4: Kernel crash, possibly tcp related

[David S. Miller]

Ralf Nyren writes:
 > The problem appears when this value is set to 40481 or higher. For ex:
 > $ tcpblast -d0 -s 40481 another_host 9000
 ...
 > KERNEL: assertion (!skb_queue_empty(>write_queue)) failed at tcp_timer.c(327):
 > tcp_retransmit_timer
 > Unable to handle kernel NULL pointer dereference...

I'm having a devil of a time finding the tcpblast sources on the
net, can you point me to where I can get them?  The one reference
I saw to get the original sources was:

ftp://ftp.xlink.net/pub/network/tcpblast.shar.gz

But even that directory no longer exists.

The kernel error you see is a gross fatal error, the TCP retransmit
timer has fired yet there are no packets on the transmit queue :-)

My current theory is that tcpblast does something erratic when the
error occurs.

Later,
David S. Miller
[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: Lid support for ACPI

[Grover, Andrew]

(btw ACPI 2.0 spec section 12.1.1 discusses this)

> From: Pavel Machek [mailto:[EMAIL PROTECTED]]
> > No, the ACPI standard requires CPUs to shut themselves down before
> > any damage would occur from overheading.  Well, at least the 1.0b
> > version of the standard did; I haven't read 2.0 yet.

> BTW shut themselves down to halt, or shut themselves to 
> *very* low speed?

Both. When a CPU overheats, the OS implements either active (turning on a
fan) or passive (cpu throttling). If the temperature still exceeds the
critical threshold, the OS must shut down.

> Slow down to 10% speed is what my toshiba does. Is there way 
> back from such
> mode?

Once the temperature drops below the active and passive cooling thresholds,
the OS should stop its cooling measures, such as throttling.

That said, I seem to recall your laptop is doing throttling in a non-OS
visible way (BIOS) so I don't know under what circumstances it stops cpu
throttling.

Regards -- Andy

-
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: Sony Memory stick format funnies...

[Matthew Dharm]

I've seen something similar with USB memory stick devices... they don't
seem to report a media change in a way that the VFS layer will understand.

I think this deserves some _serious_ debugging, personally, as this is
going to come back to haunt us over and over again with some types of
memory stick (and possibly other) media devices.

I'd do it, but I don't have a memory stick reader.  Rogier, can you
volunteer some time for this?

Matt

On Sun, Apr 29, 2001 at 10:45:41PM +0200, Rogier Wolff wrote:
> H. Peter Anvin wrote:
> 
> > Rogier Wolff wrote:
> 
> > > The image of the disk (including partition table) is at:
> > > 
> > > ftp://ftp.bitwizard.nl/misc_junk/formatted.img.gz
> > > 
> > > It's 63kb and uncompresses to the 64Mb (almost) that it's sold as.
> > > 
> > 
> > And on at least this kernel (2.4.0) there is nothing funny about it:
> > 
> > : tazenda 13 ; ls -l /mnt
> > total 0
> > -r-xr-xr-x1 root root0 May 23  2000 memstick.ind*
> > : tazenda 14 ; 
> > 
> > Mounting msdos, vfat or umsdos, no change.
> 
> OK. I rebooted the laptop: 
> 
>   Linux version 2.2.13 ([EMAIL PROTECTED]) (gcc version
>   egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Nov 8
>   15:37:25 CET 1999
> 
> which seems to have cleared it. Somehow that directory was still
> cached somewhere (not in the buffer cache) from when there were images
> on the memory stick.
> 
> So, I'm suspecting a dcache bug, that allows something to stay over
> after swapping a removable media device And all this is irrelevant
> as this was on a very old kernel. Sorry to have been wasting your
> time.
> 
>   Roger.
> 
> -- 
> ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> * There are old pilots, and there are bold pilots. 
> * There are also old, bald pilots. 
> -
> 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/

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

S:  Another stupid question?
G:  There's no such thing as a stupid question, only stupid people.
-- Stef and Greg
User Friendly, 7/15/1998

 PGP signature

Re: Dane-Elec PhotoMate Combo

[Matthew Dharm]

I would seriously argue with the "works beautifully" part of that.  

The DPCM code relies on the SDDR09 code, which is horrendously buggy.  It's
also being actively worked on.  I can crash it at will with relatively
simple operations.

Matt

On Sun, Apr 29, 2001 at 02:21:11PM +0200, [EMAIL PROTECTED] wrote:
> From: Matthew Dharm <[EMAIL PROTECTED]>
> 
> > (ii) this card needs usb/storage/dpcm.c which is compiled when
> > CONFIG_USB_STORAGE_DPCM is set, but this variable is missing
> > from usb/Config.in. Add it.
> 
> This config option is considered so immature that it's not ready for the
> kernel config, even as an EXPERIMENTAL.  Use it at your own risk.
> 
> Of course. But the choice is simple. Without it, one has a non-functional
> device. With it, one has a device that works beautifully.

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

NYET! The evil stops here!
-- Pitr
User Friendly, 6/22/1998

 PGP signature

Re: Mounting an external USB host-powered ZIP 250 drive hangs in mount()

[Matthew Dharm]

I see you're using the alternate uhci driver... are hte results the same
with the other UHCI driver?

Can you turn on usb mass storage verbose debuggig (compile option) and then
send me the logs?

Matt

On Sun, Apr 29, 2001 at 07:58:56AM +0200, [EMAIL PROTECTED] wrote:
> I cannot seem to mount my external USB host-powered 250 Mb zip-drive in
> Linux-2.4.3-ac12. This is a freshly rebooted machine, rebooted with the
> zip-drive attached and a zip-disk inside that Windows-2000 will read
> without problems.
> 
> dmesg:
> uhci.c: USB UHCI at I/O 0xc400, IRQ 7
> usb.c: new USB bus registered, assigned bus number 1
> hub.c: USB hub found
> hub.c: 2 ports detected
> uhci.c: USB UHCI at I/O 0xc800, IRQ 7
> usb.c: new USB bus registered, assigned bus number 2
> hub.c: USB hub found
> hub.c: 2 ports detected
> Initializing USB Mass Storage driver...
> usb.c: registered new driver usb-storage
> USB Mass Storage support registered.
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> IP: routing cache hash table of 4096 buckets, 32Kbytes
> TCP: Hash tables configured (established 32768 bind 32768)
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 240k freed
> hub.c: USB new device connect on bus1/1, assigned device number 2
> scsi1 : SCSI emulation for USB Mass Storage devices
>   Vendor: IOMEGAModel: ZIP 250   Rev: 61.T
>   Type:   Direct-Access  ANSI SCSI revision: 02
> Attached scsi removable disk sda at scsi1, channel 0, id 0, lun 0
> sda : READ CAPACITY failed.
> sda : status = 1, message = 00, host = 0, driver = 08 
> sda : extended sense code = 2 
> sda : block size assumed to be 512 bytes, disk size 1GB.  
>  sda: I/O error: dev 08:00, sector 0
>  unable to read partition table
> WARNING: USB Mass Storage data integrity not assured
> USB Mass Storage device found at 2
> ==
> IRQ 7 is an unshared IRQ.
> I've read that the 'READ CAPACITY failed' indicates there is no disk
> in the drive - but there is.
> 
> 
> /proc/scsi/usb-storage-0/1:
>Host scsi1: usb-storage
>Vendor: Iomega
>   Product: USB Zip 250
> Serial Number: 003240BCC4D11622
>  Protocol: Transparent SCSI
> Transport: Bulk
>  GUID: 059b0032003240bcc4d11622
> 
> All seems fine, but when I do
> 
> mount /dev/sda4 /mnt
> 
> the whole kernel hangs, including the keyboard and the network.
> Windows-2000 on the same hardware can access the device. If I strace the
> mount progress, it hangs in
> 
> mount("/dev/sda4", "/mnt", "vfat", 0xc0ed000, 0
> 
> I've searched the web, searched the mailing lists at usb/sourceforge,
> and I seem to be alone in this.
> 
> Hardware:
> 
> Abit VP6, dual P3/866
> 512 Mb memory
> gcc-2.95.3
> SuSE 7.1 basis
> linux-2.4.3-ac12
> 
> Kernel config:
> 
> CONFIG_USB=y
> CONFIG_USB_UHCI_ALT=y
> CONFIG_USB_STORAGE=y
> CONFIG_SCSI=y
> CONFIG_SCSI_DEBUG_QUEUES=y
> CONFIG_SCSI_MULTI_LUN=y
> CONFIG_SCSI_CONSTANTS=y
> CONFIG_SCSI_SYM53C8XX=y
> CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4
> CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
> CONFIG_SCSI_NCR53C8XX_SYNC=20
> CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT=y
> 
> I thought that would do the trick?
> 
> Thanks for any help that prevents me from rebooting into Windows-2000
> every time!
> 
> Jurriaan
> -- 
> I have transcended that phase in my intellectual growth where I discover
> humour in simple freakishness. What exists is real, therefore it is tragic,
> since whatever lives must die. Only fantasy, the vapors rising from sheer
> nonsense, can now excite my laughter.
>   Jack Vance - Lyonesse II - The Green Pearl
> GNU/Linux 2.4.3-ac12 SMP/ReiserFS 2x1743 bogomips load av: 0.05 0.03 0.00

-- 
Matthew Dharm  Home: [EMAIL PROTECTED] 
Maintainer, Linux USB Mass Storage Driver

Way to go, lava boy.
-- Stef to Greg
User Friendly, 3/26/1998

 PGP signature

Re: ICQ masq modules for 2.2?

[Mike A. Harris]

On Mon, 30 Apr 2001, Frank v Waveren wrote:

>Date: Mon, 30 Apr 2001 06:02:22 +0200
>From: Frank v Waveren <[EMAIL PROTECTED]>
>To: Mike A. Harris <[EMAIL PROTECTED]>
>Cc: Linux Kernel mailing list <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: ICQ masq modules for 2.2?
>
>On Sun, Apr 29, 2001 at 04:56:16PM -0400, Mike A. Harris wrote:
>> Any help in obtaining the source for this module would be greatly
>> appreciated.
>
>>From the readme included in the tarball:
>
>Homepage
>
>primary:http://freeshell.org/~djsf/masq-icq/
>alternate:  http://djsf.narod.ru/masq-icq/
>http://www.chat.ru/~djsf/masq-icq/
>http://djsf.webjump.com/masq-icq/
>http://members.xoom.com/djsf/masq-icq/
>http://djsf.tripod.com/masq-icq/
>
>At least some of these work for me... I really wonder why this guy
>didn't go to sourceforge or something, I'm sure there are lots of
>people who would like to properly something as useful as this.

Thanks, someone sent me the source tarball of version 0.56 and
I've got it installed and working great now.  It would indeed be
nice if the project was on sourceforge and easy to find.

What would be even nicer is if the author did any required
cleaning to the patch and submitted it to
Rusty/Alan/Linus/whoever for kernel inclusion along with other
modules already there.  ;o)


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

-
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: ICQ masq modules for 2.2?

[Frank v Waveren]

On Sun, Apr 29, 2001 at 04:56:16PM -0400, Mike A. Harris wrote:
> Any help in obtaining the source for this module would be greatly
> appreciated.

>From the readme included in the tarball:

Homepage

primary:http://freeshell.org/~djsf/masq-icq/
alternate:  http://djsf.narod.ru/masq-icq/
http://www.chat.ru/~djsf/masq-icq/
http://djsf.webjump.com/masq-icq/
http://members.xoom.com/djsf/masq-icq/
http://djsf.tripod.com/masq-icq/

At least some of these work for me... I really wonder why this guy
didn't go to sourceforge or something, I'm sure there are lots of
people who would like to properly something as useful as this.

-- 
Frank v Waveren  Fingerprint: 0EDB 8787
fvw@[var.cx|dse.nl|stack.nl|chello.nl] ICQ#10074100 09B9 6EF5 6425 B855
Public key: http:[EMAIL PROTECTED] 7179 3036 E136 B85D

-
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: Alpha compile problem solved by Andrea (pte_alloc)

[Eric W. Biederman]

Andrea Arcangeli <[EMAIL PROTECTED]> writes:

> On Sun, Apr 29, 2001 at 05:27:10PM -0600, Eric W. Biederman wrote:
> > 
> > Do you know if anyone has fixed the lazy vmalloc code?  I know of
> > as of early 2.4 it was broken on alpha.  At the time I noticed it I didn't
> > have time to persue it, but before I forget to even put in a bug
> > report I thought I'd ask if you know anything about it?
> 
> On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do
> that as you don't need it). As long as you use only 1 entry of the pgd
> for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is
> safe.

Hmm. I was having problems reproducible with
CONFIG_ALPHA_LARGE_VMALLOC n.

Enabling the large vmalloc was my work around, because the large
vmalloc whet back to the prelazy allocation code.

I was getting repeatable problems inside of an mtd driver.  The
problem I had was entries failed to propagate across different tasks.
I think it was something like the first pgd was lazily allocated and
not propagated.   

I don't have a SRM on my 264 alpha so alpha (for reference on which
code paths were followed.

> 
> OTOH x86 is racy and there's no workaround available at the moment.

GH

Well racy is easier to work with than just plain non-functional. 

Eric

-
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: CML2 1.3.3 is available

[jdnfk kjhds]

If only VA Linux had a gonkulator! :-O
They've issued their third earnings warning. I found
the link on http://www.theGloriousMEEPT.com .  


--- "Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> The latest version is always available at
> http://www.tuxedo.org/~esr/cml2/
> 
> Release 1.3.3: Sun Apr 29 23:00:33 EDT 2001
>   * Resync with 2.4.4.
>   * Help texts merged into symbols file; the
> `helpfile' declaration
> is gone.  (Text is merged in from
> Documentation/Configure.help
> at CML2 installation time.)
>   * Tweaked the appearance of inactive help buttons
> by popular demand.
> 
> My clever plan worked.  Less than three hours after
> I pronounced 1.3.1
> "stable", somebody turned in the first crash bug in
> three weeks.  Fortunately
> it was pretty trivial to fix, a loose end from one
> of my speedups.  Fixed in
> yesterday's 1.3.2.
> 
> The big news in this version is that all the help
> texts have been merged into
> the CML2 rules files.  A typical symbol declaration
> now looks like this:
> 
> GONK_5523 'Support for B5523 adaptive gonkulator'
> text
> Say Y here to compile in support for the Bollix 5523
> adaptive gonkulator.
> .
> 
> Help texts are merged into the CML2 symbols file at
> CML2 installation time.
> The `helpfile' declaration is gone.  Among other
> things, this means you no
> longer need to run CML2 inside a kernel source tree;
> you can test the scripts 
> anywhere.
> -- 
>   http://www.tuxedo.org/~esr/;>Eric S.
> Raymond
> 
> See, when the GOVERNMENT spends money, it creates
> jobs; whereas when the money
> is left in the hands of TAXPAYERS, God only knows
> what they do with it.  Bake
> it into pies, probably.  Anything to avoid creating
> jobs.
>   -- Dave Barry
> -
> 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/


__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.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: deregister?

[Paul Fulghum]

Andres Salomon wrote:

> I'm kind of curious; "deregister" is used quite often in the kernel:
> 
> pcmcia_deregister_client
...

> matroxfb_dh_deregisterfb
> 
> Not to mention in various comments and documentation.  Deregister,
> according to www.m-w.com (and many other dictionaries), is not a word.
> Is there some sort of historical significance to this being used, in
> place of "unregister"?

Linux kernel source vs. the English language.
One of them will have to bend...
let's get ready to rumble!

Now that it has been pointed out it will mildly
irritate people (myself included) until it
*is* corrected (I guess ignorance was bliss :-)

Paul Fulghum
[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: CML2 1.3.1, aka "I stick my neck out a mile..."

[volodya]

On Sun, 29 Apr 2001, Eric S. Raymond wrote:

> Anton Altaparmakov <[EMAIL PROTECTED]>:
> > I don't know about whether this is possible with Tcl but have you tried A) 
> > invisible text and/or B) white space character text (e.g. one or more 
> > spaces)? That's the kind of thing I usually try in this situation... Just 
> > an idea...
> 
> I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> do you do invisible text?

Make it the same color as the background.

Vladimir Dergachev


> -- 
>   http://www.tuxedo.org/~esr/;>Eric S. Raymond
> 
> ..every Man has a Property in his own Person. This no Body has any
> Right to but himself.  The Labour of his Body, and the Work of his
> Hands, we may say, are properly his.  The great and chief end
> therefore, of Mens uniting into Commonwealths, and putting themselves
> under Government, is the Preservation of their Property.
>   -- John Locke, "A Treatise Concerning Civil Government"
> -
> 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/

CML2 1.3.3 is available

[Eric S. Raymond]

The latest version is always available at http://www.tuxedo.org/~esr/cml2/

Release 1.3.3: Sun Apr 29 23:00:33 EDT 2001
* Resync with 2.4.4.
* Help texts merged into symbols file; the `helpfile' declaration
  is gone.  (Text is merged in from Documentation/Configure.help
  at CML2 installation time.)
* Tweaked the appearance of inactive help buttons by popular demand.

My clever plan worked.  Less than three hours after I pronounced 1.3.1
"stable", somebody turned in the first crash bug in three weeks.  Fortunately
it was pretty trivial to fix, a loose end from one of my speedups.  Fixed in
yesterday's 1.3.2.

The big news in this version is that all the help texts have been merged into
the CML2 rules files.  A typical symbol declaration now looks like this:

GONK_5523   'Support for B5523 adaptive gonkulator' text
Say Y here to compile in support for the Bollix 5523 adaptive gonkulator.
.

Help texts are merged into the CML2 symbols file at CML2 installation time.
The `helpfile' declaration is gone.  Among other things, this means you no
longer need to run CML2 inside a kernel source tree; you can test the scripts 
anywhere.
-- 
http://www.tuxedo.org/~esr/;>Eric S. Raymond

See, when the GOVERNMENT spends money, it creates jobs; whereas when the money
is left in the hands of TAXPAYERS, God only knows what they do with it.  Bake
it into pies, probably.  Anything to avoid creating jobs.
-- Dave Barry
-
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/

v2.4.4 PCI IRQ 0 / help wanted

[Narang]

. If a device is not found by BIOS can it still be used?
. Why is the USB device getting IRQ 0?
. Why is the Firewire device 8020 unknown?

Attached is output of lspci, syslog, and output of lspci -vv.

Hoping I can get some help. Please CC me any suggestions. Thanks.

lspci


00:00.0 Host bridge: VLSI Technology Inc 82C592-FC1 (rev 01)
00:01.0 ISA bridge: VLSI Technology Inc 82C593-FC1 (rev 01)
00:0d.0 IDE interface: CMD Technology Inc PCI0640 (rev 02)
00:10.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03)
00:11.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+]
00:12.0 SCSI storage controller: BusLogic BT-946C (BA80C30) [MultiMaster 10]
01:04.0 USB Controller: CMD Technology Inc USB0670 (rev 06)
> 01:05.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020

>From syslog
---

Apr 29 17:56:03 shakti kernel: PCI: PCI BIOS revision 2.00 entry at 0xfc9bb, last bus=0
Apr 29 17:56:03 shakti kernel: PCI: Using configuration type 1
Apr 29 17:56:03 shakti kernel: PCI: Probing PCI hardware
Apr 29 17:56:03 shakti kernel: Unknown bridge resource 0: assuming transparent
Apr 29 17:56:03 shakti kernel: Unknown bridge resource 1: assuming transparent
Apr 29 17:56:03 shakti kernel: Unknown bridge resource 2: assuming transparent
> Apr 29 17:56:03 shakti kernel: PCI: Device 01:20 not found by BIOS
> Apr 29 17:56:03 shakti kernel: PCI: Device 01:28 not found by BIOS
...
Apr 29 17:56:06 shakti kernel: usb.c: registered new driver usbdevfs
Apr 29 17:56:06 shakti kernel: usb.c: registered new driver hub
> Apr 29 17:56:06 shakti kernel: PCI: No IRQ known for interrupt pin A of device 
>01:04.0. Please try using pci=biosirq.
Apr 29 17:56:06 shakti kernel: PCI: Setting latency timer of device 01:04.0 to 64
Apr 29 17:56:06 shakti kernel: usb-ohci.c: USB OHCI at membase 0xc8917000, IRQ 0
Apr 29 17:56:06 shakti kernel: usb-ohci.c: usb-01:04.0, CMD Technology Inc USB0670
Apr 29 17:56:08 shakti kernel: usb-ohci.c: USB HC TakeOver failed!
Apr 29 17:56:08 shakti kernel: usb.c: USB bus -1 deregistered
Apr 29 17:56:08 shakti kernel: usb.c: deregistering driver usbdevfs
Apr 29 17:56:08 shakti kernel: usb.c: deregistering driver hub

lspci -vv
-

00:00.0 Host bridge: VLSI Technology Inc 82C592-FC1 (rev 01)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B-
Capabilities: 

00:11.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (prog-if 00 
[VGA])
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- 

01:05.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 (prog-if 10 
[OHCI])
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- 
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 

-
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: X15 alpha release: as fast as TUX bu

[Rick Hohensee]

Jim Gettys
>The "put the time into a magic location in shared memory" goes back, as
>far as I know, to Bob Scheifler or myself for the X Window System,
>sometime
>around 1984 or 1985: we put it into a page of shared memory where we used
>a circular buffer scheme to put input events (keyboard/mice), so that
>we could avoid the read system call overhead to get these events (and
>more importantly, check between each request if there was input to
>process).  I don't think we ever claimed it was novel, just that we did

Perhaps you'd seen an Amiga, and jealousy led to innovation. This is about
when the Amiga came out, IIRC. AmigaDos is based on Tripos from Martin
Richards at Cambridge, which was designed from the ground up to be
"single-user, multi-tasking" in full view of the pre-existing elegance of
UNIX. There is no MMU. One bad app takes the box down, but there are no
seams and things scream when they work. There are some things about the
Amiga UI that I want to go over again some time. My vague recollection is
that devices UI served multiple readers implicitly. The structure of the
code was nice too. Everything in linked lists from address 04.
Execbase, my old IRC nick :o)

Richards now has a beta port of Tripos to run on Linux called Cintpos.
It's in BCPL of course, which nowadays can compile itself in 8 seconds on
a P450. I had the pleasure of getting a thankyou from mr for noting that
you have to enable shared memory in your Linux kernel to run Cintpos.

Rick Hohensee
www.clienux.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: CML2 1.3.1, aka "I stick my neck out a mile..."

[Alexander Viro]

On Sun, 29 Apr 2001, Eric S. Raymond quoted:

> Anton Altaparmakov <[EMAIL PROTECTED]>:
> > I don't know about whether this is possible with Tcl but have you tried A) 
> > invisible text and/or B) white space character text (e.g. one or more 
> > spaces)? That's the kind of thing I usually try in this situation... Just 
> > an idea...

wrote

> I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> do you do invisible text?

and sigged
> -- 
>   http://www.tuxedo.org/~esr/;>Eric S. Raymond
> 
> ..every Man has a Property in his own Person. This no Body has any
> Right to but himself.  The Labour of his Body, and the Work of his
> Hands, we may say, are properly his.  The great and chief end
> therefore, of Mens uniting into Commonwealths, and putting themselves
> under Government, is the Preservation of their Property.
>   -- John Locke, "A Treatise Concerning Civil Government"

Eric, it's getting tiresome.  Kindly learn what the fsck McQ is, OK?

/me abstains from attaching Kibo's .sig - 1Mb of PDF is unfortunately
over the top for l-k...

-
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: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[John Cowan]

Eric S. Raymond scripsit:

> I tried whitespace, but the default Tkinter font isn't fixed-width.  How
> do you do invisible text?

Set the background color and the foreground color to be the same.

-- 
John Cowan   [EMAIL PROTECTED]
One art/there is/no less/no more/All things/to do/with sparks/galore
--Douglas Hofstadter
-
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.4 Sound corruption [PATCH] NEW, ignore previous patch

[Charl P. Botha]

Please IGNORE the previous patch, it was faulty (I blame it on the time of
day).  The one attached with this is guaranteed to be perfect(tm).

On Mon, Apr 30, 2001 at 03:06:26AM +0200, Charl P. Botha wrote:
> Attached is a patch to the quirks.c in linux kernel 2.4.4 that fixes the
> sound corruption problem (thanks to Dan Hollis for the info).  Do I have to
> send this anywhere else as well?

-- 
charl p. botha  | computer graphics and cad/cam 
http://cpbotha.net/ | http://www.cg.its.tudelft.nl/


--- quirks.c-2.4.4  Mon Apr 30 01:50:36 2001
+++ quirks.cMon Apr 30 03:54:08 2001
@@ -88,23 +88,44 @@
  * VIA Apollo KT133 needs PCI latency patch
  * Made according to a windows driver based patch by George E. Breese
  * see PCI Latency Adjust on http://www.viahardware.com/download/viatweak.shtm
+ *  Also see http://home.tiscalinet.de/au-ja/review-kt133a-1-en.html for
+ *  the info on which Mr Breese based his work.
  */
 static void __init quirk_vialatency(struct pci_dev *dev)
 {
u8 r70;
-
-   printk(KERN_INFO "Applying VIA PCI latency patch.\n");
-   /*
-*In register 0x70, mask off bit 2 (PCI Master read caching)
-*and 1 (Delay Transaction)
+   u8 rev;
+   struct pci_dev *vt82c686;
+   
+   
+   /* we want to look for a VT82C686 south bridge, and then apply the via latency
+* patch if we find that it's a 686B (by revision) <[EMAIL PROTECTED]>
 */
-   pci_read_config_byte(dev, 0x70, );
-   r70 &= 0xf9;
-   pci_write_config_byte(dev, 0x70, r70);
-   /*
-*Turn off PCI Latency timeout (set to 0 clocks)
-*/
-   pci_write_config_byte(dev, 0x75, 0x80);
+   vt82c686 = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, NULL);
+   if (vt82c686)   
+   {
+   pci_read_config_byte(vt82c686, PCI_CLASS_REVISION, );
+   /* 0x40 - 0x4f == 686B, 0x10 - 0x2f == 686A; thanks Dan Hollis */
+   if (rev >= 0x40 && rev <= 0x4f)
+   {
+   printk(KERN_INFO "Applying VIA PCI latency patch (found 
+VT82C686B).\n");
+   /*
+*In register 0x70, mask off bit 2 (PCI Master read 
+caching)
+*and 1 (Delay Transaction)
+*/
+   pci_read_config_byte(dev, 0x70, );
+   r70 &= 0xf9;
+   pci_write_config_byte(dev, 0x70, r70);
+   /*
+*Turn off PCI Latency timeout (set to 0 clocks)
+*/
+   pci_write_config_byte(dev, 0x75, 0x80);
+   }
+   else
+   {
+   printk(KERN_INFO "Found VT82C686A, not applying VIA latency 
+patch.\n");
+   }
+   } /* if (vt82c686) ... */
 }
 
 /*

Re: deregister?

[Andres Salomon]

On Sun, Apr 29, 2001 at 10:27:29PM -0300, Rik van Riel wrote:
> 
> On Sun, 29 Apr 2001, Andres Salomon wrote:
> 
> > Not to mention in various comments and documentation.  Deregister,
> > according to www.m-w.com (and many other dictionaries), is not a word.
> > Is there some sort of historical significance to this being used, in
> > place of "unregister"?
> 
> Yes, we're all anti-american terrorists who plan to make the
> US economy collapse by inventing lots of new words which will
> have to be added to the dictionary, making the US economy
> unable to support the ever-growing dictionaries and ensuring
> the Americans will be unable to (learn to) spell, leaving them

Americans can spell?  Since when?

> dead in the water if there's ever a linguistic war between
> them and the UK.
> 
> Cunning, isn't it?
> 
> cheers,
> 
> Rik
> --
> Virtual memory is like a game you can't win;
> However, without VM there's truly nothing to lose...
> 
> http://www.surriel.com/   http://distro.conectiva.com/
> 
> Send all your spam to [EMAIL PROTECTED] (spam digging piggy)
> 
>

Well, at least you provided a reason. ;P  That would be incredibly lame
if the answer turned out to be, "The original author made a mistake,
and no one cared enough to fix it.  API users (who are constantly
mixing up unregister and deregister) be damned."

-- 
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, [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: Severe trashing in 2.4.4

[David S. Miller]

Frank de Lange writes:
 > Hm, 'twould be nice to know WHAT to look for (if only for educational
 > purposes), but ok:

We're looking to see if queue collapsing is occuring on
receive.

Later,
David S. Miller
[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: deregister?

[Rik van Riel]

On Sun, 29 Apr 2001, Andres Salomon wrote:

> Not to mention in various comments and documentation.  Deregister,
> according to www.m-w.com (and many other dictionaries), is not a word.
> Is there some sort of historical significance to this being used, in
> place of "unregister"?

Yes, we're all anti-american terrorists who plan to make the
US economy collapse by inventing lots of new words which will
have to be added to the dictionary, making the US economy
unable to support the ever-growing dictionaries and ensuring
the Americans will be unable to (learn to) spell, leaving them
dead in the water if there's ever a linguistic war between
them and the UK.

Cunning, isn't it?

cheers,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/ http://distro.conectiva.com/

Send all your spam to [EMAIL PROTECTED] (spam digging piggy)

-
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: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

Anton Altaparmakov <[EMAIL PROTECTED]>:
> I don't know about whether this is possible with Tcl but have you tried A) 
> invisible text and/or B) white space character text (e.g. one or more 
> spaces)? That's the kind of thing I usually try in this situation... Just 
> an idea...

I tried whitespace, but the default Tkinter font isn't fixed-width.  How
do you do invisible text?
-- 
http://www.tuxedo.org/~esr/;>Eric S. Raymond

..every Man has a Property in his own Person. This no Body has any
Right to but himself.  The Labour of his Body, and the Work of his
Hands, we may say, are properly his.  The great and chief end
therefore, of Mens uniting into Commonwealths, and putting themselves
under Government, is the Preservation of their Property.
-- John Locke, "A Treatise Concerning Civil Government"
-
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: CML2 1.3.1, aka "I stick my neck out a mile..."

[Anton Altaparmakov]

At 23:35 29/04/2001, Eric S. Raymond wrote:
>John Stoffel <[EMAIL PROTECTED]>:
> > Also, the buttons on the right hand side for HELP, are wider when they
> > have text in them, but slightly narrower when they are blank.  They
> > should be the same width no matter what.  It looks ragged and ugly.
>
>I know.  Sadly, I couldn't find a way to coerce Tcl into doing this right.

I don't know about whether this is possible with Tcl but have you tried A) 
invisible text and/or B) white space character text (e.g. one or more 
spaces)? That's the kind of thing I usually try in this situation... Just 
an idea...

Best regards,

 Anton


-- 
Anton Altaparmakov  (replace at with @)
Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
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: deregister?

[Gregory Maxwell]

On Sun, Apr 29, 2001 at 09:10:49PM -0400, Andres Salomon wrote:
[snip]
> Not to mention in various comments and documentation.  Deregister,
> according to www.m-w.com (and many other dictionaries), is not a word.
> Is there some sort of historical significance to this being used, in
> place of "unregister"?

I purpose that we fix this horrible spelling error right away and get it
into 2.4.5! :)

(up yours binary-only module authors! :) )
-
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: ServerWorks LE and MTRR

[Dave Jones]

On Sun, 29 Apr 2001, Steffen Persvold wrote:

> ...
> Therefore please consider my small patch to allow the
> good ones to be able to use write-combining. I have several rev 06 and they are
> working fine with this patch.
> ...

ObPedant:
 Can you make a note of this in the comment a few lines above also,
so others who stumble across this code know why the check is there.
afaik, this chipset info isn't public, so it may not be obvious
in the future why the check has been added.

Just something simple like..

-/* ServerWorks LE chipsets have problems with  write-combining
+/* ServerWorks LE chipsets < rev 6 have problems with write-combining
   Don't allow it and  leave room for other chipsets to be tagged */


Otherwise, if this works for everyone else with rev 6+ serverworks
chipsets, looks ok to me.

regards,

Dave.

-- 
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs

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

deregister?

[Andres Salomon]

I'm kind of curious; "deregister" is used quite often in the kernel:

pcmcia_deregister_client
pcmcia_deregister_erase_queue
misc_deregister
atm_dev_deregister
atm_proc_dev_deregister
usb_deregister_bus
usb_deregister
usb_serial_deregister
scsi_deregister_blocked_host
matroxfb_dh_deregisterfb

Not to mention in various comments and documentation.  Deregister,
according to www.m-w.com (and many other dictionaries), is not a word.
Is there some sort of historical significance to this being used, in
place of "unregister"?


-- 
"... being a Linux user is sort of like living in a house inhabited
by a large family of carpenters and architects. Every morning when
you wake up, the house is a little different. Maybe there is a new
turret, or some walls have moved. Or perhaps someone has temporarily
removed the floor under your bed." - Unix for Dummies, 2nd Edition
-- found in the .sig of Rob Riggs, [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: 2.4.4 Sound corruption [PATCH]

[Charl P. Botha]

Attached is a patch to the quirks.c in linux kernel 2.4.4 that fixes the
sound corruption problem (thanks to Dan Hollis for the info).  Do I have to
send this anywhere else as well?

On Sun, Apr 29, 2001 at 05:29:05PM -0700, Dan Hollis wrote:
> On Mon, 30 Apr 2001, Charl P. Botha wrote:
> > I have removed this code and everything is now fine on my system.  The
> > problem is that the 686A and 686B have the same PCI IDs, else I would have
> > submitted a patch.
> 
> 686a is rev 0x10 - 0x2f, 686b is rev 0x40 - 0x4f.
> 
> The fixup code should take this into account.
> 
> -Dan

-- 
charl p. botha  | computer graphics and cad/cam 
http://cpbotha.net/ | http://www.cg.its.tudelft.nl/


--- quirks.c-2.4.4  Mon Apr 30 01:50:36 2001
+++ quirks.cMon Apr 30 03:01:28 2001
@@ -88,23 +88,36 @@
  * VIA Apollo KT133 needs PCI latency patch
  * Made according to a windows driver based patch by George E. Breese
  * see PCI Latency Adjust on http://www.viahardware.com/download/viatweak.shtm
+ *  Also see http://home.tiscalinet.de/au-ja/review-kt133a-1-en.html for
+ *  the info on which Mr Breese based his work.
  */
 static void __init quirk_vialatency(struct pci_dev *dev)
 {
u8 r70;
+   u8 rev;
 
-   printk(KERN_INFO "Applying VIA PCI latency patch.\n");
-   /*
-*In register 0x70, mask off bit 2 (PCI Master read caching)
-*and 1 (Delay Transaction)
-*/
-   pci_read_config_byte(dev, 0x70, );
-   r70 &= 0xf9;
-   pci_write_config_byte(dev, 0x70, r70);
-   /*
-*Turn off PCI Latency timeout (set to 0 clocks)
-*/
-   pci_write_config_byte(dev, 0x75, 0x80);
+   /* we test for 686B by revision, only apply patch then ([EMAIL PROTECTED]) */
+   pci_read_config_byte(dev, PCI_CLASS_REVISION, );
+/* 0x40 - 0x4f == 686B, 0x10 - 0x2f == 686A; thanks Dan Hollis */
+   if (rev >= 0x40 && rev <= 0x4f)
+   {
+   printk(KERN_INFO "Applying VIA PCI latency patch (found 
+VT82C686B).\n");
+   /*
+   *In register 0x70, mask off bit 2 (PCI Master read caching)
+   *and 1 (Delay Transaction)
+   */
+   pci_read_config_byte(dev, 0x70, );
+   r70 &= 0xf9;
+   pci_write_config_byte(dev, 0x70, r70);
+   /*
+*Turn off PCI Latency timeout (set to 0 clocks)
+*/
+   pci_write_config_byte(dev, 0x75, 0x80);
+   }
+   else
+   {
+   printk(KERN_INFO "Found VT82C686A, not applying VIA latency patch.\n");
+   }
 }
 
 /*
@@ -312,7 +325,7 @@
{ PCI_FIXUP_FINAL,  PCI_VENDOR_ID_INTEL,PCI_DEVICE_ID_INTEL_82443BX_2, 
 quirk_natoma },
{ PCI_FIXUP_FINAL,  PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_5597, 
 quirk_nopcipci },
{ PCI_FIXUP_FINAL,  PCI_VENDOR_ID_SI,   PCI_DEVICE_ID_SI_496,  
 quirk_nopcipci },
-   { PCI_FIXUP_FINAL,  PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_8363_0,  
 quirk_vialatency },
+   { PCI_FIXUP_FINAL,  PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_82C686,  
+ quirk_vialatency },
{ PCI_FIXUP_FINAL,  PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_82C597_0,
 quirk_viaetbf },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_82C597_0,
 quirk_vt82c598_id },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA,  PCI_DEVICE_ID_VIA_82C586_3,
 quirk_vt82c586_acpi },

Re: 2.4.4 Sound corruption [FIXED]

[Dan Hollis]

On Mon, 30 Apr 2001, Charl P. Botha wrote:
> I have removed this code and everything is now fine on my system.  The
> problem is that the 686A and 686B have the same PCI IDs, else I would have
> submitted a patch.

686a is rev 0x10 - 0x2f, 686b is rev 0x40 - 0x4f.

The fixup code should take this into account.

-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: Severe trashing in 2.4.4

[Frank de Lange]

On Sun, Apr 29, 2001 at 04:45:00PM -0700, David S. Miller wrote:
> 
> Frank de Lange writes:
>  > What do you want me to check for? /proc/net/netstat is a rather busy place...
> 
> Just show us the contents after you reproduce the problem.
> We just want to see if a certain event if being triggered.

Hm, 'twould be nice to know WHAT to look for (if only for educational
purposes), but ok:

 http://www.unternet.org/~frank/projects/linux2404/2404-meminfo/

it contains an extra set of files, named p_n_netstat.*. Same as before, the
.diff contains one-second interval diffs.

Cheers//Frank
-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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: X15 alpha release: as fast as TUX but in user space (fwd)

[Andrea Arcangeli]

On Sun, Apr 29, 2001 at 04:18:27PM -0400, Gregory Maxwell wrote:
> having both the code and a comprehensive jump-table might become tough in a

In the x86-64 implementation there's no jump table. The original design
had a jump table but Peter raised the issue that indirect jumps are very
costly and he suggested to jump to a fixed virtual address instead, I
agreed with his suggestion. So this is what I implemented for x86-64
with regard to the userspace vsyscall API (which will be used by glibc):

enum vsyscall_num {
__NR_vgettimeofday,
__NR_vtime,
};

#define VSYSCALL_ADDR(vsyscall_nr) (VSYSCALL_START+VSYSCALL_SIZE*(vsyscall_nr))

the linker can prelink the vsyscall virtual address into the binary as a
weak symbol and the dynamic linker will need to patch it only if
somebody is overriding the weak symbol with a LD_PRELOAD.

Virtual address space is relatively cheap. Currently the 64bit
vgettimeofday bytecode + data is nearly 200 bytes, and the first two
slots are large 512bytes each. So with 1024 bytes we do the whole thing,
and we still have space for further 6 vsyscalls without paying any
additional tlb entry.

(the implementation of the above #define will change shortly but the
VSYSCALL_ADDR() API for glibc will remain the same)

Andrea
-
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.4 Sound corruption [FIXED]

[Charl P. Botha]

I have found the problem.  The VIA latency patch in
linux/drivers/pci/quirks.c at line 92 (quirk_vialatency()) should NOT be
applied for the VIA VT82C686A (only for the 686B).  On my machine (at least)
it's causing problems (as documented below) and this bug (along with fix) is
only applicable on the 686B southbridge.

I have removed this code and everything is now fine on my system.  The
problem is that the 686A and 686B have the same PCI IDs, else I would have
submitted a patch.

Should I send this information anywhere else to make sure it gets applied in
new kernels?

On Mon, Apr 30, 2001 at 01:29:15AM +0200, Charl P. Botha wrote:
> FWIW, I have established that my sound broke between 2.4.4-pre5 and
> 2.4.4-pre6.  I.e. in pre5 it works and in pre6 it doesn't, same .config.  If
> anyone has any clues, I'd be glad to know.
> 
> On Sun, Apr 29, 2001 at 04:55:01PM +0200, Charl P. Botha wrote:
> > 2.4.4 has broken sound here in a very strange way.  I have a debian testing
> > system, Abit KT7 (thus VIA KT133 chipset) and SB PC128 (es1371-based) sound
> > card.
> > 
> > Up until 2.4.3 everything was fine.  Now, however, when I send _anything_ to
> > /dev/dsp, I get continuous high-pitched beeping (nothing remotely resembling
> > what the sound card should be doing).  
> > 
> > The strange thing is that when I cause hard disk activity (find / -name "*")
> > the correct sound is produced in time with hard disc accesses (I have tried
> > this with DMA enabled and disabled on the drive, same results).  Also, when I
> > switch desktops (icewm, XFree86 4.0.2, Nvidia 0.9.767 drivers) the correct
> > sound is (very) momentarily produced (almost non-detectibly).  After these
> > periods of lucidity, the sound card returns to its high-pitched cacophony.
> > 
> > I have attached copies of both /proc/interrupts and /proc/pci.  If anyone
> > requires more information, please say the word.  I am not subscribed to this
> > list.
> > 
> > Best regards,
> > 
> > -- 
> > charl p. botha  | computer graphics and cad/cam 
> > http://cpbotha.net/ | http://www.cg.its.tudelft.nl/
> 
> >CPU0   
> >   0: 320161  XT-PIC  timer
> >   1:  19658  XT-PIC  keyboard
> >   2:  0  XT-PIC  cascade
> >   8:  1  XT-PIC  rtc
> >   9:  0  XT-PIC  usb-uhci, usb-uhci
> >  10: 272660  XT-PIC  nvidia
> >  11:  93973  XT-PIC  eth0, es1371
> >  12:  42760  XT-PIC  PS/2 Mouse
> >  14:  39388  XT-PIC  ide0
> >  15:  5  XT-PIC  ide1
> > NMI:  0 
> > ERR:  0
> 
> > PCI devices found:
> >   Bus  0, device   0, function  0:
> > Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 3).
> >   Prefetchable 32 bit memory at 0xd800 [0xdbff].
> >   Bus  0, device   1, function  0:
> > PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (rev 0).
> >   Master Capable.  No bursts.  Min Gnt=12.
> >   Bus  0, device   7, function  0:
> > ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 34).
> >   Bus  0, device   7, function  1:
> > IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 16).
> >   Master Capable.  Latency=32.  
> >   I/O at 0xd000 [0xd00f].
> >   Bus  0, device   7, function  2:
> > USB Controller: VIA Technologies, Inc. UHCI USB (rev 16).
> >   IRQ 9.
> >   Master Capable.  Latency=32.  
> >   I/O at 0xd400 [0xd41f].
> >   Bus  0, device   7, function  3:
> > USB Controller: VIA Technologies, Inc. UHCI USB (#2) (rev 16).
> >   IRQ 9.
> >   Master Capable.  Latency=32.  
> >   I/O at 0xd800 [0xd81f].
> >   Bus  0, device   7, function  4:
> > Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 48).
> >   IRQ 11.
> >   Bus  0, device   8, function  0:
> > Multimedia video controller: Brooktree Corporation Bt878 (rev 17).
> >   IRQ 9.
> >   Master Capable.  Latency=32.  Min Gnt=16.Max Lat=40.
> >   Prefetchable 32 bit memory at 0xde00 [0xde000fff].
> >   Bus  0, device   8, function  1:
> > Multimedia controller: Brooktree Corporation Bt878 (rev 17).
> >   IRQ 9.
> >   Master Capable.  Latency=32.  Min Gnt=4.Max Lat=255.
> >   Prefetchable 32 bit memory at 0xde001000 [0xde001fff].
> >   Bus  0, device   9, function  0:
> > Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 16).
> >   IRQ 11.
> >   Master Capable.  Latency=32.  Min Gnt=32.Max Lat=64.
> >   I/O at 0xdc00 [0xdcff].
> >   Non-prefetchable 32 bit memory at 0xde002000 [0xde0020ff].
> >   Bus  0, device  13, function  0:
> > Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 8).
> >   IRQ 11.
> >   Master Capable.  Latency=32.  Min Gnt=12.Max Lat=128.
> >   I/O at 0xe000 [0xe03f].
> >   Bus  1, device   0, function  0:
> > VGA compatible controller: nVidia Corporation NV11 (rev 

Re: X15 alpha release: as fast as TUX but in user space (fwd)

[Andrea Arcangeli]

On Sun, Apr 29, 2001 at 09:38:04PM +0200, Jamie Lokier wrote:
> Fwiw, modern x86 has global TLB entries too.

my x86-64 implementation is marking the tlb entry global of course (so
it's not flushed during context switch):

#define __PAGE_KERNEL_VSYSCALL \
(_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED)
#define MAKE_GLOBAL(x) __pgprot((x) | _PAGE_GLOBAL)
#define PAGE_KERNEL_VSYSCALL MAKE_GLOBAL(__PAGE_KERNEL_VSYSCALL)

static void __init map_vsyscall(void)
{
extern char __vsyscall_0;
unsigned long physaddr_page0 = (unsigned long) &__vsyscall_0 - 
__START_KERNEL_map;

__set_fixmap(VSYSCALL_FIRST_PAGE, physaddr_page0, PAGE_KERNEL_VSYSCALL);
}

Andrea
-
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: Alpha compile problem solved by Andrea (pte_alloc)

[Andrea Arcangeli]

On Sun, Apr 29, 2001 at 05:27:10PM -0600, Eric W. Biederman wrote:
> 
> Do you know if anyone has fixed the lazy vmalloc code?  I know of
> as of early 2.4 it was broken on alpha.  At the time I noticed it I didn't
> have time to persue it, but before I forget to even put in a bug
> report I thought I'd ask if you know anything about it?

On alpha it's racy if you set CONFIG_ALPHA_LARGE_VMALLOC y (so don't do
that as you don't need it). As long as you use only 1 entry of the pgd
for the whole vmalloc space (CONFIG_ALPHA_LARGE_VMALLOC n) alpha is
safe.

OTOH x86 is racy and there's no workaround available at the moment.

Andrea
-
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.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda

[Matthias Andree]

On Sun, 29 Apr 2001, J . A . Magallon wrote:

> >  Command found on device queue
> > aic7xxx_abort returns 8194
> 
> I have seen blaming for this error to aic7xxx new driver prior to version
> 6.1.11. It was included in the 2.4.3-ac series, but its has not got into
> main 2.4.4 (there is still 6.1.5). Everything needs its time.

Since the official aic7xxx site doesn't carry a patch against 2.4.4 yet
(just 2.4.3) which has cosmetic issues when being patched, I made a
patch against 2.4.4: I took the 2.4.3-aic7xxx-6.1.12 patch, applied to
2.4.4, bumped the version to read -ma1 in EXTRAVERSION, and made a new
patch against vanilla 2.4.4, to be found at:

*** WARNING BELOW ***

http://mandree.home.pages.de/kernelpatches/v2.4/v2.4.4/
 72k linux-2.4.4-aic7xxx-to-6.1.12.patch.gz

Apply with patch -p1.

NOTE: Do not expect this patch to last until after either Justin has a
patch against 2.4.4 available or 2.4.5 has been released.

*** WARNING *** I did not yet try to boot it, that will have to wait
until later.
-
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: 8139too in 2.4.4 Hanging/Locking

[Ignacio Monge]

The same thing happens to me. I've tried to start my ethernet, but my
system hangs and, after a forced restart, the BIOS has cleared all my
setup configuration (!).
kernel 2.4.4 / modutils 2.4.5
VIA 868a, Athlon Thunderbidth 1 Ghz,  384 Mb RAM. Mandrake 8. Gcc 2.96.

cat /proc/pci
 [...
  Bus  0, device  12, function  0:
Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev
16).
  IRQ 11.
  Master Capable.  Latency=32.  Min Gnt=32.Max Lat=64.
  I/O at 0x9000 [0x90ff].
  Non-prefetchable 32 bit memory at 0xde80 [0xde8000ff].

...]

lspci -vv:
[...
00:0c.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX
(rev 10)
Subsystem: Accton Technology Corporation EN-1207D Fast Ethernet Adapter
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR-  [disabled] [size=64K]
Capabilities: 
...]

I need some help.

Thanks
-
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.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda

[Steve 'Denali' McKnelly]

Ahh... It doesn't even get that far... It just dies with the
undefined symbols...

-Original Message-
From: David Relson [mailto:[EMAIL PROTECTED]]
Sent: Sunday, April 29, 2001 11:32 AM
To: Steve 'Denali' McKnelly
Cc: Linux-Kernel mailing list
Subject: RE: 2.4.3 2.4.4pre8: aic7xxx showstopper bug fails to detect
sda


At 12:17 PM 4/29/01, Steve 'Denali' McKnelly wrote:
>Howdy J.A.,
>
> Let me ask a possibly stupid question... How do you tell
>what version of the Gibbs Adaptec driver you're using?  Did I
>misunderstand you when you said the 2.4.4 kernel is using 6.1.5?
>Also, did I understand you to say the 6.1.12 version will fix
>my unresolved symbol problem?
>
>Thanks,
>Steve

Steve,

A message saying (roughly) AIC7XXX 6.1.xxx appears while the kernel is 
loading.  You can also grep the aic7xxx.c source file or run the strings 
command ( strings /lib/modules/2.4.4/kernel/drivers/scsi/aic7xxx ).

I'm not sure about your undefined symbols problem, but I was able to build 
2.4.4 with 6.1.11 with no trouble.

David


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   Ann Arbor, MI 48103
www.osagesoftware.com  tel:  734.821.8800

-
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: Alpha compile problem solved by Andrea (pte_alloc)

[Eric W. Biederman]

Do you know if anyone has fixed the lazy vmalloc code?  I know of
as of early 2.4 it was broken on alpha.  At the time I noticed it I didn't
have time to persue it, but before I forget to even put in a bug
report I thought I'd ask if you know anything about it?

Eric
-
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.4 Sound corruption

[Charl P. Botha]

FWIW, I have established that my sound broke between 2.4.4-pre5 and
2.4.4-pre6.  I.e. in pre5 it works and in pre6 it doesn't, same .config.  If
anyone has any clues, I'd be glad to know.

On Sun, Apr 29, 2001 at 04:55:01PM +0200, Charl P. Botha wrote:
> 2.4.4 has broken sound here in a very strange way.  I have a debian testing
> system, Abit KT7 (thus VIA KT133 chipset) and SB PC128 (es1371-based) sound
> card.
> 
> Up until 2.4.3 everything was fine.  Now, however, when I send _anything_ to
> /dev/dsp, I get continuous high-pitched beeping (nothing remotely resembling
> what the sound card should be doing).  
> 
> The strange thing is that when I cause hard disk activity (find / -name "*")
> the correct sound is produced in time with hard disc accesses (I have tried
> this with DMA enabled and disabled on the drive, same results).  Also, when I
> switch desktops (icewm, XFree86 4.0.2, Nvidia 0.9.767 drivers) the correct
> sound is (very) momentarily produced (almost non-detectibly).  After these
> periods of lucidity, the sound card returns to its high-pitched cacophony.
> 
> I have attached copies of both /proc/interrupts and /proc/pci.  If anyone
> requires more information, please say the word.  I am not subscribed to this
> list.
> 
> Best regards,
> 
> -- 
> charl p. botha  | computer graphics and cad/cam 
> http://cpbotha.net/ | http://www.cg.its.tudelft.nl/

>CPU0   
>   0: 320161  XT-PIC  timer
>   1:  19658  XT-PIC  keyboard
>   2:  0  XT-PIC  cascade
>   8:  1  XT-PIC  rtc
>   9:  0  XT-PIC  usb-uhci, usb-uhci
>  10: 272660  XT-PIC  nvidia
>  11:  93973  XT-PIC  eth0, es1371
>  12:  42760  XT-PIC  PS/2 Mouse
>  14:  39388  XT-PIC  ide0
>  15:  5  XT-PIC  ide1
> NMI:  0 
> ERR:  0

> PCI devices found:
>   Bus  0, device   0, function  0:
> Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 3).
>   Prefetchable 32 bit memory at 0xd800 [0xdbff].
>   Bus  0, device   1, function  0:
> PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (rev 0).
>   Master Capable.  No bursts.  Min Gnt=12.
>   Bus  0, device   7, function  0:
> ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 34).
>   Bus  0, device   7, function  1:
> IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 16).
>   Master Capable.  Latency=32.  
>   I/O at 0xd000 [0xd00f].
>   Bus  0, device   7, function  2:
> USB Controller: VIA Technologies, Inc. UHCI USB (rev 16).
>   IRQ 9.
>   Master Capable.  Latency=32.  
>   I/O at 0xd400 [0xd41f].
>   Bus  0, device   7, function  3:
> USB Controller: VIA Technologies, Inc. UHCI USB (#2) (rev 16).
>   IRQ 9.
>   Master Capable.  Latency=32.  
>   I/O at 0xd800 [0xd81f].
>   Bus  0, device   7, function  4:
> Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 48).
>   IRQ 11.
>   Bus  0, device   8, function  0:
> Multimedia video controller: Brooktree Corporation Bt878 (rev 17).
>   IRQ 9.
>   Master Capable.  Latency=32.  Min Gnt=16.Max Lat=40.
>   Prefetchable 32 bit memory at 0xde00 [0xde000fff].
>   Bus  0, device   8, function  1:
> Multimedia controller: Brooktree Corporation Bt878 (rev 17).
>   IRQ 9.
>   Master Capable.  Latency=32.  Min Gnt=4.Max Lat=255.
>   Prefetchable 32 bit memory at 0xde001000 [0xde001fff].
>   Bus  0, device   9, function  0:
> Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 16).
>   IRQ 11.
>   Master Capable.  Latency=32.  Min Gnt=32.Max Lat=64.
>   I/O at 0xdc00 [0xdcff].
>   Non-prefetchable 32 bit memory at 0xde002000 [0xde0020ff].
>   Bus  0, device  13, function  0:
> Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 8).
>   IRQ 11.
>   Master Capable.  Latency=32.  Min Gnt=12.Max Lat=128.
>   I/O at 0xe000 [0xe03f].
>   Bus  1, device   0, function  0:
> VGA compatible controller: nVidia Corporation NV11 (rev 161).
>   IRQ 10.
>   Master Capable.  Latency=248.  Min Gnt=5.Max Lat=1.
>   Non-prefetchable 32 bit memory at 0xdc00 [0xdcff].
>   Prefetchable 32 bit memory at 0xd000 [0xd7ff].


-- 
charl p. botha  | computer graphics and cad/cam 
http://cpbotha.net/ | http://www.cg.its.tudelft.nl/
-
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: best zero-copy example?

[David S. Miller]

Albert D. Cahalan writes:
 > 
 > What would be the cleanest driver that does everything right?

All of 3c59x, acenic, sunhme, sungem do all of ipv4 right.

sunhme and sungem get ipv6 right as well because they just treat the
checksummed area as an opaque buffer, whereas the other chips really
do checksummming in an ipv4 specific way.

You can check for this "ipv4 only checksumming" feature attribute
being set in the driver, via NETIF_F_IP_CSUM.

The smarter chips which checksum in a protocol independant way will
use NETIF_F_HW_CSUM.

Later,
David S. Miller
[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 autofix?

[Chris Mason]

On Sunday, April 29, 2001 02:48:27 PM -0700 putter <[EMAIL PROTECTED]>
wrote:

> Hi,
> I am kernel newbie, especially with logging filesystems.
> Now I am using Mandrake 7.1 with 2.4.3 kernel and imon patch
> and NVidia drivers compiled into the kernel.
 ^^^

The binary only nvidia drivers make it a bit hard for us to debug.

> Now, all my partitions are ReiserFS. I usually play quake once
> or twice a day. Sometimes graphics subsystem freezes up, so it takes
> keyboard input. Caps and Numlock are working fine, unless I try to kill
> X with ctrlalt-backspace. So I reset my machine with hardware switch.

Check your /var/log/messages.  You probably have messages from reiserfs.
Send along an lspci so we can see what your hardware is.

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

Re: 2.4.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda

[Matthias Andree]

On Sun, 29 Apr 2001, Steve 'Denali' McKnelly wrote:

>   Let me ask a possibly stupid question... How do you tell
> what version of the Gibbs Adaptec driver you're using?  Did I
> misunderstand you when you said the 2.4.4 kernel is using 6.1.5?
> Also, did I understand you to say the 6.1.12 version will fix
> my unresolved symbol problem?

Try: dmesg | grep -i aic7xxx

Some distributions store the boot dmesg output in a file, since if the
kernel spews a lot of messages, the older ones get lost if the buffer is
full; SuSE e. g. have been using /var/log/boot.msg for quite some time
now.

Other systems throw the entire boot message output into the normal
syslog.  (Seen than one on FreeBSD 4.3, but I don't remember Debian 1.x
and Red Hat 6.0 Sparc.)
-
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.3-ac14: Unable to handle kernel paging request at virtual addressbccfbcd0

[BERECZ Szabolcs]

Hello!

I just did my daily apt-get upgrade + netscape w/ 32Mb ram, so it swapped
a lot. at that time there was a swap file on an ext2fs, but I think it's
not about swapping.

so the screen I saw (there is one digit missing):

[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []
[] [] [] [] [] []

Code: 8b 53 1c 89 d0 85 d2 7d 06 8d 82 ff 7f 00 00 25 00 80 ff ff
<1> Unable to handle kernel paging request at virtual address bccfbcd0

I looked up the addresses in System.map:

c0147454 ext2_get_block
c0109e08 end_8259A_irq
c0107e1d do_IRQ
c012d6f6 generic_block_bmap
c015f125 SHATransform
c015ef97 add_timer_randomness
c015f409 extract_entropy
c0147b02 ext2_bmap
c0147454 ext2_get_block
c013d65f bmap
c0124daf rw_swap_page_base
c016fa21 ide_set_handler
c0124eef rw_swap_page
c0125b60 swap_writepage
c0124234 page_launder
c012bf5c refill_freelist
c012c30e getblk
c012c4da bread
c01474f4 ext2_get_block
c0147454 ext2_get_block
c012d6f6 generic_block_bmap
c0147b02 ext2_bmap
c0147454 ext2_get_block
c013d65f bmap
c0124daf rw_swap_page_base
c0124eef rw_swap_page
c0125b60 swap_writepage
c0124234 page_launder
c012bf5c refill_freelist
c012c30e getblk
c012c4da bread
c01474f4 ext2_get_block
c0147454 ext2_get_block
c012d6f6 generic_block_bmap
c015095f submit_bh
c012db15 brw_page
c012db6b brw_page
c0147b02 ext2_bmap
c0147454 ext2_get_block
c013d65f bmap
c0124daf rw_swap_page_base
c0124eef rw_swap_page
c0125b60 swap_writepage
c0124234 page_launder
c012bf5c refill_freelist
c012c30e getblk
c014791b ext2_getblk
c0123e3e reclaim_page
c0125590 __alloc_pages_limit
c01256f2 __alloc_pages
c0148d19 ext2_find_entry
c0184a46 skb_release_data
c018a57? // here I missed one digit (maybe not the last digit) :/
c0184bd0 __kfree_skb
c0148fd7 ext2_lookup
c01340d7 real_lookup
c0134487 path_walk
c0134d96 __user_walk
c0131e99 sys_stat64
c0106a63 system_call

ver_linux:
Linux kama3 2.4.3-ac14 #2 Sun Apr 29 14:46:29 CEST 2001 i586 unknown

Gnu C  2.95.4
Gnu make   3.79.1
binutils   2.11.90.0.5
util-linux
util-linux Note: /usr/bin/fdformat is obsolete and is no longer available.
util-linux Please use /usr/bin/superformat instead (make sure you have the
util-linux fdutils package installed first).  Also, there had been some
util-linux major changes from version 4.x.  Please refer to the 
documentation.
util-linux
mount  2.11b
modutils   2.4.2
e2fsprogs  1.19
reiserfsprogs  3.x.0j
PPP2.4.1
Linux C Library2.2.2
Dynamic linker (ldd)   2.2.2
Procps 2.0.7
Net-tools  1.60
Kbd0.96
Sh-utils   2.0.11
Modules Loaded reiserfs snd-mixer-oss snd-card-fm801 snd-mpu401-uart 
snd-rawmidi snd-seq-device snd-fm801 snd-pcm snd-ac97-codec snd-mixer snd-opl3 
snd-timer snd-hwdep snd soundcore

I was also using the ppp module, but that's not related, I think.
tell me if you need more info.

Bye,
Szabi

-
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: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

John Stoffel <[EMAIL PROTECTED]>:
> Before on startup it would give:
> 
> [root@jfs linux]# make config
> rm -f include/asm
> ( cd include ; ln -sf asm-i386 asm)
> python -O scripts/cmlconfigure.py -DX86 -B 2.4.4-pre7 -W -i config.out
> rules.out
> ISA=y (deduced from X86)
> Side effects from config.out:
> NETDEVICES=m (deduced from ATALK)
> SOUND_OSS=m (deduced from SOUND_VIA82CXXX)
> SOUND_OSS=y (deduced from SOUND_YMFPCI_LEGACY)
> SOUND=y (deduced from SOUND_OSS)
> python -O scripts/configtrans.py -h include/linux/autoconf.h -s
> .config config.out
> 
> 
> So I poked around, found the RTC setting, read the help and now I
> understand why I should have had it enabled all along.  No problem.
> So saved my changes and exited.  
> 
> I then restarted, and it came up properly, but I'm now getting the
> following output:
> 
> [root@jfs linux]# make config
> rm -f include/asm
> ( cd include ; ln -sf asm-i386 asm)
> python -O scripts/cmlconfigure.py -DX86 -B 2.4.4-pre7 -W -i config.out
> rules.out
> ISA=y (deduced from X86)
> 
> 
> Notice that it's still setting the ISA=y flag, but not the rest it was
> complaining about.  I think it should have either updated this setting
> by default for the ISA bus, or warned on exit that it still needed to
> be set.
> 
> I think this is a true bug somewhere.

Nope, it's a benign side-effect of the order of evaluation of command-line
switches.  Here's what's happening:

1. X86=y is being set and frozen.
2. ISA=y is deduced from X86
3. config.out is read in.  

In step 3, you don't see any side effects from config.out because they
were calculated last time and wruitten into the saved configuration. 

You still see the ISA=y message because your config.out has not yet been
read in at the time that side effect is computed.
-- 
http://www.tuxedo.org/~esr/;>Eric S. Raymond

"Among the many misdeeds of British rule in India, history will look
upon the Act depriving a whole nation of arms as the blackest."
-- Mohandas Ghandhi, An Autobiography, pg 446
-
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: [kbuild-devel] Re: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

Eric S. Raymond <[EMAIL PROTECTED]>:
> USB and SCSI are both enabled/disabled in the system buses menu.  The
> apparent confusion 

Sorry, I typoed...

USB and SCSI are both enabled/disabled in the system buses menu.  The
apparent confusion happens because of their defaults.
-- 
http://www.tuxedo.org/~esr/;>Eric S. Raymond

Society in every state is a blessing, but government even in its best
state is but a necessary evil; in its worst state an intolerable one;
for when we suffer, or are exposed to the same miseries *by a
government*, which we might expect in a country *without government*,
our calamities is heightened by reflecting that we furnish the means
by which we suffer."
-- Thomas Paine
-
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: ServerWorks LE and MTRR

[Steffen Persvold]

[EMAIL PROTECTED] wrote:
> On Sun, 29 Apr 2001, Steffen Persvold wrote:
> 
> > I've learned it the hard way, I have two types : Compaq DL360 (rev 5) and a
> > Tyan S2510 (rev 6). On the compaq machine I constantly get data corruption on
> > the last double word (4 bytes) in a 64 byte PCI burst when I use write
> > combining on the CPU. On the Tyan however the transfer is always ok.
> >
> 
> Are you sure that is not due to board design differences?

No I can't be 100% certain that the layout of the board isn't the reason since
I haven't asked ServerWorks about this and it doesn't say anything in their
docs (yes my company has the NDA, so I shouldn't get to much in detail here),
but if this was the case it would be totally wrong to disable write combining
on any LE chipset.

The test case that I have been using to trigger this is sort of special because
we are using SCI shared memory adapters to write (with PIO) into remote nodes
memory, and the bandwidth tends to get quite high (approx 170 MByte/sec on LE
with write combining). I've been able to run this case on 5 different
motherboards using the LE and HE-SL ServerWorks chipsets, but only two of them
are LE (the DL360 and the S2510). Everything works fine with write-combining on
every motherboard except the DL360 (which has rev 5).

One basic test case that I haven't tried, could be to enable write-combining on
your PCI graphics adapter memory and see if the X display gets screwed up.

I will try to get some information from ServerWorks about this problem, but I'm
not sure if ServerWorks would be happy if I told you the answer (because of the
NDA).

Regards,
-- 
 Steffen PersvoldSystems Engineer
 Email  : mailto:[EMAIL PROTECTED]Scali AS (http://www.scali.com)
 Norway : Tel  : (+47) 2262 8950 Olaf Helsets vei 6
  Fax  : (+47) 2262 8951 N-0621 Oslo, Norway

 USA: Tel  : (+1) 713 706 0544   10500 Richmond Avenue, Suite 190
 Houston, Texas 77042, USA
-
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: CML2 1.3.1, aka "I stick my neck out a mile..."

[Eric S. Raymond]

John Stoffel <[EMAIL PROTECTED]>:
> Which is a real PITA because now I have to edit my .config file to
> have:
> 
>CONFIG_RTC=y

The correct fix for this PITA is for Linus not to ship a broken defconfig.

>   Now when I do a 'make config' it comes up properly.  I
> think this is a poor interface setup.  It should either
> 
> a.  Give more info on what to correct, such as the configuration line
> to edit and in which file.
> 
> b.  Print a warning, startup the configuration tool and put you at the
> problematic line, with the help section showing.  Or highlight this
> choice in some manner as being wrong and showing you how to ffix it.
> 
> This is a minor, but annoying problem and should be fixed ASAP before
> public use.  

I hear you.  The problem is that "what's wrong" is not as well-defined
as one might like.  In this case the error could be in the setting of
X86, SMP, or RTC.  CML2 has no way to know which of these is mis-set, so
it can't know which one to pop up..
 
> At the top-level, most stuff cannot be selected on/off, but you can
> enter it.  But you also do have some y/m/n choices which seems wierd
> and out of place.  For example, "SCSI disk support" is a menu, but
> "HAMRADIO: Amateur Radio support (NEW)" is a y/n choice.  It would
> make more sense to me to have it down a level, with a simple entry to
> "Hamradio support".  Once you go into that level, you would be asked
> to have it turned on/off there.
> 
> This would remove some of the clutter at the top level.  
> 
> As a contrast, the USB entry doesn't ask Y/N for USB support, and when
> I enter the directory, it has all these options listed.  I thought
> that CML would suppres stuff (children, drivers, etc) if I didn't have
> the top level selected.  In this case, I can't turn off USB support in
> any manner, so I see all the children when I could care less about
> them.

USB and SCSI are both enabled/disabled in the system buses menu.  The
apparent confusion 

> Also, the buttons on the right hand side for HELP, are wider when they
> have text in them, but slightly narrower when they are blank.  They
> should be the same width no matter what.  It looks ragged and ugly.

I know.  Sadly, I couldn't find a way to coerce Tcl into doing this right.

> I don't like how it keeps changing the window size whenever you go
> into a sub-level.  It should not re-size the main window at all, it
> should just update the contents and give scroll bars if needed for
> both up/down scolling and side to side.  Once the user has setup their
> prefs, the CML code shouldn't keep it jumping all over the screen.

That's on my to-do list.  It's low-priority, though, since I figure 
most people will use menuconfig.
-- 
http://www.tuxedo.org/~esr/;>Eric S. Raymond

"Today, we need a nation of Minutemen, citizens who are not only prepared to
take arms, but citizens who regard the preservation of freedom as the basic
purpose of their daily life and who are willing to consciously work and
sacrifice for that freedom."
-- John F. Kennedy
-
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: panic when booting 2.4.4

[Jan Niehusmann]

On Sun, Apr 29, 2001 at 12:43:17PM -0700, Manuel McLure wrote:
> Does your motherboard have a Promise FastTrak on it? If so this is a bug I
> reported in 2.4.3-ac10/11 and that Alan Cox fixed in -ac12 - for some
> reason it didn't make it into 2.4.4. I was just about to report it myself
> when I saw your mail. The following patch fixes:

Yes, the patch fixed the 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: X15 alpha release: as fast as TUX but in user space (fwd)

[Richard Gooch]

H. Peter Anvin writes:
> The thing that made me say we discussed this last month was
> Richard's comment that it had already been implemented (which it
> has, by Andrea, for x86-64.)  The idea of doing it for i386 has been
> kicked around for

Correction: I didn't say it had been implemented. I just asked what
happened to the idea. I never saw it go into i386.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [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: X15 alpha release: as fast as TUX but in user space (fwd)

[Richard Gooch]

Gregory Maxwell writes:
> On Sun, Apr 29, 2001 at 10:11:59PM +0200, Ingo Oeser wrote:
> [snip]
> > The point is: The code in that "magic page" that considers the
> > tradeoff is KERNEL code, which is designed to care about such
> > trade-offs for that machine. Glibc never knows this stuff and
> > shouldn't, because it is already bloated.
> > 
> > We get the full win here, for our "compile the kernel for THIS
> > machine to get maximum performance"-strategy.
> > 
> > People tend to compile the kernel, but not the glibc.
> > 
> > Just let the benchmarks, Linus and Ulrich decide ;-)
> 
> The kernel can even customize the page at runtime if it needs to, such as
> changing algorithims to deal with lock contention.
> 
> Of course, this page will need to present a stable interface to
> glibc, and having both the code and a comprehensive jump-table might
> become tough in a single page...

Sure. IIRC, Linus talked about "a few pages".

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [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: X15 alpha release: as fast as TUX but in user space (fwd)

[Richard Gooch]

Ingo Oeser writes:
> On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> > Ingo Oeser writes:
> > > There we have 10x faster memmove/memcpy/bzero for 1K blocks
> > > granularity (== alignment is 1K and size is multiple of 1K), that
> > > is done by the memory controller.
> > This sounds different to me. Using the memory controller is (should
> > be!) a privileged operation, thus it requires a system call. This is
> > quite different from code in a magic page, which is excuted entirely
> > in user-space. The point of the magic page is to avoid the syscall
> > overhead.
> 
> Yes, but we currently have more than 10K cycles for doing
> memset of a page. If we do an syscall, we have around 600-900
> (don't know exactly), which is still less.
> 
> The point is: The code in that "magic page" that considers the
> tradeoff is KERNEL code, which is designed to care about such
> trade-offs for that machine.

Um, yes. I don't disagree with that. I'm just saying the two issues
are conceptually separate, and should be considered independently.

> Glibc never knows this stuff and shouldn't, because it is already
> bloated.

True, true and true.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [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: Severe trashing in 2.4.4

[Frank de Lange]

On Mon, Apr 30, 2001 at 12:06:52AM +0200, Manfred Spraul wrote:
> You could enable STATS in mm/slab.c, then the number of alloc and free
> calls would be printed in /proc/slabinfo.
> 
> > Yeah, those as well. I kinda guessed they were related...
> 
> Could you check /proc/sys/net/core/hot_list_length and skb_head_pool
> (not available in /proc, use gdb --core /proc/kcore)? I doubt that this
> causes your problems, but the skb_head code uses a special per-cpu
> linked list for even faster allocations.
> 
> Which network card do you use? Perhaps a bug in the zero-copy code of
> the driver?

I'll give it a go once I reboot into 2.4.4 again (now in 2.4.3 to get some
'work' done). Using the dreaded ne2k cards (two of them), which have caused me
more than one headache already...

I'll have a look at the driver for these cards.

Cheers//Frank

-- 
  W  ___
 ## o o\/ Frank de Lange \
 }#   \|   /  \
  ##---# _/   \
      \  +31-320-252965/
   \[EMAIL PROTECTED]/
-
 [ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est."  ]
-
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: ServerWorks LE and MTRR

[nick]

Are you sure that is not due to board design differences?
Nick

On Sun, 29 Apr 2001, Steffen Persvold wrote:

> Gérard Roudier wrote:
> > 
> > On Sun, 29 Apr 2001, Steffen Persvold wrote:
> > 
> > > Hi all,
> > >
> > > I just compiled 2.4.4 and are running it on a Serverworks LE motherboard.
> > > Whenever I try to add a write-combining region, it gets rejected. I took a peek
> > > in the arch/i386/kernel/mtrr.c and found that this is just as expected with
> > > v1.40 of the code. It is great that the mtrr code checks and prevents the user
> > > from doing something that could eventually lead to data corruption. Using
> > > write-combining on PCI acesses can lead to this on certain LE revisions but
> > > _not_ all (only rev < 5). Therefore please consider my small patch to allow the
> > > good ones to be able to use write-combining. I have several rev 06 and they are
> > > working fine with this patch.
> > 
> > You wrote that 'only rev < 5' can lead to data corruption, but your patch
> > seems to disallow use of write combining for rev 5 too.
> > 
> > Could you clarify?
> 
> Oops just a typo, it should be <= 5. The patch is correct.
> 
> > 
> >   Gérard.
> > 
> > PS:
> > >From what hat did you get this information ? as it seems that ServerWorks
> > require NDA for letting know technical information on their chipsets.
> > 
> 
> I've learned it the hard way, I have two types : Compaq DL360 (rev 5) and a
> Tyan S2510 (rev 6). On the compaq machine I constantly get data corruption on
> the last double word (4 bytes) in a 64 byte PCI burst when I use write
> combining on the CPU. On the Tyan however the transfer is always ok.
> 
> -- 
>  Steffen PersvoldSystems Engineer
>  Email  : mailto:[EMAIL PROTECTED]Scali AS (http://www.scali.com)
>  Norway : Tel  : (+47) 2262 8950 Olaf Helsets vei 6
>   Fax  : (+47) 2262 8951 N-0621 Oslo, Norway
> 
>  USA: Tel  : (+1) 713 706 0544   10500 Richmond Avenue, Suite 190
>  Houston, Texas 77042, USA
> -
> 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: Severe trashing in 2.4.4

[Manfred Spraul]

> On Sun, Apr 29, 2001 at 01:58:52PM -0400, Alexander Viro wrote:
> > Hmm... I'd say that you also have a leak in kmalloc()'ed stuff -
> > something in 1K--2K range. From your logs it looks like the
> > thing never shrinks and grows prettu fast...

You could enable STATS in mm/slab.c, then the number of alloc and free
calls would be printed in /proc/slabinfo.

> Yeah, those as well. I kinda guessed they were related...

Could you check /proc/sys/net/core/hot_list_length and skb_head_pool
(not available in /proc, use gdb --core /proc/kcore)? I doubt that this
causes your problems, but the skb_head code uses a special per-cpu
linked list for even faster allocations.

Which network card do you use? Perhaps a bug in the zero-copy code of
the driver?

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

8139too in 2.4.4 Hanging/Locking

[Adam]

Please CC this back, as I'm not yet on the kernel-mailing-list

I'm currently running the following:

kernel 2.4.3
gcc 2.95.3
modutils 2.4.2
dhcpcd v.1.3.19-pl8

The problem is, after compiling the 2.4.4 kernel with the exact
configuration as I had used on the 2.4.3 kernel, my system hangs at:

8139too Fast Ethernet driver 0.9.16 loaded [the version number is
greater than 0.9.15c (which is used in 2.4.3) though I'm not exactly
sure if it's 0.9.16]
PCI: Found IRQ 9 for device 00:0b.0
eth0: RealTek RTL8139 Fast Ethernet at 0xd0814000, 00:50:ba:d2:45:21,
IRQ 9
eth0:  Identified 8139 chip type 'RTL-8139B'
eth0: Setting half-duplex based on auto-negotiated partner ability .
[this is where it hangs, it requires me to reboot and load up a backup
kernel (2.4.3)]

If there is any other information you require to solve this problem, I'd
be happy to help.


-- 
Adam
[EMAIL PROTECTED]
Linux user #190288
-
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: question regarding cpu selection

[Ville Herva]

On Sun, Apr 29, 2001 at 11:13:12PM +0200, you [Erik Mouw] claimed:
> On Sun, Apr 29, 2001 at 11:32:51PM +0300, Ville Herva wrote:
> > On Sun, Apr 29, 2001 at 09:28:48PM -0400, you [Duncan Gauld] claimed:
> > > I would supply a patch, but I don't know how to write such a thing :)
> > 
> > It seems Erik Mouw already submitted a patch, altough I agree that "Celeron
> > II" might be a better name for the thing than "Celeron (Coppermine)".
> 
> So what about this one? This time I had to change Configure.help and
> setup.c as well to reflect the changes in config.in :)

Hmm. I just checked Intel's web site (should've done so earlier), and it
appears that Intel still dubs the new revision as "Celeron", although I'm
sure it was introduced as CeleronII in some sources (try
http://www.google.com/search?q=CeleronII). So I'll just have admit that your
first patch was technically correct, and I was wrong. Sorry for the
inconvenience.

I still think "Celeron II" is clearer, but heaven knows what Intel will sell
by that name three years from now (just think of i860).


-- v --

[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: #define HZ 1024 -- negative effects?

[Michael Rothwell]

Great. I'm running 4.02. How do I enable "silken mouse"?

Thanks,

-Michael

On 29 Apr 2001 14:44:11 -0700, Jim Gettys wrote:
> The biggest single issue in GUI responsiveness on Linux has been caused
> by XFree86's implementation of mouse tracking in user space.
> 
> On typical UNIX systems, the mouse was often controlled in the kernel
> driver.  Until recently (XFree86 4.0 days), the XFree86 server's reads
> of mouse/keyboard events were not signal driven, so that if the X server
> was loaded, the cursor stopped moving.
> 
> On most (but not all) current XFree86 implementations, this is now
> signal drive, and further the internal X schedular has been reworked to
> make it difficult for a single client to monopolize the X server.
> 
> So the first thing you should try is to make sure you are using an X server
> with this "silken mouse" enabled; anotherwords, run XFree86 4.0x and make
> sure the implementation has it enabled
> 
> There may be more to do in Linux thereafter, but until you've done this, you
> don't get to discuss the matter further
>   - Jim Gettys
> 
> --
> Jim Gettys
> Technology and Corporate Development
> Compaq Computer Corporation
> [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/

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

reiserfs autofix?

[putter]

Hi,
I am kernel newbie, especially with logging filesystems.
Now I am using Mandrake 7.1 with 2.4.3 kernel and imon patch
and NVidia drivers compiled into the kernel.
Now, all my partitions are ReiserFS. I usually play quake once
or twice a day. Sometimes graphics subsystem freezes up, so it takes
keyboard input. Caps and Numlock are working fine, unless I try to kill
X with ctrlalt-backspace. So I reset my machine with hardware switch.

here is the interesting part... after I reset my machine like that,
some files start to appear corrupted. Segmentation faults etc. 
Isn't reiserfs suppose to be safe? NOW, THE REAL SPOOKY PART:
I reboot my machine with normal procedure, like shutdonw -r now,
and on other boot, corrupted files FIX themselves. Any insight?
I think it is rather unacceptable...
cheers,
pavel
-
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: X15 alpha release: as fast as TUX but in user space (fwd)

[Jim Gettys]

> 
> Short summary: depending on how much you were talking general idea versus
> specifics, you can go arbitrarily far back (I wouldn't be surprised if
> shared memory techniques were used regularly before memory protection.)
> 
> Fair?

Very fair.

> 
> Not to pick on you or anyone else, but it is well-known to everyone
> except the U.S. patent office that "there are no new ideas in computer
> science." :)
> 


Exactly why I noted in my mail that I didn't consider it novel even back then; just
a good engineering idea that we went ahead and used a long time ago...
- Jim
--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
[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: #define HZ 1024 -- negative effects?

[Jim Gettys]

The biggest single issue in GUI responsiveness on Linux has been caused
by XFree86's implementation of mouse tracking in user space.

On typical UNIX systems, the mouse was often controlled in the kernel
driver.  Until recently (XFree86 4.0 days), the XFree86 server's reads
of mouse/keyboard events were not signal driven, so that if the X server
was loaded, the cursor stopped moving.

On most (but not all) current XFree86 implementations, this is now
signal drive, and further the internal X schedular has been reworked to
make it difficult for a single client to monopolize the X server.

So the first thing you should try is to make sure you are using an X server
with this "silken mouse" enabled; anotherwords, run XFree86 4.0x and make
sure the implementation has it enabled

There may be more to do in Linux thereafter, but until you've done this, you
don't get to discuss the matter further
- Jim Gettys

--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
[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: X15 alpha release: as fast as TUX but in user space (fwd)

[H. Peter Anvin]

Jim Gettys wrote:
> 
> The "put the time into a magic location in shared memory" goes back...
>

Short summary: depending on how much you were talking general idea versus
specifics, you can go arbitrarily far back (I wouldn't be surprised if
shared memory techniques were used regularly before memory protection.)

Fair?

Not to pick on you or anyone else, but it is well-known to everyone
except the U.S. patent office that "there are no new ideas in computer
science." :)

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: X15 alpha release: as fast as TUX but in user space

[Fabio Riccardi]

I can disable header caching and see what happens, I'll add an option for this
in the next X15 release.

Nevertheless I don't know how much this is interesting in real life, since on
the internet most static pages are cached on proxies. I agree that the
RFC asks for a date for the original response, but once the response is cached
what does this date mean?

 - Fabio

Ingo Molnar wrote:

> Fabio,
>
> i noticed one weirdness in the Date-field handling of X15. X15 appears to
> cache the Date field too, which is contrary to RFCs:
>
>  earth2:~> wget -s http://localhost/index.html -O - 2>/dev/null | grep Date
>  Date: Sat Apr 28 10:15:14 2001
>  earth2:~> date
>  Sat Apr 28 10:32:40 CEST 2001
>
> ie. there is already a 15 minutes difference between the 'origin date of
> the reply' and the actual date of the reply. (i started X15 up 15 minutes
> ago.)
>
> per RFC 2616:
> .
> The Date general-header field represents the date and time at which the
> message was originated, [...]
>
> Origin servers MUST include a Date header field in all responses, [...]
> .
>
> i considered the caching of the Date field for TUX too, and avoided it
> exactly due to this issue, to not violate this 'MUST' item in the RFC. It
> can be reasonably expected from a web server to have a 1-second accurate
> Date: field.
>
> the header-caching in X15 gives it an edge against TUX, obviously, but IMO
> it's a questionable practice.
>
> if caching of headers was be allowed then we could the obvious trick of
> sendfile()ing complete web replies (first header, then body).
>
> Ingo

-
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: X15 alpha release: as fast as TUX but in user space (fwd)

[Jim Gettys]

The "put the time into a magic location in shared memory" goes back, as
far as I know, to Bob Scheifler or myself for the X Window System, sometime
around 1984 or 1985: we put it into a page of shared memory where we used
a circular buffer scheme to put input events (keyboard/mice), so that
we could avoid the read system call overhead to get these events (and
more importantly, check between each request if there was input to
process).  I don't think we ever claimed it was novel, just that we did
it that way (I'd have to ask Bob if he had heard of that before we did
it).  We put it into the same piece of memory we put the circular event
buffer, avoiding both the get-time-of day calls, but also the much more
expensive reads that would have been required (we put the events into a
circular buffer, with the kernel only updating one value, and user space
updating the other value defining the circular buffer).

In X, it is important for interactivity to get input events and send them
to clients ASAP: just note the effect of Keith Packard's recent implementation
of "silken mouse", where signals are used to deliver events to the X server.
This finally has made mouse tracking (done in user space on Linux; generally
done by kernel drivers on most UNIX boxes) what we were getting on 1 mip machines
under load (Keith has also done more than this with his new internal X
scheduler, which prevents clients from monopolizing the X server anywhere
like the old implementation).

This shared memory technique is very powerful to allow a client application to know if
it needs to do a system call, and is very useful for high performance servers
(like X), where a system call is way too expensive.

I've certainly mentioned this technique in the past in the Web community
(but HTTP servers are processing requests about 1/100-1/1000 the rate of
an X server, which gets into the millions of requests/second on current machines.

So if you want to get user space to really go fast, sometimes you resort
to such trickery  I think the technique has real value: the interesting
question is should there be general kernel facilities to make this easy
(we did it via ugly hacks on VAX and MIPS boxes) for kernel facilities
to provide.

"X is an exercise in avoiding system calls".  I think I said this around
1984-1985.  
- Jim

--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
[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: question regarding cpu selection

[Erik Mouw]

On Sun, Apr 29, 2001 at 11:32:51PM +0300, Ville Herva wrote:
> On Sun, Apr 29, 2001 at 09:28:48PM -0400, you [Duncan Gauld] claimed:
> > I would supply a patch, but I don't know how to write such a thing :)
> 
> It seems Erik Mouw already submitted a patch, altough I agree that "Celeron
> II" might be a better name for the thing than "Celeron (Coppermine)".

So what about this one? This time I had to change Configure.help and
setup.c as well to reflect the changes in config.in :)


Erik

Index: arch/i386/config.in
===
RCS file: /home/erik/cvsroot/elinux/arch/i386/config.in,v
retrieving revision 1.1.1.38
diff -u -r1.1.1.38 config.in
--- arch/i386/config.in 2001/04/26 12:31:41 1.1.1.38
+++ arch/i386/config.in 2001/04/29 20:52:43
@@ -33,7 +33,7 @@
 Pentium-ClassicCONFIG_M586TSC \
 Pentium-MMXCONFIG_M586MMX \
 Pentium-Pro/Celeron/Pentium-II CONFIG_M686 \
-Pentium-IIICONFIG_MPENTIUMIII \
+Pentium-III/Celeron II CONFIG_MPENTIUMIII \
 Pentium-4  CONFIG_MPENTIUM4 \
 K6/K6-II/K6-IIICONFIG_MK6 \
 Athlon/Duron/K7CONFIG_MK7 \
Index: arch/i386/kernel/setup.c
===
RCS file: /home/erik/cvsroot/elinux/arch/i386/kernel/setup.c,v
retrieving revision 1.1.1.51
diff -u -r1.1.1.51 setup.c
--- arch/i386/kernel/setup.c2001/04/28 13:24:25 1.1.1.51
+++ arch/i386/kernel/setup.c2001/04/29 21:01:10
@@ -1841,7 +1841,7 @@

case 8:
if (l2 == 128)
-   p = "Celeron (Coppermine)";
+   p = "Celeron II (Coppermine)";
break;
}
}
Index: Documentation/Configure.help
===
RCS file: /home/erik/cvsroot/elinux/Documentation/Configure.help,v
retrieving revision 1.1.1.108
diff -u -r1.1.1.108 Configure.help
--- Documentation/Configure.help2001/04/26 12:44:35 1.1.1.108
+++ Documentation/Configure.help2001/04/29 20:53:32
@@ -3033,7 +3033,7 @@
- "Pentium-MMX" for the Intel Pentium MMX.
- "Pentium-Pro" for the Intel Pentium Pro/Celeron/Pentium II.
- "Pentium-III" for the Intel Pentium III
- and Celerons based on the coppermine core.
+ and Celerons based on the coppermine core (Celeron II).
- "Pentium-4" for the Intel Pentium 4.
- "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
- "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
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: X15 alpha release: as fast as TUX but in user space

[Fabio Riccardi]

Linux 2.4 is surely one of the most advanced OSs ever happened, especially
from the optimization point of view and for the admirable economy of concepts
on which it lies. I definitively hope that X15 helps reinforcing the success
to this amazing system.

TUX has definitively been my performance yardstick for the development of
X15, but I had many sources of inspiration for the X15 architecture. Maybe
the most relevant are the Flash Web Server (Pai, Druschel, Zwaenepoel),
several Linus observations on this list about (web) server architecture and
kernnel services, and the reading of the Hennessy & Patterson architecture
books. Last but not least, aside from some heated discussions, research in
microkernel architecture has taught us many lessons on how to achieve an
efficient model of interaction across separate addressing spaces.

If i have to make some sort of educated guess and point at where the current
bottleneck lies for web server performance, I would say that it is somewhere
between the memory subsystem and the PCI bus.

With zero-copy sendfile data movement is not an issue anymore, asynchronous
network IO allows for really inexpensive thread scheduling, and system call
invocation adds a very negligible overhead in Linux. What we are left with
now is purely wait cycles, the CPUs and the NICs are contending for memory
and bus bandwidth. It would be really interesting to see where the network
shifts now that faster machines are becoming available.

On my whish list for future kernel developments I would definitively put disk
asynchronous IO and a more decent file descriptor passing implementation.
I'll detail this in subsequent messages.

I'll surely check out the impact of Ingo's patches on TUX performance
sometime this week.

I'd also like to reiterate my request for help for testing X15 on higher end
server architectures.

X15 is still very young alpha code and I can surely improve its performance
in many ways.

 - Fabio

Ingo Molnar wrote:

> On Fri, 27 Apr 2001, Fabio Riccardi wrote:
>
> > I'd like to announce the first release of X15 Alpha 1, a _user space_
> > web server that is as fast as TUX.
>
> great, the first TUX clone! ;-)
>
> This should put the accusations to rest that Linux got the outstandingly
> high SPECweb99 scores only because the webserver was in kernel-space. It's
> the 2.4 kernel's high performance that enabled those results, having the
> web-server in kernel-space didnt have much effect. TUX was and remains a
> testbed to test high-performance webserving (and FTP serving), without the
> API-exporting overhead of userspace.
>
> [i suspect the small performance advantage of X15 is due to subtle
> differences in the SPECweb99 user-space module: eg. while the TUX code was
> written, tested and ready to use mmap()-enabled
> TUXAPI_alloc_read_objectbuf(), it wasnt enabled actually. I sent Fabio a
> mail how to enable it, perhaps he can do some tests to confirm this
> suspicion?]
>
> doing a TUX 2.0 SPECweb99 benchmark on the latest -ac kernels, 86% of time
> is spent in generic parts of the kernel, 12% of time is spent in the
> user-space SPECweb99 module, and only 2% of time is spent in TUX-specific
> kernel code.
>
> doing the same test with the original TUX 1.0 code shows that more than
> 50% of CPU time was spent in TUX-specific code.
>
> what does this mean? In the roughly 6 months since TUX 1.0 was released,
> we moved much of the TUX 1.0 -only improvements into the generic kernel
> (most of which was made available to user-space as well), and TUX itself
> became smaller and smaller (and used more and more generic parts of the
> kernel). So in effect X15 is executing 50% TUX code :-)
>
> (there are still a number of performance improvement patches pending that
> are not integrated yet: the pagecache extreme-scalability patch and the
> smptimers patch. These patches speed both X15 and TUX up.)
>
> (there is one thing though that can never be 'exported to user-space': to
> isolate possibly untrusted binary application code from the server itself,
> without performance degradation. So we always have to be mentally open to
> the validity of kernel-space services.)
>
> Ingo

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

Not just RealTek 8139/dhcpcd..epic100 broken also

[James M]

Kernel 2.4.2(working) 2.4.4(broken), Xeon 2-way SMP 400 mhz, 128 mem,
gcc 2.95.3, DHCP Client Daemon v.1.3, Mandrake 7.2
 
2.4.4 is broken with my epic100/dhcpcd2.4.2 works fine. I copied
/lib/module/2.4.2../epic100.o to /lib/modules/2.4.4/../epic100.o with no
success.

Messages error: Apr 29 15:44:24 windeath kernel: eth0: Transmit timeout
using MII device, Tx status 0003.

Followed by more of the same except with status 000b. Unlike the realtek
errors a network stop/start/restart doesn't help. Looking at the patch
for 2.4.4 shows one tiny change to epic100. 

-- 

James M.
aka "Dart"
-
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: ServerWorks LE and MTRR

[Steffen Persvold]

Gérard Roudier wrote:
> 
> On Sun, 29 Apr 2001, Steffen Persvold wrote:
> 
> > Hi all,
> >
> > I just compiled 2.4.4 and are running it on a Serverworks LE motherboard.
> > Whenever I try to add a write-combining region, it gets rejected. I took a peek
> > in the arch/i386/kernel/mtrr.c and found that this is just as expected with
> > v1.40 of the code. It is great that the mtrr code checks and prevents the user
> > from doing something that could eventually lead to data corruption. Using
> > write-combining on PCI acesses can lead to this on certain LE revisions but
> > _not_ all (only rev < 5). Therefore please consider my small patch to allow the
> > good ones to be able to use write-combining. I have several rev 06 and they are
> > working fine with this patch.
> 
> You wrote that 'only rev < 5' can lead to data corruption, but your patch
> seems to disallow use of write combining for rev 5 too.
> 
> Could you clarify?

Oops just a typo, it should be <= 5. The patch is correct.

> 
>   Gérard.
> 
> PS:
> >From what hat did you get this information ? as it seems that ServerWorks
> require NDA for letting know technical information on their chipsets.
> 

I've learned it the hard way, I have two types : Compaq DL360 (rev 5) and a
Tyan S2510 (rev 6). On the compaq machine I constantly get data corruption on
the last double word (4 bytes) in a 64 byte PCI burst when I use write
combining on the CPU. On the Tyan however the transfer is always ok.

-- 
 Steffen PersvoldSystems Engineer
 Email  : mailto:[EMAIL PROTECTED]Scali AS (http://www.scali.com)
 Norway : Tel  : (+47) 2262 8950 Olaf Helsets vei 6
  Fax  : (+47) 2262 8951 N-0621 Oslo, Norway

 USA: Tel  : (+1) 713 706 0544   10500 Richmond Avenue, Suite 190
 Houston, Texas 77042, USA
-
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/

ICQ masq modules for 2.2?

[Mike A. Harris]

Where can one obtain the ip_masq_icq.o module source for 2.2.x?
Searches on freshmeat turn up nothing, search on google turns up
a page that has module source for 2.2.x, 2.0.x but when
downloaded the file is corrupt (on the server side, not just my
download).  Further searching reveals nothing but dead web links
and email that point to nowhere as well.

Any help in obtaining the source for this module would be greatly
appreciated.

Thanks.



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

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

Re: [PATCH][CFT] (updated) ext2 directories in pagecache

[Daniel Phillips]

> Patch is on ftp.math.psu.edu/pub/viro/ext2-dir-patch-S4.gz

Here is my ext2 directory index as a patch against your patch:

http://kernelnewbies.org/~phillips/htree/dx.pcache-2.4.4

Changes:

- COMBSORT macro replaced by custom sort code
- Most #ifdef CONFIG_EXT2_INDEX's changed to if ()

To do:

  - Split up the split code
  - Finalize hash function
  - Test/debug big endian
  - Fall back to linear search if bad index detected
  - Fail gracefully on random data
  - Remove the tracing and test options

To apply:

cd source/tree
zcat ext2-dir-patch-S4.gz | patch -p1
cat dx.pcache-2.4.4 | patch -p0

To create an indexed directory:

mount /dev/hdxxx /test -o index
mkdir /test/foo
-
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: X15 alpha release: as fast as TUX but in user space (fwd)

[Arjan van de Ven]

In article <[EMAIL PROTECTED]> you wrote:
> Yes, but we currently have more than 10K cycles for doing
> memset of a page.

make that 3800 or so. (700 Mhz AMD Duron)

-
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: Sony Memory stick format funnies...

[Rogier Wolff]

H. Peter Anvin wrote:

> Rogier Wolff wrote:

> > The image of the disk (including partition table) is at:
> > 
> > ftp://ftp.bitwizard.nl/misc_junk/formatted.img.gz
> > 
> > It's 63kb and uncompresses to the 64Mb (almost) that it's sold as.
> > 
> 
> And on at least this kernel (2.4.0) there is nothing funny about it:
> 
> : tazenda 13 ; ls -l /mnt
> total 0
> -r-xr-xr-x1 root root0 May 23  2000 memstick.ind*
> : tazenda 14 ; 
> 
> Mounting msdos, vfat or umsdos, no change.

OK. I rebooted the laptop: 

  Linux version 2.2.13 ([EMAIL PROTECTED]) (gcc version
  egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Nov 8
  15:37:25 CET 1999

which seems to have cleared it. Somehow that directory was still
cached somewhere (not in the buffer cache) from when there were images
on the memory stick.

So, I'm suspecting a dcache bug, that allows something to stay over
after swapping a removable media device And all this is irrelevant
as this was on a very old kernel. Sorry to have been wasting your
time.

Roger.

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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: Sony Memory stick format funnies...

[mirabilos]

Btw, the root dir contains 512 entries.
Just from the dump.
(I would let the partition start at sector ptabl+1, not wasting
so much space... but M$ fdisk.exe neither does.)
-mirabilos

-
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: Sony Memory stick format funnies...

[Rogier Wolff]

mirabilos wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Btw, the root dir contains 512 entries.
> Just from the dump.

Jep. 

> (I would let the partition start at sector ptabl+1, not wasting
> so much space... but M$ fdisk.exe neither does.)

This was formatted by my Sony DSC505V. 

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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: traceroute breaks with 2.4.4

[Mohammad A. Haque]

David Konerding wrote:
> OK, I'm unable to fix this by reverting to 2.4.2 using the same config as
> 2.4.2.
> However, an older compiled 2.4.2 worked, so I think I must have changed
> some configuration which affects it.  Can't for the life of me figure out what
> it is,
> tho'.

Send me your config and I'll see if it's duplicated here.

-- 

=
Mohammad A. Haque  http://www.haque.net/ 
   [EMAIL PROTECTED]

  "Alcohol and calculus don't mix. Project Lead
   Don't drink and derive." --Unknown  http://wm.themes.org/
   [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: Sony Memory stick format funnies...

[H. Peter Anvin]

Rogier Wolff wrote:
> 
> H. Peter Anvin wrote:
> > Gregory Maxwell wrote:
> > > >
> > > > I doubt the kernel is seeing it without it being there (it doesn't have
> > > > much imagination.)  However, it may very well be there in a funny
> > > > manner.  You do realize, of course, that it's pretty much impossible for
> > > > us to help you answer that question without a complete dump of the
> > > > filesystem on hand, I hope?
> > >
> > > He gave what he thought was a complete dump of the non-null bytes. The
> > > obvious answer is that he's looking wrong. :)
> > >
> >
> > Hence the "complete" part...
> 
> OK.
> 
> The image of the disk (including partition table) is at:
> 
> ftp://ftp.bitwizard.nl/misc_junk/formatted.img.gz
> 
> It's 63kb and uncompresses to the 64Mb (almost) that it's sold as.
> 

And on at least this kernel (2.4.0) there is nothing funny about it:

: tazenda 13 ; ls -l /mnt
total 0
-r-xr-xr-x1 root root0 May 23  2000 memstick.ind*
: tazenda 14 ; 

Mounting msdos, vfat or umsdos, no change.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: question regarding cpu selection

[Ville Herva]

On Sun, Apr 29, 2001 at 09:28:48PM -0400, you [Duncan Gauld] claimed:
> 
> compiling kernel 2.4.4 on mandrake 8.
> Just checked - no mention of Celeron II in there-
>Pentium Pro/Pentium II/Celeron
> is the only line mentioning the celeron; maybe the PIII line could be changed 
> to something like "Pentium III/Celeron II"?
> I would supply a patch, but I don't know how to write such a thing :)

It seems Erik Mouw already submitted a patch, altough I agree that "Celeron
II" might be a better name for the thing than "Celeron (Coppermine)".


-- v --

[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: question regarding cpu selection

[Duncan Gauld]

On Sunday 29 April 2001  3:36 pm, Ville Herva wrote:
> On Sun, Apr 29, 2001 at 02:56:08PM -0400, you [William Park] claimed:
> > On Sun, Apr 29, 2001 at 07:07:51PM -0400, Duncan Gauld wrote:
> > > Hi,
> > > This seems a silly question but - I have an intel celeron 800mhz CPU
> > > and thus it is of the Coppermine breed. But under cpu selection when
> > > configuring the kernel, should I select PIII or PII/Celeron? Just
> > > wondering, since Coppermine is basically a newish PIII with 128K less
> > > cache...
> >
> > Try both, and see if your machine throws up.
>
> 800Mhz Celeron is actually a CeleronII, and it does SSE just like PIII (the
> only difference being cache). Therefore PIII option should work.
>
> Perhaps this should be fixed in the config menu (or is it already? Which
> kernel are you compiling?)

compiling kernel 2.4.4 on mandrake 8.
Just checked - no mention of Celeron II in there-
   Pentium Pro/Pentium II/Celeron
is the only line mentioning the celeron; maybe the PIII line could be changed 
to something like "Pentium III/Celeron II"?
I would supply a patch, but I don't know how to write such a thing :)

---
Duncan Gauld
[EMAIL PROTECTED]
http://www.freelin.org (linux on cd, free)
-
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: Sony Memory stick format funnies...

[Rogier Wolff]

H. Peter Anvin wrote:
> Gregory Maxwell wrote:
> > >
> > > I doubt the kernel is seeing it without it being there (it doesn't have
> > > much imagination.)  However, it may very well be there in a funny
> > > manner.  You do realize, of course, that it's pretty much impossible for
> > > us to help you answer that question without a complete dump of the
> > > filesystem on hand, I hope?
> > 
> > He gave what he thought was a complete dump of the non-null bytes. The
> > obvious answer is that he's looking wrong. :)
> > 
> 
> Hence the "complete" part...

OK. 

The image of the disk (including partition table) is at:

ftp://ftp.bitwizard.nl/misc_junk/formatted.img.gz

It's 63kb and uncompresses to the 64Mb (almost) that it's sold as.

Roger. 

-- 
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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: Sony Memory stick format funnies...

[H. Peter Anvin]

Rogier Wolff wrote:
> >
> > I doubt the kernel is seeing it without it being there (it doesn't have
> > much imagination.)  However, it may very well be there in a funny
> > manner.  You do realize, of course, that it's pretty much impossible for
> > us to help you answer that question without a complete dump of the
> > filesystem on hand, I hope?
> 
> Yes, I realize. That's why I gave the whole dump in the first Email.
> 
> These are all lines of 16 bytes that do not contain only zeroes or
> only 0xff's.
> 

I can't test kernel behaviour with a hexdump!  I think the first thing
you should do is dd your entire thing to a file, mount it loopback, and
see if the behaviour reoccurs or not using the file.  Then you may want
to consider posting the binary somewhere.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: Sony Memory stick format funnies...

[Rogier Wolff]

Gregory Maxwell wrote:
> On Sun, Apr 29, 2001 at 01:09:22PM -0700, H. Peter Anvin wrote:
> > Rogier Wolff wrote:
> > > 
> > > H. Peter Anvin wrote:
> > > > Followup to:  <[EMAIL PROTECTED]>
> > > > By author:[EMAIL PROTECTED] (Rogier Wolff)
> > > > In newsgroup: linux.dev.kernel
> > > > >
> > > > > # l /mnt/d1
> > > > > total 16
> > > > > drwxr-xr-x 512 root root16384 Mar 24 17:26 dcim/
> > > > > -r-xr-xr-x   1 root root0 May 23  2000 memstick.ind*
> > > > > #
> > > > >
> > > > > Where the 

Re: X15 alpha release: as fast as TUX but in user space (fwd)

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:dean gaudet <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Sun, 29 Apr 2001, Jeff Garzik wrote:
> 
> > "H. Peter Anvin" wrote:
> > > We discussed this at the Summit, not a year or two ago.  x86-64 has
> > > it, and it wouldn't be too bad to do in i386... just noone did.
> >
> > It came up long before that.  I refer to the technique in a post dated
> > Nov 17, even though I can't find the original.
> > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg13584.html
> >
> > Initiated by a post from (iirc) Dean Gaudet, we found out that
> > gettimeofday was one particular system call in the Apache fast path that
> > couldn't be optimized well, or moved out of the fast path.  After a
> > couple of suggestions for improving things, Linus chimed in with the
> > magic page suggestion.
> 
> heheh.  i can't claim that i was the first ever to think of this.  but
> here's the post i originally made on the topic.  iirc a few folks said
> "security horror!"... then last year ingo and linus (and probably others)
> came up with a scheme everyone was happy with.
> 
> i was kind of solving a different problem with the code page though -- the
> ability to use rdtsc on SMP boxes with processors of varying speeds and
> synchronizations.
> 

The thing that made me say we discussed this last month was Richard's
comment that it had already been implemented (which it has, by Andrea,
for x86-64.)  The idea of doing it for i386 has been kicked around for
years, originally as a way to handle INT 0x80 vs SYSENTER vs SYSCALL,
which I think is part of why it never got implemented, since handling
multiple flavours of system calls apparently causes some pain in the
system call entry/exit path.

The handling of a few things like gettimeofday etc. was something we
observed could be added on top at that time, but was largely
considered secondary.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: Sony Memory stick format funnies...

[Rogier Wolff]

H. Peter Anvin wrote:
> Rogier Wolff wrote:
> > 
> > H. Peter Anvin wrote:
> > > Followup to:  <[EMAIL PROTECTED]>
> > > By author:[EMAIL PROTECTED] (Rogier Wolff)
> > > In newsgroup: linux.dev.kernel
> > > >
> > > > # l /mnt/d1
> > > > total 16
> > > > drwxr-xr-x 512 root root16384 Mar 24 17:26 dcim/
> > > > -r-xr-xr-x   1 root root0 May 23  2000 memstick.ind*
> > > > #
> > > >
> > > > Where the 

Re: X15 alpha release: as fast as TUX but in user space (fwd)

[Gregory Maxwell]

On Sun, Apr 29, 2001 at 10:11:59PM +0200, Ingo Oeser wrote:
[snip]
> The point is: The code in that "magic page" that considers the
> tradeoff is KERNEL code, which is designed to care about such
> trade-offs for that machine. Glibc never knows this stuff and
> shouldn't, because it is already bloated.
> 
> We get the full win here, for our "compile the kernel for THIS
> machine to get maximum performance"-strategy.
> 
> People tend to compile the kernel, but not the glibc.
> 
> Just let the benchmarks, Linus and Ulrich decide ;-)

The kernel can even customize the page at runtime if it needs to, such as
changing algorithims to deal with lock contention.

Of course, this page will need to present a stable interface to glibc, and
having both the code and a comprehensive jump-table might become tough in a
single page...
-
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: ServerWorks LE and MTRR

[Gérard Roudier]

On Sun, 29 Apr 2001, Steffen Persvold wrote:

> Hi all,
> 
> I just compiled 2.4.4 and are running it on a Serverworks LE motherboard.
> Whenever I try to add a write-combining region, it gets rejected. I took a peek
> in the arch/i386/kernel/mtrr.c and found that this is just as expected with
> v1.40 of the code. It is great that the mtrr code checks and prevents the user
> from doing something that could eventually lead to data corruption. Using
> write-combining on PCI acesses can lead to this on certain LE revisions but
> _not_ all (only rev < 5). Therefore please consider my small patch to allow the
> good ones to be able to use write-combining. I have several rev 06 and they are
> working fine with this patch.

You wrote that 'only rev < 5' can lead to data corruption, but your patch
seems to disallow use of write combining for rev 5 too.

Could you clarify?

  Gérard.

PS:
From what hat did you get this information ? as it seems that ServerWorks
require NDA for letting know technical information on their chipsets.

> Best regards,
> -- 
>  Steffen PersvoldSystems Engineer
>  Email  : mailto:[EMAIL PROTECTED]Scali AS (http://www.scali.com)
>  Norway : Tel  : (+47) 2262 8950 Olaf Helsets vei 6
>   Fax  : (+47) 2262 8951 N-0621 Oslo, Norway
> 
>  USA: Tel  : (+1) 713 706 0544   10500 Richmond Avenue, Suite 190
>  Houston, Texas 77042, USA
> 
> diff -Nur linux/arch/i386/kernel/mtrr.c.~1~ linux/arch/i386/kernel/mtrr.c
> --- linux/arch/i386/kernel/mtrr.c.~1~ Wed Apr 11 21:02:27 2001
> +++ linux/arch/i386/kernel/mtrr.c Sun Apr 29 10:18:06 2001
> @@ -480,6 +480,7 @@
>  {
>  unsigned long config, dummy;
>  struct pci_dev *dev = NULL;
> +u8 rev;
>  
> /* ServerWorks LE chipsets have problems with  write-combining 
>Don't allow it and  leave room for other chipsets to be tagged */
> @@ -489,7 +490,9 @@
>  case PCI_VENDOR_ID_SERVERWORKS:
>   switch (dev->device) {
>   case PCI_DEVICE_ID_SERVERWORKS_LE:
> - return 0;
> + pci_read_config_byte(dev, PCI_CLASS_REVISION, );
> + if (rev <= 5)
> + return 0;
>   break;
>   default:
>   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: Sony Memory stick format funnies...

[H. Peter Anvin]

Gregory Maxwell wrote:
> >
> > I doubt the kernel is seeing it without it being there (it doesn't have
> > much imagination.)  However, it may very well be there in a funny
> > manner.  You do realize, of course, that it's pretty much impossible for
> > us to help you answer that question without a complete dump of the
> > filesystem on hand, I hope?
> 
> He gave what he thought was a complete dump of the non-null bytes. The
> obvious answer is that he's looking wrong. :)
> 

Hence the "complete" part...

-=hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: Sony Memory stick format funnies...

[Gregory Maxwell]

On Sun, Apr 29, 2001 at 01:09:22PM -0700, H. Peter Anvin wrote:
> Rogier Wolff wrote:
> > 
> > H. Peter Anvin wrote:
> > > Followup to:  <[EMAIL PROTECTED]>
> > > By author:[EMAIL PROTECTED] (Rogier Wolff)
> > > In newsgroup: linux.dev.kernel
> > > >
> > > > # l /mnt/d1
> > > > total 16
> > > > drwxr-xr-x 512 root root16384 Mar 24 17:26 dcim/
> > > > -r-xr-xr-x   1 root root0 May 23  2000 memstick.ind*
> > > > #
> > > >
> > > > Where the 

Re: X15 alpha release: as fast as TUX but in user space (fwd)

[Ingo Oeser]

On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> Ingo Oeser writes:
> > There we have 10x faster memmove/memcpy/bzero for 1K blocks
> > granularity (== alignment is 1K and size is multiple of 1K), that
> > is done by the memory controller.
> This sounds different to me. Using the memory controller is (should
> be!) a privileged operation, thus it requires a system call. This is
> quite different from code in a magic page, which is excuted entirely
> in user-space. The point of the magic page is to avoid the syscall
> overhead.

Yes, but we currently have more than 10K cycles for doing
memset of a page. If we do an syscall, we have around 600-900
(don't know exactly), which is still less.

The point is: The code in that "magic page" that considers the
tradeoff is KERNEL code, which is designed to care about such
trade-offs for that machine. Glibc never knows this stuff and
shouldn't, because it is already bloated.

We get the full win here, for our "compile the kernel for THIS
machine to get maximum performance"-strategy.

People tend to compile the kernel, but not the glibc.

Just let the benchmarks, Linus and Ulrich decide ;-)

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
  been there and had much fun   
-
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: Sony Memory stick format funnies...

[H. Peter Anvin]

Rogier Wolff wrote:
> 
> H. Peter Anvin wrote:
> > Followup to:  <[EMAIL PROTECTED]>
> > By author:[EMAIL PROTECTED] (Rogier Wolff)
> > In newsgroup: linux.dev.kernel
> > >
> > > # l /mnt/d1
> > > total 16
> > > drwxr-xr-x 512 root root16384 Mar 24 17:26 dcim/
> > > -r-xr-xr-x   1 root root0 May 23  2000 memstick.ind*
> > > #
> > >
> > > Where the 

Re: Sony Memory stick format funnies...

[Rogier Wolff]

H. Peter Anvin wrote:
> Followup to:  <[EMAIL PROTECTED]>
> By author:[EMAIL PROTECTED] (Rogier Wolff)
> In newsgroup: linux.dev.kernel
> > 
> > # l /mnt/d1
> > total 16
> > drwxr-xr-x 512 root root16384 Mar 24 17:26 dcim/
> > -r-xr-xr-x   1 root root0 May 23  2000 memstick.ind*
> > # 
> > 
> > Where the 

Re: X15 alpha release: as fast as TUX but in user space (fwd)

[Richard Gooch]

Gregory Maxwell writes:
> Would it make sence to have libc use the magic page for all
> syscalls? Then on cpus with a fast syscall instruction, the magic
> page could contain the needed junk in userspace to use it.

That's pretty much what Linus suggested. He proposed having a new
syscall interface which was just calls into the magic page. All
syscalls would thus be available via the magic page. The kernel could
then selectively optimise individual syscalls (like gettimeofday(2))
or optimise the interface into kernel space, without libc ever having
to know about the details.

Regards,

Richard
Permanent: [EMAIL PROTECTED]
Current:   [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: question regarding cpu selection

[Gregory Maxwell]

On Sun, Apr 29, 2001 at 07:07:51PM -0400, Duncan Gauld wrote:
> Hi,
> This seems a silly question but - I have an intel celeron 800mhz CPU and thus 
> it is of the Coppermine breed. But under cpu selection when configuring the 
> kernel, should I select PIII or PII/Celeron? Just wondering, since Coppermine 
> is basically a newish PIII with 128K less cache...

PIII, the differnce in the options is stuff like SSE that your PIII/Celeron
has.
-
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: question regarding cpu selection

[Erik Mouw]

On Sun, Apr 29, 2001 at 07:07:51PM -0400, Duncan Gauld wrote:
> This seems a silly question but - I have an intel celeron 800mhz CPU and thus 
> it is of the Coppermine breed. But under cpu selection when configuring the 
> kernel, should I select PIII or PII/Celeron? Just wondering, since Coppermine 
> is basically a newish PIII with 128K less cache...

You should select PIII. Configure.help already says that, but here is a
patch against linux-2.4.4 that reflects that change in
arch/i386/config.in as well. Please apply.


Erik

Index: arch/i386/config.in
===
RCS file: /home/erik/cvsroot/elinux/arch/i386/config.in,v
retrieving revision 1.1.1.38
diff -u -r1.1.1.38 config.in
--- arch/i386/config.in 2001/04/26 12:31:41 1.1.1.38
+++ arch/i386/config.in 2001/04/29 19:28:12
@@ -27,21 +27,21 @@
 mainmenu_option next_comment
 comment 'Processor type and features'
 choice 'Processor family' \
-   "386CONFIG_M386 \
-486CONFIG_M486 \
-586/K5/5x86/6x86/6x86MXCONFIG_M586 \
-Pentium-ClassicCONFIG_M586TSC \
-Pentium-MMXCONFIG_M586MMX \
-Pentium-Pro/Celeron/Pentium-II CONFIG_M686 \
-Pentium-IIICONFIG_MPENTIUMIII \
-Pentium-4  CONFIG_MPENTIUM4 \
-K6/K6-II/K6-IIICONFIG_MK6 \
-Athlon/Duron/K7CONFIG_MK7 \
-Crusoe CONFIG_MCRUSOE \
-Winchip-C6 CONFIG_MWINCHIPC6 \
-Winchip-2  CONFIG_MWINCHIP2 \
-Winchip-2A/Winchip-3   CONFIG_MWINCHIP3D \
-CyrixIII/C3CONFIG_MCYRIXIII" Pentium-Pro
+   "386CONFIG_M386 \
+486CONFIG_M486 \
+586/K5/5x86/6x86/6x86MXCONFIG_M586 \
+Pentium-ClassicCONFIG_M586TSC \
+Pentium-MMXCONFIG_M586MMX \
+Pentium-Pro/Celeron/Pentium-II CONFIG_M686 \
+Pentium-III/Celeron(Coppermine)CONFIG_MPENTIUMIII \
+Pentium-4  CONFIG_MPENTIUM4 \
+K6/K6-II/K6-IIICONFIG_MK6 \
+Athlon/Duron/K7CONFIG_MK7 \
+Crusoe CONFIG_MCRUSOE \
+Winchip-C6 CONFIG_MWINCHIPC6 \
+Winchip-2  CONFIG_MWINCHIP2 \
+Winchip-2A/Winchip-3   CONFIG_MWINCHIP3D \
+CyrixIII/C3CONFIG_MCYRIXIII" Pentium-Pro
 #
 # Define implied options from the CPU selection here
 #

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
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/