Re: time in the future during make for 2.4.0

On Sun, 28 Jan 2001 [EMAIL PROTECTED] wrote: > > I had this problem when I was upgrading my kernel, and happened to do > it during the daylight savings time roll-back. Confused the heck out > of me for a while. Anyways, you can try 'touching' all your files, > and do a 'make clean' then try

PCI IRQ routing problem in 2.4.0

Hi Martin! While moving from 2.4.0-test9 to 2.4.0 I got the following problem: Linux thinks my usb controller is on IRQ 12 instead of IRQ 9. The 'BIOS box' (on boot) still states that usb is on IRQ 9. Under test9 pci-irq-behaviour was okay for me, but with 2.4.0 I cant load the usb-modules (the

Re: dos-partition mount bug

I suggest type # fdisk -l /dev/hdb Maybe it's FAT32 where the others are FAT16? Try SCANDISK(tm)... If you're familiar with FAT, you also could use DEBUG, the Norton Utilities etc. to look for a failure in the filesystem. For FAT16 it's easy. Bootsector, 2xFAT, root dir, data blocks Send us a

dos-partition mount bug

> Hi, The following bug-report concerns all linux-versions (inclusive 2.2.18) I have had to do with! > I have been trying to mount the dos-partition /dev/hdb1 on /dos/d for > three years and it fails: > My /etc/fstab is: > /dev/hda3 / ext2 defaults 0 1 > /dev/hdb2 /downloads ext2 defaults 0 1 >

tulip autonegotiation patch

Hi, This one-liner fixes a subtle 21143 autonegotiation problem for me on a Zynx quad card. The driver would claim to negotiate 100-FD, but would report late collisions and bad transmit throughput. The driver still allows packets to be transmitted during autonegotiation, but that only drops a

Re: ECN: Clearing the air (fwd)

On Sun, Jan 28, 2001 at 01:08:40PM -0500, jamal wrote: > On Sun, 28 Jan 2001, Rogier Wolff wrote: > > > A sufficiently paranoid firewall should block requests that he doesn't > > fully understand. ECN was in this category, so old firewalls are > > "right" to block these. (Sending an 'RST' is not

linux-kernel´Ô¾È³çÇϼ¼¿ä?

Title: ¢Ä ¿À´ÃÀÇ À¯¸Ó ÇѸ¶µð ¢Å   "Dad, I don't want to go to school today.," said the boy.  "Why not, son?"  "Well, one of the chickens on the school farm died last week and    we had chicken soup for lunch the next day. And three days ago    one of the pigs died and we had roast

Re: ECN: Clearing the air (fwd)

On Sun, Jan 28, 2001 at 05:11:20PM +, James Sutherland wrote: [snip] > > The simplest thing in this chaos is to fix the firewall because it is in > > violation to begin with. > > It is not in violation, and you can't fix it: it's not yours. [snip] > > It's too bad we end up defining

Re: Poor SCSI drive performance on SMP machine, 2.2.16

Sorry, forget this last email. Here is hdparm output. hdparm

Re: Poor SCSI drive performance on SMP machine, 2.2.16

I did this: date dd if=/dev/zero of=TESTFILE bs=1024 count=102400 date sync date and I gave the time differences from the first to the last timestamp. Regards, Para-dox ([EMAIL PROTECTED]) - Original Message - From: "Bruce Harada" <[EMAIL PROTECTED]> To: "paradox3" <[EMAIL

Re: time in the future during make for 2.4.0

I had this problem when I was upgrading my kernel, and happened to do it during the daylight savings time roll-back. Confused the heck out of me for a while. Anyways, you can try 'touching' all your files, and do a 'make clean' then try again. If it doesn't complain about a long arg list, you

Re: ECN: Clearing the air (fwd)

On Sun, Jan 28, 2001 at 02:09:19PM +, James Sutherland wrote: > On Sun, 28 Jan 2001, Ben Ford wrote: > > Do keep in mind, we aren't breaking connectivity, they are. > > Let me guess: you're a lawyer? :-) > > This is a very strange definition: if someone makes a change such that > their

Re: time in the future during make for 2.4.0

On Sun, 28 Jan 2001 12:27:46 -0600 (CST), Thomas Molina wrote: >I seem to recall a discussion on faster processors causing timing >problems during a kernel make, but I'm unable to find it in the kernel >archives. I've now upgraded to an Athlon 900 MHz processor and an ASUS >A7V motherboard and

Choosing Linux NICs (was: Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN))

Thus spake Felix von Leitner ([EMAIL PROTECTED]): > What is missing here is a good authoritative web ressource that tells > people which NIC to buy. I started one now. It's at http://www.fefe.de/linuxeth/, but there is not much content yet. Please contribute! Felix - To unsubscribe from this

Re: ECN: Clearing the air (fwd)

On Sun, Jan 28, 2001 at 06:04:17AM -0800, Ben Ford wrote: > James Sutherland wrote: [snip] > > those firewalls should be updated to allow ECN-enabled packets > > through. However, to break connectivity to such sites deliberately just > > because they are not supporting an *experimental*

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

On Sun, Jan 28, 2001 at 02:37:48PM +0100, Felix von Leitner wrote: > Thus spake Andrew Morton ([EMAIL PROTECTED]): > > Conclusions: > > > For a NIC which cannot do scatter/gather/checksums, the zerocopy > > patch makes no change in throughput in all case. > > > For a NIC which can do

Re: Kernel 2.4.0 loop device still hangs

On Sun, Jan 28 2001, Andreas Franck wrote: > Hi Jens, > > I've tested your patch quite as heavy as it gets: I created 5 files of each > 100 MB, set up 5 loop devices and made a RAID5 array out of them, putting > ext2 on it and running a bonnie loop with 350 MB test size over it for the >

Re: ECN: Clearing the air (fwd)

On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote: > > There is nothing silly with the decision, davem is simply a modern day > > internet hero. > > No. If it were something essential, perhaps, but it's just a minor > performance tweak to cut packet loss over congested links. It's

Re: Q: Release of 2.4.1

On Sun, Jan 28 2001, mirabilos wrote: > Does 2.4.1 when released, include e.g. Jens' loop patch? No, I haven't submitted it yet due to the massive restructering. Plus, it also touches other parts than loop itself. > Because it seems stable and loop else were buggy. > So for others if there are.

Re: [OT] Re: hotmail not dealing with ECN

On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote: > On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote: > ... > > An attack against an Xray system is much more likely to come from inside the > > companies network. > ... > > We are not talking about attacks here, we are

Re: Poor SCSI drive performance on SMP machine, 2.2.16

Hm. As a point of comparison, I use a similar system to yours (full SCSI, though, no IDE) and I can copy a 100MB file from disk-to-disk, or on the same disk, in around 13 seconds. Where are you copying to the SCSI drive from - the same drive, an IDE disk, CDROM? If IDE, what are its particulars?

Q: Release of 2.4.1

Does 2.4.1 when released, include e.g. Jens' loop patch? Because it seems stable and loop else were buggy. So for others if there are. mirabilos -BEGIN GEEK CODE BLOCK- Version: 3.12+custom(^=href;C-style-comments) GO/S dx@ s--: a---> C++ UL P--- L++$(-^lang) E/joe W+(++) N?

Re: Linux-2.4.1-pre11

> I just uploaded it to kernel.org, and I expect that I'll do the final > 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the > pre-kernel works for you.. Hello Linus, can we please see Andrew's latest ACPI fixes ([Acpi] ACPI source release updated: 1-25-2001) in 2.4.1

Re: Renaming lost+found

On Friday, January 26, 2001 01:19:49 PM -0500 James Lewis Nance <[EMAIL PROTECTED]> wrote: > FWIW IBM's JFS file system does not have a lost+found directory. I dont > remember if reiserfs does or not. > reiserfsck creates it. -chris - To unsubscribe from this list: send the line

Re: Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.xkernels?

On Sunday, January 28, 2001 02:29:09 PM +1100 Andrew Morton <[EMAIL PROTECTED]> wrote: > Shawn Starr wrote: >> >> Andrew, the patch HAS made a difference. For example, while untaring >> glibc-2.2.1.tar.gz the system was not sluggish (mouse movements in X) >> etc. >> >> Seems to be a go for

Re: [ANNOUNCE] Kernel Janitor's TODO list

Hi, On Sun, 28 Jan 2001, Manfred Spraul wrote: > And one more point for the Janitor's list: > Get rid of superflous irqsave()/irqrestore()'s - in 90% of the cases > either spin_lock_irq() or spin_lock() is sufficient. That's both faster > and better readable. > > spin_lock_irq(): you know that

time in the future during make for 2.4.0

I seem to recall a discussion on faster processors causing timing problems during a kernel make, but I'm unable to find it in the kernel archives. I've now upgraded to an Athlon 900 MHz processor and an ASUS A7V motherboard and have started seeing this. It shows up as the following messages

Re: 2.4.1-pre10 deadlock (Re: ps hang in 241-pre10)

On Sun, Jan 28 2001, Linus Torvalds wrote: > On Sun, 28 Jan 2001, Jens Axboe wrote: > > > > How about this instead? > > I really don't like this one. It will basically re-introduce the old > behaviour of waking people up in a trickle, as far as I can tell. The > reason we want the batching is

Re: ECN: Clearing the air (fwd)

On Sun, 28 Jan 2001, Rogier Wolff wrote: > > This would have been easier. The firewall operators were not > > provided with this option. This is hard-coded. I agree with the rest > > of your message. > > Take "configure" with a bit of liberty. Because the firewall vendor > chose to hard-code

Linux-2.4.1-pre11

I just uploaded it to kernel.org, and I expect that I'll do the final 2.4.1 tomorrow, before leaving for NY and LinuxWorld. Please test that the pre-kernel works for you.. The main noticeable things in pre11 are fixing some bugs that crept in after 2.4.0 - the block device queuing improvements

Re: 2.4.1-pre10 deadlock (Re: ps hang in 241-pre10)

On Sun, 28 Jan 2001, Jens Axboe wrote: > > How about this instead? I really don't like this one. It will basically re-introduce the old behaviour of waking people up in a trickle, as far as I can tell. The reason we want the batching is to make people have more requests to sort in the

[PATCH] ide config order

Please reorder config to group DMA options together. In 2.4.0 Pavel Rabel --- drivers/ide/Config.in.old Tue Nov 28 22:22:49 2000 +++ drivers/ide/Config.in Tue Nov 28 22:24:19 2000 @@ -42,8 +42,8 @@ bool ' Generic PCI IDE chipset support' CONFIG_BLK_DEV_IDEPCI if [

Re: 2.4.1-pre10 deadlock (Re: ps hang in 241-pre10)

On Sun, Jan 28 2001, Lorenzo Allegrucci wrote: > >Ho humm. Jens: imagine that you have more people waiting for requests than > >"batchcount". Further, imagine that you have multiple requests finishing > >at the same time. Not unlikely. Now, imagine that one request finishes, > >and causes

Re: ECN: Clearing the air (fwd)

jamal wrote: > > > On Sun, 28 Jan 2001, Rogier Wolff wrote: > > > jamal wrote: > > > > Yes, > > > > those firewalls should be updated to allow ECN-enabled packets > > > > through. However, to break connectivity to such sites deliberately just > > > > because they are not supporting an

problem exporting symbols from a lkm

Hello, I'm kinda new to this kernel hacking thing. So excuse me for any stupid questions/remarks. The problem I have occurs because I'm trying to install the rshaper software on my linux system. I'm running: Distribution: red hat 6.2 Kernel ver.: 2.2.14-5.0 System: i386 compiler: gcc compiler

Re: ECN: Clearing the air (fwd)

On Sun, 28 Jan 2001, Rogier Wolff wrote: > jamal wrote: > > > Yes, > > > those firewalls should be updated to allow ECN-enabled packets > > > through. However, to break connectivity to such sites deliberately just > > > because they are not supporting an *experimental* extension to the current

Re: ECN: Clearing the air (fwd)

On Sun, 28 Jan 2001, James Sutherland wrote: > On Sun, 28 Jan 2001, jamal wrote: > > We are allowing two rules to be broken, one is RFC 793 which > > clearly and unambigously defines what a RST means. the second is > > This is NOT being violated: the RST is honoured as normal. You are

Re: ECN: Clearing the air (fwd)

[EMAIL PROTECTED] (Rogier Wolff) writes: > If the firewall operator is sufficiently paranoid, they can say: "We > don't trust the ECN implementation on our hosts behind the firewall, > so we want to disable it.". In which case would the "correct" action not be to zero the ECN bits of packets

Re: Poor SCSI drive performance on SMP machine, 2.2.16

I don't get any messages relating to the drives in any syslog output. - Original Message - From: "Bruce Harada" <[EMAIL PROTECTED]> To: "paradox3" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Sunday, January 28, 2001 3:40 AM Subject: Re: Poor SCSI drive

Re: [ANNOUNCE] Kernel Janitor's TODO list

David Woodhouse wrote: > > TIOCMIWAIT does restore_flags() before interruptible_sleep_on(). It's > broken too. > Yes, and I found a second bug: it doesn't sti() immediately after interruptible_sleep_on(), thus cli() doesn't reacquire the global irq lock --> the atomic copy won't be atomic on

Re: ECN: Clearing the air (fwd)

jamal wrote: > > Yes, > > those firewalls should be updated to allow ECN-enabled packets > > through. However, to break connectivity to such sites deliberately just > > because they are not supporting an *experimental* extension to the current > > protocols is rather silly. > > > > This is the

Re: patch for 2.4.0 disable printk

Stefani Seibold wrote: > The inline function is the best choice, because it it full compatible to old > old printk. No side effects are expeted. What is the difference? I can't think of any difference between: #define printk(format, args...) ((int) 0) and: static inline int printk_inline

[patch] new, scalable timer implementation, smptimers-2.4.0-B1

a new, 'ultra SMP scalable' implementation of Linux kernel timers is now available for download: http://www.redhat.com/~mingo/scalable-timers/smptimers-2.4.0-B1 the patch is against 2.4.1-pre10 or ac12. The timer design in this implementation is a work of David Miller, Alexey Kuznetsov and

Re: Linux Post codes during runtime, possibly OT

H. Peter Anvin wrote: > It is; you'd have to specify "eax" as a clobber value, and that is > undesirable. For outb_p, EAX is used, usually for the last time, in the preceding "out" instruction so clobbering it is not a big deal. For inb_p, you first have to copy EAX to another register before

Re: ps hang in 241-pre10

On Sun, 28 Jan 2001, Marcelo Tosatti wrote: > > Why dont you just put set_page_dirty() back in page_launder() in case > writepage() fails? Because a EIO or similar should _not_ be re-tried or kept dirty. Imagine a bad user that goes over his quota on purpose, and then every single write will

troubles with devfs ?

This happens on a freshly booted 2.4.0 macine, with devfs and devfsd running. I got the oops by doing # cd /dev # ls -las (segmentation fault) The first oops causes the death of devfsd. I still can do # ls -als /dev/sc* 0 lr-xr-xr-x1 root root3 Jan 28 18:10

Re: ECN: Clearing the air (fwd)

On Sun, 28 Jan 2001, jamal wrote: > On Sun, 28 Jan 2001, James Sutherland wrote: > > On Sun, 28 Jan 2001, jamal wrote: > > > There were people who made the suggestion that TCP should retry after a > > > RST because it "might be an anti-ECN path" > > > > That depends what you mean by "retry"; I

Re: [ANNOUNCE] Kernel Janitor's TODO list

On Sun, 28 Jan 2001, Manfred Spraul wrote: > It isn't wrong to call schedule() with disabled interrupts - it's a > feature ;-) > Those 10% sleep_on() users that aren't broken use it: > > for(;;) { > cli(); > if(condition) > break; > sleep_on(_wait_queue); >

Re: doesn't boot.

mike wrote: > > Hi, im not sure if im emailing the right place but its a start. I just > setup kernel 2.4.0 and well it doesnt boot. > > it says " ok booting the kernel" then nothing happens on the screen, and > I hear no activity from the computer. I tried it several times following > the >

Re: hotmail not dealing with ECN

Dax Kelson wrote: > Jamie Lokier said once upon a time (Fri, 26 Jan 2001): > > > Does ECN provide perceived benefits to the node using it? > > Why are you even making suggestions when you haven't even read the RFC? > > It seems that knowing what ECN is would be prerequisite to engaging in >

compile error in 2.4.0

I'm probably doing something silly, but I have just tried to rebuild the 2.4.0 kernel. I changed a few config things and did make dep clean bzlilo modules modules_install and the following appeared. I did a brief look around for the declaration of skb_datarefp but couldn't find it.

Re: [ANNOUNCE] Kernel Janitor's TODO list

Arnaldo Carvalho de Melo wrote: > > Em Sun, Jan 28, 2001 at 05:14:37PM +0100, Manfred Spraul escreveu: > > > > > > Anything which uses sleep_on() has a 90% chance of being broken. Fix > > > them all, because we want to remove sleep_on() and friends in 2.5. > > > > > > > Then you can add 'calling

Re: ECN: Clearing the air (fwd)

On Sun, 28 Jan 2001, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > James Sutherland <[EMAIL PROTECTED]> wrote: > >On Sun, 28 Jan 2001, jamal wrote: > >> The internet is a form of organized chaos, sometimes you gotta make > >> these type of decisions to get things done.

doesn't boot.

Hi, im not sure if im emailing the right place but its a start. I just setup kernel 2.4.0 and well it doesnt boot. it says " ok booting the kernel" then nothing happens on the screen, and I hear no activity from the computer. I tried it several times following the instructions, I did make

Re: 2.4.1-pre8 losing pages

On Sun, 28 Jan 2001, Peter Horton wrote: > Okay, scratch that. It does still happen when there's no swap, but for > some reason it happens a lot less often. Looks like it's timing related, > it only fails when using 7200rpm drives, not older 5400rpm ones (even > though they too are using

flush_scheduled_tasks() question

Is is intentional that tummy_task is not initialized? Ok, it won't crash because the current __run_task_queue() implementation doesn't call tq->routine if it's NULL, but IMHO it's ugly. Additionally I don't like the loop in flush_scheduled_tasks(), what about replacing it with a locked semaphore

[patch] smbfs cache rewrite - 2nd try

Hello again This patch is more complete than the version posted earlier. It implements support for OS/2 (and possibly things even older than that :) and have been more tested. This borrows a lot from the ncpfs dircache code. Smbfs testers wanted, with or without highmem boxes. Bugs

Re: [ANNOUNCE] Kernel Janitor's TODO list

Em Sun, Jan 28, 2001 at 05:14:37PM +0100, Manfred Spraul escreveu: > > > > Anything which uses sleep_on() has a 90% chance of being broken. Fix > > them all, because we want to remove sleep_on() and friends in 2.5. > > > > Then you can add 'calling schedule() with disabled local interrupts()'

Re: [ANNOUNCE] Kernel Janitor's TODO list

Em Sun, Jan 28, 2001 at 12:28:50PM -0200, Arnaldo Carvalho de Melo escreveu: > Em Mon, Jan 29, 2001 at 03:13:19AM +1100, Andrew Morton escreveu: > > Arnaldo Carvalho de Melo wrote: > > > > > > Please send additions and corrections to me and I'll try > > > to keep it updated. > > > > Here - have

Re: ECN: Clearing the air (fwd)

On Sun, 28 Jan 2001, James Sutherland wrote: > On Sun, 28 Jan 2001, jamal wrote: > > There were people who made the suggestion that TCP should retry after a > > RST because it "might be an anti-ECN path" > > That depends what you mean by "retry"; I wanted the ability to attempt a > non-ECN

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

Andrew Morton wrote: > There has been surprisingly little discussion here about the > desirability of a preemptible kernel. > And I think that is a very intersting topic... (certainly more interesting than hotmail's firewalling policy ;o) Alright, so suppose I dream up an application which I

Re: [ANNOUNCE] Kernel Janitor's TODO list

> > Anything which uses sleep_on() has a 90% chance of being broken. Fix > them all, because we want to remove sleep_on() and friends in 2.5. > Then you can add 'calling schedule() with disabled local interrupts()' to your list. -- Manfred - To unsubscribe from this list: send the

Re: [ANNOUNCE] Kernel Janitor's TODO list

Em Mon, Jan 29, 2001 at 03:13:19AM +1100, Andrew Morton escreveu: > Arnaldo Carvalho de Melo wrote: > > > > Please send additions and corrections to me and I'll try > > to keep it updated. > > Here - have about 300 bugs: > > http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html

Re: [ANNOUNCE] Kernel Janitor's TODO list

Arnaldo Carvalho de Melo wrote: > > Please send additions and corrections to me and I'll try > to keep it updated. Here - have about 300 bugs: http://www.uwsg.iu.edu/hypermail/linux/kernel/0005.3/0269.html A lot of the timer deletion races are hard to fix because of the deadlock

Re: [PATCH] devfsd, compiling on glibc22x

While on the subject of devfs: - it doesn't seem to have any entries for raw devices: /dev/rawctl, /dev/raw/raw1, etc - when I upgraded to glibc 2.2 (via a rpm) in RH 7.0 this line in /etc/devfsd.conf caused devfsd to seg fault: "LOOKUP ^cdrom$ CFUNCTION GLOBAL

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

jamal wrote: > > PS:- can you try it out with the ttcp testcode i posted? Yup. See below. The numbers are almost the same as with `zcs' and `zcc'. The CPU utilisation code which was in `zcc' has been broken out into a standalone tool, so the new `cyclesoak' app is a general-purpose system

Re: [ANNOUNCE] Kernel Janitor's TODO list

On Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse wrote: > [EMAIL PROTECTED] said: > > Please send additions and corrections to me and I'll try to keep it > > updated. > Anything which uses sleep_on() has a 90% chance of being broken. Fix > them all, because we want to remove

Re: [ANNOUNCE] Kernel Janitor's TODO list

Em Sun, Jan 28, 2001 at 03:20:18PM +, David Woodhouse escreveu: > > [EMAIL PROTECTED] said: > > Please send additions and corrections to me and I'll try to keep it > > updated. > > Anything which uses sleep_on() has a 90% chance of being broken. Fix > them all, because we want to remove

Re: [OT] Re: hotmail not dealing with ECN

On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote: > On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote: > ... > > An attack against an Xray system is much more likely to come from inside the > > companies network. > ... > We are not talking about attacks here, we are

Re: ECN: Clearing the air (fwd)

James Sutherland wrote: > On Sun, 28 Jan 2001, Ben Ford wrote: > > > James Sutherland wrote: > > > > > I'm sure we all know what the IETF is, and where ECN came from. I haven't > > > seen anyone suggesting ignoring RST, either: DM just imagined that, > > > AFAICS. > > > > > > The one point I

Re: "no such 386 instruction" with gcc 2.95.2

> > I think I must need to upgrade my assembler, but: > > 2.4.0/Documentation/Changes does not list an assembler version. It does, the "binutils" package contain the assembler and linker, et.al. of that kind utilities. The errors quoted below are definitely due to "too

Re: [ANNOUNCE] Kernel Janitor's TODO list

[EMAIL PROTECTED] said: > Please send additions and corrections to me and I'll try to keep it > updated. Anything which uses sleep_on() has a 90% chance of being broken. Fix them all, because we want to remove sleep_on() and friends in 2.5. -- dwmw2 - To unsubscribe from this list: send the

Re: patch for 2.4.0 disable printk and panic messages, third try

On Sun, 28 Jan 2001, Stefani Seibold wrote: > this is now the third try to release my patch for disabling all kernel > messages. It is usefull on deep embedded systems with no human interactions > --- linux/arch/s390/config.in Thu Nov 16 21:51:28 2000 > +++ linux.noprintk/arch/s390/config.in

Re: patch for 2.4.0 disable printk and panic messages, third try

Stefani Seibold wrote: > > Hi guys, > > this is now the third try to release 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. > > This patch has now the following

Re: ECN: Clearing the air (fwd)

On Sun, Jan 28, 2001 at 01:29:52PM +, James Sutherland wrote: > > The internet is a form of organized chaos, sometimes you gotta make > > these type of decisions to get things done. Imagine the joy _most_ > > people would get flogging all firewall admins who block all ICMP. > > Blocking out

patch for 2.4.0 disable printk and panic messages, third try

Hi guys, this is now the third try to release 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. This patch has now the following features: The macro printk throws away all

[PATCH] udf writepage UnlockPage

Although fs/udf's args to writepage() were updated in 2.4.0-test12, its page unlocking was overlooked. udf_adinicb_writepage() should now UnlockPage, udf_expand_file_adinicb() should not now UnlockPage after udf_writepage i.e. block_write_full_page. Al Viro posted a patch for the latter, still

setitimer() and fork()

I'm having a problem when I try to profile a program that fork()'s. The problem is that it does count how many times I'm in a function, but nothing seems to use any cpu time at all. If I call setitmer(ITIMER_PROF, ...) again after the fork, it works as expected. fork() doesn't seem to copy the

Re: ECN: Clearing the air (fwd)

In article <[EMAIL PROTECTED]>, James Sutherland <[EMAIL PROTECTED]> wrote: >On Sun, 28 Jan 2001, jamal wrote: >> The internet is a form of organized chaos, sometimes you gotta make >> these type of decisions to get things done. Imagine the joy _most_ >> people would get flogging all firewall

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

On Sun, Jan 28, 2001 at 02:37:48PM +0100, Felix von Leitner wrote: > What is missing here is a good authoritative web ressource that tells > people which NIC to buy. > > I have a tulip NIC because a few years ago that apparently was the NIC > of choice. It has good multicast (which is important

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

Bill Huey wrote: > > Andrew Morton's patch uses < 10 rescheduling points (maybe less from memory) err... It grew. More like 50 now reiserfs is in there. That's counting real instances - it's not counting ones which are expanded multiple times as "1". It could be brought down to 20-25 with

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

[EMAIL PROTECTED] wrote: > > ... > > I suggest that you get your hearing checked. I'm fully in favor of sensible > low latency Linux. I believe however that low latency in Linux will > A. be "soft realtime", close to deadline most of the time. > B. millisecond level on present

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

On Sun, 28 Jan 2001, Felix von Leitner wrote: > What is missing here is a good authoritative web ressource that tells > people which NIC to buy. > I have a tulip NIC because a few years ago that apparently was the NIC > of choice. It has good multicast (which is important to me), but AFAIK > it

Re: ECN: Clearing the air (fwd)

On Sun, 28 Jan 2001, Ben Ford wrote: > James Sutherland wrote: > > > I'm sure we all know what the IETF is, and where ECN came from. I haven't > > seen anyone suggesting ignoring RST, either: DM just imagined that, > > AFAICS. > > > > The one point I would like to make, though, is that

Re: 2.4 Cpu usuage (display oddities more than anything)

Linda Walsh wrote: > Some oddities w/kapmd(2.4.0)... If I sit in X and do nothing other than run top or > "vmstat 5", I get down to as low as 60% idle and 40% in system -- with kapmd getting > 'charged' for the 40%. > > Then I go and run 'freeamp' and the CPU usage goes to 100% idle, presumably

sandisk sddr31 or scsi problems, double occurence

Hi! I have a problem with my sandisk sddr31 occuring 2 times while only one is installed. My configuration: linux-2.4.1-pre10 hotplug-scripts (newest) ohci I attach the output of cat /proc/bus/usb/devices, here only one sddr is occuring, and various cat's from my /proc/scsi dir Please, tell

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

On Sun, Jan 28, 2001 at 06:14:28AM -0700, [EMAIL PROTECTED] wrote: > > Yes, I most emphatically do disagree with Victor! IRIX is used for > > mission-critical audio applications - recording as well playback - and > And it has bloat, it's famously buggy, it is impossible to maintain, ...

Re: ECN: Clearing the air (fwd)

James Sutherland wrote: > I'm sure we all know what the IETF is, and where ECN came from. I haven't > seen anyone suggesting ignoring RST, either: DM just imagined that, > AFAICS. > > The one point I would like to make, though, is that firewalls are NOT > "brain-damaged" for blocking ECN:

Re: Oops accessing file on 2048 bytes/sector vfat MO in 2.4.0

In article you wrote: > ... and on a fair number < 2.4.0. The patch below will give you (dog slow) > read access to your FAT MOs. Apply in fs/fat/. And don't even think about > write() and mmap(). Thanks for the patch! The oops is gone, but now

Re: sendfile+zerocopy: fairly sexy (nothing to do with ECN)

Thus spake Andrew Morton ([EMAIL PROTECTED]): > Conclusions: > For a NIC which cannot do scatter/gather/checksums, the zerocopy > patch makes no change in throughput in all case. > For a NIC which can do scatter/gather/checksums, sendfile() > efficiency is improved by 40% and send()

Re: ECN: Clearing the air (fwd)

On Sun, 28 Jan 2001, jamal wrote: > On Sun, 28 Jan 2001, James Sutherland wrote: > > > I'm sure we all know what the IETF is, and where ECN came from. I haven't > > seen anyone suggesting ignoring RST, either: DM just imagined that, > > AFAICS. > > The email was not necessarily intended for

Re: [linux-audio-dev] low-latency scheduling patch for 2.4.0

On Sun, Jan 21, 2001 at 06:21:05PM -0800, Nigel Gamble wrote: > Yes, I most emphatically do disagree with Victor! IRIX is used for > mission-critical audio applications - recording as well playback - and > other low-latency applications. The same OS scales to large numbers of > CPUs. And it

Re: Kernel 2.4.0 loop device still hangs

Hi Jens, I've tested your patch quite as heavy as it gets: I created 5 files of each 100 MB, set up 5 loop devices and made a RAID5 array out of them, putting ext2 on it and running a bonnie loop with 350 MB test size over it for the night. Everything survived, worked flawlessly and I'm

Re: [PATCH] make drivers/scsi/sym53c8xx.c check request_region'sreturn code (241p9)]

On Thu, 25 Jan 2001, Rasmus Andersen wrote: > Hi. > > I apparently forgot to cc the lists on this one. Replies should be cc'ed > to [EMAIL PROTECTED] also. > > Thanks. The change should not harm, but request_region() is very unlikely to fail here. Reason is that the drivers previously

Re: ECN: Clearing the air (fwd)

On Sun, 28 Jan 2001, James Sutherland wrote: > I'm sure we all know what the IETF is, and where ECN came from. I haven't > seen anyone suggesting ignoring RST, either: DM just imagined that, > AFAICS. The email was not necessarily intended for you. You just pulled the pin. There were people

Re: Knowing what options a kernel was compiled with

On Sun, Jan 28, 2001 at 04:29:06PM +1100, Keith Owens wrote: > On Sun, 28 Jan 2001 00:13:48 -0500, > "Matthew Pitts" <[EMAIL PROTECTED]> wrote: > >Some distributions DO include the config. It may be located > >in the /boot dir with a name CONFIG-2.2.10 or similar. I > >know that Caldera 2.3

Re: 2.4.1-pre8 losing pages

On Fri, Jan 26, 2001 at 07:48:05PM +, Russell King wrote: > Peter Horton writes: > > The corruption is dependent on having a swapped on swap partition. If I > > "swapoff" the corruption goes away, but it comes back when I "swapon" > > again. I feel this a kernel bug, but as I'm the only

Re: Poor SCSI drive performance on SMP machine, 2.2.16

On Sun, 28 Jan 2001, paradox3 wrote: > I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM IBM > 10 GB SCSI drive > (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. The > SCSI drive > performs the worst. In tests of writing 100 MB and sync'ing, one

Re: Kernel 2.4.0 loop device still hangs

On Sun, Jan 28, 2001 at 03:43:00AM +0100, Jens Axboe wrote: > > It should be safe. Thanks for the feedback. The patch works fine here too, but I have not tested it very hard ... just normal read/write small/big files into it. It looks fine here. Any thoughts to integrate it into 2.4.1?

Re: Kernel 2.4.x and 2.4.1-preX - Higher latency then 2.2.xkernels?

Shawn Starr wrote: > > Andrew, the patch HAS made a difference. For example, while untaring >glibc-2.2.1.tar.gz the > system was not sluggish (mouse movements in X) etc. > > Seems to be a go for latency improvements on this system. Shawn, could you please try this patch in a pristine

<    1   2   3   4   5   >