* Ppcboot & kernel upgrade problem(2.4.x kernel does not work)
From: ByungGiBaek @ 2002-01-15 6:50 UTC (permalink / raw)
To: linuxppc-embedded@lists.linuxppc.org
Dear all,
Now I'm trying to upgrade linux kernel from 2.2.14 to 2.4.x on our own MPC860T board(50MHz).
I successfully download and boot linux-2.2.14 kernel with ppcboot-0.9.3.
But when I tried to boot linux-2.4.x kernel with same ppcboot and same board,I have some problem.
I just see under messages then the board is auto resetted.
I adjusted IMMR and bd_t of include/asm/my_board.h as ppcboot.h of ppcboot.
Thanks in advance.
=> bootm
## Booting image at 00100000 ...
Image Name: 2.4.8 for MPC860T Board
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 535804 Bytes = 523 kB = 0 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Transferring control to Linux (at address 00000000) ...
ByungGi Baek.
weapon100@hanmail.net
===========================================================================
우리 인터넷, Daum http://www.daum.net
- 2002 대입 1:1상담,원서접수,합격자발표 ☞ http://hmm.daum.net/daeip_0112
- 인터넷에서 '토정비결' 보세요~ ☞ http://hmm.daum.net/fortune_0112
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* How to increase a processes memory
From: Subhash Induri @ 2002-01-15 6:47 UTC (permalink / raw)
To: linux-mm
Hello,
I need a small help regarding increasing the amount of memory allocated
to a process.
My system has 4Gb of RAM.. my process needs about 3GB of memory..Is
there in any way i can increase the memory allocated by the system..So
that my process's data may not be frequently swapped in and out.. As of
now the process runs very slow... I figure this to be cos of the amount of
swapping that would take place..If anyone could help me out, it would be
really great..
An additional information about my process is that it uses memory-mapped
files, .. files which are mapped to the processes memory.. and thats the
only reason my process consumes that much of memory..
Thanks a lot
subhash
--
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
* [parisc-linux] LMBench on SMP A500
From: Ryan Bradetich @ 2002-01-15 6:41 UTC (permalink / raw)
To: parisc-linux
[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]
Hello Parisc-linux hackers,
I ran the lmbench mark sweet against an dual-processor A500. I have
attached the results of the benchmark for people to review.
I am not convinced of the validity of the benchmark because the
following message repeatedly showed up in dmesg:
do_page_fault() pid=22449 command='lat_sig' type=15 address=0x40019000
vm_start = 0x40019000, vm_end = 0x4001a000
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001100000000000001111 Not tainted
r00-03 0000000000000000 fffffffffffff000 0000000000011f3b
0000000040019000
r04-07 00000000bff00410 00000000bff001c8 0000000000027a32
0000000000000003
r08-11 0000000000027a72 0000000000000000 00000000000cea08
00000000000cf148
r12-15 0000000000000000 00000000000cafe8 00000000ffffffff
0000000000000000
r16-19 0000000000000000 00000000000b9e9c 0000000000000000
0000000000000001
r20-23 000000000000004e 00000000400cf460 0000000000000000
0000000000000008
r24-27 0000000000000000 0000000000000000 0000000000027b4c
0000000000027870
r28-31 0000000000000000 0000000000000000 00000000bff00500
00000000400cf46b
sr0-3 00000000002bcf00 00000000002bcf00 0000000000000000
00000000002bcf00
sr4-7 00000000002bcf00 00000000002bcf00 00000000002bcf00
00000000002bcf00
but I wanted to throw the results out for discussion.
Thanks,
- Ryan
[-- Attachment #2: lmbench.rbrad --]
[-- Type: text/plain, Size: 3787 bytes --]
L M B E N C H 2 . 0 S U M M A R Y
------------------------------------
Basic system parameters
----------------------------------------------------
Host OS Description Mhz
--------- ------------- ----------------------- ----
gsyprf11. Linux 2.4.17- hppa64-linux-gnu 443
gsyprf11. Linux 2.4.17- hppa64-linux-gnu 443
gsyprf11. Linux 2.4.17- hppa64-linux-gnu 443
Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host OS Mhz null null open selct sig sig fork exec sh
call I/O stat clos TCP inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
gsyprf11. Linux 2.4.17- 443 0.71 1.38 6.81 8.42 80.2 2.06 16.0 17.K 37.K 74.K
gsyprf11. Linux 2.4.17- 443 0.71 1.39 6.77 8.42 80.6 2.06 16.0 17.K 37.K 74.K
gsyprf11. Linux 2.4.17- 443 0.71 1.39 6.79 8.42 80.3 2.06 16.0 17.K 37.K 74.K
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
gsyprf11. Linux 2.4.17- 5.640 5.4400 4.6900 6.1000 18.3 30.2 93.0
gsyprf11. Linux 2.4.17- 5.430 5.4100 5.0300 6.9200 21.2 30.6 92.9
gsyprf11. Linux 2.4.17- 5.570 5.3800 5.0400 5.6200 19.4 30.0 94.3
*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP
ctxsw UNIX UDP TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
gsyprf11. Linux 2.4.17- 5.640 26.2 37.1 107.5 4977
gsyprf11. Linux 2.4.17- 5.430 31.6 37.1 108.4 4977
gsyprf11. Linux 2.4.17- 5.570 27.1 37.8 107.0 4932
File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host OS 0K File 10K File Mmap Prot Page
Create Delete Create Delete Latency Fault Fault
--------- ------------- ------ ------ ------ ------ ------- ----- -----
gsyprf11. Linux 2.4.17- 40.0 10.0 270.0 50.0 1480.0K 550.0
gsyprf11. Linux 2.4.17- 40.0 10.0 270.0 60.0 1480.0K 557.9 14.0
gsyprf11. Linux 2.4.17- 40.0 10.0 280.0 60.0 1480.0K 550.0 20.0
*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
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
gsyprf11. Linux 2.4.17- 51.3 81.0 68.5 78.5 483.7 204.9 206.5 483. 455.0
gsyprf11. Linux 2.4.17- 51.3 81.0 68.8 78.5 483.7 200.3 204.9 488. 458.9
gsyprf11. Linux 2.4.17- 51.3 81.0 68.6 78.5 483.7 195.9 198.8 483. 440.1
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
---------------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Guesses
--------- ------------- ---- ----- ------ -------- -------
gsyprf11. Linux 2.4.17- 443
^ permalink raw reply
* Re: [linux-lvm] Re: [RFLART] kdev_t in ioctls
From: Joe Thornber @ 2002-01-15 6:27 UTC (permalink / raw)
To: linux-lvm; +Cc: Alexander Viro, linux-kernel
In-Reply-To: <Pine.LNX.4.33.0201140957040.15128-100000@penguin.transmeta.com>
On Mon, Jan 14, 2002 at 10:01:25AM -0800, Linus Torvalds wrote:
> Consider that done. ANYTHING that exports kdev_t to user space is
> incredibly broken, and will not work in a few months when the actual bit
> representation (and size) will change.
The kdev_t's in the driver interface are just one of the *minor*
problems with the LVM driver.
I came to the conclusion last summer that a rewrite was in order, of
both the kernel driver and the userland tools. The new driver is
called 'device-mapper', and has been discussed briefly on this list.
It aims to support volume management in general, ie. not be LVM
specific.
The userland tools (known as LVM2), will go into beta this week.
Initially they will just replicate the functionality of LVM1, but we
do have a lot of extra features queued which will go in subsequent
releases.
Of course Sistina will continue to support the existing LVM1 driver
for the 2.4 series.
As far as the 2.5 series is concerned, I would much rather see people
embracing the new architecture (or telling me why it sucks). Rather
than trying to hack the LVM1 driver so it works. People have been
complaining for the last year about LVM, we weren't able to do much
about it since we were in a stable kernel and couldn't change any
interfaces. Now that 2.5 is finally here it is time for people to
address the real problems - kdev_t's only scratch the surface.
- Joe
^ permalink raw reply
* Re: [PATCH] page coloring for 2.4.17 kernel
From: Jason Papadopoulos @ 2002-01-15 6:16 UTC (permalink / raw)
To: linux-mm
I know it's bad form to respond to my own post, but I've done some
more careful lmbench runs and many of the glaring differences in the
2.4.17 kernel with and without page coloring seem to damp out. The
AF UNIX and File reread bandwidths are consistently better across multiple
runs, though.
Sorry about that,
jasonp
--
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: [parisc-linux] Problems with lasi_82596.c [CONFIG_IOMMU_CCIO]
From: Matthew Wilcox @ 2002-01-15 5:58 UTC (permalink / raw)
To: Carlos O'Donell Jr., parisc-linux
In-Reply-To: <20020115005115.B4645@systemhalted>
On Tue, Jan 15, 2002 at 12:51:15AM -0500, Carlos O'Donell Jr. wrote:
> 255 #else /* !CONFIG_IOMMU_CCIO */
> 256 #define ccio_get_iommu(dev) do { } while (0)
> --> 257 #define ccio_get_fake(dev) do { } while (0)
> -> 1521 fake_pci_dev = ccio_get_fake(dev);
My fault, fixing now.
--
Revolutions do not require corporate support.
^ permalink raw reply
* Re: [linux-lvm] lvm problem
From: Heinz J . Mauelshagen @ 2002-01-15 5:56 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <OF5335B286.82ADE051-ONC1256B41.004E7A11@hpigmbh.com>
On Mon, Jan 14, 2002 at 03:21:39PM +0100, Matthias Stoll wrote:
> Hi !
>
> I'm not so firm in linux but:
>
> We had a LG "smbdata" which went away somehow? ;-)
Hi Matthias.
What does 'somehow' mean? ;-)
LVM/Operator error? I know: in case of an operator error I wouldn't tell
anybody either ;-)
>
> Searched all threads and followed your instructions on recovering
> configuration of LV. Didn't work ;-(
>
> Here is the output of vgcfgrestore -ll -f /etc/lvmconf/smbdata.conf.7.old
> -n smbdata /dev/sda
>
> --- Volume group ---
> VG Name smbdata
> VG Access read/write
> VG Status NOT available/resizable
> VG # 0
> MAX LV 256
> Cur LV 1
> Open LV 0
> MAX LV Size 255.99 GB
> Max PV 256
> Cur PV 4
> Act PV 4
> VG Size 15.86 GB
> PE Size 4 MB
> Total PE 4060
> Alloc PE / Size 4060 / 15.86 GB
> Free PE / Size 0 / 0
> VG UUID zwceZi-TCXm-Ew3a-A5yc-H49M-R1NP-y4qg4T
>
> --- Logical volume ---
> LV Name /dev/smbdata/all
> VG Name smbdata
> LV Write Access read/write
> LV Status available
> LV # 1
> # open 0
> LV Size 15.86 GB
> Current LE 4060
> Allocated LE 4060
> Allocation next free
> Read ahead sectors 120
> Block device 58:0
>
>
> --- Physical volume ---
> PV Name /dev/sda1
> VG Name smbdata
> PV Size 3.97 GB / NOT usable 3.28 MB [LVM: 124 KB]
> PV# 1
> PV Status NOT available
> Allocatable yes (but full)
> Cur LV 1
> PE Size (KByte) 4096
> Total PE 1015
> Free PE 0
> Allocated PE 1015
> PV UUID tFA0qy-8u7r-8oBv-MwYS-SUVM-1W7h-P3hHED
>
> --- Physical volume ---
> PV Name /dev/sdb1
> VG Name smbdata
> PV Size 3.97 GB / NOT usable 3.28 MB [LVM: 124 KB]
> PV# 2
> PV Status NOT available
> Allocatable yes (but full)
> Cur LV 1
> PE Size (KByte) 4096
> Total PE 1015
> Free PE 0
> Allocated PE 1015
> PV UUID cVeBuv-1i2C-hkOO-mUA1-lNrj-Vh8l-vrr6Am
>
> --- Physical volume ---
> PV Name /dev/sdc1
> VG Name smbdata
> PV Size 3.97 GB / NOT usable 3.28 MB [LVM: 124 KB]
> PV# 3
> PV Status NOT available
> Allocatable yes (but full)
> Cur LV 1
> PE Size (KByte) 4096
> Total PE 1015
> Free PE 0
> Allocated PE 1015
> PV UUID Rtuhx3-0HR9-V0hN-iLuZ-dkFL-hyih-cEwEII
>
> --- Physical volume ---
> PV Name /dev/sdd1
> VG Name smbdata
> PV Size 3.97 GB / NOT usable 3.28 MB [LVM: 124 KB]
> PV# 4
> PV Status NOT available
> Allocatable yes (but full)
> Cur LV 1
> PE Size (KByte) 4096
> Total PE 1015
> Free PE 0
> Allocated PE 1015
> PV UUID HNkTzu-Ok46-4vqM-CJCu-Iqd1-JmQ4-c5yzea
>
>
> Could anyone provide me some help?
Please run:
# save your LVM metadata for later use
for d in /dev/sd[a-d]1; do
dd if=$d of=$d.VGDA count=512 bs=1k
done
# to recreate your PVs because vgcfgrestore needs that
pvcreate -ff /dev/sd[a-d]1
# restore the metadata from backup
for d in /dev/sd[a-d]1; do
vgcfgrestore -n smbdata -f /etc/lvmconf/smbdata.conf.7.old /dev/$d
done
# scan in the metadata
vgscan
# activate the VG
vgchange -ay smbdata
>
> Thanx
>
> Matthias
--
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@Sistina.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply
* [parisc-linux] Problems with lasi_82596.c [CONFIG_IOMMU_CCIO]
From: Carlos O'Donell Jr. @ 2002-01-15 5:51 UTC (permalink / raw)
To: parisc-linux
PA,
Maybe I'm playing too quickly (recent CVS slurp, 2.4.17-pa10)
Compling kernel.
./include/asm-parisc/pci.h
248 #ifdef CONFIG_IOMMU_CCIO
249 struct parisc_device;
250 struct ioc;
251 void * ccio_get_iommu(struct parisc_device *dev);
252 struct pci_dev * ccio_get_fake(struct parisc_device *dev);
253 void ccio_extend_mmio_range(struct ioc *ioc);
254 struct resource * ccio_find_parisc_resource(struct parisc_device *dev);
255 #else /* !CONFIG_IOMMU_CCIO */
256 #define ccio_get_iommu(dev) do { } while (0)
--> 257 #define ccio_get_fake(dev) do { } while (0)
258 #define ccio_extend_mmio_range(ioc) do { } while (0)
259 #define ccio_find_parisc_resource(x) &iomem_resource
260 #endif /* !CONFIG_IOMMU_CCIO */
Which is included by lasi_82596.c there are some alternate
defines for the case where there is no IOMMU.
However in the lasi_82596 driver we see...
./drivers/net/lasi_82596.c
1510 static int __devinit
1511 lan_init_chip(struct parisc_device *dev)
1512 {
1513 struct net_device *netdevice;
1514 int retval;
1515
1516 if (num_drivers >= MAX_DRIVERS) {
1517 /* max count of possible i82596 drivers reached */
1518 return -ENODEV;
1519 }
1520
-> 1521 fake_pci_dev = ccio_get_fake(dev);
1522
1523 if (!dev->irq) {
1524 printk(KERN_ERR __FILE__ ": IRQ not found for i82596 at 0x%lx\n", dev->hpa);
1525 return -ENODEV;
1526 }
Which on line 1521 clearly relies on ccio_get_fake(dev) to return
a value... and thus causing the kernel build to fail without any
IOMMU. Is this correct?
When the config option says:
CONFIG_IOMMU_CCIO:
The U2/UTurn is a bus converter with io mmu present in the Cxxx, D,
J, K, and R class machines. Compiling this driver into the kernel will
not hurt anything, removing it will reduce your kernel by about 14k.
If unsure, say Y.
Does a 715/50 have a U2/UTurn IOMMU or anything similar?
(Currently perusing docs)
The kernel does compile with this option on... but it won't with
the option off. Any directions? Change the define to return some value?
c.
^ permalink raw reply
* Re: [PATCH] page coloring for 2.4.17 kernel
From: Jason Papadopoulos @ 2002-01-15 4:55 UTC (permalink / raw)
To: Stephen C. Tweedie; +Cc: linux-mm
In-Reply-To: <20020114224603.N5057@redhat.com>
At 10:46 PM 1/14/02 +0000, you wrote:
>> Hello. Please be patient with this, my first post to linux-mm.
>> The included patch modifies the free list in the 2.4.17 kernel
>> to support round-robin page coloring. It seems to work okay
>> on an Alpha and speeds up a lot of number-crunching code I
>> have lying around (lmbench reports some higher bandwidths too).
>> The patch is a port of the 2.2.20 version that I recently posted
>> to the linux kernelmailing list.
>
>Do you have numbers to show the sort of performance difference it
>makes?
It's a little difficult to tell with lmbench, since results can vary
slightly from run to run. The following numbers seem to be fairly
repeatable (DS10 Alphaserver with 466MHz ev6 processor and 2MB L2 cache).
The 2.2.20 numbers are with the original page coloring patch, the first
2.4.17 numbers are for the unpatched kernel and the second set uses
page coloring.
*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP
ctxsw UNIX UDP TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
alpha-lin Linux 2.2.20 1 6 15 22 39
alpha-lin Linux 2.4.17 1 8 20 38 64 212
alpha-lin Linux 2.4.17 1 11 19 28 37 163
File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host OS 0K File 10K File Mmap Prot Page
Create Delete Create Delete Latency Fault Fault
--------- ------------- ------ ------ ------ ------ ------- ----- -----
alpha-lin Linux 2.2.20 6 1 13 1 9699 1 0.7K
alpha-lin Linux 2.4.17 3 0 9 2 619 0 0.0K
alpha-lin Linux 2.4.17 3 0 10 2 624 0 0.0K
*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
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
alpha-lin Linux 2.2.20 261 255 -1 189 370 262 209 370 330
alpha-lin Linux 2.4.17 373 327 137 203 370 268 208 371 335
alpha-lin Linux 2.4.17 362 371 196 259 371 262 203 370 332
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
---------------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Guesses
--------- ------------- --- ---- ---- -------- -------
alpha-lin Linux 2.2.20 461 6 32 199
alpha-lin Linux 2.4.17 462 6 75 199
alpha-lin Linux 2.4.17 462 6 32 199
For computational workloads whose working set fit in L2 it makes a
huge difference (I've seen 30% speedups in FFT benchmarks). Kernel
compiles also seem to go 1-2% faster. I also have a memory latency
tester written in assembly language for the ev6, and without the
patch it seems you can only get high bandwidth out of L2 for working
sets of about 256k in size. With page coloring turned on you get
constant high memory bandwidth all the way out to the full L2 cache
size.
It would be interesting to see how i386 machines benefit from page
coloring, since they have very fast but somewhat tiny L2 caches with
high associativity.
jasonp
--
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: [RFC][PATCH] cleanup file.h and INIT_TASK a bit
From: Alexander Viro @ 2002-01-15 4:50 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Linus Torvalds, linux-kernel
In-Reply-To: <20020114233512.M30639@redhat.com>
On Mon, 14 Jan 2002, Benjamin LaHaise wrote:
> Resend. Several people pointed out they like the cleanup, nobody complained.
>
> On Sun, Jan 13, 2002 at 06:59:47PM -0500, Benjamin LaHaise wrote:
> > This patches does a couple of things: first off, it removes the sched.h
> > include from file.h that was added recently, as we really don't need yet
> > another include file chain mess. To make this a bit more palatable, a
> > few of the inlines are moved out of file.h and into fcntl.c, plus the
> > files_struct is moved to file.h from sched.h. Since this meant adding
> > file.h to the various arch/*/kernel/init_task.c files, I took the time
> > to move the INIT_* bits for initializing the init task out of sched.h
> > and into init_task.h. If this is okay, please apply the patch. There
> > are other cleanups to do if people are interested: the #define for init_task
> > is currently duplicated in *all* asm-*/processor.h files to be exactly
> > the same thing... This is a way of testing the waters on include file
> > cleanups. Done properly, they shave ~10-15% off of the kernel compile
> > time on my machine.
> >
> > Oh, the file.h cleanup exposed a mess (bug): usb.c was duplicating code
> > from daemonize().
Please, split it in two chunks - init_task.h stuff and everything else.
The former is obviously good thing, the latter may need more - I understand
why you do the #define tricks, but I'm less than sure that it's the best
way.
As for the USB... There is a bunch of other places that should do
daemonize() - I'll dig the patch out and send it.
^ permalink raw reply
* Re: New network monitoring proc file.
From: David S. Miller @ 2002-01-15 4:47 UTC (permalink / raw)
To: fds; +Cc: netdev, ak, kuznet, linux-kernel
In-Reply-To: <20020114234525.4C84B77BB@bulldog.sacerdoti.org>
From: Federico David Sacerdoti <fds@cs.ucsd.edu>
Date: Mon, 14 Jan 2002 15:48:26 -0800
I would like to submit a patch that adds a /proc file to the kernel which
monitors the health of active TCP connections. It does this by counting
the number of duplicate ACKs sent out, among other things.
I have a website detailing the exact metrics used and why I choose them:
http://heron.ucsd.edu/tcphealth/
I would rather that you add this to the tcp_diag facility in
2.4.x instead of creating yet another proc file. tcp_diag is
designed perfectly for fetching the kind of information your
TCP health monitor is providing.
This is irregardless of whether your selection of health metrics is
sound or not, I have not looked into this part at all. But it will
have to be discussed before we think about adding the changes.
^ permalink raw reply
* Re: Linux-2.5.2
From: Davide Libenzi @ 2002-01-15 4:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
In-Reply-To: <Pine.LNX.4.33.0201141840070.2544-100000@penguin.transmeta.com>
On Mon, 14 Jan 2002, Linus Torvalds wrote:
>
> Ok, lots of various changes between 2.5.1->2, mainly in bio, kdev_t and
> scheduler (and several USB updates).
Linus, i've a weird behavior with 2.5.2
swapon first fails at boot ( early stage ) then it succeed ( late boot
stage ) but the swap is not actually activated. Running swapon by hand it
reports a seccessful operation but the swap is not on.
I'm trying to understand what is happening ...
- Davide
^ permalink raw reply
* Re: [RFC][PATCH] cleanup file.h and INIT_TASK a bit
From: Benjamin LaHaise @ 2002-01-15 4:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
In-Reply-To: <20020113185947.A32700@redhat.com>
Resend. Several people pointed out they like the cleanup, nobody complained.
On Sun, Jan 13, 2002 at 06:59:47PM -0500, Benjamin LaHaise wrote:
> This patches does a couple of things: first off, it removes the sched.h
> include from file.h that was added recently, as we really don't need yet
> another include file chain mess. To make this a bit more palatable, a
> few of the inlines are moved out of file.h and into fcntl.c, plus the
> files_struct is moved to file.h from sched.h. Since this meant adding
> file.h to the various arch/*/kernel/init_task.c files, I took the time
> to move the INIT_* bits for initializing the init task out of sched.h
> and into init_task.h. If this is okay, please apply the patch. There
> are other cleanups to do if people are interested: the #define for init_task
> is currently duplicated in *all* asm-*/processor.h files to be exactly
> the same thing... This is a way of testing the waters on include file
> cleanups. Done properly, they shave ~10-15% off of the kernel compile
> time on my machine.
>
> Oh, the file.h cleanup exposed a mess (bug): usb.c was duplicating code
> from daemonize().
-ben
:r ~/patches/v2.5.2-pre11-file_init.diff
diff -urN v2.5.2/arch/arm/kernel/init_task.c v2.5.2-file_init/arch/arm/kernel/init_task.c
--- v2.5.2/arch/arm/kernel/init_task.c Mon Jan 14 22:49:50 2002
+++ v2.5.2-file_init/arch/arm/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -5,6 +5,7 @@
#include <linux/fs.h>
#include <linux/sched.h>
#include <linux/init.h>
+#include <linux/init_task.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/arch/i386/kernel/init_task.c v2.5.2-file_init/arch/i386/kernel/init_task.c
--- v2.5.2/arch/i386/kernel/init_task.c Mon Sep 17 18:29:09 2001
+++ v2.5.2-file_init/arch/i386/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -1,6 +1,7 @@
#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/init.h>
+#include <linux/init_task.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/arch/ia64/kernel/init_task.c v2.5.2-file_init/arch/ia64/kernel/init_task.c
--- v2.5.2/arch/ia64/kernel/init_task.c Mon Sep 17 18:29:09 2001
+++ v2.5.2-file_init/arch/ia64/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -9,6 +9,7 @@
#include <linux/init.h>
#include <linux/mm.h>
#include <linux/sched.h>
+#include <linux/init_task.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/arch/mips/kernel/init_task.c v2.5.2-file_init/arch/mips/kernel/init_task.c
--- v2.5.2/arch/mips/kernel/init_task.c Mon Sep 17 18:29:09 2001
+++ v2.5.2-file_init/arch/mips/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -1,5 +1,6 @@
#include <linux/mm.h>
#include <linux/sched.h>
+#include <linux/init_task.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/arch/mips64/kernel/init_task.c v2.5.2-file_init/arch/mips64/kernel/init_task.c
--- v2.5.2/arch/mips64/kernel/init_task.c Mon Sep 17 18:29:09 2001
+++ v2.5.2-file_init/arch/mips64/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -1,5 +1,6 @@
#include <linux/mm.h>
#include <linux/sched.h>
+#include <linux/init_task.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/arch/parisc/kernel/init_task.c v2.5.2-file_init/arch/parisc/kernel/init_task.c
--- v2.5.2/arch/parisc/kernel/init_task.c Mon Sep 17 18:29:09 2001
+++ v2.5.2-file_init/arch/parisc/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -1,6 +1,7 @@
#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/init.h>
+#include <linux/init_task.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/arch/s390/kernel/init_task.c v2.5.2-file_init/arch/s390/kernel/init_task.c
--- v2.5.2/arch/s390/kernel/init_task.c Fri Nov 9 16:58:02 2001
+++ v2.5.2-file_init/arch/s390/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -8,6 +8,7 @@
#include <linux/mm.h>
#include <linux/sched.h>
+#include <linux/init_task.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/arch/s390x/kernel/init_task.c v2.5.2-file_init/arch/s390x/kernel/init_task.c
--- v2.5.2/arch/s390x/kernel/init_task.c Fri Nov 9 16:58:02 2001
+++ v2.5.2-file_init/arch/s390x/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -8,6 +8,7 @@
#include <linux/mm.h>
#include <linux/sched.h>
+#include <linux/init_task.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/arch/sh/kernel/init_task.c v2.5.2-file_init/arch/sh/kernel/init_task.c
--- v2.5.2/arch/sh/kernel/init_task.c Wed Jan 2 19:32:34 2002
+++ v2.5.2-file_init/arch/sh/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -1,6 +1,7 @@
#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/init.h>
+#include <linux/init_task.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/arch/sparc/kernel/init_task.c v2.5.2-file_init/arch/sparc/kernel/init_task.c
--- v2.5.2/arch/sparc/kernel/init_task.c Mon Jan 14 22:49:51 2002
+++ v2.5.2-file_init/arch/sparc/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -1,5 +1,6 @@
#include <linux/mm.h>
#include <linux/sched.h>
+#include <linux/init_task.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
diff -urN v2.5.2/arch/sparc64/kernel/init_task.c v2.5.2-file_init/arch/sparc64/kernel/init_task.c
--- v2.5.2/arch/sparc64/kernel/init_task.c Thu Sep 20 17:11:57 2001
+++ v2.5.2-file_init/arch/sparc64/kernel/init_task.c Mon Jan 14 22:58:58 2002
@@ -1,5 +1,6 @@
#include <linux/mm.h>
#include <linux/sched.h>
+#include <linux/init_task.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
diff -urN v2.5.2/drivers/usb/storage/usb.c v2.5.2-file_init/drivers/usb/storage/usb.c
--- v2.5.2/drivers/usb/storage/usb.c Mon Jan 14 22:49:52 2002
+++ v2.5.2-file_init/drivers/usb/storage/usb.c Mon Jan 14 22:58:58 2002
@@ -314,9 +314,6 @@
* This thread doesn't need any user-level access,
* so get rid of all our resources..
*/
- exit_files(current);
- current->files = init_task.files;
- atomic_inc(¤t->files->count);
daemonize();
/* set our name for identification purposes */
diff -urN v2.5.2/fs/fcntl.c v2.5.2-file_init/fs/fcntl.c
--- v2.5.2/fs/fcntl.c Mon Sep 17 16:16:30 2001
+++ v2.5.2-file_init/fs/fcntl.c Mon Jan 14 22:58:58 2002
@@ -20,6 +20,28 @@
extern int fcntl_setlease(unsigned int fd, struct file *filp, long arg);
extern int fcntl_getlease(struct file *filp);
+void set_close_on_exec(unsigned int fd, int flag)
+{
+ struct files_struct *files = current->files;
+ write_lock(&files->file_lock);
+ if (flag)
+ FD_SET(fd, files->close_on_exec);
+ else
+ FD_CLR(fd, files->close_on_exec);
+ write_unlock(&files->file_lock);
+}
+
+static inline int get_close_on_exec(unsigned int fd)
+{
+ struct files_struct *files = current->files;
+ int res;
+ read_lock(&files->file_lock);
+ res = FD_ISSET(fd, files->close_on_exec);
+ read_unlock(&files->file_lock);
+ return res;
+}
+
+
/* Expand files. Return <0 on error; 0 nothing done; 1 files expanded,
* we may have blocked.
*
diff -urN v2.5.2/fs/file.c v2.5.2-file_init/fs/file.c
--- v2.5.2/fs/file.c Fri Feb 9 14:29:44 2001
+++ v2.5.2-file_init/fs/file.c Mon Jan 14 22:58:58 2002
@@ -11,6 +11,7 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
+#include <linux/file.h>
#include <asm/bitops.h>
diff -urN v2.5.2/fs/proc/array.c v2.5.2-file_init/fs/proc/array.c
--- v2.5.2/fs/proc/array.c Mon Jan 14 22:49:53 2002
+++ v2.5.2-file_init/fs/proc/array.c Mon Jan 14 22:58:58 2002
@@ -70,6 +70,7 @@
#include <linux/smp.h>
#include <linux/signal.h>
#include <linux/highmem.h>
+#include <linux/file.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/include/linux/file.h v2.5.2-file_init/include/linux/file.h
--- v2.5.2/include/linux/file.h Mon Jan 14 22:49:53 2002
+++ v2.5.2-file_init/include/linux/file.h Mon Jan 14 22:58:58 2002
@@ -5,31 +5,39 @@
#ifndef __LINUX_FILE_H
#define __LINUX_FILE_H
-#include <linux/sched.h>
+#ifndef _LINUX_POSIX_TYPES_H /* __FD_CLR */
+#include <linux/posix_types.h>
+#endif
+#ifndef __LINUX_COMPILER_H /* unlikely */
+#include <linux/compiler.h>
+#endif
+
+/*
+ * The default fd array needs to be at least BITS_PER_LONG,
+ * as this is the granularity returned by copy_fdset().
+ */
+#define NR_OPEN_DEFAULT BITS_PER_LONG
+
+/*
+ * Open file table structure
+ */
+struct files_struct {
+ atomic_t count;
+ rwlock_t file_lock; /* Protects all the below members. Nests inside tsk->alloc_lock */
+ int max_fds;
+ int max_fdset;
+ int next_fd;
+ struct file ** fd; /* current fd array */
+ fd_set *close_on_exec;
+ fd_set *open_fds;
+ fd_set close_on_exec_init;
+ fd_set open_fds_init;
+ struct file * fd_array[NR_OPEN_DEFAULT];
+};
extern void FASTCALL(fput(struct file *));
extern struct file * FASTCALL(fget(unsigned int fd));
-
-static inline int get_close_on_exec(unsigned int fd)
-{
- struct files_struct *files = current->files;
- int res;
- read_lock(&files->file_lock);
- res = FD_ISSET(fd, files->close_on_exec);
- read_unlock(&files->file_lock);
- return res;
-}
-
-static inline void set_close_on_exec(unsigned int fd, int flag)
-{
- struct files_struct *files = current->files;
- write_lock(&files->file_lock);
- if (flag)
- FD_SET(fd, files->close_on_exec);
- else
- FD_CLR(fd, files->close_on_exec);
- write_unlock(&files->file_lock);
-}
+extern void FASTCALL(set_close_on_exec(unsigned int fd, int flag));
static inline struct file * fcheck_files(struct files_struct *files, unsigned int fd)
{
@@ -43,15 +51,7 @@
/*
* Check whether the specified fd has an open file.
*/
-static inline struct file * fcheck(unsigned int fd)
-{
- struct file * file = NULL;
- struct files_struct *files = current->files;
-
- if (fd < files->max_fds)
- file = files->fd[fd];
- return file;
-}
+#define fcheck(fd) fcheck_files(current->files, fd)
extern void put_filp(struct file *);
@@ -59,19 +59,18 @@
static inline void __put_unused_fd(struct files_struct *files, unsigned int fd)
{
- FD_CLR(fd, files->open_fds);
+ __FD_CLR(fd, files->open_fds);
if (fd < files->next_fd)
files->next_fd = fd;
}
-static inline void put_unused_fd(unsigned int fd)
+static inline void put_unused_fd_files(struct files_struct *files, unsigned int fd)
{
- struct files_struct *files = current->files;
-
write_lock(&files->file_lock);
__put_unused_fd(files, fd);
write_unlock(&files->file_lock);
}
+#define put_unused_fd(fd) put_unused_fd_files(current->files, fd)
/*
* Install a file pointer in the fd array.
@@ -86,16 +85,16 @@
* will follow.
*/
-static inline void fd_install(unsigned int fd, struct file * file)
+static inline void fd_install_files(struct files_struct *files,
+ unsigned int fd, struct file * file)
{
- struct files_struct *files = current->files;
-
write_lock(&files->file_lock);
- if (files->fd[fd])
+ if (unlikely(files->fd[fd] != NULL))
BUG();
files->fd[fd] = file;
write_unlock(&files->file_lock);
}
+#define fd_install(fd, file) fd_install_files(current->files, fd, file)
void put_files_struct(struct files_struct *fs);
diff -urN v2.5.2/include/linux/init_task.h v2.5.2-file_init/include/linux/init_task.h
--- v2.5.2/include/linux/init_task.h Wed Dec 31 19:00:00 1969
+++ v2.5.2-file_init/include/linux/init_task.h Mon Jan 14 22:58:58 2002
@@ -0,0 +1,88 @@
+#ifndef _LINUX__INIT_TASK_H
+#define _LINUX__INIT_TASK_H
+
+#ifndef __LINUX_FILE_H
+#include <linux/file.h>
+#endif
+
+#define INIT_FILES \
+{ \
+ count: ATOMIC_INIT(1), \
+ file_lock: RW_LOCK_UNLOCKED, \
+ max_fds: NR_OPEN_DEFAULT, \
+ max_fdset: __FD_SETSIZE, \
+ next_fd: 0, \
+ fd: &init_files.fd_array[0], \
+ close_on_exec: &init_files.close_on_exec_init, \
+ open_fds: &init_files.open_fds_init, \
+ close_on_exec_init: { { 0, } }, \
+ open_fds_init: { { 0, } }, \
+ fd_array: { NULL, } \
+}
+
+#define INIT_MM(name) \
+{ \
+ mm_rb: RB_ROOT, \
+ pgd: swapper_pg_dir, \
+ mm_users: ATOMIC_INIT(2), \
+ mm_count: ATOMIC_INIT(1), \
+ mmap_sem: __RWSEM_INITIALIZER(name.mmap_sem), \
+ page_table_lock: SPIN_LOCK_UNLOCKED, \
+ mmlist: LIST_HEAD_INIT(name.mmlist), \
+}
+
+#define INIT_SIGNALS { \
+ count: ATOMIC_INIT(1), \
+ action: { {{0,}}, }, \
+ siglock: SPIN_LOCK_UNLOCKED \
+}
+
+/*
+ * INIT_TASK is used to set up the first task table, touch at
+ * your own risk!. Base=0, limit=0x1fffff (=2MB)
+ */
+#define INIT_TASK(tsk) \
+{ \
+ state: 0, \
+ flags: 0, \
+ sigpending: 0, \
+ addr_limit: KERNEL_DS, \
+ exec_domain: &default_exec_domain, \
+ lock_depth: -1, \
+ __nice: DEF_USER_NICE, \
+ policy: SCHED_OTHER, \
+ cpus_allowed: -1, \
+ mm: NULL, \
+ active_mm: &init_mm, \
+ run_list: LIST_HEAD_INIT(tsk.run_list), \
+ time_slice: PRIO_TO_TIMESLICE(DEF_PRIO), \
+ next_task: &tsk, \
+ prev_task: &tsk, \
+ p_opptr: &tsk, \
+ p_pptr: &tsk, \
+ thread_group: LIST_HEAD_INIT(tsk.thread_group), \
+ wait_chldexit: __WAIT_QUEUE_HEAD_INITIALIZER(tsk.wait_chldexit),\
+ real_timer: { \
+ function: it_real_fn \
+ }, \
+ cap_effective: CAP_INIT_EFF_SET, \
+ cap_inheritable: CAP_INIT_INH_SET, \
+ cap_permitted: CAP_FULL_SET, \
+ keep_capabilities: 0, \
+ rlim: INIT_RLIMITS, \
+ user: INIT_USER, \
+ comm: "swapper", \
+ thread: INIT_THREAD, \
+ fs: &init_fs, \
+ files: &init_files, \
+ sigmask_lock: SPIN_LOCK_UNLOCKED, \
+ sig: &init_signals, \
+ pending: { NULL, &tsk.pending.head, {{0}}}, \
+ blocked: {{0}}, \
+ alloc_lock: SPIN_LOCK_UNLOCKED, \
+ journal_info: NULL, \
+}
+
+
+
+#endif
diff -urN v2.5.2/include/linux/sched.h v2.5.2-file_init/include/linux/sched.h
--- v2.5.2/include/linux/sched.h Mon Jan 14 22:49:53 2002
+++ v2.5.2-file_init/include/linux/sched.h Mon Jan 14 23:00:50 2002
@@ -156,44 +156,7 @@
extern int start_context_thread(void);
extern int current_is_keventd(void);
-/*
- * The default fd array needs to be at least BITS_PER_LONG,
- * as this is the granularity returned by copy_fdset().
- */
-#define NR_OPEN_DEFAULT BITS_PER_LONG
-
struct namespace;
-/*
- * Open file table structure
- */
-struct files_struct {
- atomic_t count;
- rwlock_t file_lock; /* Protects all the below members. Nests inside tsk->alloc_lock */
- int max_fds;
- int max_fdset;
- int next_fd;
- struct file ** fd; /* current fd array */
- fd_set *close_on_exec;
- fd_set *open_fds;
- fd_set close_on_exec_init;
- fd_set open_fds_init;
- struct file * fd_array[NR_OPEN_DEFAULT];
-};
-
-#define INIT_FILES \
-{ \
- count: ATOMIC_INIT(1), \
- file_lock: RW_LOCK_UNLOCKED, \
- max_fds: NR_OPEN_DEFAULT, \
- max_fdset: __FD_SETSIZE, \
- next_fd: 0, \
- fd: &init_files.fd_array[0], \
- close_on_exec: &init_files.close_on_exec_init, \
- open_fds: &init_files.open_fds_init, \
- close_on_exec_init: { { 0, } }, \
- open_fds_init: { { 0, } }, \
- fd_array: { NULL, } \
-}
/* Maximum number of active map areas.. This is a random (large) number */
#define MAX_MAP_COUNT (65536)
@@ -230,17 +193,6 @@
extern int mmlist_nr;
-#define INIT_MM(name) \
-{ \
- mm_rb: RB_ROOT, \
- pgd: swapper_pg_dir, \
- mm_users: ATOMIC_INIT(2), \
- mm_count: ATOMIC_INIT(1), \
- mmap_sem: __RWSEM_INITIALIZER(name.mmap_sem), \
- page_table_lock: SPIN_LOCK_UNLOCKED, \
- mmlist: LIST_HEAD_INIT(name.mmlist), \
-}
-
struct signal_struct {
atomic_t count;
struct k_sigaction action[_NSIG];
@@ -248,12 +200,6 @@
};
-#define INIT_SIGNALS { \
- count: ATOMIC_INIT(1), \
- action: { {{0,}}, }, \
- siglock: SPIN_LOCK_UNLOCKED \
-}
-
/*
* Some day this will be a full-fledged user tracking system..
*/
@@ -505,53 +451,6 @@
*/
extern struct exec_domain default_exec_domain;
-/*
- * INIT_TASK is used to set up the first task table, touch at
- * your own risk!. Base=0, limit=0x1fffff (=2MB)
- */
-#define INIT_TASK(tsk) \
-{ \
- state: 0, \
- flags: 0, \
- sigpending: 0, \
- addr_limit: KERNEL_DS, \
- exec_domain: &default_exec_domain, \
- lock_depth: -1, \
- __nice: DEF_USER_NICE, \
- policy: SCHED_OTHER, \
- cpus_allowed: -1, \
- mm: NULL, \
- active_mm: &init_mm, \
- run_list: LIST_HEAD_INIT(tsk.run_list), \
- time_slice: PRIO_TO_TIMESLICE(DEF_PRIO), \
- next_task: &tsk, \
- prev_task: &tsk, \
- p_opptr: &tsk, \
- p_pptr: &tsk, \
- thread_group: LIST_HEAD_INIT(tsk.thread_group), \
- wait_chldexit: __WAIT_QUEUE_HEAD_INITIALIZER(tsk.wait_chldexit),\
- real_timer: { \
- function: it_real_fn \
- }, \
- cap_effective: CAP_INIT_EFF_SET, \
- cap_inheritable: CAP_INIT_INH_SET, \
- cap_permitted: CAP_FULL_SET, \
- keep_capabilities: 0, \
- rlim: INIT_RLIMITS, \
- user: INIT_USER, \
- comm: "swapper", \
- thread: INIT_THREAD, \
- fs: &init_fs, \
- files: &init_files, \
- sigmask_lock: SPIN_LOCK_UNLOCKED, \
- sig: &init_signals, \
- pending: { NULL, &tsk.pending.head, {{0}}}, \
- blocked: {{0}}, \
- alloc_lock: SPIN_LOCK_UNLOCKED, \
- journal_info: NULL, \
-}
-
-
#ifndef INIT_TASK_SIZE
# define INIT_TASK_SIZE 2048*sizeof(long)
#endif
diff -urN v2.5.2/kernel/exit.c v2.5.2-file_init/kernel/exit.c
--- v2.5.2/kernel/exit.c Mon Jan 14 22:49:53 2002
+++ v2.5.2-file_init/kernel/exit.c Mon Jan 14 22:58:58 2002
@@ -17,6 +17,7 @@
#ifdef CONFIG_BSD_PROCESS_ACCT
#include <linux/acct.h>
#endif
+#include <linux/file.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
diff -urN v2.5.2/kernel/fork.c v2.5.2-file_init/kernel/fork.c
--- v2.5.2/kernel/fork.c Mon Jan 14 22:49:53 2002
+++ v2.5.2-file_init/kernel/fork.c Mon Jan 14 22:58:58 2002
@@ -21,6 +21,7 @@
#include <linux/completion.h>
#include <linux/namespace.h>
#include <linux/personality.h>
+#include <linux/file.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
diff -urN v2.5.2/kernel/kmod.c v2.5.2-file_init/kernel/kmod.c
--- v2.5.2/kernel/kmod.c Mon Jan 14 22:49:53 2002
+++ v2.5.2-file_init/kernel/kmod.c Mon Jan 14 22:58:58 2002
@@ -27,6 +27,7 @@
#include <linux/slab.h>
#include <linux/namespace.h>
#include <linux/completion.h>
+#include <linux/file.h>
#include <asm/uaccess.h>
^ permalink raw reply
* Re: [PATCH] fbdev currcon
From: James Simmons @ 2002-01-15 4:26 UTC (permalink / raw)
To: Russell King
Cc: Geert Uytterhoeven, Linux Fbdev development list,
Linux Kernel Mailing List
In-Reply-To: <20020115005650.J23429@flint.arm.linux.org.uk>
> On Mon, Jan 14, 2002 at 04:39:43PM -0800, James Simmons wrote:
> > [stuff about currcon]
>
> I've killed currcon completely in the cyber2000fb driver in favour of
> tracking which struct display is current. Tracking 'currcon', doing
> a whole pile of special cases, and copying 'var' stuff to/from fb.var
> didn't make sense anymore. I'm expecting the same thing will happen
> with the other stuff in the struct fb_info.
But struct display is going to go away!!!!!! You haven't seen the complete
new fbdev api. How much cleaner and superior to the current stuff.
http://linuxconsole.sf.net
The whole point was to make the fbdev layer independent of the VT tty
system. It makes no sense to have a tty on something like a iPAQ. This way
you can a /dev/fb interface with no VT. You can also do other nice
things like have a vga console on one display and still have a fbdev
driver. Think about how much easier it would be to debug a fbdev driver
that way. BTW that is how I was testing the new fbdev api. Having printk
on a vga terminal will looking at printks while testing the fbdev driver.
It was so nice. Plus the amount of code reduction will be huge. I mean
huge.
Over the years the lower level console drivers have been building crude
to make up for the limitations of the upper console layer. This will be
cleaned up for 2.5.X. So now fbcon will be a wrapper around the fbdev
layer if we do want to use a VT. It will make a very nice small footprint
for embedded systems. BTW this was my goal. Another bonus will be I will
make the VT system modular. So if we do want a VT we can :-) I haven't had
the time to do this but I plan to. I wanted to test it on a iPAQ with a
stowaway keyboard. Think about the power of insmod a keyboard driver,
fbcon.o and then insmod vt.o. Talk about having a even smaller kernel
image to put in a partition. Some devices only have 512K of space to
place a bootable kernel. As time goes on it is becoming harder and
harder to do this. Now we can!!!!!!
It just makes me excited thinking about it:-)
> (Think about the current cyber2000fb code, and what happens to other
> consoles when you fbset 800x600-60 -a and then switch to them to
> discover you only have a 640x480 window where the characters appear).
This will be fixed and very soon. Trust me.
P.S
currcon is a temporary step to deal with the issue of only one foreground
console. It will also GO AWAY as the console system is truly fixed to
support multiple desktops. Yes I have such a system at home so it is
possible. The only reason I'm doing it this way is so when I start
changing the console layer I don't have to rewrite ever single fbdev
driver. Or do you think I should rework the console layer first.
^ permalink raw reply
* devfsd-v1.3.21 available
From: Richard Gooch @ 2002-01-15 4:22 UTC (permalink / raw)
To: linux-kernel, devfs-announce-list
Hi, all. I've just released version 1.3.21 of my devfsd (devfs
daemon) at: http://www.atnf.csiro.au/~rgooch/linux/
Tarball directly available from:
ftp://ftp.??.kernel.org/pub/linux/daemons/devfsd/devfsd.tar.gz
AND:
ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/daemons/devfsd/devfsd.tar.gz
This works with devfs-patch-v130, kernel 2.3.46 and devfs-patch-v99.7
(or later).
The main changes are:
- GNUmakefile changes
- Created INSTALL file
- Man page improvements
- Switched to extended regular expression support
- Fixed dummy opens of /dev/null
- Sample devfsd.conf updated to use mksymlink().
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
^ permalink raw reply
* RE: [linux-lvm] pvcreate error
From: Yves Alloyer @ 2002-01-15 4:13 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <5E34D857F6BB704CA3369B7553233A81651ACA@ntsviemxs0152.connect.at-work.ent>
Hi Csuk,
1.0.1rc4 is not the latest. I ran into the same problem because when it sees
an md device, no matter the raid level, it thinks the device has a partition
table which is wrong. These device are always used as a whole.
To fix the problem you may either upgrade to 1.0.1 or just have a look at
the thread
"[linux-lvm] pvcreate fails on a software RAID metadisk". It describes a
patch from Luca Berra and me:
--- tools/lib/lvm_check_partitioned_dev.c.bluca Thu Aug 23 07:51:53 2001
+++ tools/lib/lvm_check_partitioned_dev.c Fri Oct 5 21:18:51 2001
@@ -55,6 +55,8 @@
switch (lvm_get_device_type(st_rdev)) {
case LVM_DEVICE_TYPE_INVALID:
break;
+ case LVM_DEVICE_TYPE_MD:
+ break;
default:
ret = TRUE;
}
Yves
-----Original Message-----
From: linux-lvm-admin@sistina.com [mailto:linux-lvm-admin@sistina.com]On
Behalf Of Csuk, Ferenc
Sent: Monday, January 14, 2002 9:32 PM
To: linux-lvm@sistina.com
Subject: [linux-lvm] pvcreate error
Dear All,
I made a typing error in my question. Each line of the error message is
related to /dev/md2 instead of /dev/md7.
I just installed a new system and I installed the latest 2.4.16 kernel and
the latest LVM tool 1.0.1-rc4. I established a software RAID-5 device(md)
and wanted to create a logical volume group on it(as I did with 2.4.7 kernel
on another system). However, when I issued the command I got the following
error:
# pvcreate -v /dev/md2
pvcreate -- locking logical volume manager
> pvcreate -- checking physical volume name "/dev/md2"
> pvcreate -- getting physical volume size
> pvcreate -- checking partition type
> pvcreate -- creating new physical volume
> pvcreate -- setting up physical volume for /dev/md2 with 0 sectors
> pvcreate -- ERROR "parameter error" setting up physical volume "/dev/md2"
I checked the archives where I saw suggestion to patch the LVM tool, but I
don�t think that is related to the latest version.
What is the problem? Should I downgrade to 2.4.7?
Thanks in advance,
Ferenc
^ permalink raw reply
* Re: [RFC] klibc requirements, round 2
From: Oliver Xymoron @ 2002-01-15 4:05 UTC (permalink / raw)
To: Andreas Dilger
Cc: Theodore Tso, Juan Quintela, Greg KH, linux-kernel,
felix-dietlibc, andersen
In-Reply-To: <20020114204830.E26688@lynx.adilger.int>
On Mon, 14 Jan 2002, Andreas Dilger wrote:
> > Interesting point. Modulo any existing LVM brokenness, we can do this with
> > a read-only snapshot and pivot_root afterwards. Alternately, a read-only
> > /bootsupport or something of the sort which contains *fsck. What we don't
> > want is initramfs to get big.
>
> Err, you think putting the necessary LVM tools in initramfs (vgscan,
> vgchange, lvcreate, liblvm) will be _smaller_ than e2fsck???
No, I forgot about that dependency entirely. Doh.
> Your "modulo" is also a very big one - I'd rather trust e2fsck than LVM
> in my boot environment any day.
Fair enough. The deeper point is that the purpose of initramfs is to move
stuff out of the kernel in to userland. Ergo, this all becomes a
non-kernel issue. We do not want to be in the business here of packaging
things into the ramfs archives, we rather want to give external tools and
distros all the info they need to make intelligent choices about how to
make the kernel bootable.
Let's just try to focus on what we're taking out of the kernel in this
process and not on all the nifty stuff that can now be added to the
initial boot process.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
^ permalink raw reply
* Significant Slowdown Occuring in 2.2 starting with 19pre2
From: Steve Sheftic @ 2002-01-15 4:02 UTC (permalink / raw)
To: linux-kernel
Hi,
I encountered a significant disk-write slowdown in the 2.2 kernel that
I've tracked to 2.2.19pre2. I do backups to a SCSI magneto-optical disk.
My /home backup creates a 700MB+ file (using BRU). When I was using
2.2.14, this took roughly a half hour. When I upgraded to 2.2.20, this
same backup started taking nearly 3 hours. Yes, same 700MB+ file size.
The table below shows the results of many tests with many kernels. For
2.2.14 through 2.2.19, the config is essentially identical (doing "make
oldconfig" and answering "No" to new stuff). The config for 2.2.20 and
2.2.21p2 is slightly different, but doesn't seem to be a factor. As you
can see, something happened in 2.2.19pre2 that led to this slowdown.
During these nearly 3 hour backups, the load number stayed at about 3
(with no user-level activity) and the Select light on the MO drive
glowed constantly. System response was poor during this time.
Minutes required to write MO disk vs. kernel version
(multiple tests)
Kernel Minutes
------ -------
2.2.14 29 33
2.2.15 31 30
2.2.16 67 78 <--- elapsed time more than doubled
2.2.17 22 23 22 <--- notable improvement
2.2.18 34 40
2.2.19p1 30 44
2.2.19p2 161 165 <--- 4x to 5x longer
2.2.19p5 168 (pre3,4 skipped - wouldn't build for me)
2.2.19 168 168
2.2.20 171
2.2.21p2 166
2.4.17 17 17 <--- Woohoo!! 2.4 is GREAT!!
Hardware
--------
Intel 430TX motherboard
Pentium (MMX)
192 MB memory
Advansys ABP940 SCSI controller (hosts the hard disks and MO drive)
Adaptec 2940 SCSI controller (hosts a scanner only)
(more details if requested)
The great news is that for 2.4.17, this backup is only taking 17
minutes! Now that I'm using 2.4, I'm ecstatic! :) However, I wanted to
provide my timing results regarding 2.2.
I also want to express my gratitude to all of you who contribute to this
marvelous OS that I enjoy so much. Thank you!
Steve Sheftic
^ permalink raw reply
* Re: Penelope builds a kernel
From: Tom Rini @ 2002-01-15 3:59 UTC (permalink / raw)
To: John Levon; +Cc: linux-kernel
In-Reply-To: <20020115020758.GA59418@compsoc.man.ac.uk>
On Tue, Jan 15, 2002 at 02:07:58AM +0000, John Levon wrote:
> On Mon, Jan 14, 2002 at 06:39:54PM -0700, Tom Rini wrote:
>
> > Wrong. She needs to compile a new module for her kernel. What might be
> > useful is some automagic tool that will find the vendor-provided kernel
> > source tree and config (which is usually /boot/config-`uname -r`, but
> > still findable anyhow)
>
> autoconf code already exists for this, it's a non-problem.
Er, why on earth is it 'autoconf' tho? This isn't something that's
necessaryily a CONFIG_xxx issue, it's a 'compile this for me' issue.
> Note they must use
> the config in the header file of the vendor-provided kernel source tree, not
> /boot/config-`uname -r`
And why wouldn't the two match? If you're running a vendor-provided
kernel, /boot/config-`uname -r` should be the config for the
vendor-provided kernel (and its source tree)...
> There are two cases:
>
> 1) the vendor source tree is installed and set up with the right config -> use header file
>
> 2) it's installed and the config has changed. -> use header file
2) should never happen. I'm not talking about a patch (like said what
i2c does traditionally), I'm talking about driver.[ch].
> I don't see a point in ever looking at /boot/config-`uname -r` instead of
> the source tree, given that we must compile against a tree configured like the
> eventual running kernel anyway.
Because they should be the same thing? And why do you mention 'eventual
running kernel'. There is a running kernel. Compile the module, load
the module, work. No reboot (or kernel recompile) needed.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [RFC] klibc requirements, round 2
From: Andreas Dilger @ 2002-01-15 3:48 UTC (permalink / raw)
To: Oliver Xymoron
Cc: Theodore Tso, Juan Quintela, Greg KH, linux-kernel,
felix-dietlibc, andersen
In-Reply-To: <Pine.LNX.4.44.0201141921580.2836-100000@waste.org>
On Jan 14, 2002 19:26 -0600, Oliver Xymoron wrote:
> On Mon, 14 Jan 2002, Andreas Dilger wrote:
> > Actually, the whole point of Juan's suggestion was that you _don't_ want
> > to fsck a filesystem that is currently mounted. There is always a
> > potential problem that fsck will change the on-disk data of the filesystem
> > in a way that is not coherent with what the kernel has in-memory, which
> > should force a system reboot before continuing (which most initscripts
> > don't do). For ext2/ext3 this may be relatively safe (data/metadata don't
> > move around much), but reiserfsck cannot (or will not) fsck a mounted
> > filesystem at all.
>
> Interesting point. Modulo any existing LVM brokenness, we can do this with
> a read-only snapshot and pivot_root afterwards. Alternately, a read-only
> /bootsupport or something of the sort which contains *fsck. What we don't
> want is initramfs to get big.
Err, you think putting the necessary LVM tools in initramfs (vgscan,
vgchange, lvcreate, liblvm) will be _smaller_ than e2fsck??? Your
"modulo" is also a very big one - I'd rather trust e2fsck than LVM
in my boot environment any day.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
^ permalink raw reply
* [parisc-linux] Re: [lug] serial breakout box
From: Allen Brown @ 2002-01-15 3:47 UTC (permalink / raw)
To: collver, lug, parisc-linux
The breakout box is probably most convenient. I've never had access
to one. But the first thing you need to determine is if you need
to crossover or not. You can do that with just a voltmeter.
Pin 7 is GND. Pins 2 and 3 are the input and outputs, not necessarily
in that order. Measure from 7 to 2. Measure from 7 to 3. One
of them will be close to 0V. The other will be much higher. I think
-10V or something like that. The pin with the higher voltage is
the output.
Do the same thing on the other system also using the 25 pin connector.
Then make sure you are not connecting the output to the output.
--
Allen Brown
work: Agilent Technologies non-work: http://www.peak.org/~abrown/
allen_brown@agilent.com abrown@peak.org
Where are we going? And what's with this hand basket? --- George Carlin
^ permalink raw reply
* 2.5.2 / IDE cdrom_read_intr: data underrun / end_request: I/O error
From: David Dyck @ 2002-01-15 3:46 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.33.0201120834140.672-100000@dd.tc.fluke.com>
I'm still getting data underrun errors using 2.5.2
that don't occur using 2.4.18-pre3.
Linux dd 2.5.2 #1 Mon Jan 14 19:02:09 PST 2002 i686
here's a section of dmesg output
VFS: Disk change detected on device ide1(22,0)
ISO 9660 Extensions: Microsoft Joliet Level 3
ISOFS: changing to secondary root
hdc: cdrom_read_intr: data underrun (4294967256 blocks)
end_request: I/O error, dev 16:00, sector 299300
hdc: cdrom_read_intr: data underrun (4294967260 blocks)
end_request: I/O error, dev 16:00, sector 299304
the blocks number is 'interesting' in that it is either negative or
really massive, not something that would seem to be appropriate
for the cdrom driver.
dd:dcd$ dmesg | perl -ne 'printf "%x\n", $1 if /data underrun.*?(\d+) blocks/ ' | sort | uniq -c | head
2 ffffff40
2 ffffff44
2 ffffff48
2 ffffff4c
2 ffffff50
2 ffffff54
2 ffffff58
2 ffffff5c
2 ffffff60
2 ffffff64
dd:dcd$ dmesg | perl -ne 'printf "%x\n", $1 if /data underrun.*?(\d+) blocks/ ' | sort | uniq -c | tail
4 ffffffd8
4 ffffffdc
4 ffffffe0
4 ffffffe4
4 ffffffe8
4 ffffffec
4 fffffff0
4 fffffff4
4 fffffff8
4 fffffffc
On Sat, 12 Jan 2002 at 08:37 -0800, David Dyck <dcd@tc.fluke.com> wrote:
> On Fri, 11 Jan 2002 at 18:55 -0800, David Dyck <dcd@tc.fluke.com> wrote:
>
> I had been testing 2.5.2-pre11 and earlier, but hadn't looked at
> reading from my cdrom for a while. Yesterday I created examined several
> large cdrom sets that had been readable earlier and they read partially
> but get read errors. These same cdroms can be read reliable on
> 2.4.18-pre3 using the same hardware, and are readable on other
> PC's runing older kernels.
>
> Has anyone else seen cdrom read errors with 2.5.2-pre* kernels?
>
> Using 2.5.2-pre11
>
> # mount /cdrom && md5sum /cdrom/*
> md5sum: /cdrom/dcd-c.tar.gz: I/O error
> md5sum: /cdrom/dcd-d.tar.gz: I/O error
>
>
> An example of some of the messages were
>
> ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
> hdc: NEC CD-ROM DRIVE:28B, ATAPI CD/DVD-ROM drive
> hdc: ATAPI 32X CD-ROM drive, 256kB Cache
>
>
> VFS: Disk change detected on device ide1(22,0)
> ISO 9660 Extensions: Microsoft Joliet Level 3
> ISOFS: changing to secondary root
> hdc: cdrom_read_intr: data underrun (4294967256 blocks)
> end_request: I/O error, dev 16:00, sector 299300
> hdc: cdrom_read_intr: data underrun (4294967260 blocks)
> end_request: I/O error, dev 16:00, sector 299304
>
> errors repeated with sector and blocks increasing by 4
> repeating 118 times
>
>
> using 2.4.18-pre3 I get no errors
^ permalink raw reply
* Re: [2.4.17/18pre] VM and swap - it's really unusable
From: Daniel Phillips @ 2002-01-15 3:31 UTC (permalink / raw)
To: george anzinger
Cc: yodaiken, Momchil Velikov, Arjan van de Ven, Roman Zippel,
linux-kernel
In-Reply-To: <3C439D02.EBCD78C4@mvista.com>
On January 15, 2002 04:07 am, george anzinger wrote:
> Daniel Phillips wrote:
> >
> > On January 14, 2002 10:09 am, yodaiken@fsmlabs.com wrote:
> > > UNIX generally tries to ensure liveness. So you know that
> > > cat lkarchive | grep feel | wc
> > > will complete and not just that, it will run pretty reasonably because
> > > for UNIX _every_ process is important and gets cpu and IO time.
> > > When you start trying to add special low latency tasks, you endanger
> > > liveness. And preempt is especially corrosive because one of the
> > > mechanisms UNIX uses to assure liveness is to make sure that once a
> > > process starts it can do a significant chunk of work.
>
> If I read this right, your complaint is not with preemption but with
> scheduler policy. Clearly both are needed to "assure liveness".
> Another way of looking at preemption is that is enables a more
> responsive and nimble scheduler policy (afterall it is the scheduler
> that decided that task A should give way to task B. All preemption does
> is to allow that to happen with greater dispatch.) Given that, we can
> then discuss what scheduler policy should be.
You responded to the wrong person, however I'll take this opportunity to
agree with you, on the basis of my years of experience with critical path
scheduling. For project schedules 'earlist completion' is the name of the
game, within bounds of available resources. When you delay an indvidual
'task' (I'm using the project management term here) past the earliest time it
can be scheduled, you are using up its 'float', and if the delay is longer
than the task's float, the completion time of the schedule as a whole will be
delayed. This is no different for a computer than it is for a group of
people, it is still a scheduling problem. Delaying any random task risks
delaying the schedule as a whole, and that risk approaches certainty as the
number of delays approaches infinity.
N.B.: the above observation is aimed at project managers, who will know
exactly what I'm talking about. Otherwise, don't worry if it sounds like so
much BS, it actually isn't ;-)
--
Daniel
^ permalink raw reply
* Re: Multicast fails when interface changed
From: Chris Wright @ 2002-01-15 3:28 UTC (permalink / raw)
To: Christopher James; +Cc: kuznet, linux-kernel
In-Reply-To: <3C4374BA.F8E26684@berkeley.innomedia.com>
* Christopher James (cjames@berkeley.innomedia.com) wrote:
> It was our expectation that the switch from the first to second
> interface should work without any involvement from the application
> because the second interface is configured exactly the same as the
> first interface. After the switch, everything seems to work with the
> exception of multicasting: the multicast membership information is not
> propagated to the second interface, it stays with the first interface.
i don't think this is a valid expectation. joining a multicast group
is a device specific action. when you join, you either specify an
interface to join on (imr_interface=dev_ip_addr) or let the kernel choose
(imr_interface=INADDR_ANY). in either case, you are telling some hardware
to adjust its multicast filter and identifying that hardware by a unique
device index. as alexey mentioned, it sounds like your app has never told
the second interface that is should even care about multicast packets.
did you try joining on both interfaces? (you may find using a unique
service ip addr on each interface, and failing over an application ip
addr using aliases will help)
cheers,
-chris
^ permalink raw reply
* Re: [patch] O(1) scheduler-H6/H7 and nice +19
From: Davide Libenzi @ 2002-01-15 3:27 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Ingo Molnar, lkml, Dave Jones
In-Reply-To: <20020115031905.01B0624AC1@oscar.casa.dyndns.org>
On Mon, 14 Jan 2002, Ed Tomlinson wrote:
> On January 14, 2002 09:33 pm, Davide Libenzi wrote:
> > try to replace :
> >
> > PRIO_TO_TIMESLICE() and RT_PRIO_TO_TIMESLICE() with :
> >
> > #define NICE_TO_TIMESLICE(n) (MIN_TIMESLICE + ((MAX_TIMESLICE - \
> > MIN_TIMESLICE) * ((n) + 20)) / 39)
> >
> >
> > NICE_TO_TIMESLICE(p->__nice)
>
> Not sure about this change. gkrellm shows the compile getting about 40%
> cpu. Best result here seems to be with a larger range of timeslices. ie
> 1-15 ((10*HZ)/1000...) instead lets the compile get 80% of the cpu. wonder
> if this might be the way to go?
What's the MIN/MAX_TIMESLICE range that you used to get 80% of cpu ?
- Davide
^ 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.