Re: Massive speed slowdown with any kernel after 2.4.1

On Wed, 7 Feb 2001, Alexander Trotsai wrote: > I have PIII/128Mb/IDE uDMA 66 PC I try 2.4.1ac1, ac2 and > 2.4.2pre1 And all this kernel after message "Freeing unused > kernel memmory" highly slowing Even cursor (I have framebuffer) > blink slowly But Turn off ACPI Rik -- Linux MM bugzilla:

Massive speed slowdown with any kernel after 2.4.1

Hello all I have PIII/128Mb/IDE uDMA 66 PC I try 2.4.1ac1, ac2 and 2.4.2pre1 And all this kernel after message "Freeing unused kernel memmory" highly slowing Even cursor (I have framebuffer) blink slowly But (via vmstat) no processor used, no disk operation. I try to compile both gcc from redhat

Re: 2.4 kernel & gcc code generation: a bug?

Followup to: <3A8108F8.2476.21D0F5@localhost> By author:"Ulrich Windl" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > You'll notice that %edx is not pushed at the start of the function. > Unless the caller saves that, edx will be spilled. Depending on the > level of optimization

[UPDATE] New zerocopy patch.

Against 2.4.2-pre1: ftp://ftp.kernel.org/pub/linux/kernel/people/davem/zerocopy-2.4.2p1-2.diff.gz Only one notable change since the last installment, but an important one: 1) When doing paged SKB sendmsg(), use csum_and_copy_from_user instead of copy_from_user. The problem is that

2.4 kernel & gcc code generation: a bug?

Trying to find out what got broken in kernel 2.4, I was so clueless as to compare assembly output for 2.2.18 with 2.4.1. However the assembler is quite different, as 2.4 uses the more advanced optimizations of gcc- 2.95.2. Anyway: 1) spinlocks look strange in 2.2(!): .globl rtc_lock

having a hard time with 2.4.x

Hello, I have some news on the topic of timekeeping in Linux-2.4: As Alan Cox pointed out the ACPI changes between 2.4.0 and 2.4.1 created a extremely slow console output (if not more). Configuring away ACPI support solved that problem. However there is still a problem that I cannot explain.

Re: OK to mount multiple FS in one dir?

On Wed, Feb 07, 2001 at 12:25:10AM -0600, Peter Samuelson wrote: > > [Wakko Warner] > > I have a question, why was this idea even considered? > > Al Viro likes Plan9 process-local namespaces. He seems to be trying to > move Linux in that direction. In the past year he has been hacking the >

Re: Software Mestizo Manifesto

This is very intesting seeing as the story I read in the Newspaper (USA Today) on encryption and terrorism today is an example of this. It seems that people are using open source software to do idiotic things. Many open source references were made in the article, I should see if the article is

[PATCH] updates for KLSI usb->ethernet

This patch, against 2.4.1-ac4, does the following for the KLSI USB->ethernet adapter: (patch at http://lager.dyndns.org/kaweth/KLSI-2.4.1-ac4.patch.bz2) o Fixes firmware downloading. If firmware is already loaded and an attempt is made to download it again, the device will hang. This will

hotplugging with regular PCI cards

I saw an interesting demonstration at LinuxWorld last week. Compaq had a machine that did hot plugging with regular PCI cards (not Compact PCI). If anyone out there is familiar with this machine, I would be interested in knowing what the status is on getting the support for that

[PATCH] vm_enough_memory() & i/d cache

Hi Linus, Alan, the attached patch makes vm_enough_memory() take the inode and dentry cache memory into account so people will again be able to start 300MB processes on their 384MB machine, even after slocate has eaten up 100MB in inode and dentry caches... It doesn't even try to get the

Re: RedHat kernel RPM 2.2.16

I appreciate your comments, but the SOURCE is exactly what I am needing in order to compile in PCTel modem support. FYI, I'm not a newbie, so I do not uninstall a kernel from a running system (no offense on your assumption :-P). Besides if I did, I would just simply spend 5 minutes creating a

Re: Software Mestizo Manifesto

> Quoted from the GPL: > --- > 6. Each time you redistribute the Program (or any work based on the > Program), the recipient automatically receives a license from the > original licensor to copy, distribute or modify the Program subject to > these terms and conditions. You may not impose

2.4.x and oops on 'mount -t smbfs'

Howdy, I'm running RedHat 7.0 on a Compaq Proliant 5500, 4x Xeon 550MHz, 4GB 50Ns EDO RAM. Under kernel 2.2.16-22 I'm able to use 'mount -t smbfs //ntserver/share /net -o username=me,password=mine,workgroup=yours' ... without a problem. NT files become available under '/net', as

Software Mestizo Manifesto

Hi this is off-topic sorry. I am trying to make a manifesto in order to attach it to all my gpl'd developments.. due to limitations in my english I would like to ask for your help... and maybe you can have a couple of new ideas to improve it. I am doing this because gpl'd developments usually

RedHat kernel RPM 2.2.16

I am trying to get RedHat's Kernel RPM 2.2.16 installed, however, the rpm program does unpack the files, but does not run any script to install them into the source tree (kernel-2.2.16-3.i386.src.rpm). Is there a trick to making it work? - To unsubscribe from this list: send the line

Re: Software Mestizo Manifesto

On Wed, 7 Feb 2001, Roberto Diaz wrote: > I am trying to make a manifesto in order to attach it to all my > gpl'd developments.. > I am doing this because gpl'd developments usually involves > people all around the world.. and being aware that a lot of > gpl'd / GNU resources are used by

Software Mestizo Manifesto

Hi this is off-topic sorry. I am trying to make a manifesto in order to attach it to all my gpl'd developments.. due to limitations in my english I would like to ask for your help... and maybe you can have a couple of new ideas to improve it. I am doing this because gpl'd developments usually

2.4.1-ac3 oops decoded with ksymoops

Here is an oops I got on one of my computers. It came about 5 mins after I forcibly ejected a PCMCIA card (A Spectrum24t 802.11b card), I don't know if it is related. The oops: == kernel BUG at sched.c:714! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286

Re: CPU error codes

Followup to: <[EMAIL PROTECTED]> By author:Carlos Carvalho <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Really? I thought it could be because of RAM. Here's the story: > > The kernel is 2.2.18pre24. > > I'm having VERY frequent of this (sometimes once a day, sometimes once > a

Re: freshmeat editorial on journaling filesystems

>We'd like to run an editorial this coming Saturday about the >journaling filesystems available for Linux. We'd like an author who >isn't a developer on any of them so he/she can give an object analysis >of the pros and cons of each and share thoughts on his/her opinions >about which should be

Re: Bug: 2.4.0 w/ PCMCIA on ThinkPad: KERNEL: assertion(dev->ip_ptr==NULL)failed at dev.c(2422):netdev_finish_unregister

I have a bit more information about this bug now. The message "assertion(yadda) failed ..." occurs only if the eth0 interface has been configured using pump or dhclient. If the card isn't connected to the network the message never occurs. If eth0 is merely brought up and down using ifconfig the

[PATCH] Modify scripts/ver_linux to display reiserfsprogs version

Here is a patch to the linux/scripts/ver_linux script which adds the reiserfsprogs utils to the items checked. If the reiserfsprogs have not been installed, the modified script outputs nothing for the Reiserfsprogs line (output looks the same as now). The current version of reiserfsck does not

Re: PATCH: ipfwadm IP accounting (2.4.1)

In message you write: > Using ipfwadm on a 2.4.1 kernel, some ip accouting rules for outgoing > packets have theirs packet and byte counter stuck to 0 value. There is no > such problem with incoming packets. Hi Eric! You're exactly right: it was a typo.

Re: Hard system freeze in 2.2.17, 2.2.18, 2.4.1-AC3 VIA Athlon

Mark Hahn wrote me and convinced me that the problem I described is a hardware problem, probably related to heat. Testing bears this out. I am still mystified as to why xemacs in particular should stress the system more than everything else, but I've got the sanity check I was looking for,

Re: Problems with Linux 2.4.1

On 07 Feb 2001 02:27:57 +, Alexander Zvyagin wrote: > 2) Frame-buffer mode does not work with my video card SiS630. >But ok, frame-buffer mode is EXPERIMENTAL in linux. >Computer boots, but screen is blank. All messages are fine. > 01:00:0 VGA compatible controller: Silicon

freshmeat editorial on journaling filesystems

We'd like to run an editorial this coming Saturday about the journaling filesystems available for Linux. We'd like an author who isn't a developer on any of them so he/she can give an object analysis of the pros and cons of each and share thoughts on his/her opinions about which should be

Re: [reiserfs-list] NFS and reiserfs

On Wed, 7 Feb 2001, Neil Brown wrote: > http://www.cse.unsw.edu.au/~neilb/patches/linux/2.4.2-pre1/patch-D-nfsirix > not yet submitted to Linus. > ahh. didn't know. I have the first patch you sent me for the weird IRIX device file permissions checking - but i didn't notice this second pipe

Re: [reiserfs-list] NFS and reiserfs

On Tuesday February 6, [EMAIL PROTECTED] wrote: > On Mon, 5 Feb 2001, Samuel Flory wrote: > > > someone (you?) talking about v3 issues with SGI boxes under 2.4 on the > > nfs list. I didn't much pay much attention as it wasn't an issue I > > could help with. > > that might have been me... > >

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > > > "struct buffer_head" can deal with pretty much any size: the only thing it > > cares about is bh->b_size. > > Right now, anything larger than a page is physically non-contiguous, > and sorry if I didn't make that explicit, but I thought that

[OT] Re: PCI-SCI Drivers v1.1-7 released

On Tue, Feb 06, 2001 at 07:06:24PM -0700, Jeff V. Merkey wrote: > More to add on the gcc 2.96 problems. After compiling a Linux 2.4.1 > kernel on gcc 2.91, running SCI benchmarks, then compiling on RedHat > 7.1 (Fischer) with gcc 2.96, the 2.96 build DROPPED 30% in throughput > from the gcc

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, Feb 06 2001, Linus Torvalds wrote: > > > [...] so I would be _really_ nervous about just turning it on > > > silently. This is all very much a 2.5.x-kind of thing ;) > > > > Then you might want to apply this :-) > > > > --- drivers/block/ll_rw_blk.c~ Wed Feb 7 02:38:31 2001 > >

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

Hi, On Tue, Feb 06, 2001 at 04:50:19PM -0800, Linus Torvalds wrote: > > > On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > > > > That gets us from 512-byte blocks to 4k, but no more (ll_rw_block > > enforces a single blocksize on all requests but that relaxing that > > requirement is no big

Re: FA-311 / Natsemi problems with 2.4.1

At 05:28 PM 2/6/01 , you wrote: >Jocelyn Mayer wrote: > > > > I found something from OpenBSD: > > the natsemi chip (in fact DP83815) > > is quite the same as SiS900 one. > >If that is true, maybe you can hack drivers/net/sis900.c to get it to >work with the FA-311? > > Jeff My FA311

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, 7 Feb 2001, Jens Axboe wrote: > > > [...] so I would be _really_ nervous about just turning it on > > silently. This is all very much a 2.5.x-kind of thing ;) > > Then you might want to apply this :-) > > --- drivers/block/ll_rw_blk.c~Wed Feb 7 02:38:31 2001 > +++

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > > > > The fact is, if you have problems like the above, then you don't > > understand the interfaces. And it sounds like you designed kiobuf support > > around the wrong set of interfaces. > > They used the only interfaces available at the

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, Feb 06 2001, Linus Torvalds wrote: > > I don't see anything that would break doing this, in fact you can > > do this as long as the buffers are all at least a multiple of the > > block size. All the drivers I've inspected handle this fine, noone > > assumes that rq->bh->b_size is the same

Oopses in 2.4.1 (lots of them)

Hi all, I have a misfortune of reporting yet another Oops in 2.4.1 (my previous report got ignored). After running for 4 days I got many, many oopses. They were trigerred by xscreensaver, and some other X-related apps. After dopping to runlevel 3, the system seemed O.K. Nothing unusual in

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

Hi, On Tue, Feb 06, 2001 at 04:41:21PM -0800, Linus Torvalds wrote: > > On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > > No, it is a problem of the ll_rw_block interface: buffer_heads need to > > be aligned on disk at a multiple of their buffer size. > > Ehh.. True of ll_rw_block() and

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, 7 Feb 2001, Ingo Molnar wrote: > > most likely some coding error on your side. buffer-size mismatches should > show up as filesystem corruption or random DMA scribble, not in-driver > oopses. I'm not sure. If I was a driver writer (and I'm happy those days are mostly behind me ;), I

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, 7 Feb 2001, Jens Axboe wrote: > > I don't see anything that would break doing this, in fact you can > do this as long as the buffers are all at least a multiple of the > block size. All the drivers I've inspected handle this fine, noone > assumes that rq->bh->b_size is the same in all

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, Feb 07, 2001 at 02:06:27AM +0100, Ingo Molnar wrote: > > On Tue, 6 Feb 2001, Jeff V. Merkey wrote: > > > > I don't see anything that would break doing this, in fact you can > > > do this as long as the buffers are all at least a multiple of the > > > block size. All the drivers I've

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, 7 Feb 2001, Jens Axboe wrote: > > > Adaptec drivers had an oops. Also, AIC7XXX also had some oops with it. > > > > most likely some coding error on your side. buffer-size mismatches should > > show up as filesystem corruption or random DMA scribble, not in-driver > > oopses. > > I

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, Feb 07, 2001 at 02:08:53AM +0100, Jens Axboe wrote: > On Tue, Feb 06 2001, Jeff V. Merkey wrote: > > Adaptec drivers had an oops. Also, AIC7XXX also had some oops with it. > > Do you still have this oops? > I can recreate. Will work on it tommorrow. SCI testing today. Jeff > -- >

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, Feb 06 2001, Jeff V. Merkey wrote: > Adaptec drivers had an oops. Also, AIC7XXX also had some oops with it. Do you still have this oops? -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, Feb 07 2001, Ingo Molnar wrote: > > > So I would appreciate pointers to these devices that break so we > > > can inspect them. > > > > > > -- > > > Jens Axboe > > > > Adaptec drivers had an oops. Also, AIC7XXX also had some oops with it. > > most likely some coding error on your side.

Re: PCI-SCI Drivers v1.1-7 released

On Tue, Feb 06, 2001 at 06:25:01PM -0700, Jeff V. Merkey wrote: > > Also, the GCC 2.96 compiler shipped with RedHat 7.1 is terribly > broken, and does not support #ident lines in the source code, > which also means that RedHat 7.1 will not work properly with > CVS (Code Versioning System)

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Jeff V. Merkey wrote: > > I don't see anything that would break doing this, in fact you can > > do this as long as the buffers are all at least a multiple of the > > block size. All the drivers I've inspected handle this fine, noone > > assumes that rq->bh->b_size is the

Hard system freeze in 2.2.17, 2.2.18, 2.4.1-AC3 VIA Athlon

I am having terribly frustrating system stability problems, and I can't figure out whether I should suspect hardware or the kernel. Software: Any of Linux 2.2.17, 2.2.18, 2.4.1-AC3 Hardware: Athlon Thunderbird 750mhz, running at rated speed EPoX 8KTA2 VIA Athlon motherboard with VT82C686B

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, Feb 07, 2001 at 02:02:21AM +0100, Jens Axboe wrote: > On Tue, Feb 06 2001, Jeff V. Merkey wrote: > > I remember Linus asking to try this variable buffer head chaining > > thing 512-1024-512 kind of stuff several months back, and mixing them to > > see what would happen -- result. About

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, Feb 07, 2001 at 02:01:54AM +0100, Ingo Molnar wrote: > > On Tue, 6 Feb 2001, Jeff V. Merkey wrote: > > > I remember Linus asking to try this variable buffer head chaining > > thing 512-1024-512 kind of stuff several months back, and mixing them > > to see what would happen -- result.

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Jeff V. Merkey wrote: > I remember Linus asking to try this variable buffer head chaining > thing 512-1024-512 kind of stuff several months back, and mixing them > to see what would happen -- result. About half the drivers break with > it. [...] time to fix them then -

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, Feb 06 2001, Jeff V. Merkey wrote: > I remember Linus asking to try this variable buffer head chaining > thing 512-1024-512 kind of stuff several months back, and mixing them to > see what would happen -- result. About half the drivers break with it. > The interface allows you to do

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, Feb 06, 2001 at 04:50:19PM -0800, Linus Torvalds wrote: > > > On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > > > > That gets us from 512-byte blocks to 4k, but no more (ll_rw_block > > enforces a single blocksize on all requests but that relaxing that > > requirement is no big deal).

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > > That gets us from 512-byte blocks to 4k, but no more (ll_rw_block > enforces a single blocksize on all requests but that relaxing that > requirement is no big deal). Buffer_heads can't deal with data which > spans more than a page right now.

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, Feb 07, 2001 at 12:36:29AM +, Stephen C. Tweedie wrote: > Hi, > > On Tue, Feb 06, 2001 at 07:25:19PM -0500, Ingo Molnar wrote: > > > > On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > > > > > No, it is a problem of the ll_rw_block interface: buffer_heads need to > > > be aligned on

Re: sync & asyck i/o

On Tue, 6 Feb 2001, Stephen C. Tweedie wrote: > The ll_rw_block interface is perfectly clear: it expects the data to > be written to persistent storage once the buffer_head end_io is > called. If that's not the case, somebody needs to fix the lower > layers. Sure in 2.5 when I have a cleaner

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Ingo Molnar wrote: > > On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > > > No, it is a problem of the ll_rw_block interface: buffer_heads need to > > be aligned on disk at a multiple of their buffer size. Under the Unix > > raw IO interface it is perfectly legal to begin

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > > On Tue, Feb 06, 2001 at 08:57:13PM +0100, Ingo Molnar wrote: > > > > [overhead of 512-byte bhs in the raw IO code is an artificial problem of > > the raw IO code.] > > No, it is a problem of the ll_rw_block interface: buffer_heads need to >

[BUG] 2.4.[01] lockups

Hello, I am experiencing a problem with both 2.4.0 and 2.4.1. The problem is that at seemingly random times the console locks up. After the lockup I can no longer type and the mouse is frozen. As far as I can tell, other systems services are not affected, i.e. programs continue to run, music is

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

Hi, On Tue, Feb 06, 2001 at 07:25:19PM -0500, Ingo Molnar wrote: > > On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > > > No, it is a problem of the ll_rw_block interface: buffer_heads need to > > be aligned on disk at a multiple of their buffer size. Under the Unix > > raw IO interface it is

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, Feb 07 2001, Stephen C. Tweedie wrote: > > [overhead of 512-byte bhs in the raw IO code is an artificial problem of > > the raw IO code.] > > No, it is a problem of the ll_rw_block interface: buffer_heads need to > be aligned on disk at a multiple of their buffer size. Under the Unix >

PCI-SCI Drivers v1.1-7 released

The PCI-SCI v1.1-7 Drivers for Dolphin's Scalable Coherent Interface Adapters have been posted and are available for download at vger.timpanogas.org:\sci\pci-sci-1.1-7 in tar.gz and RPM (RedHat Package Manager Formats). This version supports Linux kernels 2.2.X up through 2.4.1. These

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

Hi, On Tue, Feb 06, 2001 at 08:57:13PM +0100, Ingo Molnar wrote: > > [overhead of 512-byte bhs in the raw IO code is an artificial problem of > the raw IO code.] No, it is a problem of the ll_rw_block interface: buffer_heads need to be aligned on disk at a multiple of their buffer size. Under

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Wed, 7 Feb 2001, Stephen C. Tweedie wrote: > No, it is a problem of the ll_rw_block interface: buffer_heads need to > be aligned on disk at a multiple of their buffer size. Under the Unix > raw IO interface it is perfectly legal to begin a 128kB IO at offset > 512 bytes into a device. then

Re: smp_num_cpus redefined? (compiling 2.2.18 for non-SMP?)

Hello, sorry, too stupid not to look on the web first, but this should really _NOT_ appear in the kernel source tree. I found that apm=power_off and make mrproper before build helps. Juraj. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body

Re: smp_num_cpus redefined? (compiling 2.2.18 for non-SMP?)

On 02.07 Juraj Bednar wrote: > Hello, > > > the same for vanilla 2.4.1 and 2.4.1ac3. Everything works ok until I turn > off SMP > support (which is required to make it possible to turn off the machine using > APM, since > ACPI is completely broken in 2.4.1 for me). > You do not need to do

Re: smp_num_cpus redefined? (compiling 2.2.18 for non-SMP?)

Hello, the same for vanilla 2.4.1 and 2.4.1ac3. Everything works ok until I turn off SMP support (which is required to make it possible to turn off the machine using APM, since ACPI is completely broken in 2.4.1 for me). Juraj. - To unsubscribe from this list: send the line

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Marcelo Tosatti wrote: > > Its arguing against making a smart application block on the disk while its > able to use the CPU for other work. There are currently no other alternatives in user space. You'd have to create whole new interfaces for aio_read/write, and ways for

Re: FA-311 / Natsemi problems with 2.4.1

Jocelyn Mayer wrote: > > I found something from OpenBSD: > the natsemi chip (in fact DP83815) > is quite the same as SiS900 one. If that is true, maybe you can hack drivers/net/sis900.c to get it to work with the FA-311? Jeff -- Jeff Garzik | "You see, in this world there's

Problems with Linux 2.4.1

Hello, I have several problems with my computer (running RedHat 6.2) under Linux 2.4.1 kernel. (See attached files for more information). Here is a short summary: 1) Audio card (based on SiS chipset) does not work due to incorrect initialization of PCI resources. It seems that this is not a

Re: sync & asyck i/o

Hi, On Tue, Feb 06, 2001 at 11:25:00AM -0800, Andre Hedrick wrote: > On Tue, 6 Feb 2001, Stephen C. Tweedie wrote: > > No, we simply omit to instruct them to enable write-back caching. > > Linux assumes that the WCE (write cache enable) bit in a disk's > > caching mode page is zero. > > You

[PATCH] Spelling fixes for commonly misspelled words

I did some grepping for words that are often misspelled, and the below patch is the result of that. The patch fixes a large number of spelling errors (64 in total.) The changes that have been made (in many places) are these: adress --> address adressed --> addressed adressing --> addressing

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

My previous note was probably in error. W. Michael Petullo probably is really using a PCI internal Venus DSP1673 modem. I read too quickly and assumed that we were talking about the "Linmodem" topic. I will pass the note around here, and will summarize any replies I get. Clearly we should try

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Linus Torvalds wrote: > Remember: in the end you HAVE to wait somewhere. You're always going to be > able to generate data faster than the disk can take it. SOMETHING has to > throttle - if you don't allow generic_make_request() to throttle, you have > to do it on your own

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

Date: Tue, 06 Feb 2001 17:37:12 -0500 From: Ed Schulz <[EMAIL PROTECTED]> One editorial correction: Our PCI host-controller modem is based on the Mars DSP1646 or 1648, not the Venus DSP1673. Venus modems include the controller function, so require no special Linux code to work.

[BUG] linux 2.4.1 to 2.4.1-ac3 hangs

Hi, I have been see quite a few hangs on 2.4.1 thru 2.4.1-ac3. By hang I mean that the box stops Shift scroll-lock etc have no effect. I use a screen switch to share a monitor with a box setup as a serial console. Even switch this freezes leading me to suspect the video signal is dieing.

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

One editorial correction: Our PCI host-controller modem is based on the Mars DSP1646 or 1648, not the Venus DSP1673. Venus modems include the controller function, so require no special Linux code to work. I'll forward these notes along to our developers, and let you know the result. The

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Linus Torvalds wrote: > > > On Tue, 6 Feb 2001, Manfred Spraul wrote: > > > > > > The aio functions should NOT use READA/WRITEA. They should just use the > > > normal operations, waiting for requests. > > > > But then you end with lots of threads blocking in get_request()

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Jens Axboe wrote: > On Tue, Feb 06 2001, Marcelo Tosatti wrote: > > > > Reading write(2): > > > >EAGAIN Non-blocking I/O has been selected using O_NONBLOCK and there was > > no room in the pipe or socket connected to fd to write the data > >

ibmtr.o does not like 2.4 [Was: IBM Model 350 does not like 2.4]

Hi, Just to follow up on my own post, the problem is way down in the network driver layer, specifically in the ibmtr driver - it seems to be happy with 2.2, and barfs with 2.4 - for now I replaced it with an IBM pci card (olympic driver) and 2.4 is now solid on the machine that had serious

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Manfred Spraul wrote: > > > > The aio functions should NOT use READA/WRITEA. They should just use the > > normal operations, waiting for requests. > > But then you end with lots of threads blocking in get_request() So? What the HELL do you expect to happen if somebody

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, Feb 06 2001, Marcelo Tosatti wrote: > > > > We don't even need that, non-blocking is implicitly applied with READA. > > > > > > > READA just returns - I doubt that the aio functions should poll until > > > there are free entries in the request queue. > > > > The aio functions should NOT

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Linus Torvalds wrote: > > > On Tue, 6 Feb 2001, Manfred Spraul wrote: > > Jens Axboe wrote: > > > > > > > Several kernel functions need a "dontblock" parameter (or a callback, or > > > > a waitqueue address, or a tq_struct pointer). > > > > > > We don't even need that,

Re: Lucent Microelectronics Venus Modem, serial 5.05, and Linux 2.4.0

On Sun, Jan 14, 2001 at 08:10:45PM +0100, W. Michael Petullo wrote: > > In serial.c, you seem to perform a check by writing to a possible > > modem's interrupt enable register and reading the result. This seems to > > be one of the points at which the auto-configuration process occasionally > >

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

Linus Torvalds wrote: > > On Tue, 6 Feb 2001, Manfred Spraul wrote: > > Jens Axboe wrote: > > > > > > > Several kernel functions need a "dontblock" parameter (or a callback, or > > > > a waitqueue address, or a tq_struct pointer). > > > > > > We don't even need that, non-blocking is implicitly

patch for 2.4.1 disable printk and panic messages

Hi, this is an updated release of my patch for disabling all kernel messages. It is usefull on deep embedded systems with no human interactions and for rescue discs where the diskspace is always to less. To Linus: What must i do, to get this patch in the offical kernel? To Zack Brown: Not all

[PATCH] drivers/media/radio/radio-maxiradio.c - 2.4.1-ac4

Changes: - pci_enable_device return value wasn't checked, - unbalanced video_register_device if late failure in radio_install, - request_region is now done on the whole resource size (if it's wrong, the magic value "4" deserves a small comment imho), - new pci interface beautification (may help

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Manfred Spraul wrote: > Jens Axboe wrote: > > > > > Several kernel functions need a "dontblock" parameter (or a callback, or > > > a waitqueue address, or a tq_struct pointer). > > > > We don't even need that, non-blocking is implicitly applied with READA. > > > READA just

[RFC][PATCH] block ioctl to read/write last sector

Problem Summary: There is no function exported to userspace to read or write the last 512-byte sector of an odd-size disk. The block device uses 1K blocksize, and will prevent userspace from seeing the odd-block at the end of the disk, if the disk is odd-size. IA-64 architecture defines

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

Jens Axboe wrote: > > > Several kernel functions need a "dontblock" parameter (or a callback, or > > a waitqueue address, or a tq_struct pointer). > > We don't even need that, non-blocking is implicitly applied with READA. > READA just returns - I doubt that the aio functions should poll until

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

> > On Tue, 6 Feb 2001, Marcelo Tosatti wrote: > > > Think about a given number of pages which are physically contiguous on > > disk -- you dont need to cache the block number for each page, you > > just need to cache the physical block number of the first page of the > > "cluster". > > ranges

Re: FA-311 / Natsemi problems with 2.4.1

I found something from OpenBSD: the natsemi chip (in fact DP83815) is quite the same as SiS900 one. You'll find as attachement the driver code from OpenBSD. If someone wo knows something about OpenBSD driver could merge the driver drivers into Linux, I think it would be a real great deal !

Re: d-link dfe-530 tx (bug-report)

I just installed Urban's most recent patch, and I still get much the same problems when I reboot from Windows. The main difference appears to be that there's a few seconds' pause during the via-rhine driver initialisation (presumably while it tries to find PHY devices), and there aren't quite so

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Christoph Hellwig wrote: > > The second is that bh's are two things: > > - a cacheing object > - an io buffer Actually, they really aren't. They kind of _used_ to be, but more and more they've moved away from that historical use. Check in particular the page cache, and

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Marcelo Tosatti wrote: > Think about a given number of pages which are physically contiguous on > disk -- you dont need to cache the block number for each page, you > just need to cache the physical block number of the first page of the > "cluster". ranges are a hell of a

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, 6 Feb 2001, Ingo Molnar wrote: > > On Tue, 6 Feb 2001, Christoph Hellwig wrote: > > > The second is that bh's are two things: > > > > - a cacheing object > > - an io buffer > > > > This is not really an clean appropeach, and I would really like to get > > away from it. > > caching

Re: [OT] Re: Matrox G450 problems with 2.4.0 and xfree

On Tue, 6 Feb 2001, Mike A. Harris wrote: > If anyone has open source g450 patches against stock 4.0.2 that > get the thing to work at all, _please_ send me unified diffs, and > I will put them into my next build. I've yet to have my g450 do > anything but turn off my monitor, although a

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, Feb 06 2001, Ben LaHaise wrote: > =) This is what I'm seeing: lots of processes waiting with wchan == > __get_request_wait. With async io and a database flushing lots of io > asynchronously spread out across the disk, the NR_REQUESTS limit is hit > very quickly. You can't do async I/O

Re: [Kiobuf-io-devel] RFC: Kernel mechanism: Compound event wait

On Tue, Feb 06 2001, Manfred Spraul wrote: > > =) This is what I'm seeing: lots of processes waiting with wchan == > > __get_request_wait. With async io and a database flushing lots of io > > asynchronously spread out across the disk, the NR_REQUESTS limit is hit > > very quickly. > > > Has

  1   2   3   4   5   >