* Re: 2.5.52-mjb1 (scalability / NUMA patchset)
From: Martin J. Bligh @ 2002-12-17 19:31 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: linux-kernel
In-Reply-To: <20021217174958.GY2690@holomorphy.com>
>> The patchset contains mainly scalability and NUMA stuff, and
>> anything else that stops things from irritating me. It's meant
>> to be pretty stable, not so much a testing ground for new stuff.
>> I'd be very interested in feedback from other people running
>> large SMP or NUMA boxes.
>> http://www.aracnet.com/~fletch/linux/2.5.52/patch-2.5.52-mjb1.bz2
>
> pfn_to_nid() got lots of icache misses. Try using a macro.
How much difference does this make?
M.
^ permalink raw reply
* Re: Trouble with kernel 2.4.18-18.7.x
From: Bill Davidsen @ 2002-12-17 19:34 UTC (permalink / raw)
To: Alan Cox; +Cc: Karina, Linux Kernel Mailing List
In-Reply-To: <1039553498.14302.58.camel@irongate.swansea.linux.org.uk>
On 10 Dec 2002, Alan Cox wrote:
> So it looks like its ok. Do file the kmod: failed to exec report in
> https://bugzilla.redhat.com/bugzilla however. Regardless of it not being
> a problem in your case it does want fixing
It appears that recent RH build initrd files w/o all of the stuff in
modules.conf. Perhaps only the first SCSI adaptor, perhaps just ignoring
the ones which don't match the build hardware. I suspect the latter, since
even using --with= in a manual mkinitrd failed (silently) to include the
modules. I can't tell you how much that sucks if you build kernels for
multiple machines on a compile server.
Also, I installed 2.4.18-18.8.0 and it put a bunch of overlong label=
statements in lilo.conf, then ran lilo and didn't check the status. Since
it had deleted the old kernel that left a totally unbootable system. Guess
RH really likes grub and only tests upgrades and such with that.
I will report this later tonight when I'm willing to take the time to
prepare a proper bug report.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: rmap and nvidia?
From: Andrew McGregor @ 2002-12-17 19:35 UTC (permalink / raw)
To: O.Sezer, linux-kernel; +Cc: zander
In-Reply-To: <3DFE522A.6010803@superonline.com>
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
So, first apply the patch for 4191 from www.minion.de, then the attached
one based on yours. Been running overnight and beaten on by XScreesaver,
no memory leak anymore.
Andrew
--On Tuesday, December 17, 2002 00:22:34 +0200 "O.Sezer"
<sezero@superonline.com> wrote:
> Is this patch correct in any way?
> (Ripped out of the 2.5 patch and modified some).
>
> Thanks.
>
[-- Attachment #2: NVIDIA_kernel-1.0-4191-2.5-pte_unmap.diff --]
[-- Type: application/octet-stream, Size: 1607 bytes --]
--- NVIDIA_kernel-1.0-4191-2.5-minion/nv-linux.h 2002-12-18 08:25:50.000000000 +1300
+++ NVIDIA_kernel-1.0-4191-2.5/nv-linux.h 2002-12-17 22:03:31.000000000 +1300
@@ -151,21 +151,27 @@
# define SMP_NUM_CPUS smp_num_cpus
#endif
-#ifdef KERNEL_2_5
-#define PTE_OFFSET(pmd, address, pte) (pte = *pte_offset_map(pmd, address))
+#ifdef pte_offset_map /* rmap-vm or 2.5 */
+#define PTE_OFFSET(pmd, address, pte) \
+ { \
+ pte_t *pPTE; \
+ pPTE = pte_offset_map(pmd, address); \
+ pte = *pPTE; \
+ pte_unmap(pPTE); \
+ }
#else
-#ifdef pte_offset_atomic
+#ifdef pte_offset_atomic /* aa-vm */
#define PTE_OFFSET(pmd, address, pte) \
- { \
+ { \
pte_t *pPTE; \
pPTE = pte_offset_atomic(pmd, address); \
pte = *pPTE; \
pte_kunmap(pPTE); \
}
-#else /* !pte_offset_atomic */
+#else /* !pte_offset_atomic */
#define PTE_OFFSET(pmd, address, pte) (pte = *pte_offset(pmd, address))
-#endif /* pte_offset_atomic */
-#endif /* KERNEL_2_5 */
+#endif /* pte_offset_atomic */
+#endif /* pte_offset_map */
#define NV_PAGE_ALIGN(addr) ( ((addr) + PAGE_SIZE - 1) / PAGE_SIZE)
#define NV_MASK_OFFSET(addr) ( (addr) & (PAGE_SIZE - 1) )
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 19:37 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ulrich Drepper, Alan Cox, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, Linux Kernel Mailing List
In-Reply-To: <3DFF7951.6020309@transmeta.com>
On Tue, 17 Dec 2002, H. Peter Anvin wrote:
>
> Let's see... it works fine on UP and on *most* SMP, and on the ones
> where it doesn't work you just fill in a system call into the vsyscall
> slot. It just means that gettimeofday() needs a different vsyscall slot.
The thing is, gettimeofday() isn't _that_ special. It's just not worth a
vsyscall of it's own, I feel. Where do you stop? Do we do getpid() too?
Just because we can?
This is especially true since the people who _really_ might care about
gettimeofday() are exactly the people who wouldn't be able to use the fast
user-space-only version.
How much do you think gettimeofday() really matters on a desktop? Sure, X
apps do gettimeofday() calls, but they do a whole lot more of _other_
calls, and gettimeofday() is really far far down in the noise for them.
The people who really call for gettimeofday() as a performance thing seem
to be database people who want it as a timestamp. But those are the same
people who also want NUMA machines which don't necessarily have
synchronized clocks.
Linus
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Martin J. Bligh @ 2002-12-17 19:26 UTC (permalink / raw)
To: H. Peter Anvin, Linus Torvalds; +Cc: Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <3DFF772E.2050107@transmeta.com>
>> It's not as good as a pure user-mode solution using tsc could be, but
>> we've seen the kinds of complexities that has with multi-CPU systems, and
>> they are so painful that I suspect the sysenter approach is a lot more
>> palatable even if it doesn't allow for the absolute best theoretical
>> numbers.
>
> The complexity only applies to nonsynchronized TSCs though, I would
> assume. I believe x86-64 uses a vsyscall using the TSC when it can
> provide synchronized TSCs, and if it can't it puts a normal system call
> inside the vsyscall in question.
You can't use the TSC to do gettimeofday on boxes where they aren't
syncronised anyway though. That's nothing to do with vsyscalls, you just
need a different time source (eg the legacy stuff or HPET/cyclone).
M.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 19:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ulrich Drepper, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212171115450.1095-100000@home.transmeta.com>
Linus Torvalds wrote:
>
> On Tue, 17 Dec 2002, Linus Torvalds wrote:
>
>>Hmm.. Which system calls have all six parameters? I'll have to see if I
>>can find any way to make those use the new interface too.
>
>
> The only ones I found from a quick grep are
> - sys_recvfrom
> - sys_sendto
> - sys_mmap2()
> - sys_ipc()
>
> and none of them are of a kind where the system call entry itself is the
> biggest performance issue (and sys_ipc() is deprecated anyway), so it's
> probably acceptable to just use the old interface for them.
>
recvfrom() and sendto() can also be implemeted as sendmsg() recvmsg() if
one really wants to.
What one can also do is that a sixth argument, if one exists, is passed
on the stack (i.e. in (%ebp), since %ebp contains the stack pointer.)
-hpa
^ permalink raw reply
* Re: HT Benchmarks (was: /proc/cpuinfo and hyperthreading)
From: Bill Davidsen @ 2002-12-17 19:27 UTC (permalink / raw)
To: J.A. Magallon; +Cc: Linux-Kernel Mailing List
In-Reply-To: <20021216223848.GA2994@werewolf.able.es>
On Mon, 16 Dec 2002, J.A. Magallon wrote:
> Number of threads Elapsed time User Time System Time
> 1 53:216 53:220 00:000
> 2 29:272 58:180 00:320
> 3 27:162 1:21:450 00:540
> 4 25:094 1:41:080 01:250
>
> Elapsed is measured by the parent thread, that is not doing anything
> but wait on a pthread_join. User and system times are the sum of
> times for all the children threads, that do real work.
>
> The jump from 1->2 threads is fine, the one from 2->4 is ridiculous...
> I have my cpus doubled but each one has half the pipelining for floating
> point...see the user cpu time increased due to 'worst' processors and
> cache pollution on each package.
>
> So, IMHO and for my apps, HyperThreading is just a bad joke.
I must be misreading this, it looks to me as though having threads running
HT is reducing the clock time, and frankly that's what I want. It may not
be as good as having more processors, but it certainly is better for
nothing, even for your application. I read that as about 10% faster, and I
know people who spend more on fans to o/c their CPU than the premium for a
Xeon.
More to the point, since you have no choice if you want to go fast or have
>2 CPUs, you get HT included. Clearly if you want good latency you don't
run SMP at all due to the extra locking, that's a kernel issue, not HT.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 19:28 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel,
hpa
In-Reply-To: <Pine.LNX.4.44.0212171050470.1095-100000@home.transmeta.com>
On Tue, 17 Dec 2002, Linus Torvalds wrote:
>
> Hmm.. Which system calls have all six parameters? I'll have to see if I
> can find any way to make those use the new interface too.
The only ones I found from a quick grep are
- sys_recvfrom
- sys_sendto
- sys_mmap2()
- sys_ipc()
and none of them are of a kind where the system call entry itself is the
biggest performance issue (and sys_ipc() is deprecated anyway), so it's
probably acceptable to just use the old interface for them.
One other alternative is to change the calling convention for the
new-style system call, and not have arguments in registers at all. We
could make the interface something like
- %eax contains system call number
- %edx contains pointer to argument block
- call *syscallptr // trashes all registers
and then the old "compatibility" function would be something like
movl 0(%edx),%ebx
movl 4(%edx),%ecx
movl 12(%edx),%esi
movl 16(%edx),%edi
movl 20(%edx),%ebp
movl 8(%edx),%edx
int $0x80
ret
while the "sysenter" interface would do the loads from kernel space.
That would make some things easier, but the problem with this approach is
that if you have a single-argument system call, and you just pass in the
stack pointer offset in %edx directly, then the system call stubs will
always load 6 arguments, and if we're just at the end of the stack it
won't actually _work_. So part of the calling convention would have to be
the guarantee that there is stack-space available (should always be true
in practice, of course).
Linus
^ permalink raw reply
* Re: My fixes to ide-tape in 2.4.20-ac2
From: Marcelo Tosatti @ 2002-12-17 16:28 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linux-kernel
In-Reply-To: <20021217142235.C8233@devserv.devel.redhat.com>
On Tue, 17 Dec 2002, Pete Zaitcev wrote:
> > Date: Mon, 16 Dec 2002 22:49:35 -0200 (BRST)
> > From: Marcelo Tosatti <marcelo@conectiva.com.br>
>
> > > I checked that my fixes were not corrected by Alan Stern,
> > > and re-diffed them against 2.4.20-ac2. I think it would
> > > be right if Alan (Cox :-) applied this patch to -ac3 or something.
> > > Marcelo agreed to take it many times but forgot to actually apply.
> >
> > I haven't applied them because I was afraid they could break something.
> >
> > Great that now its been tested in -ac.
>
> Yes, Alan saves the day. However, I would think this is what your
> -pre series were supposed to do. Add fixes, see if they break things.
> Release more often. If patches regress, remove them. Obviously, your
> master vision is different, but personally I think it's unfortunate.
Pete,
I'm not master. Most people here know much more than what I do.
^ permalink raw reply
* Re: QoS limitations ....
From: Marcello Scacchetti @ 2002-12-17 19:17 UTC (permalink / raw)
To: raymondl; +Cc: Netfilter Mailing List
In-Reply-To: <1040123813.1886.89.camel@rayw.knowledgefactory.co.za>
After some checking i found this:
/* "Handles"
---------
All the traffic control objects have 32bit identifiers, or
"handles".
They can be considered as opaque numbers from user API viewpoint,
but actually they always consist of two fields: major and
minor numbers, which are interpreted by kernel specially,
that may be used by applications, though not recommended.
F.e. qdisc handles always have minor number equal to zero,
classes (or flows) have major equal to parent qdisc major, and
minor uniquely identifying class inside qdisc.
Macros to manipulate handles:
*/
#define TC_H_MAJ_MASK (0xFFFF0000U)
#define TC_H_MIN_MASK (0x0000FFFFU)
#define TC_H_MAJ(h) ((h)&TC_H_MAJ_MASK)
#define TC_H_MIN(h) ((h)&TC_H_MIN_MASK)
#define TC_H_MAKE(maj,min) (((maj)&TC_H_MAJ_MASK)|((min)&TC_H_MIN_MASK))
#define TC_H_UNSPEC (0U)
#define TC_H_ROOT (0xFFFFFFFFU)
#define TC_H_INGRESS (0xFFFFFFF1U)
inside include/linux/pkt_sched.h (linux 2.4.19 kernel tree).
It seems that you can set FFFF class ids as stated by the minor mask.
Hope to be right,
Marcello
Il mar, 2002-12-17 alle 12:16, Raymond Leach ha scritto:
> Hi all
>
> Does anyone know of a limit to the number of filters or classes that can
> be attached to a single qdisc (let's say CBQ or HTB)?
>
> I have a client that want to do bandwidth throttling per ip across 10
> class C subnets.
>
> What problems can I expect, and does anyone have any other suggestions
> on how to accomplish this?
>
> Ray
--
Marcello Scacchetti <marcello.scacchetti@nextrem.it>
^ permalink raw reply
* Re: My fixes to ide-tape in 2.4.20-ac2
From: Pete Zaitcev @ 2002-12-17 19:22 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Pete Zaitcev, linux-kernel
In-Reply-To: <Pine.LNX.4.50L.0212162248480.31876-100000@freak.distro.conectiva>
> Date: Mon, 16 Dec 2002 22:49:35 -0200 (BRST)
> From: Marcelo Tosatti <marcelo@conectiva.com.br>
> > I checked that my fixes were not corrected by Alan Stern,
> > and re-diffed them against 2.4.20-ac2. I think it would
> > be right if Alan (Cox :-) applied this patch to -ac3 or something.
> > Marcelo agreed to take it many times but forgot to actually apply.
>
> I haven't applied them because I was afraid they could break something.
>
> Great that now its been tested in -ac.
Yes, Alan saves the day. However, I would think this is what your
-pre series were supposed to do. Add fixes, see if they break things.
Release more often. If patches regress, remove them. Obviously, your
master vision is different, but personally I think it's unfortunate.
Greetings,
-- Pete
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 19:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ulrich Drepper, Alan Cox, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212171106210.1095-100000@home.transmeta.com>
Linus Torvalds wrote:
>
> On Tue, 17 Dec 2002, Ulrich Drepper wrote:
>
>>But this is exactly what I expect to happen. If you want to implement
>>gettimeofday() at user-level you need to modify the page.
>
> Note that I really don't think we ever want to do the user-level
> gettimeofday(). The complexity just argues against it, it's better to try
> to make system calls be cheap enough that you really don't care.
>
Let's see... it works fine on UP and on *most* SMP, and on the ones
where it doesn't work you just fill in a system call into the vsyscall
slot. It just means that gettimeofday() needs a different vsyscall slot.
-hpa
^ permalink raw reply
* [2.5.52, ALSA] Unable to handle kernel paging request at virtual address 32347363
From: Jochen Hein @ 2002-12-17 19:13 UTC (permalink / raw)
To: linux-kernel
This is when loading the cs4232 driver for my Thinkpad 600.
Unable to handle kernel paging request at virtual address 32347363
c6abb81c
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<c6abb81c>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: c489e064 ebx: 32347363 ecx: c6ac2460 edx: c489e014
esi: c6ac0320 edi: 32347363 ebp: c5bdff38 esp: c5bdff2c
ds: 0068 es: 0068 ss: 0068
Stack: c489e014 32347363 c6ae2780 c5bdff54 c6aba660 32347363 00000000 00000000
c6ae2780 00000004 c5bdff90 c6af807a 00000001 32347363 c6ae0000 00000004
00000000 00000000 c6ae2780 00000000 00000010 c6aca304 c6aca394 00000000
Call Trace: [<c6ae2780>] [<c6aba660>] [<c6ae2780>] [<c6af807a>] [<c6ae2780>] [<c6af836c>] [<c012ca67>] [<c0108cd7>]
Code: ae 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 74 34 83
>>EIP; c6abb81c <END_OF_CODE+66b7fdc/????> <=====
Trace; c6ae2780 <END_OF_CODE+66def40/????>
Trace; c6aba660 <END_OF_CODE+66b6e20/????>
Trace; c6ae2780 <END_OF_CODE+66def40/????>
Trace; c6af807a <END_OF_CODE+66f483a/????>
Trace; c6ae2780 <END_OF_CODE+66def40/????>
Trace; c6af836c <END_OF_CODE+66f4b2c/????>
Trace; c012ca67 <sys_init_module+113/1a4>
Trace; c0108cd7 <syscall_call+7/b>
Code; c6abb81c <END_OF_CODE+66b7fdc/????>
00000000 <_EIP>:
Code; c6abb81c <END_OF_CODE+66b7fdc/????> <=====
0: ae scas %es:(%edi),%al <=====
Code; c6abb81d <END_OF_CODE+66b7fdd/????>
1: 75 08 jne b <_EIP+0xb>
Code; c6abb81f <END_OF_CODE+66b7fdf/????>
3: 84 c0 test %al,%al
Code; c6abb821 <END_OF_CODE+66b7fe1/????>
5: 75 f8 jne ffffffff <_EIP+0xffffffff>
Code; c6abb823 <END_OF_CODE+66b7fe3/????>
7: 31 c0 xor %eax,%eax
Code; c6abb825 <END_OF_CODE+66b7fe5/????>
9: eb 04 jmp f <_EIP+0xf>
Code; c6abb827 <END_OF_CODE+66b7fe7/????>
b: 19 c0 sbb %eax,%eax
Code; c6abb829 <END_OF_CODE+66b7fe9/????>
d: 0c 01 or $0x1,%al
Code; c6abb82b <END_OF_CODE+66b7feb/????>
f: 85 c0 test %eax,%eax
Code; c6abb82d <END_OF_CODE+66b7fed/????>
11: 74 34 je 47 <_EIP+0x47>
Code; c6abb82f <END_OF_CODE+66b7fef/????>
13: 83 00 00 addl $0x0,(%eax)
How can I decode the addresses in the modules?
Jochen
--
Wenn Du nicht weißt was Du tust, tu's mit Eleganz.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ulrich Drepper @ 2002-12-17 19:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel,
hpa
In-Reply-To: <Pine.LNX.4.44.0212171050470.1095-100000@home.transmeta.com>
Linus Torvalds wrote:
> In the meantime, I do agree with you that the TLS approach should work
> too, and might be better. It will allow all six arguments to be used if we
> just find a good calling conventions
If you push out the AT_* patch I'll hack the glibc bits (probably the
TLS variant). Won't take too long, you'll get results this afternoon.
What about AMD's instruction? Is it as flawed as sysenter? If not and
%ebp is available I really should use the TLS method.
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 19:19 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Alan Cox, Linus Torvalds, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List
In-Reply-To: <3DFF717C.90006@redhat.com>
Ulrich Drepper wrote:
> Alan Cox wrote:
>
>
>>Is there any reason you can't just keep the linker out of the entire
>>mess by generating
>>
>> .byte whatever
>> .dword 0xFFFF0000
>>
>>instead of call ?
>
>
> There is no such instruction. Unless you know about some secret
> undocumented opcode...
>
Well, there is lcall $0xffff0000, $USER_CS... (no, I'm most definitely
*not* suggesting it.)
-hpa
^ permalink raw reply
* [ANNOUNCE] Journaled File System (JFS) release 1.1.1
From: Steve Best @ 2002-12-17 19:18 UTC (permalink / raw)
To: linux-kernel
Release 1.1.1 of JFS was made available today.
Drop 64 on December 17, 2002 (jfs-2.4-1.1.1.tar.gz
and jfsutils-1.1.1.tar.gz) includes fixes to the file
system and utilities.
Utilities changes
- fix segmentation fault in mkfs.jfs when given bad block device
- fix jfs_debugfs to display directory index with directory entries
File System changes
- calling brelse() with wrong bh during writing out of secondary
superblock while resizing the FS
- Remove COMMIT_Holdlock
- jfs_clear_inode was assuming that active_ag should never be set
coming into this routine. Since it's possible for a file to be
extended after the file descriptor has been closed, we need to allow
the possibility. (Dirty pages of memory mapped files can be written
after the file has been closed.)
- Avoid writing partial log pages for lazy transactions.
- Move index table out of directory inode's address space.
- jfs_truncate needs to call block_truncate_page
For more details about JFS, please see the patch instructions or
readme files.
Steve
JFS for Linux http://oss.software.ibm.com/jfs
^ permalink raw reply
* [linux-lvm] RH8 install - LVM sizing problem
From: grenoml @ 2002-12-17 19:10 UTC (permalink / raw)
To: linux-lvm
I am new to LVM and I wanted to use it when I installed a new machine
with RH8. So going through the install I set everything up with Disk
Druid selecting PV, LV, LVM and gathering all my LV into groups. I
kept /boot out of the LVM config but everything else is in LVM. The
layout is shown below. I have two drives and on the first drive I have
four partitions: dos, /boot, swap and one for /tmp and /var/tmp. On my
second disk I have one partition (Volume00) and the following
filesystems: /, /usr, /usr/local, /usr/src, /var, /home.
With plenty of disk space > 100GB I selected an 'Everything' install
and sat back just waiting for everything to complete. Well, part way
through the install an error displayed saying that I didn't have enough
space on /usr and I needed 1991M more space. Well /usr was provisioned
for 2GB so I went back and just selected specific packages and tried
again. This time an error displayed saying I needed 1500M more space on
/. That seemed odd as I had set / to 500M which I thought would be
plenty with a separate /home, /usr, /tmp, /var. So I went back and did
just a very minimal package selection and tried again. This time the
installation succeeded. Finally finished all the additional screens
and it said to have a nice computing experience and then went to a
blank screen and just sat there - dead. So I pushed the big button and
waited for reboot. It booted fine and seems to be operating ok but now
I have concerns.
Why was the RH8 installation with LVM needing so much space in / and
/usr? Was this correct or a bug?
Do I need to expand any of the filesystems to install all the
additional
packages that I was not able to install during installation.
How can I expand the filesystems when LVM commands aren't working?
------------------------------------------------------------------
Here are the results from running some commands:
+ /sbin/pvdisplay
pvdisplay -- ERROR: "/etc/lvmtab" doesn't exist; please run vgscan
+ /sbin/vgscan
vgscan -- LVM driver/module not loaded?
+ cat /etc/fstab
/dev/Volume02/LogVol00 / ext3 defaults
1 1
LABEL=/boot12 /boot ext3 defaults
1 2
none /dev/pts devpts gid=5,mode=620
0 0
/dev/Volume02/LogVol05 /home ext3 defaults
1 2
none /proc proc defaults
0 0
none /dev/shm tmpfs defaults
0 0
/dev/Volume01/LogVol00 /tmp ext3 defaults
1 2
/dev/Volume02/LogVol01 /usr ext3 defaults
1 2
/dev/Volume02/LogVol02 /usr/local ext3 defaults
1 2
/dev/Volume02/LogVol03 /usr/src ext3 defaults
1 2
/dev/Volume02/LogVol04 /var ext3 defaults
1 2
/dev/Volume01/LogVol01 /var/tmp ext3 defaults
1 2
/dev/Volume00/LogVol00 swap swap defaults
0 0
/dev/cdrom /mnt/cdrom iso9660
noauto,owner,kudzu,ro 0 0
/dev/hda /mnt/ls120.0 auto
noauto,owner,kudzu 0 0
+ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/Volume02/LogVol00
495844 77895 392349 17% /
/dev/hdc2 147778 9594 130554 7% /boot
/dev/Volume02/LogVol05
5039616 35736 4747880 1% /home
none 256976 0 256976 0% /dev/shm
/dev/Volume01/LogVol00
5039616 32968 4750648 1% /tmp
/dev/Volume02/LogVol01
2015824 844632 1068792 45% /usr
/dev/Volume02/LogVol02
10079084 32916 9534168 1% /usr/local
/dev/Volume02/LogVol03
10079084 32828 9534256 1% /usr/src
/dev/Volume02/LogVol04
15118728 67072 14283656 1% /var
/dev/Volume01/LogVol01
51395204 32828 48751588 1% /var/tmp
+ ps -e
PID TTY TIME CMD
1 ? 00:00:05 init
2 ? 00:00:00 keventd
3 ? 00:00:01 kapmd
4 ? 00:00:00 ksoftirqd_CPU0
5 ? 00:00:00 kswapd
6 ? 00:00:00 bdflush
7 ? 00:00:00 kupdated
8 ? 00:00:00 mdrecoveryd
15 ? 00:00:00 kjournald
71 ? 00:00:00 khubd
208 ? 00:00:00 kjournald
209 ? 00:00:00 kjournald
210 ? 00:00:00 kjournald
211 ? 00:00:00 kjournald
212 ? 00:00:00 kjournald
213 ? 00:00:00 kjournald
214 ? 00:00:00 kjournald
215 ? 00:00:00 kjournald
514 ? 00:00:00 dhclient
553 ? 00:00:00 syslogd
557 ? 00:00:00 klogd
574 ? 00:00:00 portmap
593 ? 00:00:00 rpc.statd
674 ? 00:00:00 apmd
712 ? 00:00:00 sshd
726 ? 00:00:00 xinetd
740 ? 00:00:00 ntpd
764 ? 00:00:00 sendmail
774 ? 00:00:00 sendmail
784 ? 00:00:00 gpm
793 ? 00:00:00 crond
822 ? 00:00:00 xfs
840 ? 00:00:00 atd
849 tty1 00:00:00 mingetty
850 tty2 00:00:00 mingetty
851 tty3 00:00:00 mingetty
852 tty4 00:00:00 mingetty
853 tty5 00:00:00 mingetty
854 tty6 00:00:00 mingetty
855 ? 00:00:00 gdm-binary
900 ? 00:00:00 gdm-binary
901 ? 03:14:45 X
910 ? 00:00:01 gnome-session
952 ? 00:00:00 ssh-agent
957 ? 00:00:00 gconfd-2
959 ? 00:00:00 bonobo-activati
961 ? 00:00:09 metacity
964 ? 00:00:00 gnome-settings-
977 ? 00:00:00 xscreensaver
980 ? 00:00:08 gnome-panel
982 ? 00:00:03 nautilus
984 ? 00:00:41 magicdev
987 ? 00:00:00 pam-panel-icon
989 ? 00:01:23 rhn-applet-gui
990 ? 00:00:00 pam_timestamp_c
1033 ? 00:00:00 nautilus-throbb
8880 ? 00:00:22 gnome-terminal
8881 pts/0 00:00:00 bash
9053 ? 00:00:00 gconfd-2
9055 ? 00:00:00 gnome-help
9057 ? 00:00:00 bonobo-activati
9066 ? 03:32:00 gnome2-info2htm
9070 ? 00:00:02 yelp
9085 ? 00:00:33 mozilla-bin
9691 ? 00:00:00 lpd
9758 ? 00:00:05 gnome-search-to
9965 pts/0 00:00:00 bash
9970 pts/0 00:00:00 ps
------------------------------------------------------------------
Wouldn't LVM be running by default when the system boots?
Additional questions:
Is it better to have / outside of LVM maybe in case of LVM problems?
If it is then should any other filesystems be outside with /.
Regards,
Gerry Reno
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: make module_install
From: Wolfgang Denk @ 2002-12-17 19:06 UTC (permalink / raw)
To: Ing.Gianfranco Morandi; +Cc: LinuxPPC
In-Reply-To: <002301c2a5fd$918c5fc0$0700a8c0@pc005>
In message <002301c2a5fd$918c5fc0$0700a8c0@pc005> you wrote:
>
> Many are the things that we must learn (from Linux point of view) before
> release some code under GPL, and we shouldn't like to release something that
> could be a bad example.
Do not hesitate to relase your code early. This is one of the basic
ideas of Open Source development, and a source of huge mutual
benefit: first, a duplication of effort may result, as others can
pick up your results early instead of starting the same project just
because they didn't know about yours; second, you may receive
feedback which helps you to solve or avoid problems or to improve
your code.
The good old rule is: release early, release often.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
In the beginning there was nothing.
And the Lord said "Let There Be Light!"
And still there was nothing, but at least now you could see it.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 19:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212162204300.1800-100000@home.transmeta.com>
Linus Torvalds wrote:
>
> It's not as good as a pure user-mode solution using tsc could be, but
> we've seen the kinds of complexities that has with multi-CPU systems, and
> they are so painful that I suspect the sysenter approach is a lot more
> palatable even if it doesn't allow for the absolute best theoretical
> numbers.
>
The complexity only applies to nonsynchronized TSCs though, I would
assume. I believe x86-64 uses a vsyscall using the TSC when it can
provide synchronized TSCs, and if it can't it puts a normal system call
inside the vsyscall in question.
-hpa
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: H. Peter Anvin @ 2002-12-17 19:11 UTC (permalink / raw)
To: dean gaudet; +Cc: Linus Torvalds, Dave Jones, Ingo Molnar, linux-kernel
In-Reply-To: <Pine.LNX.4.50.0212162241150.26163-100000@twinlark.arctic.org>
dean gaudet wrote:
> On Mon, 16 Dec 2002, Linus Torvalds wrote:
>
>>It's not as good as a pure user-mode solution using tsc could be, but
>>we've seen the kinds of complexities that has with multi-CPU systems, and
>>they are so painful that I suspect the sysenter approach is a lot more
>>palatable even if it doesn't allow for the absolute best theoretical
>>numbers.
>
> don't many of the multi-CPU problems with tsc go away because you've got a
> per-cpu physical page for the vsyscall?
>
> i.e. per-cpu tsc epoch and scaling can be set on that page.
>
> the only trouble i know of is what happens when an interrupt occurs and
> the task is rescheduled on another cpu... in theory you could test %eip
> against 0xfffffxxx and "rollback" (or complete) any incomplete
> gettimeofday call prior to saving a task's state. but i bet that test is
> undesirable on all interrupt paths.
>
Exactly. This is a real problem.
-hpa
^ permalink raw reply
* Re: How Do I: Make My Own /root file system
From: Wolfgang Denk @ 2002-12-17 19:02 UTC (permalink / raw)
To: James Don; +Cc: 'linuxppc-embedded@lists.linuxppc.org'
In-Reply-To: <DB0585C9F6F9D411BE8F00D0B7896A4CC05F40@SNCMAIL>
In message <DB0585C9F6F9D411BE8F00D0B7896A4CC05F40@SNCMAIL> you wrote:
>
> I just finished getting a basic bash shell running on my embedded PPC
> platform using a standard RAM file system from www.denx.de.
>
> Are there any instructions on line as to how I would go about making my own
> RAM FS? ... most online info seem to point to commercial distro's ... and I
> wouldn't mind learning the do's and don'ts for my self.
There is the our SELF (Simple Embedded Linux Framework) package at
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF , and there is the SELF
RPM in our ELDK which is where the tarball you're using comes from.
You can download the build script (especially the SELF.spec file)
from our CVS server.
> In the mean time I will keep dogging for information.
There is more projects of "Linux on a flopy disk" than I can name
here. They all can be used as a starting point.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
You can observe a lot just by watchin'. - Yogi Berra
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ross Biro @ 2002-12-17 19:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Alan Cox, Ulrich Drepper, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <Pine.LNX.4.44.0212171046550.1095-100000@home.transmeta.com>
It doesn't make sense to me to use a specially formatted page forced
into user space to tell libraries how to do system calls. Perhaps each
executable personality in the kernel should export a special shared
library in it's own native format that contains the necessary
information. That way we don't have to worry as much about code or
values changing sizes or locations.
We would have the chicken/egg problem with how the special shared
library gets loaded in the first place. For that we either support a
legacy syscall method (i.e. int 0x80 on x86) which should only be used
by ld.so or the equivalent or magically force the library into user
space at a known address.
Ross
Linus Torvalds wrote:
>On 17 Dec 2002, Alan Cox wrote:
>
>
>>Is there any reason you can't just keep the linker out of the entire
>>mess by generating
>>
>> .byte whatever
>> .dword 0xFFFF0000
>>
>>instead of call ?
>>
>>
>
>Alan, the problem is that there _is_ no such instruction as a "call
>absolute".
>
>There is only a "call relative" or "call indirect-absolute". So you either
>have to indirect through memory or a register, or you have to fix up the
>call at link-time.
>
>Yeah, I know it sounds strange, but it makes sense. Absolute calls are
>actually very unusual, and using relative calls is _usually_ the right
>thing to do. It's only in cases like this that we really want to call a
>specific address.
>
> Linus
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 19:10 UTC (permalink / raw)
To: Ulrich Drepper
Cc: Alan Cox, Matti Aarnio, Hugh Dickins, Dave Jones, Ingo Molnar,
Linux Kernel Mailing List, hpa
In-Reply-To: <3DFF7399.40708@redhat.com>
On Tue, 17 Dec 2002, Ulrich Drepper wrote:
>
> But this is exactly what I expect to happen. If you want to implement
> gettimeofday() at user-level you need to modify the page.
Note that I really don't think we ever want to do the user-level
gettimeofday(). The complexity just argues against it, it's better to try
to make system calls be cheap enough that you really don't care.
sysenter helps a bit there.
If we'd need to modify the page, we couldn't share one page between all
processes, and we couldn't make it global in the TLB. So modifying the
info page is something we should avoid at all cost - it's not totally
unlikely that the overheads implied by per-thread pages would drown out
the wins from trying to be clever.
The advantage of the current static fixmap is that it's _extremely_
streamlined. The only overhead is literally the system entry itself, which
while a bit too high on a P4 is not that bad in general (and hopefully
Intel will fix the stupidities that cause the P4 to be slow at kernel
entry. Somebody already mentioned that apparently the newer P4 cores are
actually faster at system calls than mine is).
Linus
^ permalink raw reply
* [U-Boot-Users] U-Boot-0.2.0 released
From: Wolfgang Denk @ 2002-12-17 18:58 UTC (permalink / raw)
To: u-boot
The first version of U-Boot has been released. It is named
U-Boot-0.2.0 and tagged as "U-Boot-0_2_0" on the CVS server.
A tarball is available at
ftp://ftp.denx.de/pub/u-boot/u-boot-0.2.0.tar.bz2
[In case anybody asks if there was a version 0.1.0: yes, there is
such a version. It is identical with PPCBoot-2.0.0.]
Major news:
- Support for AmigaOne board
- Support for x86 architecture
======================================================================
Changes for U-Boot 0.2.0:
======================================================================
* Use 1-byte-read instead of -write for iprobe() function
Add i2c commands to PM826 config
* extend I2C POST code: check for list on known addresses
* Improve log buffer code; use "loglevel" to decide which messages
to log on the console, too (like in Linux); get rid of "logstart"
* Add command line tool to access the U-Boot's environment
(board-specific for TRAB now, to be fixed later)
* Patch by Hans-Joerg Frieden, 06 Dec 2002
Fix misc problems with AmigaOne support
* Patch by Chris Hallinan, 3 Dec 2002:
minor cleanup to the MPC8245 EPIC driver
* Patch by Pierre Aubert , 28 Nov 2002
Add support for external (SIU) interrupts on MPC8xx
* Patch by Pierre Aubert , 28 Nov 2002
Fix nested syscalls bug in standalone applications
* Patch by David M?ller, 27 Nov 2002:
fix output of "pciinfo" command for CardBus bridge devices.
* Fix bug in TQM8260 board detection - boards got stuck when board ID
was not readable
* Add LED indication for IDE activity on KUP4K board
* Fix startup problems with VFD display on TRAB
* Patch by Pierre Aubert, 20 Nov 2002
Add driver for Epson SED13806 graphic controller.
Add support for BMP logos in cfb_console driver.
* Added support for both PCMCIA slots (at the same time!) on MPC8xx
* Patch by Rod Boyce, 21 Nov 2002:
fix PCMCIA on MBX8xx board
* Patch by Pierre Aubert , 21 Nov 2002
Add CFG_CPM_POST_WORD_ADDR to make the offset of the
bootmode word in DPRAM configurable
* Patch by Daniel Engstr?m, 18 Nov 2002:
Fixes for x86 port (mostly strings issues)
* Patch by Ken Chou, 18 Nov 2002:
Fix for natsemi NIC cards (DP83815)
* Patch by Pierre Aubert, 19 Nov 2002:
fix a bug for the MII configuration, and some warnings
* Patch by Thomas Frieden, 13 Nov 2002:
Add code for AmigaOne board
(preliminary merge to U-Boot, still WIP)
* Patch by Jon Diekema, 12 Nov 2002:
- Adding URL for IEEE OUI lookup
- Making the autoboot #defines dependent on CONFIG_AUTOBOOT_KEYED
being defined.
- In the CONFIG_EXTRA_ENV_SETTINGS #define, the root-on-initrd and
root-on-nfs macros are designed to switch how the default boot
method gets defined.
* Patch by Daniel Engstr?m, 13 Nov 2002:
Add support for i386 architecture and AMD SC520 board
* Patch by Pierre Aubert, 12 Nov 2002:
Add support for DOS filesystem and booting from DOS floppy disk
* Patch by Jim Sandoz, 07 Nov 2002:
Increase number of network RX buffers (PKTBUFSRX in
"include/net.h") for EEPRO100 based boards (especially SP8240)
which showed "Receiver is not ready" errors when U-Boot was
processing the receive buffers slower than the network controller
was filling them.
* Patch by Andreas Oberritter, 09 Nov 2002:
Change behaviour of NetLoop(): return -1 for errors, filesize
otherwise; return code 0 is valid an means no file loaded - in this
case the environment still gets updated!
* Patches by Jon Diekema, 9 Nov 2002:
- improve ADC/DAC clocking on the SACSng board to align
the failing edges of LRCLK and SCLK
- sbc8260 configuration tweaks
- add status LED support for 82xx systems
- wire sspi/sspo commands into command handler; improved error
handlering
- add timestamp support and alternate memory test to the
SACSng configuration
* Patch by Vince Husovsky, 7 Nov 2002:
Add "-n" to linker options to get rid of "Not enough room for
program headers" problem
* Patch by David M?ller, 05 Nov 2002
Rename CONFIG_PLL_INPUT_FREQ to CONFIG_SYS_CLK_FREQ
so we can use an already existing name
* Patch by Pierre Aubert, 05 Nov 2002
Hardware relatied improvments in FDC boot code
* Patch by Holger Schurig, 5 Nov 2002:
Make the PXA really change it's frequency
* Patch by Pierre Aubert, 05 Nov 2002
Add support for slave serial Spartan 2 FPGAs
* Fix uninitialized memory (MAC address) in 8xx SCC/FEC ethernet
drivers
* Add support for log buffer which can be passed to Linux kernel's
syslog mechanism; used especially for POST results.
* Patch by Klaus Heydeck, 31 Oct 2002:
Add initial support for kup4k board
* Patch by Robert Schwebel, 04 Nov 2002:
- use watchdog to reset PXA250 systems
- added progress callbacks to (some of the) ARM code
- update for Cogent CSB226 board
* Add support for FPS860 board
* Patch by Guillaume Alexandre,, 04 Nov 2002:
Improve PCI access on 32-bits Compact PCI bus
* Fix mdelay() on TRAB - this was still the debugging version with
seconds instead of ms.
* Patch by Robert Schwebel, 1 Nov 2002:
XScale related cleanup (affects all ARM boards)
* Cleanup of names and README.
======================================================================
Notes for U-Boot 0.1.0:
======================================================================
This is the initial version of "Das U-Boot", the Universal Boot Loader.
It is based on version 2.0.0 (the "Halloween Release") of PPCBoot.
For information about the history of the project please see the
PPCBoot project page at http://sourceforge.net/projects/ppcboot
======================================================================
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
"Though a program be but three lines long,
someday it will have to be maintained."
- The Tao of Programming
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 19:05 UTC (permalink / raw)
To: Jeff Dike; +Cc: Hugh Dickins, Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <200212171839.NAA08357@ccure.karaya.com>
On Tue, 17 Dec 2002, Jeff Dike wrote:
>
> torvalds@transmeta.com said:
> > That also allows the kernel to move around the SYSINFO page at will,
> > and even makes it possible to avoid it altogether (ie this will solve
> > the inevitable problems with UML - UML just wouldn't set AT_SYSINFO,
> > so user level just wouldn't even _try_ to use it).
>
> Why shouldn't I just set it to where UML provides its own SYSINFO page?
Sure, that works fine too.
Linus
^ 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.