* Re: Compile Filure on 2.4.10-ac10+preempt+smp
From: Mike Fedyk @ 2001-10-10 5:24 UTC (permalink / raw)
To: Robert Love; +Cc: linux-kernel
In-Reply-To: <1002690949.862.233.camel@phantasy>
On Wed, Oct 10, 2001 at 01:15:25AM -0400, Robert Love wrote:
> On Wed, 2001-10-10 at 00:46, Mike Fedyk wrote:
> > Fail 2.4.10-ac10+preempt+smp
> > Success 2.4.10-ac10+preempt+up-apic+up-ipapic
> > Success 2.4.10-ac10+preempt
> > Success 2.4.10-ac10
> >
> > Robert, can you do a test compile for smp just in case?
>
> Ahh, yes. Thank you for spotting this. include/asm-i386/spinlock.h has
> two separate defines for spin_unlock and we only renamed one of them. I
> guess you hit the conditional that used the other define...
>
> The attached patch fixes it.
>
Thank you. Will compile now...
> > Also, I couldn't find any links to old patches on your web site...
> > [...]
>
> I only keep around patches to the last official kernel, plus the latest
> -pre and -ac I patched. Since the patch itself is being updated, its a
> pain to backport to older kernels.
>
No, I'm not asking for backport, just links to one version back just in case
the latest patch has a bug much like this...
I'd rather run one (working) version back than have to go to UP just to get
preempt... Needless to say, I chose to keep smp.
Mike
^ permalink raw reply
* RE: [PATCH] EFI GUID Partition Tables
From: Richard Gooch @ 2001-10-10 5:18 UTC (permalink / raw)
To: Matt_Domsch; +Cc: adilger, torvalds, alan, Martin.Wilck, viro, linux-kernel
In-Reply-To: <71714C04806CD51193520090272892178BD6DB@ausxmrr502.us.dell.com>
Matt Domsch writes:
> Richard and Andreas, thanks for your feedback.
> > Would it be possible to put this somewhere else and/or rename it? It
> > appears that GUIDs are really DCE UUIDs (which are used by
> > other things
> > like ext2, XFS, MD RAID, etc) so if we are "advertising"
> > UUIDs from the
> > kernel, we may as well make it "sensible" for other users. How about
> > "/dev/dis[ck]s/uuid", unless there are other users of UUID
> > identifiers?
>
> Yes, UUIDs and GUIDs are the same thing, fortunately.
> I'll have to defer this to the author of this piece of code. Martin, any
> reason why it shouldn't be renamed? Richard, any preferred name?
I'd prefer /dev/volumes/uuids/
Similarly, if label reading code is added, I'd like to see that put in
/dev/volumes/labels/
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
^ permalink raw reply
* Idle bug net yet solved in 2.4.11-pre6(aa1)
From: G. Hugh Song @ 2001-10-10 5:18 UTC (permalink / raw)
To: linux-kernel
I just realized that
since around 2.4.10-pre8aa1, I have been having the idle-bug trouble which
have been actively addressed at the moment.
In patch-2.4.11.log file, I was able to find:
Under pre6
- Peter Rival: update alpha SMP bootup to match wait_init_idle fixes
Apparently, it has not been fixed even in 2.4.11-pre6(aa1).
"top" showed the idle percentage upsurdly high around 10^8 %.
Then the machine freezed completely.
Configuration:
SuSE-7.1 (for alpha) running on UP2000 SMP with 2GB main memory.
5GB swap space all together in three hard disks.
Reasonably high mem usage which does not actually need any
swap space.
I am now using 2.2.20pre9aa2. I have not had much luck with
2.4 kernels yet. Every time I tried 2.4 kernels, I have had all
those vm-related troubles. I sincerely hope that the situation will soon
be corrected all together. Then, we can say linux-2.4 is truly 2.4 (even
numbered version).
Best regards,
G. Hugh Song
^ permalink raw reply
* Re: [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion
From: Paul McKenney @ 2001-10-10 4:43 UTC (permalink / raw)
To: Andrea Arcangeli
Cc: Peter Rival, Jay.Estabrook, linux-kernel, lse-tech,
Richard Henderson
> The point here is that it is suprisingly that alpha needs this IPI
> unlike all other architectures. So while the IPI is certainly safe we
> wouldn't expect it to be necessary on alpha either.
>
> Now my only worry is that when you worked on this years ago with the
> alpha architects there were old chips, old caches and old machines (ev5
> maybe?).
>
> So before changing any code, I would prefer to double check with the
> current alpha architects that the read dependency really isn't enough to
> enforce read ordering without the need of rmb also on the beleeding edge
> ev6/ev67/etc.. cores. So potentially as worse we'd need to redefine
> wmb() as wmbdd() (and friends) only for EV5+SMP compiles of the kernel,
> but we wouldn't be affected with any recent hardware compiling for
> EV6/EV67. Jay, Peter, comments?
Hello, Andrea!
This is a very good point. I will double-check with the people I know.
I agree that it would also be very good to get an independent check.
There is clearly no use in adding expensive IPIs to the kernel except
where they are absolutely necessary!
Thanx, Paul
^ permalink raw reply
* Re: [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion
From: BALBIR SINGH @ 2001-10-10 5:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
In-Reply-To: <9q0ku6$175$1@penguin.transmeta.com>
[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]
Linus Torvalds wrote:
>In article <20011010040502.A726@athlon.random>,
>Andrea Arcangeli <andrea@suse.de> wrote:
>
>>On Tue, Oct 09, 2001 at 08:45:15AM -0700, Paul McKenney wrote:
>>
>>>Please see the example above. I do believe that my algorithms are
>>>reliably forcing proper read ordering using IPIs, just in an different
>>>way. Please note that I have discussed this algorithm with Alpha
>>>architects, who believe that it is sound.
>>>
>>The IPI way is certainly safe.
>>
>
>Now, before people get all excited, what is this particular code
>actually _good_ for?
>
>Creating a lock-free list that allows insertion concurrently with lookup
>is _easy_.
>
>But what's the point? If you insert stuff, you eventually have to remove
>it. What goes up must come down. Insert-inane-quote-here.
>
>And THAT is the hard part. Doing lookup without locks ends up being
>pretty much worthless, because you need the locks for the removal
>anyway, at which point the whole thing looks pretty moot.
>
>Did I miss something?
>
> Linus
>
What about cases like the pci device list or any other such list. Sometimes
you do not care if somebody added something, while you were looking through
the list as long as you do not get illegal addresses or data.
Wouldn't this be very useful there? Most of these lists come up
at system startup and change rearly, but we look through them often.
Me too, Did I miss something?
Balbir
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 853 bytes --]
----------------------------------------------------------------------------------------------------------------------
Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
is intended for use only by the individual or entity to which it is
addressed, and may contain information that is privileged, confidential or
exempt from disclosure under applicable law. If you are not the intended
recipient or it appears that this mail has been forwarded to you without
proper authority, you are notified that any use or dissemination of this
information in any manner is strictly prohibited. In such cases, please
notify us immediately at mailto:mailadmin@wipro.com and delete this mail
from your records.
----------------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: Compile Filure on 2.4.10-ac10+preempt+smp
From: Robert Love @ 2001-10-10 5:15 UTC (permalink / raw)
To: Mike Fedyk; +Cc: linux-kernel
In-Reply-To: <20011009214655.A26663@mikef-linux.matchmail.com>
On Wed, 2001-10-10 at 00:46, Mike Fedyk wrote:
> Fail 2.4.10-ac10+preempt+smp
> Success 2.4.10-ac10+preempt+up-apic+up-ipapic
> Success 2.4.10-ac10+preempt
> Success 2.4.10-ac10
>
> Robert, can you do a test compile for smp just in case?
Ahh, yes. Thank you for spotting this. include/asm-i386/spinlock.h has
two separate defines for spin_unlock and we only renamed one of them. I
guess you hit the conditional that used the other define...
The attached patch fixes it.
> Also, I couldn't find any links to old patches on your web site...
> [...]
I only keep around patches to the last official kernel, plus the latest
-pre and -ac I patched. Since the patch itself is being updated, its a
pain to backport to older kernels.
--- linux-2.4.10-ac10/include/asm-i386/spinlock.h.orig Mon Oct 8 18:33:10 2001
+++ linux-2.4.10-ac10/include/asm-i386/spinlock.h Wed Oct 10 01:08:47 2001
@@ -97,7 +97,7 @@
:"=q" (oldval), "=m" (lock->lock) \
:"0" (1) : "memory"
-static inline void spin_unlock(spinlock_t *lock)
+static inline void _raw_spin_unlock(spinlock_t *lock)
{
char oldval;
#if SPINLOCK_DEBUG
Robert Love
^ permalink raw reply
* Re: 2.4.10-ac10-preempt lmbench output.
From: Andrew Morton @ 2001-10-10 5:13 UTC (permalink / raw)
To: Dieter Nützel; +Cc: Andrea Arcangeli, Robert Love, Linux Kernel List
In-Reply-To: <200110100358.NAA17519@isis.its.uow.edu.au>
Dieter Nützel wrote:
>
> Andrew have you a current version of your lowlatency patches handy?
>
mm.. Nice people keep sending me updates. It's at
http://www.uow.edu.au/~andrewm/linux/schedlat.html and applies
to 2.4.11 with one little reject. I don't know how it's
performing at present - it's time for another round of tuning
and testing.
wrt this discussion: I would assume that xmms is simply stalling
on disk access. All it takes is for one of its text pages to be
dropped and it could have to wait a very long time indeed to
come back to life. The disk read latency could easily exceed
any sane buffering in the sound card or its driver.
The application should be using mlockall(MCL_FUTURE) and it should
run `nice -19' (SCHED_FIFO and SCHED_RR are rather risky - if the
app gets stuck in a loop, it's time to hit the big button). If the
app isn't doing both these things then it just doesn't have a chance.
I don't understand why Andrea is pointing at write throttling? xmms
doesn't do any disk writes, does it??
Andrea's VM has a rescheduling point in shrink_cache(), which is the
analogue of the other VM's page_launder(). This rescheduling point
is *absolutely critial*, because it opens up what is probably the
longest-held spinlock in the kernel (under common use). If there
were a similar reschedulig point in page_launder(), comparisons
would be more valid...
I would imagine that for a (very) soft requirement such as audio
playback, the below patch, combined with mlockall and renicing
should fix the problems. I would expect that this patch will
give effects which are similar to the preempt patch. This is because
most of the other latency problems are under locks - icache/dcache
shrinking and zap_page_range(), etc.
This patch should go into the stock 2.4 kernel.
Oh. And always remember to `renice -19' your X server.
--- linux-2.4.11/mm/filemap.c Tue Oct 9 21:31:40 2001
+++ linux-akpm/mm/filemap.c Tue Oct 9 21:47:51 2001
@@ -1230,6 +1230,9 @@ found_page:
page_cache_get(page);
spin_unlock(&pagecache_lock);
+ if (current->need_resched)
+ schedule();
+
if (!Page_Uptodate(page))
goto page_not_up_to_date;
generic_file_readahead(reada_ok, filp, inode, page);
@@ -2725,6 +2728,9 @@ generic_file_write(struct file *file,con
if (!PageLocked(page)) {
PAGE_BUG(page);
}
+
+ if (current->need_resched)
+ schedule();
kaddr = kmap(page);
status = mapping->a_ops->prepare_write(file, page, offset, offset+bytes);
--- linux-2.4.11/fs/buffer.c Tue Oct 9 21:31:40 2001
+++ linux-akpm/fs/buffer.c Tue Oct 9 22:08:51 2001
@@ -29,6 +29,7 @@
/* async buffer flushing, 1999 Andrea Arcangeli <andrea@suse.de> */
#include <linux/config.h>
+#include <linux/compiler.h>
#include <linux/sched.h>
#include <linux/fs.h>
#include <linux/slab.h>
@@ -231,6 +232,10 @@ static int write_some_buffers(kdev_t dev
static void write_unlocked_buffers(kdev_t dev)
{
do {
+ if (unlikely(current->need_resched)) {
+ __set_current_state(TASK_RUNNING);
+ schedule();
+ }
spin_lock(&lru_list_lock);
} while (write_some_buffers(dev));
run_task_queue(&tq_disk);
--- linux-2.4.11/fs/proc/array.c Sun Sep 23 12:48:44 2001
+++ linux-akpm/fs/proc/array.c Tue Oct 9 21:47:51 2001
@@ -414,6 +414,9 @@ static inline void statm_pte_range(pmd_t
pte_t page = *pte;
struct page *ptpage;
+ if (current->need_resched)
+ schedule(); /* For `top' and `ps' */
+
address += PAGE_SIZE;
pte++;
if (pte_none(page))
--- linux-2.4.11/fs/proc/generic.c Sun Sep 23 12:48:44 2001
+++ linux-akpm/fs/proc/generic.c Tue Oct 9 21:47:51 2001
@@ -98,6 +98,9 @@ proc_file_read(struct file * file, char
retval = n;
break;
}
+
+ if (current->need_resched)
+ schedule(); /* Some proc files are large */
/* This is a hack to allow mangling of file pos independent
* of actual bytes read. Simply place the data at page,
^ permalink raw reply
* Reg-xpbsmon
From: SATHISH.J @ 2001-10-10 5:29 UTC (permalink / raw)
To: kernelnewbies, linux-kernel
Hi all,
I am very sorry as this is not a right question to this list.
There is an open source package 'xpbsmon' which is cluster manager for
the
High Performance Computing and it is a part of the PBS ( Portable Batch
Systems ) package. Currently here, we are porting this package to run
on
64-bit linux on an IA-64 architecture. We were told that the 32-bit
version
of this package is available on the internet and the 64-bit may also be
available as this is an open source package. We are required to find out
if
the 64-bit version of the 'xpbsmon' package is already available on the
Internet.
I could not get the xpbsmon package download from the net. Please help me
out.
Thanks in advance,
Warm regards,
sathish.j
^ permalink raw reply
* Re: [Lse-tech] Re: RFC: patch to allow lock-free traversal of lists with insertion
From: Linus Torvalds @ 2001-10-10 5:05 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20011010040502.A726@athlon.random>
In article <20011010040502.A726@athlon.random>,
Andrea Arcangeli <andrea@suse.de> wrote:
>On Tue, Oct 09, 2001 at 08:45:15AM -0700, Paul McKenney wrote:
>> Please see the example above. I do believe that my algorithms are
>> reliably forcing proper read ordering using IPIs, just in an different
>> way. Please note that I have discussed this algorithm with Alpha
>> architects, who believe that it is sound.
>
>The IPI way is certainly safe.
Now, before people get all excited, what is this particular code
actually _good_ for?
Creating a lock-free list that allows insertion concurrently with lookup
is _easy_.
But what's the point? If you insert stuff, you eventually have to remove
it. What goes up must come down. Insert-inane-quote-here.
And THAT is the hard part. Doing lookup without locks ends up being
pretty much worthless, because you need the locks for the removal
anyway, at which point the whole thing looks pretty moot.
Did I miss something?
Linus
^ permalink raw reply
* Re: usb_bulk_msg timeout w/ rvmalloc
From: Pete Zaitcev @ 2001-10-10 4:51 UTC (permalink / raw)
To: paul.thacker, linux-kernel
In-Reply-To: <mailman.1002674521.5223.linux-kernel2news@redhat.com>
> I have written a driver which, in part, facilitates the usb bulk
> transfer of raw image data. It works fine for small (CIF, QCIF)
> images, but for larger images, kmalloc will not allocate enough
> memory.
How much do you need?
> I copied the rvmalloc code from the cpia2 driver and used it in place
> of kmalloc. The memory allocates fine, but usb_bulk_msg now times out
> when using the pointer to the rvmalloc'd memory. I have been unable to
> find an instance of an existing driver using rvmalloc in conjunction
> with usb_bulk_msg.
The best thing would be to use pipelined transfer with
several URBs, I think. If that is too difficult for you,
try to use __get_free_pages(), but mind that even if free
RAM is available, kernel may not be able to fulfill your
request. Check response codes carefuly.
-- Pete
^ permalink raw reply
* Re: 2.4.10-ac10-preempt lmbench output.
From: Andrea Arcangeli @ 2001-10-10 4:48 UTC (permalink / raw)
To: Dieter Nützel; +Cc: Robert Love, Andrew Morton, Linux Kernel List
In-Reply-To: <20011010044242.82D131E768@Cantor.suse.de>
On Wed, Oct 10, 2001 at 06:42:37AM +0200, Dieter Nützel wrote:
> Am Mittwoch, 10. Oktober 2001 06:23 schrieb Andrea Arcangeli:
> > On Wed, Oct 10, 2001 at 05:57:46AM +0200, Dieter Nützel wrote:
>
> [...]
> > > I get the dropouts (2~3 sec) after dbench 32 is running for 9~10 seconds.
>
> It is mostly only _ONE_ dropout like above.
One isn't really too bad actually, if there's an huge I/O going on at
least.
> The above plus nice -20 mpg123 *.mp3
> I've forgotten to clearify this, sorry.
>
> Should I try 2.4.11 + 00_vm-1 or 2.4.11aa1, again?
2.4.11aa1 with also read/write reschedule points would be more
interesting I think.
> > You're probably more interested in the possible heuristic that I've in
> > mind to avoid xmms to wait I/O completion for the work submitted by
> > dbench. Of course assuming the vm write throttling was a relevant cause
> > of the dropouts, and that the dropouts weren't just due an I/O
> > congestion (too low disk bendwith).
>
> > BTW, to find out if the reason of the dropouts where the vm write
> > throttling or the too low disk bandwith you can run ps l <pid_of_xmms>,
>
> What do you mean here? I can't find a meaningfully ps option.
I meant the output of `ps l` (WCHAN column xmms row).
Andrea
^ permalink raw reply
* Compile Filure on 2.4.10-ac10+preempt+smp
From: Mike Fedyk @ 2001-10-10 4:46 UTC (permalink / raw)
To: Robert Love; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 23279 bytes --]
Fail 2.4.10-ac10+preempt+smp
Success 2.4.10-ac10+preempt+up-apic+up-ipapic
Success 2.4.10-ac10+preempt
Success 2.4.10-ac10
Robert, can you do a test compile for smp just in case?
Also, I couldn't find any links to old patches on your web site...
Mike
End of attached compile.log.bz2:
/home/src/lk2.4/2.4.10ac-preempt/include/linux/sched.h: In function `task_unlock':
/home/src/lk2.4/2.4.10ac-preempt/include/linux/sched.h:913: warning: implicit declaration of function `_raw_spin_unlock'
In file included from /home/src/lk2.4/2.4.10ac-preempt/include/linux/blkdev.h:5,
from /home/src/lk2.4/2.4.10ac-preempt/include/linux/blk.h:4,
from constants.c:12:
/home/src/lk2.4/2.4.10ac-preempt/include/linux/sched.h: In function `task_unlock':
/home/src/lk2.4/2.4.10ac-preempt/include/linux/sched.h:913: warning: implicit declaration of function `_raw_spin_unlock'
In file included from /home/src/lk2.4/2.4.10ac-preempt/include/linux/mm.h:4,
from /home/src/lk2.4/2.4.10ac-preempt/include/linux/locks.h:5,
from /home/src/lk2.4/2.4.10ac-preempt/include/linux/devfs_fs_kernel.h:6,
from /home/src/lk2.4/2.4.10ac-preempt/include/linux/genhd.h:58,
from scsicam.c:17:
/home/src/lk2.4/2.4.10ac-preempt/include/linux/sched.h: In function `task_unlock':
/home/src/lk2.4/2.4.10ac-preempt/include/linux/sched.h:913: warning: implicit declaration of function `_raw_spin_unlock'
init/main.o: In function `rest_init':
init/main.o(.text+0x48): undefined reference to `_raw_spin_unlock'
init/main.o: In function `init':
init/main.o(.text+0xe5): undefined reference to `_raw_spin_unlock'
arch/i386/kernel/kernel.o: In function `machine_real_restart':
arch/i386/kernel/kernel.o(.text+0xf1): undefined reference to `_raw_spin_unlock'
arch/i386/kernel/kernel.o: In function `__down':
arch/i386/kernel/kernel.o(.text+0x960): undefined reference to `_raw_spin_unlock'
arch/i386/kernel/kernel.o(.text+0x9cb): undefined reference to `_raw_spin_unlock'
arch/i386/kernel/kernel.o(.text+0xa8d): more undefined references to `_raw_spin_unlock' follow
make: *** [vmlinux] Error 1
.config:
#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
# CONFIG_GENERIC_BUST_SPINLOCK is not set
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_PPRO_FENCE=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_SMP=y
CONFIG_PREEMPT=y
CONFIG_HAVE_DEC_LOCK=y
#
# General setup
#
CONFIG_NET=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
# CONFIG_APM_CPU_IDLE is not set
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y
#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
CONFIG_MD_RAID0=y
CONFIG_MD_RAID1=y
CONFIG_MD_RAID5=y
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
# CONFIG_NETFILTER is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
# CONFIG_PHONE_IXJ_PCMCIA is not set
#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y
#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDETAPE=y
CONFIG_BLK_DEV_IDEFLOPPY=y
# CONFIG_BLK_DEV_IDESCSI is not set
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_AEC62XX_TUNING is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_PDC202XX=y
CONFIG_PDC202XX_BURST=y
CONFIG_PDC202XX_FORCE=y
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set
#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
CONFIG_SCSI_DEBUG_QUEUES=y
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=253
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# CONFIG_AIC7XXX_BUILD_FIRMWARE is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_NCR53C8XX is not set
CONFIG_SCSI_SYM53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
# CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_DEBUG is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_LAN is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
CONFIG_ETHERTAP=m
# CONFIG_NET_SB1000 is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_SUNLANCE is not set
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNLANCE is not set
# CONFIG_SUNGEM is not set
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
# CONFIG_EL3 is not set
# CONFIG_3C515 is not set
# CONFIG_ELMC is not set
# CONFIG_ELMC_II is not set
CONFIG_VORTEX=m
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_CS89x0 is not set
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
# CONFIG_DE4X5 is not set
# CONFIG_DGRS is not set
# CONFIG_DM9102 is not set
CONFIG_EEPRO100=m
# CONFIG_LNE390 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_NE3210 is not set
# CONFIG_ES3210 is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Input core support
#
# CONFIG_INPUT is not set
# CONFIG_INPUT_KEYBDEV is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SERIAL_EXTENDED=y
# CONFIG_SERIAL_MANY_PORTS is not set
CONFIG_SERIAL_SHARE_IRQ=y
CONFIG_SERIAL_DETECT_IRQ=y
# CONFIG_SERIAL_MULTIPORT is not set
# CONFIG_HUB6 is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
#
# I2C support
#
# CONFIG_I2C is not set
#
# Mice
#
# CONFIG_BUSMOUSE is not set
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set
#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_QIC02_TAPE is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_INTEL_RNG=y
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_SIS is not set
CONFIG_AGP_INTEL=y
CONFIG_AGP_I810=y
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
CONFIG_DRM=y
# CONFIG_DRM_NEW is not set
CONFIG_DRM_OLD=y
# CONFIG_DRM40_TDFX is not set
# CONFIG_DRM40_GAMMA is not set
# CONFIG_DRM40_R128 is not set
# CONFIG_DRM40_RADEON is not set
# CONFIG_DRM40_I810 is not set
# CONFIG_DRM40_MGA is not set
# CONFIG_MWAVE is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# File systems
#
# CONFIG_QUOTA is not set
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
# CONFIG_REISERFS_FS is not set
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
CONFIG_HFS_FS=m
# CONFIG_BFS_FS is not set
# CONFIG_CMS_FS is not set
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FAT_FS=m
# CONFIG_MSDOS_FS is not set
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=m
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
CONFIG_TMPFS=y
# CONFIG_RAMFS is not set
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_FREEVXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=m
# CONFIG_NFS_V3 is not set
# CONFIG_ROOT_NFS is not set
# CONFIG_NFSD is not set
# CONFIG_NFSD_V3 is not set
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
# CONFIG_ZISOFS_FS is not set
# CONFIG_ZLIB_FS_INFLATE is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
#
# Frame-buffer support
#
# CONFIG_FB is not set
#
# Sound
#
CONFIG_SOUND=y
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_CMPCI is not set
# CONFIG_SOUND_EMU10K1 is not set
# CONFIG_MIDI_EMU10K1 is not set
# CONFIG_SOUND_FUSION is not set
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
# CONFIG_SOUND_ICH is not set
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
# CONFIG_SOUND_VIA82CXXX is not set
# CONFIG_MIDI_VIA82CXXX is not set
CONFIG_SOUND_OSS=y
# CONFIG_SOUND_TRACEINIT is not set
CONFIG_SOUND_DMAP=y
# CONFIG_SOUND_AD1816 is not set
# CONFIG_SOUND_SGALAXY is not set
# CONFIG_SOUND_ADLIB is not set
# CONFIG_SOUND_ACI_MIXER is not set
# CONFIG_SOUND_CS4232 is not set
# CONFIG_SOUND_SSCAPE is not set
# CONFIG_SOUND_GUS is not set
# CONFIG_SOUND_VMIDI is not set
# CONFIG_SOUND_TRIX is not set
# CONFIG_SOUND_MSS is not set
# CONFIG_SOUND_MPU401 is not set
# CONFIG_SOUND_NM256 is not set
# CONFIG_SOUND_MAD16 is not set
# CONFIG_SOUND_PAS is not set
# CONFIG_PAS_JOYSTICK is not set
# CONFIG_SOUND_PSS is not set
CONFIG_SOUND_SB=m
CONFIG_SOUND_AWE32_SYNTH=m
# CONFIG_SOUND_WAVEFRONT is not set
# CONFIG_SOUND_MAUI is not set
# CONFIG_SOUND_YM3812 is not set
# CONFIG_SOUND_OPL3SA1 is not set
# CONFIG_SOUND_OPL3SA2 is not set
# CONFIG_SOUND_YMFPCI is not set
# CONFIG_SOUND_YMFPCI_LEGACY is not set
# CONFIG_SOUND_UART6850 is not set
# CONFIG_SOUND_AEDSP16 is not set
# CONFIG_SOUND_TVMIXER is not set
#
# USB support
#
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_LONG_TIMEOUT is not set
# CONFIG_USB_LARGE_CONFIG is not set
CONFIG_USB_UHCI=y
# CONFIG_USB_UHCI_ALT is not set
# CONFIG_USB_OHCI is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH is not set
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_PLUSB is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_CATC is not set
# CONFIG_USB_CDCETHER is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_ID75 is not set
#
# Bluetooth support
#
# CONFIG_BLUEZ is not set
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_IOVIRT=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
CONFIG_DEBUG_BUGVERBOSE=y
[-- Attachment #2: compile.log.bz2 --]
[-- Type: application/octet-stream, Size: 4674 bytes --]
^ permalink raw reply
* Re: Bad memory ... reservation !
From: Andres Salomon @ 2001-10-10 4:42 UTC (permalink / raw)
To: Martin Josefsson; +Cc: Patrick Allaire, linux-kernel
In-Reply-To: <Pine.LNX.4.21.0110062251290.14152-100000@tux.rsn.bth.se>
FYI, the badram stuff seems to have moved to http://badmem.sourceforge.net/.
The latest kernel patch there is against 2.4.10.
On Sat, Oct 06, 2001 at 10:52:05PM +0200, Martin Josefsson wrote:
[...]
>
> You might be able to use the BadRAM patches from
> http://rick.vanrein.org/linux/badram/
>
> /Martin
>
> Never argue with an idiot. They drag you down to their level, then beat you with experience.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
"Any OS is only as good as its admin, and you obviously suck."
-- Ian Gulliver, http://orbz.org/mail/mansunix.txt
^ permalink raw reply
* Re: 2.4.10-ac10-preempt lmbench output.
From: Dieter Nützel @ 2001-10-10 4:42 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Robert Love, Andrew Morton, Linux Kernel List
In-Reply-To: <20011010062300.H726@athlon.random>
Am Mittwoch, 10. Oktober 2001 06:23 schrieb Andrea Arcangeli:
> On Wed, Oct 10, 2001 at 05:57:46AM +0200, Dieter Nützel wrote:
[...]
> > I get the dropouts (2~3 sec) after dbench 32 is running for 9~10 seconds.
It is mostly only _ONE_ dropout like above.
> > I've tried with RT artds and nice -20 mpg123.
> >
> > Kernel: 2.4.11-pre6 + 00_vm-1 + preempt
> >
> > Only solution:
> > I have to copy the test MPG3 file into /dev/shm.
>
> If copying the mp3 data into /dev/shm fixes the problem it could be also
> an I/O overload.
The above plus nice -20 mpg123 *.mp3
I've forgotten to clearify this, sorry.
Should I try 2.4.11 + 00_vm-1 or 2.4.11aa1, again?
> So if this is just an I/O overload (possible too) some possible fixes
> could be:
>
> 1) buy faster disk
:-)
But I've checked it with two SCSI disks.
IBM DDYS U160 10k for dbench 32 and
IBM DDRS UW 7.2k for the mp3s
=> the hiccup
> 2) try with elvtune -r 1 -w 2 /dev/hd[abcd] /dev/sd[abcd] that will try
> to decrease the global I/O disk bandwith of the system, but it will
> increase fairness
OK, after I had some sleep...
> > CPU (1 GHz Athlon II) is ~75% idle during the hiccup.
>
> Of course I can imagine. This is totally unrelated to scheduler
> latencies, it's either vm write throttling or I/O congestion so you
> don't have enough bandwith to read the file or both.
It is only _ONE_ time during the whole dbench 32 run.
> > The dbench processes are mostly in wait_page/wait_cache if I remember
> > right. So I think that you are right it is a file IO wait (latency)
> > problem.
>
> Yes.
>
> > Please hurry up with your read/write copy-user paths lowlatency patches
> > ;-)
>
> In the meantime you can use the preemption points in the copy-user, they
> can add a bit more of overhead but nothing interesting, I believe it's
> more a cleanup than an improvement to move the reschedule points in
> read/write as suggested by Andrew.
>
> BTW, this is the relevant patch:
>
> ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.11
>aa1/00_copy-user-lat-5
GREAT.
> You're probably more interested in the possible heuristic that I've in
> mind to avoid xmms to wait I/O completion for the work submitted by
> dbench. Of course assuming the vm write throttling was a relevant cause
> of the dropouts, and that the dropouts weren't just due an I/O
> congestion (too low disk bendwith).
> BTW, to find out if the reason of the dropouts where the vm write
> throttling or the too low disk bandwith you can run ps l <pid_of_xmms>,
What do you mean here? I can't find a meaningfully ps option.
> if it says wait_on_buffer all the time it's the vm write throttling, if
> it says always something else it's the too low disk bandwith, I suspect
> as said above that you'll see both things because it is probably a mixed
> effect. If it's not vm write throttling only a faster disk or elvtune
> tweaking can help you, there's no renice-IO -n -20 that allows to
> prioritize the I/O bandwith to a certain application.
Thanks,
Dieter
^ permalink raw reply
* Re: 2.4.10-ac10-preempt lmbench output.
From: Andrea Arcangeli @ 2001-10-10 4:27 UTC (permalink / raw)
To: Robert Love; +Cc: Dieter Nützel, Andrew Morton, Linux Kernel List
In-Reply-To: <1002686542.866.164.camel@phantasy>
On Wed, Oct 10, 2001 at 12:02:13AM -0400, Robert Love wrote:
> On Tue, 2001-10-09 at 23:57, Dieter Nützel wrote:
> > Robert you are running a dual PIII system, right?
> > Could that be the ground why you aren't see the hiccup with your nice preempt
> > patch? Are you running ReiserFS or EXT2/3?
>
> No, I am on a single P3-733. I am using ext3.
>
> I have had reports from users on both UP and SMP systems that say audio
> playback is undisturbed during heavy I/O with preempt-kernel patch. Of
> course, I don't know their definition of undisturbed...but I would wager
> it doesn't include 2-3s skips.
If it's purerly I/O even mainline that is missing the reschedule points
shouldn't matter.
Infact the only thing that hurts during pure I/O (I mean not I/O from
cache, I mean real I/O to disk) is the browse of the lru dirty lists in
buffer.c and the vm lists (the latter are covered in latest 2.4). And
just the preemptive patch cannot help there since they're both covered
by locks and the explicit checks in the preemptive patch will get a
result equal to the lowlatency approch.
If it's mixed I/O half from cache and half from disk, then the lack of
reschedule points could be the culprit of course.
Andrea
^ permalink raw reply
* Re: [PATCH] EFI GUID Partition Tables
From: Andreas Dilger @ 2001-10-10 4:23 UTC (permalink / raw)
To: Matt_Domsch; +Cc: rgooch, torvalds, alan, Martin.Wilck, viro, linux-kernel
In-Reply-To: <71714C04806CD51193520090272892178BD6DB@ausxmrr502.us.dell.com>
On Oct 09, 2001 22:01 -0500, Matt_Domsch@Dell.com wrote:
> > Would it be possible to put this somewhere else and/or rename it? It
> > appears that GUIDs are really DCE UUIDs (which are used by
> > other things
> > like ext2, XFS, MD RAID, etc) so if we are "advertising"
> > UUIDs from the
> > kernel, we may as well make it "sensible" for other users. How about
> > "/dev/dis[ck]s/uuid", unless there are other users of UUID
> > identifiers?
>
> Yes, UUIDs and GUIDs are the same thing, fortunately.
> I'll have to defer this to the author of this piece of code. Martin, any
> reason why it shouldn't be renamed? Richard, any preferred name?
Well, the "common" usage is in /etc/fstab, where we allow "UUID=" and
"LABEL=", so it would be nice to stick with "uuid" or "UUID".
> > On a side note, I have a user-space library which locates/identifies
> > devices by UUID/LABELs as well. It is likely to become part
> > of e2fsprogs
> > and mount as a way to consolidate all of the fs identification code,
> > but it could easily to partition identification also (hasn't
> > been possible until now).
>
> This would be great! How can I help?
Hmm. I was originally thinking it would be a no-brainer to add in GPT
support for libblkid (add a "magic" field, and then extract the UUID/LABEL
from each partition). Some questions pop up:
1) Currently libblkid is only doing identification of "content" (e.g.
filesystems, RAID, swap, LVM, etc) and not actual "partition tables".
Is it possible to get the GPT data when reading the actual partitioned
device (e.g. /dev/hda1) or do you need to read the whole-disk device
(e.g. /dev/hda)?
2) What to do with multiple identifiers for a single partition? Current
partitioning schemes don't have any identifiers, so I've assumed that
there will only be one "correct" identifier for each block device.
With GPT, you could have a GPT GUID+LABEL and a filesystem UUID+LABEL.
It would be nice NOT to introduce new "types" for each possible ID
(i.e. I have been calling all "serial number" type things "UUID" and
all "name" type things "LABEL" to match current usage).
> > Another question, does GPT support user-defined names/LABELs
> > for partitions?
>
> Yes. 36 efi_char_t (Unicode, really UCS-2, 72 bytes) per partition name
> field. :-) No relying on the file system (e.g. swap doesn't support names).
Hmm, how easy to handle these as regular strings (i.e. just pretend they
are unsigned chars and never interpret)? I was actually in the process of
adding LABEL support to swap and reiserfs, because we will still be stuck
with DOS partitions a long time.
> Happy to. I haven't done an extensive grep for other uuid uses in the
> kernel (besides knowing they're used for ext2). If lib/ is a better place
> to combine them, I'll do that.
Well, I've played with uuid_unparse() in the kernel a couple of times for
other reasons (UUID-root patch for example) so it would still be useful
to have.
>
> > Have you looked at the DocBook stuff? It would be desirable (not that
> > I'm complaining about ANY documentation, mind you) if the
> > comments were
> > in DocBook format (as some parts of the kernel are moving).
>
> No, I haven't looked at DocBook. I can do that if it's important.
It's not _important_, but given that your comments are relatively well
formatted already, it shouldn't be more than a few minutes work to
convert to DocBook (see Documentation/kernel-doc-nano-HOWTO.txt).
> I prefer to think of it as "partition content type", with a single type for
> all normal file systems (ext2, ext3, etc), and different types for different
> content uses (LVM, RAID, SWAP should be grouped in with normal file systems,
> but for historical reasons isn't).
>
> Each disk and each partition also includes a UniquePartitionGUID which is
> what /proc/guid points to, separate from the PartitionTypeGUID.
Ah, I missed the distinction there. This makes more sense.
> > How is this different than a "struct partition" in
> > <linux/genhd.h> (aside
> > from the fact that "struct partition" should use fixed-sized
> > types because
> > it is referring to on-disk data)?
>
> Same thing, but I didn't want to go mucking about with struct partition in
> exactly that way, as it's used in a variety of places across the kernel, and
> I didn't want this GPT patch to be so invasive.
I think that since the GPT struct definition is the "right" way, you
may as well fix the genhd.h header. By "right" I mean - it is on disk
in fixed sized chunks, so lets not mess with the possibility of breakage
in the future becase the size of an "int" changes. DOS partitions were
defined on x86 hardware so the struct needs to be declared with that
in mind.
> > Are there not already plenty of crc32 functions in the kernel, or does
> > this one have different coefficients?
>
> Yes, in fact I grabbed this one out of the CIPE kernel patch and put it in
> lib/ for that reason. CIPE had it as a table (it needs to be fast as it's
> processing network packets at that point), so I wanted to have a single 1KB
> array that both use. There are other crc32 functions in the kernel, but
> this happens to be the one that Intel is using in their firmware (despite
> what their spec says).
Oh, I don't disagree it should be a table, but since it can be generated
on-the-fly you may as well do so at boot time and avoid the extra kernel
size (assuming the generation code is < 1kB). This code can be marked
__init so it will be freed later.
As for the other crc32 functions, presumably they all use different
coefficients? There was some discussion about this last week in that
several of these tables could also be merged between different drivers.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
^ permalink raw reply
* Re: 2.4.10-ac10-preempt lmbench output.
From: Andrea Arcangeli @ 2001-10-10 4:23 UTC (permalink / raw)
To: Dieter Nützel; +Cc: Robert Love, Andrew Morton, Linux Kernel List
In-Reply-To: <20011010035818.A556B1E760@Cantor.suse.de>
On Wed, Oct 10, 2001 at 05:57:46AM +0200, Dieter Nützel wrote:
> On Tue, Oct 10, 2001 at 03:06, Andrea Arcangeli wrote:
> > On Tue, Oct 09, 2001 at 10:37:56PM -0400, Robert Love wrote:
> > > On Tue, 2001-10-09 at 22:30, Andrea Arcangeli wrote:
> > > > As said it's very very unlikely that preemption points can fix xmms
> > > > skips anyways, the worst scheduler latency is always of the order of the
> > > > msecs, to generate skips you need a latency of seconds.
>
> [...]
> > The point is that to avoid dropouts dbench must take say 40% of the cpu
> > and xmms another 40% of the cpu. Then the 10msec doesn't matter. If each
> > one takes 50% of cpu exactly you can run in dropouts anyways because of
> > scheduler imprecisions.
>
> I get the dropouts (2~3 sec) after dbench 32 is running for 9~10 seconds.
> I've tried with RT artds and nice -20 mpg123.
>
> Kernel: 2.4.11-pre6 + 00_vm-1 + preempt
>
> Only solution:
> I have to copy the test MPG3 file into /dev/shm.
If copying the mp3 data into /dev/shm fixes the problem it could be also
an I/O overload. But it could also be still the vm write throttling: to
read the mp3 from disk you need to allocate some cache, while to read
from /dev/shm you don't need to allocate anything because it was just
allocate when you copied the file there. Or it could be both things
together.
Like the cpu is divided by all the CPU hogs, the disk bandwith is also
divided by all the applications doing I/O at the same time (modulo the
fact the gloabl bandwith dramatically decrease when multiple apps do I/O
at the same time due the seeks, the thing that the elevator tries to
avoid by introducing some degree of unfairness in the I/O patterns).
So if this is just an I/O overload (possible too) some possible fixes
could be:
1) buy faster disk
2) try with elvtune -r 1 -w 2 /dev/hd[abcd] /dev/sd[abcd] that will try
to decrease the global I/O disk bandwith of the system, but it will
increase fairness
> CPU (1 GHz Athlon II) is ~75% idle during the hiccup.
Of course I can imagine. This is totally unrelated to scheduler
latencies, it's either vm write throttling or I/O congestion so you
don't have enough bandwith to read the file or both.
> The dbench processes are mostly in wait_page/wait_cache if I remember right.
> So I think that you are right it is a file IO wait (latency) problem.
Yes.
> Please hurry up with your read/write copy-user paths lowlatency patches ;-)
In the meantime you can use the preemption points in the copy-user, they
can add a bit more of overhead but nothing interesting, I believe it's
more a cleanup than an improvement to move the reschedule points in
read/write as suggested by Andrew.
BTW, this is the relevant patch:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.11aa1/00_copy-user-lat-5
You're probably more interested in the possible heuristic that I've in
mind to avoid xmms to wait I/O completion for the work submitted by
dbench. Of course assuming the vm write throttling was a relevant cause
of the dropouts, and that the dropouts weren't just due an I/O
congestion (too low disk bendwith).
BTW, to find out if the reason of the dropouts where the vm write
throttling or the too low disk bandwith you can run ps l <pid_of_xmms>,
if it says wait_on_buffer all the time it's the vm write throttling, if
it says always something else it's the too low disk bandwith, I suspect
as said above that you'll see both things because it is probably a mixed
effect. If it's not vm write throttling only a faster disk or elvtune
tweaking can help you, there's no renice-IO -n -20 that allows to
prioritize the I/O bandwith to a certain application.
Andrea
^ permalink raw reply
* Re: [PATCH] again: Re: Athlon kernel crash (i686 works)
From: Dan Maas @ 2001-10-10 4:06 UTC (permalink / raw)
To: Bryan Mayland; +Cc: linux-kernel
In-Reply-To: <fa.efssf0v.146031s@ifi.uio.no>
> I've run several LMbench tests against both 686-optimized
> and Athlon-optimized kernels. The results waver across multiple
> tests, one kernel winning some tests one time and losing the next,
> but the values are all close.
The benefits of the kernel Athlon optimizations are higher memory bandwidth
for bulk copies/clears and less cache pollution. But LMbench isn't going to
show any difference, because its tests use generic x86 mem*() functions, not
Athlon-optimized SSE memory routines like in the Athlon kernel.
*Local* Communication bandwidths in MB/s - bigger is better
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem
UNIX reread reread (libc) (hand) read
write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- ----
-
Athlon-1 Linux 2.4.10- 847. 685. 311. 332.4 501.3 176.2 206.2 471.
342.5
Athlon-2 Linux 2.4.10- 882. 586. 187. 331.6 510.2 177.6 207.1 484.
343.5
i686-1 Linux 2.4.10- 863. 586. 299. 320.0 510.2 176.3 206.6 472.
342.6
i686-2 Linux 2.4.10- 874. 318. 199. 319.6 520.2 177.7 206.8 486.
343.5
It should be obvious that LMbench uses sub-optimal memory routines, since
the numbers for "Bcopy" and "Mem read/write" bandwidth are so much lower
than pipe and AF UNIX bandwidths! (the pipe/UNIX tests are basically
equivalent to Bcopy, plus extra user<->kernel transitions and context
switches).
The only cases where I'd expect the Athlon kernel to do better on LMbench
are essentially kernel memcpy() benchmarks - pipe and AF UNIX bandwidths.
I'm not sure if the kernel pipe and UNIX socket code actually uses
Athlon-optimized routines; in any case the small buffer sizes (eg 4KB for
pipes) could be hiding any performance gain.
Regards,
Dan
^ permalink raw reply
* Re: 2.4.10-ac10-preempt lmbench output.
From: Robert Love @ 2001-10-10 4:04 UTC (permalink / raw)
To: Robert Love
Cc: Dieter Nützel, Andrea Arcangeli, Andrew Morton,
Linux Kernel List
In-Reply-To: <1002686542.866.164.camel@phantasy>
On Wed, 2001-10-10 at 00:02, Robert Love wrote:
> On Tue, 2001-10-09 at 23:57, Dieter Nützel wrote:
> > Robert you are running a dual PIII system, right?
> > Could that be the ground why you aren't see the hiccup with your nice preempt
> > patch? Are you running ReiserFS or EXT2/3?
>
> No, I am on a single P3-733. I am using ext3.
Oh, I'm not using Linus's tree, either.
Right now I am 2.4.10-ac10 + preempt-kernel + Rik's eatcache
Robert Love
^ permalink raw reply
* Re: 2.4.10-ac10-preempt lmbench output.
From: Andrea Arcangeli @ 2001-10-10 4:03 UTC (permalink / raw)
To: Robert Love; +Cc: safemode, linux-kernel
In-Reply-To: <1002684288.862.123.camel@phantasy>
On Tue, Oct 09, 2001 at 11:24:36PM -0400, Robert Love wrote:
> On Tue, 2001-10-09 at 23:06, Andrea Arcangeli wrote:
> > [...]
> > I think the issue you raise is that dbench gets a 10msec more of cpu
> > time and xmms starts running 10msec later than expected (because of the
> > scheduler latency peak worst case of 10msec).
> >
> > But that doesn't matter. The scheduler isn't perfect anyways. The
> > resolution of the scheduler is 10msec too, so you can easily lose 10msec
> > anywhere else no matter of whatever scheduler latency of 10msec. [...]
>
> I agree with generally everything you say.
>
> I think, however, you are making two assumptions:
>
> (a) xmms has a very large leeway in the timing of its execution
Yes.
> (b) the maximum time a process sits in kernel space is 10ms.
Actually a task can sit in the kernel for its whole life and still
provide usec scheduler latencies (ksoftirqd)
> While I agree (a) is true, it may not be so in all scenerios.
Correct, of course if you run xmms on a 16mhz CPU it will dropout no
matter of the size of the dma buffer. And you're right the slower the
CPU is the strictier the scheduler latency requirements to avoid the
dropouts are. If the CPU is very slow as soon as xmms gets runnable it
may not have enough time to decode the next mp3 data before the DMA ring
drys out.
So yes I'm assuming doing playback on any recent cpu where xmms just
hurts because it generates high frequency reschedule that in turns means
tlb flushing on x86 (not because of the real cpu load). And mostly
because of its "moving" GUI, not even because of the sound backend :).
> Furthermore, the specified leeway does not exist for all timing-critical
> tasks. Not all of these tasks are specialized real-time applications,
> either.
>
> Most importantly, however, the maximum latency of the system is not
> 10ms. Even _with_ preemption, we have observed greater latencies (due
> to long held locks).
I was reading a very detailed latency analyse done on the 2.4.10 SuSE
kernel by Takashi and it showed 10msec peaks of worst case latency.
The stress during the latency measurement were x11perf (but ok, that's
mostly userspace), /proc with top, disk write, disk read and disk copy.
But of course in -aa as said there's just the most important part of the
low latency patch included, so without -aa I know for sure that the
scheduler latency can run up to several seconds with lots of ram in the
system (this is why I included only those scheduler points even in 2.2
for the multigigabyte machines, where the lack of rescheduling in
read/write could become a patological case visible with eyes while
typing in the shell).
And of course if you only apply the preempt patch and you don't add the
explicit points in the cpu hogs under locks, you'll cover only
copy-user lock less and semaphore parts, but not the other bits like the
ones in the memory management that are also covered since 2.4.1[01] and
in recent 2.2.
> This is why I believe the a preemptible kernel benefits more than just
> real-time signal processing.
Provided that read/write gets fixed like in either Andrew's patch,
Ingo's patch or -aa, I believe it cannot make any visible difference for
mp3 playback in any recent machine. Feel free to experiment yourself
with 2.4.11aa1.
Andrea
^ permalink raw reply
* Re: 2.4.10-ac10-preempt lmbench output.
From: Robert Love @ 2001-10-10 4:02 UTC (permalink / raw)
To: Dieter Nützel; +Cc: Andrea Arcangeli, Andrew Morton, Linux Kernel List
In-Reply-To: <200110100358.f9A3wSB17421@zero.tech9.net>
On Tue, 2001-10-09 at 23:57, Dieter Nützel wrote:
> Robert you are running a dual PIII system, right?
> Could that be the ground why you aren't see the hiccup with your nice preempt
> patch? Are you running ReiserFS or EXT2/3?
No, I am on a single P3-733. I am using ext3.
I have had reports from users on both UP and SMP systems that say audio
playback is undisturbed during heavy I/O with preempt-kernel patch. Of
course, I don't know their definition of undisturbed...but I would wager
it doesn't include 2-3s skips.
Robert Love
^ permalink raw reply
* Re: iptables in 2.4.10, 2.4.11pre6 problems
From: Rusty Russell @ 2001-10-10 3:55 UTC (permalink / raw)
To: Jeffrey W. Baker; +Cc: trever_adams, linux-kernel
In-Reply-To: <Pine.LNX.4.33.0110091005540.209-100000@desktop>
On Tue, 9 Oct 2001 10:07:05 -0700 (PDT)
"Jeffrey W. Baker" <jwbaker@acm.org> wrote:
> On 9 Oct 2001, Trever L. Adams wrote:
>
> > I am seeing messages such as:
> >
> > Oct 9 12:52:51 smeagol kernel: Firewall:IN=ppp0 OUT= MAC=
> > SRC=64.152.2.36 DST=MY_IP_ADDRESS LEN=52 TOS=0x00 PREC=0x00 TTL=246
> > ID=1093 DF PROTO=TCP SPT=80 DPT=33157 WINDOW=34752 RES=0x00 ACK FIN
> > URGP=0
> >
> > In my firewall logs. I see them for ACK RST as well. These are valid
> > connections. My rules follow for the most part (a few allowed
> > connections to the machine in question have been removed from the
> > list). This often leaves open connections in a half closed state on
> > machines behind this firewall. It also some times kills totally open
> > connections and I see packets rejected that should be allowed through.
>
> I see this too. iptables is refusing packets on locally-initiated TCP
> connections when the RELATED,ESTABLISHED rule should be letting them
> through.
Yes, but it has forgotten them. Play with the TCP timeout numbers in
net/ipv4/netfilter/ip_conntrack_proto_tcp.c. Especially the 60 seconds for
TCP_CONNTRACK_CLOSE_WAIT for the ACK FIN case. These numbers were stolen
from the 2.0 and 2.2 masq code, which had real world testing (but didn't
report failures, so...)
Given some actual feedback on appropriate numbers, this can be fed as a
patch to Linus...
Hope that helps,
Rusty.
^ permalink raw reply
* Re: [linux-lvm] kernel reports vg twice
From: Andreas Dilger @ 2001-10-10 3:58 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <20011008160013.A26865@cistron.nl>
On Oct 08, 2001 16:00 +0200, Wichert Akkerman wrote:
> LVM still does not work for me on one of my machines work:
>
> cloud:/dev/discs/disc1# vgscan
> vgscan -- reading all physical volumes (this may take a while...)
> vgscan -- found active volume group "vg_user"
> vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
> vgscan -- WARNING: This program does not do a VGDA backup of your volume group
>
> cloud:/dev/discs/disc1# vgchange -a y
> vgchange -- ERROR: VGDA in kernel and lvmtab are NOT consistent; please run vgscan
>
> I did a bit of looking around and it seems the confusement is in the
> kernel: when lvm_check_kernel_lvmtab_consistency() compares the kernel
> and the lvmtab entries the list from the kernel mentions the vg_user
> volume group twice, while the lvmtab only mentions it once. This
> results in an immediate abort and as a result I can't do anything
> with the LVM tools.
I take it that this is after a reboot?
Does "vgscan -d -v" process vg_user twice, or does "vgchange -a y -v -d"
send vg_user to the kernel twice? Don't know what else to say.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
^ permalink raw reply
* Re: 2.4.10-ac10-preempt lmbench output.
From: Dieter Nützel @ 2001-10-10 3:57 UTC (permalink / raw)
To: Andrea Arcangeli, Robert Love, Andrew Morton; +Cc: Linux Kernel List
On Tue, Oct 10, 2001 at 03:06, Andrea Arcangeli wrote:
> On Tue, Oct 09, 2001 at 10:37:56PM -0400, Robert Love wrote:
> > On Tue, 2001-10-09 at 22:30, Andrea Arcangeli wrote:
> > > As said it's very very unlikely that preemption points can fix xmms
> > > skips anyways, the worst scheduler latency is always of the order of the
> > > msecs, to generate skips you need a latency of seconds.
[...]
> The point is that to avoid dropouts dbench must take say 40% of the cpu
> and xmms another 40% of the cpu. Then the 10msec doesn't matter. If each
> one takes 50% of cpu exactly you can run in dropouts anyways because of
> scheduler imprecisions.
I get the dropouts (2~3 sec) after dbench 32 is running for 9~10 seconds.
I've tried with RT artds and nice -20 mpg123.
Kernel: 2.4.11-pre6 + 00_vm-1 + preempt
Only solution:
I have to copy the test MPG3 file into /dev/shm.
CPU (1 GHz Athlon II) is ~75% idle during the hiccup.
The dbench processes are mostly in wait_page/wait_cache if I remember right.
So I think that you are right it is a file IO wait (latency) problem.
Please hurry up with your read/write copy-user paths lowlatency patches ;-)
> So again: the preemptive patch cannot make any difference, except for
> the read/write copy-user paths that originally Ingo fixed ages ago in
> 2.2, and that I also later fixed in all -aa 2.2 and 2.4 and that are
> also fixed in the lowlatency patches from Andrew (but in the
> generic_file_read/write rather than in copy-user, to possible avoid some
> overhead for short copy users, but the end result for an xmms user is
> exactly the same).
Andrew have you a current version of your lowlatency patches handy?
Robert you are running a dual PIII system, right?
Could that be the ground why you aren't see the hiccup with your nice preempt
patch? Are you running ReiserFS or EXT2/3?
Thanks,
Dieter
^ permalink raw reply
* Re: [linux-lvm] More strangeness
From: Andreas Dilger @ 2001-10-10 3:56 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <000901c1513c$0b59d9d0$836788cf@industry>
On Oct 09, 2001 23:31 -0400, Jason A. Lixfeld wrote:
> Oct 9 22:26:36 hit0day kernel: hdg: read_intr: error=0x10 {
> SectorIdNotFound }, LBAsect=239992834, sector=2
> Oct 9 22:26:36 hit0day kernel: hdg: read_intr: status=0x59 { DriveReady
> SeekComplete DataRequest Error }
> Oct 9 22:26:36 hit0day kernel: hdg: read_intr: error=0x10 {
> SectorIdNotFound }, LBAsect=239992834, sector=2
> Oct 9 22:26:36 hit0day kernel: hdg: read_intr: status=0x59 { DriveReady
> SeekComplete DataRequest Error }
> Oct 9 22:26:36 hit0day kernel: hdg: read_intr: error=0x10 {
> SectorIdNotFound }, LBAsect=239992834, sector=2
> Oct 9 22:26:36 hit0day sshd: Starting sshd:
> Oct 9 22:26:36 hit0day kernel: hdg: read_intr: status=0x59 { DriveReady
> SeekComplete DataRequest Error }
> Oct 9 22:26:36 hit0day kernel: hdg: read_intr: error=0x10 {
> SectorIdNotFound }, LBAsect=239992834, sector=2
> Oct 9 22:26:36 hit0day kernel: ide3: reset: success
> <various hard drive errors for ALL drives (/dev/hde /dev/hdg AND
> /dev/hdi) in LVM test continue for a couple of pages>
There is another user with similar problems with SCSI disks. With LVM
on, it causes disk errors, but with LVM off (or raw disk access) all
is well. It must be something in the low-level LVM kernel code which
is going wrong.
The above looks like LVM doing wrong math - LBAsect=239992834 is
119996417 kiB = 117184 MiB which is larger than hdg (61GB or so).
Do you have similar problems with ext2 and/or reiserfs?
Could you try using an older version of the LVM kernel code to see if
the problem exists there as well? Running ext3 on 2.4.10 is a bit on
the risky side, since there is no "official" patch for it.
You could try enabling LVM DEBUG_MAP (don't log to an LVM device!!!)
to see what it is doing when it gets these errors. You could also
try enabling the JBD buffer debugging to get additional info.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.