* Re: Any non-BS VM work queued for 2.5?
From: Arnaldo Carvalho de Melo @ 2002-01-14 2:04 UTC (permalink / raw)
To: Alan Cox; +Cc: Duraid Madina, linux-kernel
In-Reply-To: <E16PsBq-00083i-00@the-village.bc.nu>
Em Sun, Jan 13, 2002 at 09:29:18PM +0000, Alan Cox escreveu:
> > Is this true? Judging by the ease with which AA's hackwork made it into
> > 2.4, I think we may all be, well, fucked.
>
> 2.4 is now in good hands. Now be careful before the sun comes up and you get
> turned to stone ;)
Oh, this has something to do with that "don't feed the..." thing?
;)
- Arnaldo
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: Andrew Morton @ 2002-01-14 2:04 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Andrea Arcangeli, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.3.96.1020113193700.17441G-100000@gatekeeper.tmr.com>
Bill Davidsen wrote:
>
> Finally, I doubt that any of this will address my biggest problem with
> Linux, which is that as memory gets cheap a program doing significant disk
> writing can get buffers VERY full (perhaps a while CD worth) before the
> kernel decides to do the write, at which point the system becomes
> non-responsive for seconds at a time while the disk light comes on and
> stays on. That's another problem, and I did play with some patches this
> weekend without making myself really happy :-( Another topic,
> unfortunately.
/proc/sys/vm/bdflush: Decreasing the kupdate interval from five
seconds, decreasing the nfract and nfract_sync setting in there
should smooth this out. The -aa patches add start and stop
levels for bdflush as well, which means that bdflush can be the
one who blocks on IO rather than your process. And it means that
the request queue doesn't get 100% drained as soon as the writer
hits nfract_sync.
All very interesting and it will be fun to play with when it
*finally* gets merged.
But with the current elevator design, disk read latencies will
still be painful.
-
^ permalink raw reply
* Re: Linux 2.4.18pre3-ac1
From: Benjamin LaHaise @ 2002-01-14 2:13 UTC (permalink / raw)
To: Alan Cox; +Cc: Adam Kropelin, linux-kernel
In-Reply-To: <E16PvI2-0008WI-00@the-village.bc.nu>
On Mon, Jan 14, 2002 at 12:47:54AM +0000, Alan Cox wrote:
> That is very useful information actually. That does rather imply that some
> of the performance hit came from the block I/O elevator differences in the
> old ac tree (the ones Linus hated ;)). Now the question (and part of the
> reason Linus didnt like them) - is why ?
Iirc, Linus just didn't like the low/high watermarks for starting & stopping
io. Personally, I liked it and wanted to use that mechanism for deciding
when to submit additional blocks from the buffer cache for the device (it
provides a nice means of encouraging batching). The problem that started
this whole mess was a combination of the missing wake_up in the block layer
that I found, plus the horrendous io latency that we hit with a long io queue
and no priorities. The critical pages for swap in and program loading, as
well as background write outs need to have a priority boost so that
interactive feel is better. Of course, with quite a few improvements in
when we wait on ios going into the vm between 2.4.7 and 2.4.17, we don't
wait as indiscriminately on io as we did back then. But write out latency
can still harm us.
In effect, it is a latency vs thruput tradeoff.
-ben
^ permalink raw reply
* [PATCH] devfs v199.7 available
From: Richard Gooch @ 2002-01-14 2:14 UTC (permalink / raw)
To: linux-kernel, devfs-announce-list
Hi, all. Version 199.7 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz
AND:
ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz
This is against 2.4.18-pre3. Highlights of this release:
- Unregister /dev/root symlink prior to creating second one (for
initrd)
- Added support for multiple Compaq cpqarray controllers
- Fixed (rare, old) race in <devfs_lookup>
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
^ permalink raw reply
* ISA hardware discovery -- the elegant solution
From: Eric S. Raymond @ 2002-01-14 1:58 UTC (permalink / raw)
To: Linux Kernel List; +Cc: Linus Torvalds
I've been thinking about the hardware-discovery problem for ISA devices,
and there may be an elegant solution. It will take a number of small changes
to the kernel sources, however.
The kernel's device drivers have, of course, to include probe
routines, and those hard-compiled in typically log the presence of
their hardware to /var/log/mesg when it loads. By scanning that
file, we in effect get to use those probes.
My autoconfigurator's probe table now has a small number of tests than
do regexp matches against the dmesg log. As is, this solution does not
scale well, because each regexp has to be discovered by eyeball and then
maintained in the table by hand.
But suppose the format of boot-time driver messages were standardized in a
format that included their config symbol in a discoverable form?
I have hand-edited a copy of my current /var/log/dmesg to illustrate
how I think this could work.
:MTRR: your CPUs had inconsistent fixed MTRR settings
:MTRR: probably your BIOS does not setup all CPUs
:PCI: PCI BIOS revision 2.10 entry at 0xfd7c0, last bus=1
:PCI: Using configuration type 1
:PCI: Probing PCI hardware
BIOS disabled PCI ordering compliance, so we enabled it again.
:IO_APIC: AMD Errata #22 may be present. In the event of instability try
: booting with the "noapic" option.
:NET: Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
:RTNETLINK: Initializing RT netlink socket
Starting kswapd
allocated 32 pages and 32 bhs reserved for the highmem bounces
:JBD: Journalled Block Device driver loaded
:UNIX_PTY: 2048 Unix98 ptys configured
block: 128 slots per queue, batch=32
:IDE: Uniform Multi-Platform E-IDE driver Revision: 6.31
:IDE: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
:SCSI: SCSI subsystem driver Revision: 1.00
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.4
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
Vendor: IBM-PSG Model: ST318451LW !# Rev: B833
Type: Direct-Access ANSI SCSI revision: 03
Vendor: IBM-PSG Model: ST318451LW !# Rev: B833
Type: Direct-Access ANSI SCSI revision: 03
Vendor: HP Model: C5683A Rev: C005
Type: Sequential-Access ANSI SCSI revision: 02
scsi0:A:0:0: Tagged Queuing enabled. Depth 253
scsi0:A:1:0: Tagged Queuing enabled. Depth 253
Vendor: PIONEER Model: DVD-ROM DVD-305 Rev: 1.00
Type: CD-ROM ANSI SCSI revision: 02
Vendor: PLEXTOR Model: CD-R PX-W1210S Rev: 1.02
Type: CD-ROM ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sda: 35548320 512-byte hdwr sectors (18201 MB)
Partition check:
sda: sda1 sda2 < sda5 >
(scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
SCSI device sdb: 35548320 512-byte hdwr sectors (18201 MB)
sdb: sdb1 sdb2
Attached scsi CD-ROM sr0 at scsi1, channel 0, id 0, lun 0
Attached scsi CD-ROM sr1 at scsi1, channel 0, id 1, lun 0
(scsi1:A:0): 20.000MB/s transfers (20.000MHz, offset 16)
:BLK_DEV_SR: scsi3-mmc drive: 16x/40x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
(scsi1:A:1): 20.000MB/s transfers (20.000MHz, offset 16)
:BLK_DEV_SR: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
:USB_DEVFS: registered new driver usbdevfs
:USB: registered new driver hub
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 16384 buckets, 128Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 96k freed
Adding Swap: 1807272k swap-space (priority -1)
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,5), internal journal
:BLK_DEV_MD: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
kjournald starting. Commit interval 5 seconds
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
:EXT3_FS: FS 2.4-0.9.16, 02 Dec 2001 on sd(8,18), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
:BLK_DEV_ST: Version 20011103, bufsize 32768, wrt 30720, max init. bufs 4, s/g segs 16
Attached scsi tape st0 at scsi0, channel 0, id 2, lun 0
The convention I propose is that at least one line of a driver probe message
should begin with :, followed by the driver config symbol, followed by :.
I am not attached to that particular punctuation, it is simply an unambiguous
way of indicating "this is a config symbol".
With this change, generating a report on ISA hardware and other
facilities configured in at boot time would be trivial. This would
make the autoconfigurator much more capable. Best of all, the only
change required to accomplish this would be safe edits of print format
strings.
I would be willing to generate a patch to implement this change.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
-- Lazarus Long
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: Dieter Nützel @ 2002-01-14 2:12 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Linux Kernel List, Andrew Morton
> Or just doing a large write while doing lots of reads... my personal
> nemesis is "mkisofs" for backups, which reads lots of small files and
> builds a CD image, which suddenly gets discovered by the kernel and
> written, seemingly in a monolythic chunk. I MAY be able to improve this
> with tuning the bdflush parameters, and I tried some tentative patches
> which didn't make a huge gain.
>
> I don't know if the solution lies in forcing write to start when a certain
> size of buffers are queued regardless of percentages, or in better
> scheduling of reads ahead of writes, or whatever.
Have you observed it with -rmap or -aa, too?
I bet, you have.
Try Andrew's read-latency.patch then.
I use it on top of O(1) and preempt all the time.
It should be one of the next 2.4.18-preX/2.4.19-preX patches.
Regards,
Dieter
--
Dieter Nützel
Graduate Student, Computer Science
University of Hamburg
Department of Computer Science
@home: Dieter.Nuetzel@hamburg.de
^ permalink raw reply
* Re: Linux 2.4.18pre3-ac1-aia21 (IDE patches)
From: Andrew Morton @ 2002-01-14 2:10 UTC (permalink / raw)
To: Anton Altaparmakov; +Cc: linux-kernel
In-Reply-To: <5.1.0.14.2.20020113232757.04f34ec0@pop.cus.cam.ac.uk>
Anton Altaparmakov wrote:
>
> Alan's -ac series is back! To celebrate this I added in the IDE patches and
> an NTFS update which dramatically reduces the number of vmalloc()s and have
> posted the resulting (tested) patch (to be applied on top of
> 2.4.18pre3-ac1) at below URL.
>
Is that the NTFS code which produces eighty five quintillion warnings
with the recommended gcc versions? :-)
-
^ permalink raw reply
* Re: Oops in kswapd (Kernel 2.4.17)
From: Andrew Morton @ 2002-01-14 2:13 UTC (permalink / raw)
To: Patrick Burns; +Cc: linux-kernel
In-Reply-To: <3C423A90.2E34D426@vrlaw.com.au>
Patrick Burns wrote:
>
> Is there some kind of memory problem with kernel 2.4.17? I noticed in an
> article at:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=101096234600708&w=2
>
> and another at:
>
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0201.1/0809.html
>
> that people were getting oopses in kswapd.
One does begin to think that there may be a problem. The inode,
dentry and buffer caches do involve a lot of pointer chasing,
and do tend to expose hardware problems (memory), and we've tended
to assume that's the reason for all the reports.
But there are a *lot* of reports, and the same argument applies:
the long pointer chases will expose random memory corruption caused
by a kernel bug.
It's starting to look fishy.
-
^ permalink raw reply
* Re: cross-cpu balancing with the new scheduler
From: Rusty Russell @ 2002-01-14 2:19 UTC (permalink / raw)
To: Manfred Spraul; +Cc: mingo, linux-kernel
In-Reply-To: <3C41BD74.28F6707A@colorfullife.com>
On Sun, 13 Jan 2002 18:01:40 +0100
Manfred Spraul <manfred@colorfullife.com> wrote:
> Is it possible that the inter-cpu balancing is broken in 2.5.2-pre11?
>
> eatcpu is a simple cpu hog ("for(;;);"). Dual CPU i386.
>
> $nice -19 ./eatcpu&;
> <wait>
> $nice -19 ./eatcpu&;
> <wait>
> $./eatcpu&.
>
> IMHO it should be
> * both niced process run on one cpu.
> * the non-niced process runs with a 100% timeslice.
>
> But it's the other way around:
> One niced process runs with 100%. The non-niced process with 50%, and
> the second niced process with 50%.
This could be fixed by making "nr_running" closer to a "priority sum".
Ingo?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: [PATCH] 1-2-3 GB
From: Rik van Riel @ 2002-01-14 2:21 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-kernel
In-Reply-To: <a1sqd3$nc6$1@cesium.transmeta.com>
On 13 Jan 2002, H. Peter Anvin wrote:
> By the way, expect user programs to fail due to lack of address space
> if you only give them 1 GB of userspace. At 1 GB of userspace there
> is *no* address space which is compatible with the normal address
> space map available to the user process.
>
> I would personally vote against including that particular option.
It could be useful for machines where most activity happens
inside the kernel, though. Think of TUX web or ftp servers
or dedicated NFS servers.
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
^ permalink raw reply
* Re: Linux 2.4.18pre3-ac1-aia21 (IDE patches)
From: Anton Altaparmakov @ 2002-01-14 2:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <5.1.0.14.2.20020113232757.04f34ec0@pop.cus.cam.ac.uk>
At 02:10 14/01/02, Andrew Morton wrote:
>Anton Altaparmakov wrote:
> >
> > Alan's -ac series is back! To celebrate this I added in the IDE patches and
> > an NTFS update which dramatically reduces the number of vmalloc()s and have
> > posted the resulting (tested) patch (to be applied on top of
> > 2.4.18pre3-ac1) at below URL.
> >
>
>Is that the NTFS code which produces eighty five quintillion warnings
>with the recommended gcc versions? :-)
Huh? You are referring to ntfs tng perhaps? No, this is just a small update
to the existing ntfs driver (admittedly taken from ntfs tng but this little
part shouldn't produce any compiler problems AFAIK).
This update makes ntfs use kmalloc instead of vmalloc for <= PAGE_SIZE
allocations and since the majority of the allocations are <= PAGE_SIZE this
is both a performance improvement and a decrease of load on the 128MiB
vmalloc vm area.
There were people who reported problems under load due to failing vmallocs
and concurrent ldt allocation problems. This patch should address those
problems.
Best regards,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
* Re: Any non-BS VM work queued for 2.5?
From: Rik van Riel @ 2002-01-14 2:38 UTC (permalink / raw)
To: Duraid Madina; +Cc: linux-kernel
In-Reply-To: <1010956364.50291.0.camel@simplex.idesign.fl.net.au>
On 14 Jan 2002, Duraid Madina wrote:
> A good spot o' webtrawling has left me with the impression that
> Rik Riel is Linux's only hope of ever competing with FreeBSD on large
> jobs other than dbench.
>
> Is this true? Judging by the ease with which AA's hackwork made
> it into 2.4, I think we may all be, well, fucked.
I take it you're volunteering to do tests of the AA VM and
of my -rmap VM patch, pointing out weak points in both VMs?
(not necessarily performance bugs ... more situations where
one or both of the VMs just "fall apart completely", the stuff
that really needs to be fixed)
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
^ permalink raw reply
* Try #3: UML has been sent to Linus again
From: Jeff Dike @ 2002-01-14 2:39 UTC (permalink / raw)
To: linux-kernel
This patch is against 2.5.2-pre11 and is available at
http://prdownloads.sourceforge.net/user-mode-linux/uml-patch-2.5.2-pre11.bz2
It's also available from the other UML mirrors - they are listed at
http://user-mode-linux.sourceforge.net/dl-sf.html
This UML is the same as the 2.4.17-5 patch.
Note - Ingo's scheduler has broken UML in a fairly fundamental way by holding
IRQs off across a context switch. See my separate LKML post for the gory
details.
Jeff
^ permalink raw reply
* The O(1) scheduler breaks UML
From: Jeff Dike @ 2002-01-14 2:39 UTC (permalink / raw)
To: mingo; +Cc: linux-kernel
The new scheduler holds IRQs off across the call to context_switch. UML's
_switch_to expects them to be enabled when it is called, and things go
badly wrong when they are not.
Because UML has a host process for each UML thread, SIGIO needs to be
forwarded from one process to the next during a context switch. A SIGIO
arriving during the window between the disabling of IRQs and forwarding of
IRQs to the next process will be trapped on the process going out of
context. This happens fairly regularly and causes hangs because some process
is waiting for disk IO which never arrives because the process that was notified
of the completion is switched out.
So, is it possible to enable IRQs across the call to _switch_to?
Jeff
^ permalink raw reply
* [PATCH] devfs v206 available
From: Richard Gooch @ 2002-01-14 2:42 UTC (permalink / raw)
To: linux-kernel, devfs-announce-list
Hi, all. Version 206 of my devfs patch is now available from:
http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
The devfs FAQ is also available here.
Patch directly available from:
ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.5/devfs-patch-current.gz
AND:
ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.5/devfs-patch-current.gz
NOTE: kernel 2.5.1 and later require devfsd-v1.3.19 or later.
This is against 2.5.2-pre11. Highlights of this release:
- Added support for multiple Compaq cpqarray controllers
- Fixed (rare, old) race in <devfs_lookup>
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
^ permalink raw reply
* Re: cross-cpu balancing with the new scheduler
From: Davide Libenzi @ 2002-01-14 2:49 UTC (permalink / raw)
To: Rusty Russell; +Cc: Manfred Spraul, mingo, linux-kernel
In-Reply-To: <20020114131925.4fcbd127.rusty@rustcorp.com.au>
On Mon, 14 Jan 2002, Rusty Russell wrote:
> On Sun, 13 Jan 2002 18:01:40 +0100
> Manfred Spraul <manfred@colorfullife.com> wrote:
>
> > Is it possible that the inter-cpu balancing is broken in 2.5.2-pre11?
> >
> > eatcpu is a simple cpu hog ("for(;;);"). Dual CPU i386.
> >
> > $nice -19 ./eatcpu&;
> > <wait>
> > $nice -19 ./eatcpu&;
> > <wait>
> > $./eatcpu&.
> >
> > IMHO it should be
> > * both niced process run on one cpu.
> > * the non-niced process runs with a 100% timeslice.
> >
> > But it's the other way around:
> > One niced process runs with 100%. The non-niced process with 50%, and
> > the second niced process with 50%.
>
> This could be fixed by making "nr_running" closer to a "priority sum".
I've a very simple phrase when QA is bugging me with these corner cases :
"As Designed"
It's much much better than adding code and "Return To QA" :-)
I tried priority balancing in BMQS but i still prefer "As Designed" ...
- Davide
^ permalink raw reply
* Re: The O(1) scheduler breaks UML
From: Davide Libenzi @ 2002-01-14 2:55 UTC (permalink / raw)
To: Jeff Dike; +Cc: mingo, linux-kernel
In-Reply-To: <200201140239.VAA05307@ccure.karaya.com>
On Sun, 13 Jan 2002, Jeff Dike wrote:
> The new scheduler holds IRQs off across the call to context_switch. UML's
> _switch_to expects them to be enabled when it is called, and things go
> badly wrong when they are not.
>
> Because UML has a host process for each UML thread, SIGIO needs to be
> forwarded from one process to the next during a context switch. A SIGIO
> arriving during the window between the disabling of IRQs and forwarding of
> IRQs to the next process will be trapped on the process going out of
> context. This happens fairly regularly and causes hangs because some process
> is waiting for disk IO which never arrives because the process that was notified
> of the completion is switched out.
>
> So, is it possible to enable IRQs across the call to _switch_to?
Yes, this should work :
if (likely(prev != next)) {
rq->nr_switches++;
rq->curr = next;
next->cpu = prev->cpu;
spin_unlock_irq(&rq->lock);
context_switch(prev, next);
} else
spin_unlock_irq(&rq->lock);
and there's no need for barrier() and rq reload in this way.
- Davide
^ permalink raw reply
* Re: ISA hardware discovery -- the elegant solution
From: Larry McVoy @ 2002-01-14 2:54 UTC (permalink / raw)
To: Eric S. Raymond, Linux Kernel List, Linus Torvalds
In-Reply-To: <20020113205839.A4434@thyrsus.com>
> :MTRR: your CPUs had inconsistent fixed MTRR settings
> :MTRR: probably your BIOS does not setup all CPUs
> :PCI: PCI BIOS revision 2.10 entry at 0xfd7c0, last bus=1
> :PCI: Using configuration type 1
> :PCI: Probing PCI hardware
It's ugly and distracting and if this proposal goes anywhere, move the tag to
end of the line. Then your eyes can scan the output and the tools can scan
the end of the line.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
^ permalink raw reply
* Re: Linux 2.4.18pre3-ac1
From: Rik van Riel @ 2002-01-14 2:54 UTC (permalink / raw)
To: Adam Kropelin; +Cc: linux-kernel
In-Reply-To: <028b01c19c90$87300760$02c8a8c0@kroptech.com>
On Sun, 13 Jan 2002, Adam Kropelin wrote:
> From: "Alan Cox" <alan@redhat.com>
>
> > People keep bugging me about the -ac tree stuff so this is whats in my
> > current internal diff with the ll patch and the ide changes excluded.
> For the sake of completeness I ran my large inbound FTP transfer test
> (details in the "Writeout in recent kernels..." thread) on this
> release. Performance and observed writeout behavior was essentially
> the same as for 2.4.17, both stock and with -rmap11a. Transfer time
> was 6:56 and writeout was uneven. 2.4.13-ac7 is still the winner by a
> significant margin.
I'm looking into this bug, I just finished the first large
dbench test set on 2.4.17-rmap11b with 512 MB RAM, tomorrow
I'll run them with 128 and 32 MB of RAM.
Luckily you have already shown the other recent kernels to
have the same performance, so I only have to do half a day
of testing. I'll try to track down this bug and get it fixed.
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
http://www.surriel.com/ http://distro.conectiva.com/
^ permalink raw reply
* possible change to usb.agent
From: Robert Anderson @ 2002-01-14 2:58 UTC (permalink / raw)
To: linux-hotplug
I've been trying to get a script to autorun when my USB Fuji 2800
camera is added to the system. I could only get it to work by
changing the program flow in "usb.agent". It seemed that
"usb.usermap" was only looked at if no other match was found?
I used the jPhoto example, except where they used "usb.handmap" I used
"usb.usermap". It seemed like the comments indicated it should be in
the "usb.usermap" section to me, perhaps I misunderstood the comments?
If I'm way off here please let me know so that I can conform to what
was expected. I'm giving a user group talk on Monday evening 1/13/02,
and I'd like to be give out the correct information.
----------------------------------------------------------------------
I was using the following rpm on Redhat 7.2 and 7.1 systems:
----------------------------------------------------------------------
[root@anthill hotplug]# rpm -qi hotplug
Name : hotplug Relocations: (not relocateable)
Version : 2001_04_24 Vendor: Red Hat, Inc.
Release : 11 Build Date: Mon 27 Aug 2001 12:41:30 PM EDT
Install date: Sun 13 Jan 2002 09:31:19 PM EST Build Host: stripples.devel.redhat.com
Group : System Environment/Kernel Source RPM: hotplug-2001_04_24-11.src.rpm
Size : 97618 License: GPL
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://linux-hotplug.sourceforge.net/
Summary : A helper application which loads modules for USB devices.
Description :
The term "hotplugging" refers to the dynamic reconfiguration performed
after a device has been attached to a running system. This package
contains the application which is called by the kernel when a USB
device is added; hotplug then loads the required modules for that
device.
----------------------------------------------------------------------
The line I added to /etc/hotplug/usb.usermap
----------------------------------------------------------------------
cam2hd 0x3 0x4cb 0x100 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
----------------------------------------------------------------------
The diff of my one line change to /etc/hotplug/usb.agent
----------------------------------------------------------------------
[root@anthill hotplug]# diff -c usb.agent.orig usb.agent
*** usb.agent.orig Sun Jan 13 21:31:38 2002
--- usb.agent Sun Jan 13 21:31:58 2002
***************
*** 307,313 ****
fi
# some devices have user-mode drivers (no kernel module, but config)
! if [ "$FOUND" = "false" -a -r $MAP_USERMAP ]; then
MODPROBE=:
load_drivers usb $MAP_USERMAP "$LABEL"
if [ "$DRIVERS" != "" ]; then
--- 307,313 ----
fi
# some devices have user-mode drivers (no kernel module, but config)
! if [ -r $MAP_USERMAP ]; then
MODPROBE=:
load_drivers usb $MAP_USERMAP "$LABEL"
if [ "$DRIVERS" != "" ]; then
[root@anthill hotplug]#
--------------------------------------------------------------
Robert E. Anderson email: rea@sr.unh.edu
Systems Programmer phone: (603) 862-3489
UNH Research Computing Center fax: (603) 862-1761
--------------------------------------------------------------
_______________________________________________
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
* radeonfb fix
From: Erik Andersen @ 2002-01-14 2:59 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
In-Reply-To: <Pine.LNX.4.21.0201101827100.22287-100000@freak.distro.conectiva>
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
On Thu Jan 10, 2002 at 06:30:07PM -0200, Marcelo Tosatti wrote:
>
> Hi,
>
> So here it goes pre3.
Hi Marcelo,
This patch is needed to make radeonfb compile and work.
It is based on an earlier patch on the list attributed to
Ani Joshi, plus adds the needed devinit fix.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
[-- Attachment #2: radeonfb.patch.bz2 --]
[-- Type: application/octet-stream, Size: 2192 bytes --]
^ permalink raw reply
* Ich bin's
From: schneckchen @ 2002-01-13 21:03 UTC (permalink / raw)
To: linux-mips@oss.sgi.com
Hallo,
....danke für Dein Mail. Ist schon `ne Weile her. Nun ja, bist Du immer
noch allein? Einsam? Ich auch.
Obwohl Freunde von mir sagen, dass ich recht gut aussehe, fehlt mir doch
noch ein netter Partner zum Reden, Lieben und Kuscheln. Vielleicht bist Du
es. Dein Alter und Dein Aussehen ist für mich nicht so wichtig.
Im Moment spanne ich einige Tage aus, lasse die Seele baumeln-, versuche
nach Enttäuschungen mein Leben neu zu ordnen.
Ich habe mich bei www.fairway-contacts.com eingetragen. Du findest ein
Foto und meine Wohnungsanschrift mit normaler Telefonnummer unter der
Rubrik "Sie sucht Ihn". Wenn ich Dir gefallen sollte, rufe mich doch
einfach einmal an.
Ich freue mich auf ein Gespräch mit Dir. Bis bald
Dein
Schneckchen
^ permalink raw reply
* drivers missing __devexit_p in 2.4.18pre3
From: Erik Andersen @ 2002-01-14 3:07 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
A quick check of the source code shows that the following drivers
appear to still be lacking the devinit fixes which are needed for
the kernel to compile when using newer versions of binutils.
Each of these files probably needs the following (though I'm too
lazy to do it all myself, since my kernel doesn't use any of this
stuff):
s/remove:\(.*\)/remove:__devexit_p(\1)/g
drivers/net/wan/dscc4.c
drivers/net/tokenring/abyss.c
drivers/net/tokenring/tmspci.c
drivers/net/pcnet32.c
drivers/net/sis900.c
drivers/net/dmfe.c
drivers/net/rcpci45.c
drivers/net/hamachi.c
drivers/net/wireless/orinoco_plx.c
drivers/char/synclink.c
drivers/char/n_r3964.c
drivers/char/wdt_pci.c
drivers/scsi/tmscsim.c
drivers/scsi/aic7xxx/aic7xxx_linux_pci.c
drivers/sound/es1370.c
drivers/sound/maestro.c
drivers/sound/trident.c
drivers/sound/es1371.c
drivers/sound/cs4281/cs4281m.c
drivers/sound/i810_audio.c
drivers/sound/sonicvibes.c
drivers/sound/esssolo1.c
drivers/sound/maestro3.c
drivers/sound/cs46xx.c
drivers/sound/nm256_audio.c
drivers/sound/via82cxxx_audio.c
drivers/sound/rme96xx.c
drivers/sound/ite8172.c
drivers/sound/nec_vrc5477.c
drivers/video/matrox/matroxfb_base.c
drivers/video/matrox/matroxfb_crtc2.c
drivers/video/matrox/matroxfb_g450.c
drivers/ieee1394/pcilynx.c
drivers/mtd/ftl.c
drivers/mtd/mtdchar.c
drivers/mtd/nftlcore.c
drivers/message/fusion/mptscsih.c
drivers/hotplug/cpqphp_core.c
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
^ permalink raw reply
* Re: [RFC][PATCH] cleanup file.h and INIT_TASK a bit
From: Greg KH @ 2002-01-14 3:09 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: linux-kernel
In-Reply-To: <20020113185947.A32700@redhat.com>
On Sun, Jan 13, 2002 at 06:59:47PM -0500, Benjamin LaHaise wrote:
>
> Oh, the file.h cleanup exposed a mess (bug): usb.c was duplicating code
> from daemonize().
That's drivers/usb/storage/usb.c, the usb-storage driver's file. Which
should not be confused with drivers/usb/usb.c :)
greg k-h
^ permalink raw reply
* Re: radeonfb fix, fixed
From: Erik Andersen @ 2002-01-14 3:14 UTC (permalink / raw)
To: Marcelo Tosatti, lkml
In-Reply-To: <20020114025951.GA17592@codepoet.org>
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Sun Jan 13, 2002 at 07:59:51PM -0700, Erik wrote:
> On Thu Jan 10, 2002 at 06:30:07PM -0200, Marcelo Tosatti wrote:
> >
> > Hi,
> >
> > So here it goes pre3.
>
> Hi Marcelo,
>
> This patch is needed to make radeonfb compile and work.
> It is based on an earlier patch on the list attributed to
> Ani Joshi, plus adds the needed devinit fix.
Oops. That patch had some crap in it. Lets try that again.
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
[-- Attachment #2: radeonfb.patch.bz2 --]
[-- Type: application/octet-stream, Size: 1460 bytes --]
^ 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.