* [ANNOUNCE] Linux project funding
From: Randy.Dunlap @ 2002-10-26 19:24 UTC (permalink / raw)
To: linux-hotplug
Hi,
The Linux-USB project has some funds available to be used to
encourage or support Linux kernel or userspace open-source
development.
Information for qualifying projects and applications to this fund
can be found at "http://www.linux-usb.org/beanieForm.html".
Thanks,
~Randy
[apologies if you receive multiple copies of this announcement]
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* [ANNOUNCE] Linux project funding
From: Randy.Dunlap @ 2002-10-26 19:22 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi,
The Linux-USB project has some funds available to be used to
encourage or support Linux kernel or userspace open-source
development.
Information for qualifying projects and applications to this fund
can be found at "http://www.linux-usb.org/beanieForm.html".
Thanks,
~Randy
[apologies if you receive multiple copies of this announcement]
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
^ permalink raw reply
* Re: rootfs exposure in /proc/mounts
From: Jeff Garzik @ 2002-10-26 19:26 UTC (permalink / raw)
To: Andreas Steinmetz; +Cc: Alexander Viro, linux-kernel
In-Reply-To: <3DBAE931.7000409@domdv.de>
Andreas Steinmetz wrote:
> Alexander Viro wrote:
>
>>
>> On Sat, 26 Oct 2002, Andreas Steinmetz wrote:
>>
>>
>>> Maybe I do oversee the obious but:
>>>
>>> can somebody please explain why rootfs is exposed in /proc/mounts (I
>>> do mean the "rootfs / rootfs rw 0 0" entry) and if there is a good
>>> reason for the exposure?
>>
>>
>>
>> Mostly the fact that it _is_ mounted and special-casing its removal from
>> /proc/mounts is more PITA than it's worth.
>>
> Acceptable but somewhat sad as it confuses e.g. "umount -avt noproc"
> which is somewhat standard in shutdown/reboot scripts (using a
> softlink from /etc/mtab to /proc/mounts).
Bug 1 - don't softlink directly to /proc/mounts :) embedded guys
typically do this, and you see why it bites you in the ass :)
Bug 2 - "noproc" clearly does not avoid ramfs mounts, which is rootfs's
filesystem type. And more and more ramfs filesystems will be appearing,
so that should be taken into consideration.
Sounds like userspace slackness to me, and nothing that the kernel guys
need to worry about...
Jeff
^ permalink raw reply
* [PATCH,RFC] faster kmalloc lookup
From: Manfred Spraul @ 2002-10-26 19:22 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 241 bytes --]
kmalloc spends a large part of the total execution time trying to find
the cache for the passed in size.
What about the attached patch (against 2.5.44-mm5)?
It uses fls jump over the caches that are definitively too small.
--
Manfred
[-- Attachment #2: patch-fast-kmalloc --]
[-- Type: text/plain, Size: 1219 bytes --]
--- 2.5/mm/slab.c Sat Oct 26 21:13:33 2002
+++ build-2.5/mm/slab.c Sat Oct 26 20:40:09 2002
@@ -424,6 +430,7 @@
CN("size-131072")
};
#undef CN
+static struct cache_sizes *malloc_hints[sizeof(size_t)*8];
struct arraycache_init initarray_cache __initdata = { { 0, BOOT_CPUCACHE_ENTRIES, 1, 0} };
struct arraycache_init initarray_generic __initdata = { { 0, BOOT_CPUCACHE_ENTRIES, 1, 0} };
@@ -587,6 +594,7 @@
void __init kmem_cache_init(void)
{
size_t left_over;
+ int i;
init_MUTEX(&cache_chain_sem);
INIT_LIST_HEAD(&cache_chain);
@@ -604,6 +612,18 @@
* that initializes ac_data for all new cpus
*/
register_cpu_notifier(&cpucache_notifier);
+
+ for (i=0;i<sizeof(size_t)*8;i++) {
+ struct cache_sizes *csizep = malloc_sizes;
+ int size = (1<<i)/2+1;
+
+ for ( ; csizep->cs_size; csizep++) {
+ if (size > csizep->cs_size)
+ continue;
+ break;
+ }
+ malloc_hints[i] = csizep;
+ }
}
@@ -1796,7 +1816,11 @@
*/
void * kmalloc (size_t size, int flags)
{
- struct cache_sizes *csizep = malloc_sizes;
+ struct cache_sizes *csizep;
+
+ if(unlikely(size<2))
+ size=2;
+ csizep = malloc_hints[fls((size-1))];
for (; csizep->cs_size; csizep++) {
if (size > csizep->cs_size)
^ permalink raw reply
* use of a state machine compiler in netfilter?
From: Adrian Thurston @ 2002-10-26 19:11 UTC (permalink / raw)
To: netfilter-devel
Hello, I'd like to contribute to netfilter, but first I need to do a
little research. I don't have much experience kernel hacking or with
netfilter but...
I have written a realtime operating system that included
a stateless ip network driver. It was for a course at school.
I am the author of the Ragel State Machine Compiler
(http://www.essemage.com/ragel/). State machines are very useful for
matching a large number of diverse patterns very efficiently.
This leads me to my question. Would the netfilter project benefit from
code that built state machines from high-level descriptions of packets
that would recognise and ultimately route many different types of packets
on one pass?
Perhaps you have something like this implemented already?
-Adrian
^ permalink raw reply
* NUMA scheduler (was: 2.5 merge candidate list 1.5)
From: Martin J. Bligh @ 2002-10-26 19:14 UTC (permalink / raw)
To: Erich Focht, Michael Hohnbaum, mingo, habanero; +Cc: linux-kernel, lse-tech
In-Reply-To: <200210251015.46388.efocht@ess.nec.de>
>> From my point of view, the reason for focussing on this was that
>> your scheduler degraded the performance on my machine, rather than
>> boosting it. Half of that was the more complex stuff you added on
>> top ... it's a lot easier to start with something simple that works
>> and build on it, than fix something that's complex and doesn't work
>> well.
>
> You're talking about one of the first 2.5 versions of the patch. It
> changed a lot since then, thanks to your feedback, too.
OK, I went to your latest patches (just 1 and 2). And they worked!
You've fixed the performance degradation problems for kernel compile
(now a 14% improvement in systime), that core set works without
further futzing about or crashing, with or without TSC, on either
version of gcc ... congrats!
It also produces the fastest system time for kernel compile I've ever
seen ... this core set seems to be good (I'm still less than convinced
about the further patches, but we can work on those one at a time now
you've got it all broken out and modular). Michael posted slightly
different looking results for virgin 44 yesterday - the main difference between virgin 44 and 44-mm4 for this stuff is probably the per-cpu
hot & cold pages (Ingo, this is like your original per-cpu pages).
All results are for a 16-way NUMA-Q (P3 700MHz 2Mb cache) 16Gb RAM.
Kernbench:
Elapsed User System CPU
2.5.44-mm4 19.676s 192.794s 42.678s 1197.4%
2.5.44-mm4-hbaum 19.422s 189.828s 40.204s 1196.2%
2.5.44-mm4-focht12 19.316s 189.514s 36.704s 1146.8%
Schedbench 4:
Elapsed TotalUser TotalSys AvgUser
2.5.44-mm4 32.45 49.47 129.86 0.82
2.5.44-mm4-hbaum 31.31 43.85 125.29 0.84
2.5.44-mm4-focht12 38.50 45.34 154.05 1.07
Schedbench 8:
Elapsed TotalUser TotalSys AvgUser
2.5.44-mm4 39.90 61.48 319.26 2.79
2.5.44-mm4-hbaum 32.63 46.56 261.10 1.99
2.5.44-mm4-focht12 35.56 46.57 284.53 1.97
Schedbench 16:
Elapsed TotalUser TotalSys AvgUser
2.5.44-mm4 62.99 93.59 1008.01 5.11
2.5.44-mm4-hbaum 49.78 76.71 796.68 4.43
2.5.44-mm4-focht12 51.94 61.43 831.26 4.68
Schedbench 32:
Elapsed TotalUser TotalSys AvgUser
2.5.44-mm4 88.13 194.53 2820.54 11.52
2.5.44-mm4-hbaum 54.67 147.30 1749.77 7.91
2.5.44-mm4-focht12 55.43 119.49 1773.97 8.41
Schedbench 64:
Elapsed TotalUser TotalSys AvgUser
2.5.44-mm4 159.92 653.79 10235.93 25.16
2.5.44-mm4-hbaum 65.20 300.58 4173.26 16.82
2.5.44-mm4-focht12 56.49 235.78 3615.71 18.05
There's a small degredation at the low end of schedbench (Erich's
numa_test) in there ... would be nice to fix, but I'm less worried
about that (where the machine is lightly loaded) than the other
numbers. Kernbench is just gcc-2.95-4 compiling the 2.4.17 kernel
doing a "make -j24 bzImage".
diffprofile 2.5.44-mm4 2.5.44-mm4-hbaum
(for kernbench, + got worse by adding the patch, - got better)
184 vm_enough_memory
154 d_lookup
83 do_schedule
75 page_add_rmap
73 strnlen_user
58 find_get_page
52 flush_signal_handlers
...
-61 pte_alloc_one
-63 do_wp_page
-85 .text.lock.file_table
-96 __set_page_dirty_buffers
-112 clear_page_tables
-118 get_empty_filp
-134 free_hot_cold_page
-144 page_remove_rmap
-150 __copy_to_user
-213 zap_pte_range
-217 buffered_rmqueue
-875 __copy_from_user
-1015 do_anonymous_page
diffprofile 2.5.44-mm4 2.5.44-mm4-focht12
(for kernbench, + got worse by adding the patch, - got better)
<nothing significantly degraded>
....
-57 path_lookup
-69 do_page_fault
-73 vm_enough_memory
-77 filemap_nopage
-78 do_no_page
-83 __set_page_dirty_buffers
-83 __fput
-84 do_schedule
-97 find_get_page
-106 file_move
-115 free_hot_cold_page
-115 clear_page_tables
-130 d_lookup
-147 atomic_dec_and_lock
-157 page_add_rmap
-197 buffered_rmqueue
-236 zap_pte_range
-264 get_empty_filp
-271 __copy_to_user
-464 page_remove_rmap
-573 .text.lock.file_table
-618 __copy_from_user
-823 do_anonymous_page
^ permalink raw reply
* Re: rootfs exposure in /proc/mounts
From: Andreas Steinmetz @ 2002-10-26 19:12 UTC (permalink / raw)
To: Alexander Viro; +Cc: linux-kernel
In-Reply-To: <Pine.GSO.4.21.0210261458460.29768-100000@steklov.math.psu.edu>
Alexander Viro wrote:
>
> On Sat, 26 Oct 2002, Andreas Steinmetz wrote:
>
>
>>Maybe I do oversee the obious but:
>>
>>can somebody please explain why rootfs is exposed in /proc/mounts (I do
>>mean the "rootfs / rootfs rw 0 0" entry) and if there is a good reason
>>for the exposure?
>
>
> Mostly the fact that it _is_ mounted and special-casing its removal from
> /proc/mounts is more PITA than it's worth.
>
Acceptable but somewhat sad as it confuses e.g. "umount -avt noproc"
which is somewhat standard in shutdown/reboot scripts (using a softlink
from /etc/mtab to /proc/mounts).
^ permalink raw reply
* [LARTC] Is this a kernel bug???
From: Mohit Gupta @ 2002-10-26 19:07 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
Hi
I am encountering what I suspect to be a bug in the kernel processing of
tc netlink messages:
I am using kernel version 2.4.9 with iproute2-current-001007
package. Everything works fine in the kernel. Now I open a netlink
socket with a user process, read the tc netlink messages generated by
the tc process and parse them.
What I see is that the kernel has already processed the messages (i.e.,
adds some default
values for example) before making them available to my process.
Problem comes when I parse the tcindex messages. Here is an excerpt
from the examples in iproute2 diffserv distribution.
$TC qdisc add $EGDEV handle 2:0 root dsmark indices 64
#
# The class mapping
#
$TC filter add $EGDEV parent 2:0 protocol ip prio 1 \
handle 1 tcindex classid 2:1
$TC filter add $EGDEV parent 2:0 protocol ip prio 1 \
handle 2 tcindex classid 2:2
$TC filter add $EGDEV parent 2:0 protocol ip prio 1 \
handle 3 tcindex classid 2:3
$TC filter add $EGDEV parent 2:0 protocol ip prio 1 \
handle 4 tcindex classid 2:4
When I parse the tcindex filter messages I dont see the handle and the
classid information. I only see the default value that are set by the
kernel for mask, shift and fall_through.
I SEE >> hash 64 mask 0xffff shift 0 fall_through
But when I do a >> tc filter ls dev eth0 parent 2:0, I see all the
handle - classid pair I have instantiated. I feel there is something
wrong in the way the tcindex filter messages are being processed by the
kernel. The handle and classid information is no longer there in the netlink
message when it is put back on the netlink socket by the kernel.
If indeed does anyone know how to fix this and if not then can
someone please tell me how the read the handle and classid information
for these messages.
PS - My process parses all the other tc messages correctly.
Thanks,
Mog.
[-- Attachment #2: Type: text/html, Size: 2759 bytes --]
^ permalink raw reply
* Creating a Hybrid Connection to Balance Traffic
From: Paul Aumer-Ryan @ 2002-10-26 19:04 UTC (permalink / raw)
To: netfilter
I've got a peculiar situation that I hope you all
would listen to and offer feedback on any possible
implementations.
So I've recently broke down and purchased a DSL
connection for my home computer, and I've just
discovered the joys of p2p file sharing (i.e., being
able to download television shows that my local
stations have stopped carrying, like Enterprise).
Anyway, as you can guess, these video files are rather
large, and other users also grab them from my computer
as well, so my upload speeds are rather high. Since
I've subscribed to DSL service through a local ISP,
and since local ISPs are big on service but not on
resources, I got a call from them recently asking me
to tone down my upload bandwidth usage on the DSL
line. I've pretty much got to listen or I will lose
my service.
My local setup consists of a linux box acting as a
gateway for my home network of (gasp!) one computer
and a laptop. The linux box currently uses ipchains
to perform the necessary IP masquerading for the
connection. Some quick stats:
eth0: external network connection (to ISP)
eth1: internal network
ppp0: modem attached, but not currently used.
So here comes the question: since I've got to reduce
my upload usage, I'd like to try to use the linux box
to do a special form of SNAT routing. I would like
all outgoing data to leave through the attached ppp0
interface (the modem which I can hook up to a dialup
ISP) and all incoming data to come back in through the
eth0 interface (the broadband connection to my local
ISP). Basically, I need to do a form of SNAT routing
that overwrites the source address of packets leaving
on the ppp0 interface with the IP address of the eth0
interface, so when their replies come back the will
come on the faster broadband connection. This way the
upload bandwidth usage on the DSL connection will be
effectively zero, while I will still be able to enjoy
the fast download speeds of the DSL line, satisfying
both me and the ISP.
My issues include the current usage of SNAT routing
(masquerading) since my local network connects to the
internet through the linux box's one IP address, and
how to use ipchains, iptables, or ipnatctl (or others)
to perform this extra set of SNAT routing. Does
anyone have any ideas on how to implement this?
Sorry for the long story, and I thank everyone in
advance for their time. Have a good one,
Paul
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
^ permalink raw reply
* Re: 2.5 Problem Report Status
From: Patrick Mochel @ 2002-10-26 19:06 UTC (permalink / raw)
To: Toon van der Pas; +Cc: linux-kernel
In-Reply-To: <20021026161830.E30058@vdpas.hobby.nl>
On Sat, 26 Oct 2002, Toon van der Pas wrote:
> On Wed, Oct 23, 2002 at 10:03:51AM -0700, Patrick Mochel wrote:
> >
> > ===== drivers/ide/ide.c 1.33 vs edited =====
> > --- 1.33/drivers/ide/ide.c Fri Oct 18 12:44:11 2002
> > +++ edited/drivers/ide/ide.c Wed Oct 23 09:42:27 2002
> > @@ -3351,6 +3351,14 @@
> > return 0;
> > }
> >
> > +static void ide_drive_shutdown(struct device * dev)
> > +{
> > + ide_drive_t * drive = container_of(dev,ide_drive_t,gendev);
> > + ide_driver_t * drive = drive->driver;
>
> Are you sure you didn't introduce a typo here? (missing 'r')
> Maybe you meant this line to be:
>
> + ide_driver_t * driver = drive->driver;
Uhm..yes. Sorry about that.
-pat
^ permalink raw reply
* Re: Crunch time -- the musical. (2.5 merge candidate list 1.5)
From: Martin J. Bligh @ 2002-10-26 18:58 UTC (permalink / raw)
To: Erich Focht, Michael Hohnbaum, landley; +Cc: linux-kernel
In-Reply-To: <200210251015.46388.efocht@ess.nec.de>
>> I still haven't been able to get your scheduler to boot for about
>> the last month without crashing the system. Andrew says he has it
>> booting somehow on 2.5.44-mm4, so I'll steal his kernel tommorow and
>> see how it looks. If the numbers look good for doing boring things
>> like kernel compile, SDET, etc, I'm happy.
>
> I thought this problem is well understood! For some reasons independent of
> my patch you have to boot your machines with the "notsc" option. This
> leaves the cache_decay_ticks variable initialized to zero which my patch
> doesn't like. I'm trying to deal with this inside the patch but there is
> still a small window when the variable is zero. In my opinion this needs
> to be fixed somewhere in arch/i386/kernel/smpboot.c. Booting a machine
> with cache_decay_ticks=0 is pure nonsense, as it switches off cache
> affinity which you absolutely need! So even if "notsc" is a legal option,
> it should be fixed such that it doesn't leave your machine without cache
> affinity. That would anyway give you a falsified behavior of the O(1)
> scheduler.
Oh, not sure if I ever replied to this or not. I don't *have* to boot
with notsc, I just usually do. And it crashed either way, so it's a
different problem (changing versions of gcc seems to perturb it too).
BUT ... your new patches 1 and 2 don't have this problem. See followup
email in a second.
M.
^ permalink raw reply
* Re: rootfs exposure in /proc/mounts
From: Alexander Viro @ 2002-10-26 18:59 UTC (permalink / raw)
To: Andreas Steinmetz; +Cc: linux-kernel
In-Reply-To: <3DBAE4A0.4090802@domdv.de>
On Sat, 26 Oct 2002, Andreas Steinmetz wrote:
> Maybe I do oversee the obious but:
>
> can somebody please explain why rootfs is exposed in /proc/mounts (I do
> mean the "rootfs / rootfs rw 0 0" entry) and if there is a good reason
> for the exposure?
Mostly the fact that it _is_ mounted and special-casing its removal from
/proc/mounts is more PITA than it's worth.
^ permalink raw reply
* Re: 2.5.44-ac3 usb audio - illegal sleep call
From: Greg KH @ 2002-10-26 18:53 UTC (permalink / raw)
To: Kevin Brosius; +Cc: Oliver Neukum, kernel
In-Reply-To: <3DBADB56.C782BD1D@compuserve.com>
On Sat, Oct 26, 2002 at 02:13:42PM -0400, Kevin Brosius wrote:
> Oliver Neukum wrote:
> >
> >
> > Am Samstag, 26. Oktober 2002 16:13 schrieb Kevin Brosius:
> > > I've been trying to get USB up to test a audio device and just managed
> > > to get it all working to some extent. When using xmms to play audio
> > > (usb audio module - oss soundcore) I see the following kernel messages
> > > repeatedly, maybe once a second or so:
> >
> > Go edit usbout_completed() and usbin_completed(). Change the GFP_KERNEL
> > in usb_submit_urb to GFP_ATOMIC.
> > Does that help ?
> >
> > Regards
> > Oliver
>
>
> Hi guys,
> No... Well, actually, it does change which function gives the
> warning. Now usbout_sync_completed is complaining.
Heh, can you change that instance of GFP_KERNEL to GFP_ATOMIC too?
thanks,
greg k-h
^ permalink raw reply
* rootfs exposure in /proc/mounts
From: Andreas Steinmetz @ 2002-10-26 18:53 UTC (permalink / raw)
To: linux-kernel
Maybe I do oversee the obious but:
can somebody please explain why rootfs is exposed in /proc/mounts (I do
mean the "rootfs / rootfs rw 0 0" entry) and if there is a good reason
for the exposure?
--
Andreas Steinmetz
^ permalink raw reply
* strange report from vmstat
From: Nikolay Datchev @ 2002-10-26 18:31 UTC (permalink / raw)
To: linux-smp
Hello there,
I have a machine with few resource-eater processes, and during a probe
how to reduce the system load, i've found a strange report from vmstat:
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
4294967295 0 0 264 10888 9920 741400 0 0 37 39 523 148 32 2 66
which means that there are 4294967295 processes waiting for run time,
which is - impossible ;-) Maybe there is some scheduling problem ? System
is 2x1 GHz PIII coppermines, 1 Gb RAM with enabled high mem, kernel is
2.4.19 compiled with -O3 and patched only with grsecurity, vmstat is from
procps-3.0.5 .
-- Nikolay Datchev
^ permalink raw reply
* [linux-lvm] lvscan and df result differs
From: Magnus Sandberg @ 2002-10-26 18:31 UTC (permalink / raw)
To: linux-lvm
I have just installed lvm on my debian testing server.
I have finally managed to create a PV on a maxtor
120G disk, the 'pvcreate' command complained about
a partitiontable being present even if there is no
table there.
--8<--
server:~# pvcreate --version
pvcreate: Logical Volume Manager 1.0.4
Heinz Mauelshagen, Sistina Software 02/05/2002 (IOP 10)
--8<--
I managed to get around that by using a v2 lvm command.
Is there a bug in 1.0.x's pvcreate?
I have also managed to create a VG a and a LV and that
seems to work. I have formatted the LV with ext3 and now
the strange thing is that lvscan reports:
--8<--
server:~# lvscan
lvscan -- ACTIVE "/dev/vg/lg" [114.49 GB]
lvscan -- 1 logical volumes with 114.49 GB total in 1 volume group
lvscan -- 1 active logical volumes
--8<--
But when using the filesystem df reports:
--8<--
Filesystem Size Used Avail Use% Mounted on
/dev/hde1 123GB 121GB 2.4GB 99% /store
/dev/vg/lg 122GB 121GB 0 100% /store2
--8<--
/dev/hde1 is also a 120G disk but with resierfs, ext3
takeing up more size is probably normal. But the actual
size on the lvm is 122G and as you can see I can fit
121G on the disk, so why is lvscan reporting ~115G?
Can i safetly use my lvm setup without running the risk
of losing data?
Thanks,
/Magnus
^ permalink raw reply
* Re: PATCH: Fix errlist for mips
From: H. J. Lu @ 2002-10-26 18:20 UTC (permalink / raw)
To: Roland McGrath, GNU C Library, linux-mips
In-Reply-To: <20021026181431.GA11105@nevyn.them.org>
On Sat, Oct 26, 2002 at 02:14:31PM -0400, Daniel Jacobowitz wrote:
> On Fri, Oct 25, 2002 at 09:55:43PM -0700, H. J. Lu wrote:
> > On Sat, Oct 26, 2002 at 12:45:49AM -0400, Daniel Jacobowitz wrote:
> > > Not everyone uses your MIPS patches; I have a completely functional
> > > MIPS system with:
> > > 0019df30 l O .data 000011b8 _new_sys_errlist
> > > 0019df30 l O .data 000001ec _old_sys_errlist
> >
> > It doesn't tell anything. Please, please show size of sys_errlist in
> > glibc 2.0 for mips. I am not even sure if you can run mips binaries
> > compiled against glibc 2.0 with glibc 2.2/2.3.
>
> I didn't use 2.0 for MIPS either. And I got the wrong impression from
> your last message; sorry!
>
> Here's what my MIPS glibc has:
> 0019df30 g DO .data 000001ec (GLIBC_2.0) sys_errlist
> 0019df30 g DO .data 000011b8 GLIBC_2.2 sys_errlist
> 0019df30 g DO .data 000001ec (GLIBC_2.0) _sys_errlist
> 0019df30 g DO .data 000011b8 GLIBC_2.2 _sys_errlist
>
> So: I don't know where the GLIBC_2.1 version came from, or why we need
> a GLIBC_2.3 version, or why we should change the size of the GLIBC_2.0
> version. Your patch looks good; should you wipe the GLIBC_2.1 version
> also?
sys_errlist in glibc 2.0 is naked. We gave it a version of GLIBC_2.0
when versioning was implemented and we had to increase the size of
sys_errlist. We gave it a new version, GLIBC_2.1. Now sys_errlist is
changed again for some arches. That is where GLIBC_2.3 came from. For
mips, the first supported glibc version after 2.0 is 2.2. That turns
GLIBC_2.1 into GLIBC_2.2 for mips. Since mips's sys_errlist is huge in
2.2, there is no need to change it in 2.3.
H.J.
^ permalink raw reply
* Re: PATCH: Fix errlist for mips
From: Daniel Jacobowitz @ 2002-10-26 18:14 UTC (permalink / raw)
To: H. J. Lu; +Cc: Roland McGrath, GNU C Library, linux-mips
In-Reply-To: <20021025215543.A26333@lucon.org>
On Fri, Oct 25, 2002 at 09:55:43PM -0700, H. J. Lu wrote:
> On Sat, Oct 26, 2002 at 12:45:49AM -0400, Daniel Jacobowitz wrote:
> > Not everyone uses your MIPS patches; I have a completely functional
> > MIPS system with:
> > 0019df30 l O .data 000011b8 _new_sys_errlist
> > 0019df30 l O .data 000001ec _old_sys_errlist
>
> It doesn't tell anything. Please, please show size of sys_errlist in
> glibc 2.0 for mips. I am not even sure if you can run mips binaries
> compiled against glibc 2.0 with glibc 2.2/2.3.
I didn't use 2.0 for MIPS either. And I got the wrong impression from
your last message; sorry!
Here's what my MIPS glibc has:
0019df30 g DO .data 000001ec (GLIBC_2.0) sys_errlist
0019df30 g DO .data 000011b8 GLIBC_2.2 sys_errlist
0019df30 g DO .data 000001ec (GLIBC_2.0) _sys_errlist
0019df30 g DO .data 000011b8 GLIBC_2.2 _sys_errlist
So: I don't know where the GLIBC_2.1 version came from, or why we need
a GLIBC_2.3 version, or why we should change the size of the GLIBC_2.0
version. Your patch looks good; should you wipe the GLIBC_2.1 version
also?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
^ permalink raw reply
* Re: 2.5.44-ac3 usb audio - illegal sleep call
From: Kevin Brosius @ 2002-10-26 18:13 UTC (permalink / raw)
To: Oliver Neukum, Greg KH; +Cc: kernel
In-Reply-To: <200210261902.32626.oliver@neukum.name>
Oliver Neukum wrote:
>
>
> Am Samstag, 26. Oktober 2002 16:13 schrieb Kevin Brosius:
> > I've been trying to get USB up to test a audio device and just managed
> > to get it all working to some extent. When using xmms to play audio
> > (usb audio module - oss soundcore) I see the following kernel messages
> > repeatedly, maybe once a second or so:
>
> Go edit usbout_completed() and usbin_completed(). Change the GFP_KERNEL
> in usb_submit_urb to GFP_ATOMIC.
> Does that help ?
>
> Regards
> Oliver
Hi guys,
No... Well, actually, it does change which function gives the
warning. Now usbout_sync_completed is complaining.
Oct 26 13:54:18 sea kernel: Debug: sleeping function called from illegal
context at mm/slab.c:1374
Oct 26 13:54:18 sea kernel: Call Trace:
Oct 26 13:54:18 sea kernel: [<c013fd0b>] __kmem_cache_alloc+0x17b/0x180
Oct 26 13:54:18 sea kernel: [<e0a38bb5>] ohci_urb_enqueue+0xb5/0x2d0
[ohci-hcd]
Oct 26 13:54:18 sea kernel: [<e09b9017>] hcd_submit_urb+0x117/0x180
[usbcore]
Oct 26 13:54:18 sea kernel: [<e09c9d20>] usb_hcd_operations+0x0/0x40
[usbcore]
Oct 26 13:54:18 sea kernel: [<e09b993b>] usb_submit_urb+0x1db/0x250
[usbcore]
Oct 26 13:54:18 sea kernel: [<e0a2bd45>]
usbout_sync_completed+0xe5/0x110 [audio]
Oct 26 13:54:18 sea kernel: [<e09b9409>] usb_hcd_giveback_urb+0x19/0x30
[usbcore]
Oct 26 13:54:18 sea kernel: [<e0a38add>] dl_done_list+0x13d/0x160
[ohci-hcd]
Oct 26 13:54:18 sea kernel: [<e0a3945b>] ohci_irq+0xfb/0x160 [ohci-hcd]
Oct 26 13:54:18 sea kernel: [<e09b9442>] usb_hcd_irq+0x22/0x60
[usbcore]
Oct 26 13:54:18 sea kernel: [<c010b8c5>] handle_IRQ_event+0x45/0x70
Oct 26 13:54:18 sea kernel: [<c010bb6a>] do_IRQ+0xba/0x160
Oct 26 13:54:18 sea kernel: [<c0107100>] default_idle+0x0/0x50
Oct 26 13:54:18 sea kernel: [<c010a1ba>] common_interrupt+0x42/0x58
--
Kevin
^ permalink raw reply
* Re: 2.5 Problem Report Status
From: Toon van der Pas @ 2002-10-26 14:18 UTC (permalink / raw)
To: Patrick Mochel; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0210230952311.983-100000@cherise.pdx.osdl.net>
On Wed, Oct 23, 2002 at 10:03:51AM -0700, Patrick Mochel wrote:
>
> ===== drivers/ide/ide.c 1.33 vs edited =====
> --- 1.33/drivers/ide/ide.c Fri Oct 18 12:44:11 2002
> +++ edited/drivers/ide/ide.c Wed Oct 23 09:42:27 2002
> @@ -3351,6 +3351,14 @@
> return 0;
> }
>
> +static void ide_drive_shutdown(struct device * dev)
> +{
> + ide_drive_t * drive = container_of(dev,ide_drive_t,gendev);
> + ide_driver_t * drive = drive->driver;
Are you sure you didn't introduce a typo here? (missing 'r')
Maybe you meant this line to be:
+ ide_driver_t * driver = drive->driver;
> + if (driver && driver->standby)
> + driver->standby(drive);
> +}
> +
> int ide_register_driver(ide_driver_t *driver)
> {
> struct list_head list;
> @@ -3372,6 +3380,7 @@
> driver->gen_driver.name = driver->name;
> driver->gen_driver.bus = &ide_bus_type;
> driver->gen_driver.remove = ide_drive_remove;
> + driver->gen_driver.shutdown = ide_drive_shutdown;
> return driver_register(&driver->gen_driver);
> }
Regards,
Toon.
--
/"\ |
\ / ASCII RIBBON CAMPAIGN | "Who is this General Failure, and
X AGAINST HTML MAIL | what is he doing on my harddisk?"
/ \
^ permalink raw reply
* Re: [PATCH] pre-decoded wchan output
From: Robert Love @ 2002-10-26 17:44 UTC (permalink / raw)
To: Pavel Machek; +Cc: Christoph Hellwig, torvalds, linux-kernel, riel
In-Reply-To: <20021021230856.GA120@elf.ucw.cz>
On Mon, 2002-10-21 at 19:08, Pavel Machek wrote:
> Yes, and force users to update procps for no good reason. And "new"
> procps will still need code to deal with get_wchan themselves... Plus
> you loose information by killing get_wchan() -- two different wait
> points in one function seems very possible to me.
- users of 2.5 need a new procps but only wchan is "broken" and
only if CONFIG_KALLSYMS is set anyhow
- I did not kill get_wchan, just do not use it in stat - in fact
I use it in the new wchan approach, too
- its not an issue now because the updated patch (posted 5 days
after this email you are replying to) keeps wchan.
So you got your way. Look at the patch posted 22 Oct. It is now in
2.5-mm.
Robert Love
^ permalink raw reply
* Re: rmap for 2.4.19-strict-vm-overcommit?
From: Robert Love @ 2002-10-26 17:37 UTC (permalink / raw)
To: Amit Shah; +Cc: Rik van Riel, linux-mm
In-Reply-To: <20021026160534.26faec56.shahamit@gmx.net>
On Sat, 2002-10-26 at 06:35, Amit Shah wrote:
> I would've liked if I got a separate patch that I could apply against my
> 2.4.19-overcommit.
I have a 2.4.19-pre7 + rmap patch. I do not know how easily it will
apply to 2.4.19 and current rmap but it should go pretty good.
http://www.kernel.org/pub/linux/kernel/people/rml/vm/strict-overcommit/v2.4/vm-strict-overcommit-rml-2.4.19-pre7-rmap-1.patch
> Also: any indications that overcommit and/or rmap might be included in the
> standard 2.4 kernel?
Probably no to both. If you want them, they are both in 2.4-ac and 2.5.
Robert Love
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: Was: Trying to get GUI'ed
From: John E. Jay Maass @ 2002-10-26 17:34 UTC (permalink / raw)
To: Bryan Simmons; +Cc: linux-newbie
Hi Bryan,
I get all coffeed up and stay up all crazy hours and maybe I
thought you were being condescending. So, the laugh's on me.
Yes, virtual memory is interesting, for as little as I know
of it. NT 4.0, don't quote me, can address up to 4 gigs of
virtual memory? When I finally got some amount of RAM I noticed
that my hard drive rarely ran. That point is further driven
home by your case of your Mandrake running 2 months without
swapping to hdd. Awesome. And better things arrive daily.
When the holographic images begin dancing in the living
room, I bet some computer users bow out. 512 mb is a nice
number. I have 256 mb in this Windows 2000 box, and love it.
I am anxious now to have my other 3 or 4 machines sharing
this Verizon DSL, especially my Red Hat 7.0 installation,
and maybe my machine with Steven Darnold's Basic Linux 1.61
onboard. I cannot be enthusiastic about my Linux boxes until
I have a router here.
While subscribing to this list I am using the dreaded Microsoft
product, and feeling guilty. On the subject of Windows 2000,
though, I am very pleased with the purchase. I laid out some
$300 to have a licensed copy of the OS, and am not sorry.
It has the executive services and the hardware abstraction
layer, and is darned stable, so far, knock on wood.
Thanks for putting up with my coffeed craziness.
Jay
> From: Bryan Simmons <bsimmo1@gl.umbc.edu>
> Date: 2002/10/26 Sat PM 01:11:57 EDT
> To: "John E. Jay Maass" <jay.maass@verizon.net>
> CC: linux-newbie <linux-newbie@vger.kernel.org>
> Subject: Re: Was: Trying to get GUI'ed
>
> didn't mean to sound condescending. I was just trying to add to the
> point of importance of RAM. Virtual memory makes it so that you can
> address MORE RAM than you physically have. It has many other benefits
> as well. But it goes without saying that the more RAM you have, the
> better. When I first installed Mandrake 9.0, I ran it for 2 months
> without using any swap space. I have 512MB RAM. I don't intend to
> screw around with performance. Hell, I'd use a gig or more if I thought
> it wasn't overkill for my applications...
>
>
>
> On Sat, 2002-10-26 at 07:01, John E. Jay Maass wrote:
> > Bryan Simmons <bsimmo1@gl.umbc.edu> writes:
> >
> > > Think that was informative? Learn assembly on x86 Linux.
> > > You have NO idea what a computer goes through just to add
> > > two numbers, let alone manage network traffic... The most
> > > shocking part is the idea of virtual memory.
> >
> > Bryan,
> >
> > I thought my little RAM thing was informative, yeah. It was
> > intended as practical, nothing esoteric or high minded. About
> > assembly language, a friend of mine worked with it and I took
> > a peek. I would love to know a little assembly. What I read
> > of it was impossible for me to grasp. Somehow I get by. With
> > great perseverance I manage to eventually grasp a little of
> > what others take for granted. Certainly nothing like assembly,
> > though <grins>.
> >
> > All best,
> > Jay
> >
> >
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
> --
> Bryan Simmons <bsimmo1@gl.umbc.edu>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Àu½èªwÄÑ.. Time:¤W¤È 01:22:33
From: nfs @ 2002-10-27 1:22 UTC (permalink / raw)
To: nfs
[-- Attachment #1: Type: text/html, Size: 6711 bytes --]
^ permalink raw reply
* FAQ submission with answer
From: Duane Ellis @ 2002-10-26 17:22 UTC (permalink / raw)
To: trmcneal, nfs
I have a "FAQ" question and at least
an Answer or work around for the problem.
I hope this helps others on this list
(I am not on the nfs list)
I am an administer a fairly large
Unix network ( +50 SunOS boxes, and +20 linux boxes)
and have hit this problem a few times when
configuring a new linux machine.
I am trying to export "/" (root) file system
from one linux box to all others via the
the directory construct:
# cd /net/HOSTNAME/filesystem
When I run the exportfs command, I got a cryptic
message that did not help what so ever.
# exportfs -ra
europa:/: Invalid argument
Manytimes this is mis-diagnosted as a condition
where you are exporting a sub-directory of an
already exported file system - That's not my
problem.
Specifically my problem is this:
The file /var/lib/nfs/rmtab had a stale
entry in it.
Specifically to fix my problem I had to do this:
# [stop nfs]
# cd /var/lib/nfs
# rm -f etab mtab rmtab
# touch rmtab
[otherwise exportfs complains]
# [start nfs]
A better answer would be to explain or fix why
the file /var/lib/nfs/rmtab had the stale entry
or to fix what ever updates the file.
Perhaps this is a latent bug that is inside of NFS or
one of the other utlities, or maybe these files
should be removed during a reboot as part of some
type of 'house-cleaning' operation.
It appears that a fix was offered to this problem
in this posting, but it has ether not picked up
or not trickled through to all the various distros.
http://sourceforge.net/mailarchive/message.php?msg_id=553411
look for:
>> # First we should cleanup and then prepare our exports.
> /var/lib/nfs/etab #
> /var/lib/nfs/xtab # contains list of exportable filesystems
>> /var/lib/nfs/rmtab # list of used exported filesystems
Thanks.
-Duane Ellis
Others have seen this problem too:
http://sourceforge.net/mailarchive/message.php?msg_id=1228515
http://sourceforge.net/mailarchive/message.php?msg_id=550491
It appears that a fix was offered to this problem
in this posting:
http://sourceforge.net/mailarchive/message.php?msg_id=553411
look for:
>> # First we should cleanup and then prepare our exports.
> /var/lib/nfs/etab #
> /var/lib/nfs/xtab # contains list of exportable filesystems
>> /var/lib/nfs/rmtab # list of used exported filesystems
http://www.geocrawler.com/archives/3/789/2001/8/50/6372419/
http://www.cs.helsinki.fi/linux/linux-kernel/2002-01/0811.html
https://listman.redhat.com/pipermail/wolverine-list/2001-March/001096.html
http://plug.skylab.org/199906/msg00469.html
http://www.van-dijk.net/linuxkernel/200202/0583.html.gz
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ 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.