* Re: After Uncompresseing Linux..., what's next
From: Prakash kanthi @ 2002-12-20 16:32 UTC (permalink / raw)
To: LinuxPPC
In-Reply-To: <20021220161436.81737.qmail@web41212.mail.yahoo.com>
I found the correct exception guys. It means
Privileged Instruction Exception.
--- Prakash kanthi <pkanthi@yahoo.com> wrote:
>
> Folks,
>
> I just wanted to provide more info on my env. I have
> PPC405 based board with no network support forcing
> me
> to use zImage.initrd.elf.
>
> Can you suggest more on my problem described below?
> I
> saw the memory values at 0x00000000 onwards after
> uncompressing linux and they have changed. But when
> the control jumps to 0x0, my board hangs. I see that
> ESR is showing a value of 0x80000000, meaning either
> illegal instruction or Machine Check.
>
> Can you tell what's going on? What happens next
> after
> uncompressing? I am thinking it executes
> start_kernel
> function which calls lock_kernel. Let me know if i
> am
> wrong.
>
> thanks,
> Prakash
>
>
>
>
> --- James Don <JDon@spacebridge.com> wrote:
> > I just went thru this myself ... ;-)
> >
> > 1.) Get a BDM/JTAG tool look halt the processor
> > after you see " Now booting
> > the kernel" and look for valid asm at 0x0 ... make
> > sure it mathes your
> > start.s file ...
> >
> > 2.) Veryfy you have your mem map from ppcboot
> > matching requirements for the
> > kernel i.e ram (physical=0x0, virtual=0xc0000000)
> > and immr (phys 0xff000000
> > virtual 0xff000000) ... I had my immr in ppc boot
> at
> > 0x02200000 this screwed
> > me for quite a while ... otherwise you have no
> > printk ... the memory map is
> > very important not to screw with some things
> depend
> > on it (unless your
> > careful) ...
> >
> > 3.) verify you SMC1 (uart) is getting proper
> > clocking config ... i.e
> > bus->brg1 and brg1 is 16 times baud rate ...
> > otherwise you have no printk
> >
> > 4.) and always always keep in mind your RAM refesh
> > could be wrong ...
> > everyone will tell you this even when it has
> nothing
> > to do with your problem
> > ... try not to ignore them if you are still stuck
> > ;-) But verifying step 1
> > should prove your ok ...
> >
> > Best of luck,
> > Jim
> >
> >
> > -----Original Message-----
> > From: Prakash kanthi [mailto:pkanthi@yahoo.com]
> > Sent: Wednesday, December 18, 2002 7:14 PM
> > To: LinuxPPC
> > Subject: After Uncompresseing Linux..., what's
> next
> >
> >
> > Hi there,
> >
> > I was trying to load linuxppc_2_4_devel onto my
> > board.
> > It goes through the board info read, UART init and
> > Uncompressing the linux kernel. But after that, i
> do
> > not see any messages and board hangs.
> >
> > Here is the UART output:
> > ------------------------------------
> > OS Booting...
> >
> > loaded at: 00400000 0060D1CC
> > board data at: 00000030 00000044
> > relocated to: 00405C24 00405C38
> > zimage at: 00406290 004A08FF
> > initrd at: 004A1000 006097CA
> > avail ram: 0060E000 007F8000
> >
> > Linux/PPC load: console=ttyS0,9600 console=tty1
> > ip=on
> > root=/dev/xsysace/disc0/pa
> > rt3 rw
> > Uncompressing Linux...done.
> > Now booting the kernel
> > -------------------------------------------
> >
> > After the last line, it hangs. I get a feeling
> that,
> > the uncompressing process is not writing in the
> > memory
> > starting from 0x00000000 and, after uncompressing,
> > it
> > is jumping into 0x00000000 and is not able to find
> > anything.
> >
> > My questions are,
> > 1. How can i make sure that, the uncompressing
> > process
> > is going to start writing the data from
> 0x00000000.
> >
> > 2. How big a space this uncompressing process
> needs?
> > And also how much overall memory is required for
> > running linux. I just have 8MB SDRAM.
> >
> > 3. What is the next step in the booting process?
> > Which
> > Device (eth, pci, ide, ???) Initialization?
> >
> > Your help is appreciated.
> >
> > thanks,
> > Prakash
> >
> >
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Next round of AGPGART fixes.
From: Felix Seeger @ 2002-12-20 16:41 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel
In-Reply-To: <200212201542.48221.felix.seeger@gmx.de>
Am Freitag 20 Dezember 2002 15:42 schrieb Felix Seeger:
> Am Freitag 20 Dezember 2002 13:41 schrieb Dave Jones:
> > Linus,
> > Please pull from bk://linux-dj.bkbits.net/agpgart to get at the
> > following fixes..
> >
> > - AGP 3.0 now compiles as a module too.
> > - beginnings of VIA KT400 AGP 3.0 support.
> > (Not functional yet, more work needed).
> > - corrected handling of AGP capability bit in PCI headers for chipset
> > drivers. This should fix the problems on I815 and similar chipsets.
>
> [...]
>
> > Dave
>
> I am running 2.5.52bk5 with you GNU patch. Doesn't help.
> I do a modprobe i810 and I get:
>
> FATAL: Error inserting i810
> (/lib/modules/2.5.52bk5/kernel/drivers/char/drm/i810.ko): Cannot allocate
> memory
>
Mhm, I compiled all in the kernel and it works now, maybe I've done something
wrong.
thanks
have fun
Felix
^ permalink raw reply
* [PATCH 2.4] Enable checking of reap of in-use slab
From: James Bottomley @ 2002-12-20 16:45 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: James.Bottomley, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
Hi Marcelo,
On older (2.4.9) kernels, we keep running into the occasional attempts to reap
in-use slabs. The checks for this were compiled out on 2.4.10 and above in
the name of efficiency.
I'd like to add the checks just for the in use parts back just to make
assurances doubly sure that this bug is actually fixed, not just obscured.
The changes use the BUG_ON macro, so the actual debugging stuff is in the
unlikely branch which shouldn't impact the critical path too much.
Please consider applying for 2.4.22
Thanks,
James
[-- Attachment #2: tmp.diff --]
[-- Type: text/plain , Size: 882 bytes --]
===== mm/slab.c 1.21 vs edited =====
--- 1.21/mm/slab.c Mon Dec 16 00:22:20 2002
+++ edited/mm/slab.c Fri Dec 20 10:33:02 2002
@@ -928,10 +928,9 @@
break;
slabp = list_entry(cachep->slabs_free.prev, slab_t, list);
-#if DEBUG
- if (slabp->inuse)
- BUG();
-#endif
+
+ BUG_ON(slabp->inuse);
+
list_del(&slabp->list);
spin_unlock_irq(&cachep->spinlock);
@@ -1785,10 +1784,9 @@
p = searchp->slabs_free.next;
while (p != &searchp->slabs_free) {
slabp = list_entry(p, slab_t, list);
-#if DEBUG
- if (slabp->inuse)
- BUG();
-#endif
+
+ BUG_ON(slabp->inuse);
+
full_free++;
p = p->next;
}
@@ -1838,10 +1836,9 @@
if (p == &best_cachep->slabs_free)
break;
slabp = list_entry(p,slab_t,list);
-#if DEBUG
- if (slabp->inuse)
- BUG();
-#endif
+
+ BUG_ON(slabp->inuse);
+
list_del(&slabp->list);
STATS_INC_REAPED(best_cachep);
^ permalink raw reply
* Re: After Uncompresseing Linux..., what's next
From: Gary Thomas @ 2002-12-20 16:38 UTC (permalink / raw)
To: Prakash kanthi; +Cc: linuxppc embedded
In-Reply-To: <20021220161436.81737.qmail@web41212.mail.yahoo.com>
On Fri, 2002-12-20 at 09:14, Prakash kanthi wrote:
>
> Folks,
>
> I just wanted to provide more info on my env. I have
> PPC405 based board with no network support forcing me
> to use zImage.initrd.elf.
>
> Can you suggest more on my problem described below? I
> saw the memory values at 0x00000000 onwards after
> uncompressing linux and they have changed. But when
> the control jumps to 0x0, my board hangs. I see that
> ESR is showing a value of 0x80000000, meaning either
> illegal instruction or Machine Check.
>
> Can you tell what's going on? What happens next after
> uncompressing? I am thinking it executes start_kernel
> function which calls lock_kernel. Let me know if i am
> wrong.
>
A *lot* happens, even before the first "printk"!
At the point where the kernel is being started, all that
has happened is the basic image has been loaded to low
memory. The kernel then needs to set up the memory management
(to map things the way it wants to), then perform quite a
lot of initialization, then start up the generic kernel
which will then do things like initialize devices, etc.
Since you just say you have a board (and don't name it),
I assume that you are porting Linux yourself. In this case,
you'll either need some tools (like the BDI already mentioned)
or a lot of patience. You'll need to look at how the kernel
is trying to do its work, at least to the point where you can
get to the first "printk" (which comes during the memory 'find'
sequence on the PPC in arch/ppc/mm/ppc_mmu.c). Once you get
this far, and printk is working, you can then move on and find
out what else needs to be done.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: After Uncompresseing Linux..., what's next
From: Jim Potter @ 2002-12-20 16:47 UTC (permalink / raw)
To: Prakash kanthi; +Cc: LinuxPPC
In-Reply-To: <20021220161436.81737.qmail@web41212.mail.yahoo.com>
Actually it executes quite a lot of code in head.S, before it gets to
start_kernel. Check to see if you can find out exactly where the problem
occurs (for example, on the 74xx cpus, registers SRR0 & SRR1 have this info).
> Folks,
>
> I just wanted to provide more info on my env. I have
> PPC405 based board with no network support forcing me
> to use zImage.initrd.elf.
>
> Can you suggest more on my problem described below? I
> saw the memory values at 0x00000000 onwards after
> uncompressing linux and they have changed. But when
> the control jumps to 0x0, my board hangs. I see that
> ESR is showing a value of 0x80000000, meaning either
> illegal instruction or Machine Check.
>
> Can you tell what's going on? What happens next after
> uncompressing? I am thinking it executes start_kernel
> function which calls lock_kernel. Let me know if i am
> wrong.
>
> thanks,
> Prakash
>
> --- James Don <JDon@spacebridge.com> wrote:
> > I just went thru this myself ... ;-)
> >
> > 1.) Get a BDM/JTAG tool look halt the processor
> > after you see " Now booting
> > the kernel" and look for valid asm at 0x0 ... make
> > sure it mathes your
> > start.s file ...
> >
> > 2.) Veryfy you have your mem map from ppcboot
> > matching requirements for the
> > kernel i.e ram (physical=0x0, virtual=0xc0000000)
> > and immr (phys 0xff000000
> > virtual 0xff000000) ... I had my immr in ppc boot at
> > 0x02200000 this screwed
> > me for quite a while ... otherwise you have no
> > printk ... the memory map is
> > very important not to screw with some things depend
> > on it (unless your
> > careful) ...
> >
> > 3.) verify you SMC1 (uart) is getting proper
> > clocking config ... i.e
> > bus->brg1 and brg1 is 16 times baud rate ...
> > otherwise you have no printk
> >
> > 4.) and always always keep in mind your RAM refesh
> > could be wrong ...
> > everyone will tell you this even when it has nothing
> > to do with your problem
> > ... try not to ignore them if you are still stuck
> > ;-) But verifying step 1
> > should prove your ok ...
> >
> > Best of luck,
> > Jim
> >
> >
> > -----Original Message-----
> > From: Prakash kanthi [mailto:pkanthi@yahoo.com]
> > Sent: Wednesday, December 18, 2002 7:14 PM
> > To: LinuxPPC
> > Subject: After Uncompresseing Linux..., what's next
> >
> >
> > Hi there,
> >
> > I was trying to load linuxppc_2_4_devel onto my
> > board.
> > It goes through the board info read, UART init and
> > Uncompressing the linux kernel. But after that, i do
> > not see any messages and board hangs.
> >
> > Here is the UART output:
> > ------------------------------------
> > OS Booting...
> >
> > loaded at: 00400000 0060D1CC
> > board data at: 00000030 00000044
> > relocated to: 00405C24 00405C38
> > zimage at: 00406290 004A08FF
> > initrd at: 004A1000 006097CA
> > avail ram: 0060E000 007F8000
> >
> > Linux/PPC load: console=ttyS0,9600 console=tty1
> > ip=on
> > root=/dev/xsysace/disc0/pa
> > rt3 rw
> > Uncompressing Linux...done.
> > Now booting the kernel
> > -------------------------------------------
> >
> > After the last line, it hangs. I get a feeling that,
> > the uncompressing process is not writing in the
> > memory
> > starting from 0x00000000 and, after uncompressing,
> > it
> > is jumping into 0x00000000 and is not able to find
> > anything.
> >
> > My questions are,
> > 1. How can i make sure that, the uncompressing
> > process
> > is going to start writing the data from 0x00000000.
> >
> > 2. How big a space this uncompressing process needs?
> > And also how much overall memory is required for
> > running linux. I just have 8MB SDRAM.
> >
> > 3. What is the next step in the booting process?
> > Which
> > Device (eth, pci, ide, ???) Initialization?
> >
> > Your help is appreciated.
> >
> > thanks,
> > Prakash
> >
> >
>
--
Sincerely,
Jim Potter
45th Parallel Processing
Firefighting: Bustin' ours, Savin' yours.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: After Uncompresseing Linux..., what's next
From: Prakash kanthi @ 2002-12-20 16:48 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc embedded
In-Reply-To: <1040402316.32282.6202.camel@hermes.chez-thomas.org>
I do have xilinx tools and i am working with their V2P
product. I completely understands what you are said.
But the problem is, right after the uncompression and
cpy to 0x00000000, i loose total control because i
don't have any clue what is getting executed.
And also, i have my boot monitor code at 0x00000000,
before uncompress process overwrites it. I see that
some of that code is getting executed after jump to
0x0. I reason i am overwriting 0x0 is because, i only
have 8MB RAM.
thanks,
Prakash
--- Gary Thomas <gary@chez-thomas.org> wrote:
> On Fri, 2002-12-20 at 09:14, Prakash kanthi wrote:
> >
> > Folks,
> >
> > I just wanted to provide more info on my env. I
> have
> > PPC405 based board with no network support forcing
> me
> > to use zImage.initrd.elf.
> >
> > Can you suggest more on my problem described
> below? I
> > saw the memory values at 0x00000000 onwards after
> > uncompressing linux and they have changed. But
> when
> > the control jumps to 0x0, my board hangs. I see
> that
> > ESR is showing a value of 0x80000000, meaning
> either
> > illegal instruction or Machine Check.
> >
> > Can you tell what's going on? What happens next
> after
> > uncompressing? I am thinking it executes
> start_kernel
> > function which calls lock_kernel. Let me know if i
> am
> > wrong.
> >
>
> A *lot* happens, even before the first "printk"!
>
> At the point where the kernel is being started, all
> that
> has happened is the basic image has been loaded to
> low
> memory. The kernel then needs to set up the memory
> management
> (to map things the way it wants to), then perform
> quite a
> lot of initialization, then start up the generic
> kernel
> which will then do things like initialize devices,
> etc.
>
> Since you just say you have a board (and don't name
> it),
> I assume that you are porting Linux yourself. In
> this case,
> you'll either need some tools (like the BDI already
> mentioned)
> or a lot of patience. You'll need to look at how
> the kernel
> is trying to do its work, at least to the point
> where you can
> get to the first "printk" (which comes during the
> memory 'find'
> sequence on the PPC in arch/ppc/mm/ppc_mmu.c). Once
> you get
> this far, and printk is working, you can then move
> on and find
> out what else needs to be done.
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: After Uncompresseing Linux..., what's next
From: Jim Potter @ 2002-12-20 16:49 UTC (permalink / raw)
To: Prakash kanthi; +Cc: LinuxPPC
In-Reply-To: <20021220163238.45233.qmail@web41215.mail.yahoo.com>
The early code needs to perform many privileged instructions; make sure that
you aren't restricting the cpu to only user instructions.
> I found the correct exception guys. It means
> Privileged Instruction Exception.
>
> --- Prakash kanthi <pkanthi@yahoo.com> wrote:
> >
> > Folks,
> >
> > I just wanted to provide more info on my env. I have
> > PPC405 based board with no network support forcing
> > me
> > to use zImage.initrd.elf.
> >
> > Can you suggest more on my problem described below?
> > I
> > saw the memory values at 0x00000000 onwards after
> > uncompressing linux and they have changed. But when
> > the control jumps to 0x0, my board hangs. I see that
> > ESR is showing a value of 0x80000000, meaning either
> > illegal instruction or Machine Check.
> >
> > Can you tell what's going on? What happens next
> > after
> > uncompressing? I am thinking it executes
> > start_kernel
> > function which calls lock_kernel. Let me know if i
> > am
> > wrong.
> >
> > thanks,
> > Prakash
> >
> >
> >
> >
> > --- James Don <JDon@spacebridge.com> wrote:
> > > I just went thru this myself ... ;-)
> > >
> > > 1.) Get a BDM/JTAG tool look halt the processor
> > > after you see " Now booting
> > > the kernel" and look for valid asm at 0x0 ... make
> > > sure it mathes your
> > > start.s file ...
> > >
> > > 2.) Veryfy you have your mem map from ppcboot
> > > matching requirements for the
> > > kernel i.e ram (physical=0x0, virtual=0xc0000000)
> > > and immr (phys 0xff000000
> > > virtual 0xff000000) ... I had my immr in ppc boot
> > at
> > > 0x02200000 this screwed
> > > me for quite a while ... otherwise you have no
> > > printk ... the memory map is
> > > very important not to screw with some things
> > depend
> > > on it (unless your
> > > careful) ...
> > >
> > > 3.) verify you SMC1 (uart) is getting proper
> > > clocking config ... i.e
> > > bus->brg1 and brg1 is 16 times baud rate ...
> > > otherwise you have no printk
> > >
> > > 4.) and always always keep in mind your RAM refesh
> > > could be wrong ...
> > > everyone will tell you this even when it has
> > nothing
> > > to do with your problem
> > > ... try not to ignore them if you are still stuck
> > > ;-) But verifying step 1
> > > should prove your ok ...
> > >
> > > Best of luck,
> > > Jim
> > >
> > >
> > > -----Original Message-----
> > > From: Prakash kanthi [mailto:pkanthi@yahoo.com]
> > > Sent: Wednesday, December 18, 2002 7:14 PM
> > > To: LinuxPPC
> > > Subject: After Uncompresseing Linux..., what's
> > next
> > >
> > >
> > > Hi there,
> > >
> > > I was trying to load linuxppc_2_4_devel onto my
> > > board.
> > > It goes through the board info read, UART init and
> > > Uncompressing the linux kernel. But after that, i
> > do
> > > not see any messages and board hangs.
> > >
> > > Here is the UART output:
> > > ------------------------------------
> > > OS Booting...
> > >
> > > loaded at: 00400000 0060D1CC
> > > board data at: 00000030 00000044
> > > relocated to: 00405C24 00405C38
> > > zimage at: 00406290 004A08FF
> > > initrd at: 004A1000 006097CA
> > > avail ram: 0060E000 007F8000
> > >
> > > Linux/PPC load: console=ttyS0,9600 console=tty1
> > > ip=on
> > > root=/dev/xsysace/disc0/pa
> > > rt3 rw
> > > Uncompressing Linux...done.
> > > Now booting the kernel
> > > -------------------------------------------
> > >
> > > After the last line, it hangs. I get a feeling
> > that,
> > > the uncompressing process is not writing in the
> > > memory
> > > starting from 0x00000000 and, after uncompressing,
> > > it
> > > is jumping into 0x00000000 and is not able to find
> > > anything.
> > >
> > > My questions are,
> > > 1. How can i make sure that, the uncompressing
> > > process
> > > is going to start writing the data from
> > 0x00000000.
> > >
> > > 2. How big a space this uncompressing process
> > needs?
> > > And also how much overall memory is required for
> > > running linux. I just have 8MB SDRAM.
> > >
> > > 3. What is the next step in the booting process?
> > > Which
> > > Device (eth, pci, ide, ???) Initialization?
> > >
> > > Your help is appreciated.
> > >
> > > thanks,
> > > Prakash
> > >
> > >
> >
> >
> >
>
--
Sincerely,
Jim Potter
45th Parallel Processing
Firefighting: Bustin' ours, Savin' yours.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-20 16:47 UTC (permalink / raw)
To: Jamie Lokier
Cc: Ulrich Drepper, bart, davej, hpa, terje.eggestad, matti.aarnio,
hugh, mingo, linux-kernel
In-Reply-To: <20021220120656.GA20674@bjl1.asuk.net>
On Fri, 20 Dec 2002, Jamie Lokier wrote:
>
> Ulrich Drepper wrote:
> > int $0x80 -> call *%gs:0x18
>
> The calling convention has been (slightly) changed - i.e. 6 argument
> calls don't work, so why not go a bit further: allow the vsyscall entry
> point to clobber more GPRs?
Actually, six-argument syscalls _do_ work. I admit that the way to make
them work is "interesting", but it's also extremely simple.
> The benefit is that this allows Glibc to do a wholesale replacement of
> "int $0x80" -> "single call instruction". Otherwise, those pushes are
> completely unnecessary. It could be this short instead:
>
> vsyscall:
> movl %esp,%ebp
> sysenter
> jmp vsyscall
> ret
Yes, we could have changed the implementation to clobber more registers,
but if we want to support all system calls it would still have to save
%ebp, so the minimal approach would have been
vsyscall:
pushl %ebp
0:
movl %esp,%ebp
sysenter
jmp 0b /* only done for restarting */
popl %ebp
ret
which is all of 4 (simple) instructions cheaper than the one we have now.
And if the caller cannot depend on registers being saved, the caller may
actually end up being more complicated. For example, with the current
setup, you can have
getpid():
movl $__NR_getpid,%eax
jmp *%gs:0x18
but if system calls clobber registers, the caller needs to be
getpid():
pushl %ebx
pushl %esi
pushl %edi
pushl %ebp
movl $__NR_getpid,%eax
call *%gs:0x18
popl %ebp
popl %edi
popl %esi
popl %ebx
ret
and notice how the _real_ code sequence actually got much _worse_ from the
fact that you tried to save time by not saving registers.
> It is nice to be able to use the _exact_ same convention in glibc, for
> getting a patch out of the door quickly. But it is just as easy to do
> that putting the pushes and pops into the library itself:
>
> Instead of
>
> int $0x80 -> call *%gs:0x18
>
> Write
>
> int $0x80 -> pushl %ebp
> pushl %ecx
> pushl %edx
> call *%gs:0x18
> popl %edx
> popl %ecx
> popl %ebp
But where's the advantage then? You use the same number of instructions
dynamically, and you use _more_ icache space than if you have the pushes
and pops in just one place?
> It has exactly the same cost as the current patches, but provides
> userspace with more optimisation flexibility, using an asm clobber
> list instead of explicit instructions for inline syscalls, etc.
In practice, there is nothing around the call. And you have to realize
that the pushes and pops you added in your version are _wasted_ for other
cases. If the system call ends up being int 0x80, you just wasted time. If
the system call ended up being AMD's x86-64 version of syscall, you just
wsted time.
The advantage of putting all the register save in the trampoline is that
user mode literally doesn't have to _know_ what it is calling. It only
needs to know two simple rules:
- registers are preserved (except for %eax which is the return value, of
course)
- it should fill in arguments in %ebx, %ecx ... (but the things that
aren't arguments can just be left untouched)
And then depending on what the real low-level calling convention is, the
trampoline will save the _minimum_ number of registers (ie some calling
conventions might clobber different registers than %ecx/%edx - you have to
remember that "sysenter" is just _one_ out of at least three calling
conventions available).
Linus
^ permalink raw reply
* Re: [PATCH] Fix CPU bitmask truncation
From: Bjorn Helgaas @ 2002-12-20 17:00 UTC (permalink / raw)
To: William Lee Irwin III, torvalds, linux-kernel, Andreas Schwab
In-Reply-To: <20021220111523.GA7644@holomorphy.com>
On Friday 20 December 2002 4:15 am, William Lee Irwin III wrote:
> Actually, this looks like a non-issue from userspace on the IA64 boxen
> I can get to. akpm pointed out that this seemed to pass his testing,
> and on deeper inspection, IA64 userspace did not find this to be an issue.
>
> Bjorn, could you explain on what toolchains and/or architectures you had
> this issue? It sounds serious and/or real enough yet I can't actually
> make this happen myself.
This was an issue with gcc 2.96 on a 64-way IA64 box. I don't have
access to one at the moment, but as I remember, without the 2.4 changes:
- ((p)->cpus_runnable & (p)->cpus_allowed & (1 << cpu))
+ ((p)->cpus_runnable & (p)->cpus_allowed & (1UL << cpu))
nothing would get scheduled on CPUs 32-63. I guess those changes
aren't controversial, though.
The question of whether this was strictly necessary:
- cpus_runnable: -1, \
- cpus_allowed: -1, \
+ cpus_runnable: ~0UL, \
+ cpus_allowed: ~0UL, \
I don't specifically recall, and a quick test suggests that it really
doesn't matter. Since cpus_runnable and cpus_allowed are declared
unsigned long, I think ~0UL is a more direct expression of what is
desired, but maybe that's just a personal preference.
Bjorn
^ permalink raw reply
* Re: After Uncompresseing Linux..., what's next
From: Gary Thomas @ 2002-12-20 16:52 UTC (permalink / raw)
To: Prakash kanthi; +Cc: linuxppc embedded
In-Reply-To: <20021220164821.77027.qmail@web41213.mail.yahoo.com>
On Fri, 2002-12-20 at 09:48, Prakash kanthi wrote:
> I do have xilinx tools and i am working with their V2P
> product. I completely understands what you are said.
> But the problem is, right after the uncompression and
> cpy to 0x00000000, i loose total control because i
> don't have any clue what is getting executed.
>
What sort of things can you do with the Xilinx tools? Is
there any way to set [hardware] breakpoints or single step?
> And also, i have my boot monitor code at 0x00000000,
> before uncompress process overwrites it. I see that
> some of that code is getting executed after jump to
> 0x0. I reason i am overwriting 0x0 is because, i only
> have 8MB RAM.
>
8M should be plenty of RAM.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [parisc-linux] 2.4.21-pre2 : sysctl.h pb
From: jsoe0708 @ 2002-12-20 16:52 UTC (permalink / raw)
To: Randolph Chung; +Cc: parisc-linux
In-Reply-To: <20021220152034.GC31792@tausq.org>
Hi Randolph,
>> Merging 2.4.21-pre2 with parisc tree, I notice the following the follo=
wing
>> pb:
>
>just bump the hppa numbers
>> KERN_HPPA_PWRSW=3D55, /* int: hppa soft-power enable */
>> KERN_HPPA_UNALIGNED=3D56, /* int: hppa unaligned-trap enable *=
/
>
>make these 57, 58 or so
>
>it seems a bit odd to me that the sysctl number space is not
>partitioned, but...
>
Well I choose 57 and obtain a vmlinux.
But eventhought I used my config file I get this time a system which hung=
on my b2k at 'Search Devices...' and the green led stay continiously ligh=
t???
I will try to fix it next year :-))
Thanks for advise,
Joel
********************************************
Promo Tiscali ADSL: 35 Euros/mois, 1er mois et activation =3D 0 Euro http=
://adsl.tiscali.be
^ permalink raw reply
* Re: PATCH 2.5.x disable BAR when sizing
From: Linus Torvalds @ 2002-12-20 17:05 UTC (permalink / raw)
To: davidm; +Cc: linux-kernel
In-Reply-To: <15874.58889.846488.868570@napali.hpl.hp.com>
On Fri, 20 Dec 2002, David Mosberger wrote:
>
> Could you please stop this ia64 paranoia and instead explain to me why
> it's OK to relocate a PCI device to (0x100000000-PCI_dev_size)
> temporarily? That just seems horribly unsafe to me.
No. It's not horribly unsafe at all. It's very safe, for one simple
reason: it's how PCI probing has _always_ been done. Exactly because the
alternatives simply do not work.
I can also tell you why it does work, and why it's supposed to work: by
writing 0xffffffff to the BAR register, you basically move the BAR to high
PCI memory - even if it was enabled before. Which is fine, as long as
nobody else is in that high memory. So the secondary rule to "don't turn
off MEM or IO accesses" is "never allocate real PCI BAR resources at the
top of memory".
Think about it: if you move the BAR to high memory, you basically disable
only _that_ bar, and nothing else. You don't clobber any other associated
functions, or anything like that. It's clearly a _less_ disruptive thing
than disabling access to the whole device.
Anyway, why do you really want to add the MEM/IO disable? Do you actually
have a device that wants it, or are you just blinded by documentation
written by somebody who had no idea about what real life is all about?
> The PCI spec
> seems to say the same as it says pretty clearly that memory decoding
> should be disabled during BAR-sizing. If certain bridges cause
> problems, perhaps those need to be special-cased?
No. Do it the other way around: if there is some specific chipset that
actually _needs_ the disable, you do THAT special cased.
Because the current code works on everything that we know about, and we
_know_ that the disable doesn't work. As Ivan already pointed out, it's
not just bridges. When you disable IO/MEM accesses, you often disable
_everything_, which can break pretty much anything.
(I say "often", because it does actually depend on the chipset. Some chips
only seem to disable the BAR entries. Others disable all the "extended"
ports too, and leave only config space accessible after you've disable
IO/MEM)
The cases I've seen are northbridges that stop forwarding DMA, and USB
controllers that are still in legacy mode (because the BAR probing happens
before the USB driver has had a chance to _change_ it), where disabling IO
and/or MEM will cause the SMM code that does the legacy handling to just
lock up, since suddenly the hardware they expect to be there doesn't
respond any more.
Ivan pointed out that it also disables things like VGA legacy registers.
It will disable IDE legacy registers too, btw. I'd also expect it to
disable IDE DMA access, so if you happen to be trying to probe the BAR's
after somebody started IO on the IDE, you just made that IO fail
spectacularly, and I'd not be surprised if the IDE controller just locked
up as a result.
Let me re-iterate the "turn power off at the master switch in a house when
switching a light bulb" analogy. Yes, it's a good idea if you are nervous,
but you do that only when you _know_ who is in the house and you know what
they are doing and it's ok by them.
For example, it would be fine for a low-level driver (who has already
taken control of the device) to turn the device off. But it is NOT fine to
do it in general.
One solution in the long term may be to not even probe the BAR's at all in
generic code, and only do it in the pci_enable_dev() stuff. That way it
would literally only be done by the driver, who can hopefully make sure
that the device is ok with it.
Linus
^ permalink raw reply
* Reading battery looks up system
From: TornieriC-YDxpq3io04c @ 2002-12-20 16:59 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Hi,
I recently install mandrake 9.0 and replace kernel with mandrake kernel 2.4.20. All seems to work fine but battery. When I read battery state or info with cat /proc/acpi/battery/... it hangs my system.
I've already seen some posts on this topic but I have not find any solution.
Thanks for any help.
Christophe.
-------------------------------------------------------
This SF.NET email is sponsored by: The Best Geek Holiday Gifts!
Time is running out! Thinkgeek.com has the coolest gifts for
your favorite geek. Let your fingers do the typing. Visit Now.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: After Uncompresseing Linux..., what's next
From: Jim Potter @ 2002-12-20 17:02 UTC (permalink / raw)
To: Prakash kanthi, LinuxPPC
In-Reply-To: <3E034A34.A2E32F46@wvi.com>
I'm not especially familiar with the 4xx cpus, but on the 74xx cpus the MSR
register has the "privilege level" bit, which determines if the processor can
execute both user- and supervisor-level instructions, or only user-level
instructions.
This needs to be setup by the bootloader to allow supervisor-level instructions
to be executed, else you'll see some errors.
> The early code needs to perform many privileged instructions; make sure that
> you aren't restricting the cpu to only user instructions.
>
> > I found the correct exception guys. It means
> > Privileged Instruction Exception.
> >
> > --- Prakash kanthi <pkanthi@yahoo.com> wrote:
> > >
> > > Folks,
> > >
> > > I just wanted to provide more info on my env. I have
> > > PPC405 based board with no network support forcing
> > > me
> > > to use zImage.initrd.elf.
> > >
> > > Can you suggest more on my problem described below?
> > > I
> > > saw the memory values at 0x00000000 onwards after
> > > uncompressing linux and they have changed. But when
> > > the control jumps to 0x0, my board hangs. I see that
> > > ESR is showing a value of 0x80000000, meaning either
> > > illegal instruction or Machine Check.
> > >
> > > Can you tell what's going on? What happens next
> > > after
> > > uncompressing? I am thinking it executes
> > > start_kernel
> > > function which calls lock_kernel. Let me know if i
> > > am
> > > wrong.
> > >
> > > thanks,
> > > Prakash
> > >
> > >
> > >
> > >
> > > --- James Don <JDon@spacebridge.com> wrote:
> > > > I just went thru this myself ... ;-)
> > > >
> > > > 1.) Get a BDM/JTAG tool look halt the processor
> > > > after you see " Now booting
> > > > the kernel" and look for valid asm at 0x0 ... make
> > > > sure it mathes your
> > > > start.s file ...
> > > >
> > > > 2.) Veryfy you have your mem map from ppcboot
> > > > matching requirements for the
> > > > kernel i.e ram (physical=0x0, virtual=0xc0000000)
> > > > and immr (phys 0xff000000
> > > > virtual 0xff000000) ... I had my immr in ppc boot
> > > at
> > > > 0x02200000 this screwed
> > > > me for quite a while ... otherwise you have no
> > > > printk ... the memory map is
> > > > very important not to screw with some things
> > > depend
> > > > on it (unless your
> > > > careful) ...
> > > >
> > > > 3.) verify you SMC1 (uart) is getting proper
> > > > clocking config ... i.e
> > > > bus->brg1 and brg1 is 16 times baud rate ...
> > > > otherwise you have no printk
> > > >
> > > > 4.) and always always keep in mind your RAM refesh
> > > > could be wrong ...
> > > > everyone will tell you this even when it has
> > > nothing
> > > > to do with your problem
> > > > ... try not to ignore them if you are still stuck
> > > > ;-) But verifying step 1
> > > > should prove your ok ...
> > > >
> > > > Best of luck,
> > > > Jim
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Prakash kanthi [mailto:pkanthi@yahoo.com]
> > > > Sent: Wednesday, December 18, 2002 7:14 PM
> > > > To: LinuxPPC
> > > > Subject: After Uncompresseing Linux..., what's
> > > next
> > > >
> > > >
> > > > Hi there,
> > > >
> > > > I was trying to load linuxppc_2_4_devel onto my
> > > > board.
> > > > It goes through the board info read, UART init and
> > > > Uncompressing the linux kernel. But after that, i
> > > do
> > > > not see any messages and board hangs.
> > > >
> > > > Here is the UART output:
> > > > ------------------------------------
> > > > OS Booting...
> > > >
> > > > loaded at: 00400000 0060D1CC
> > > > board data at: 00000030 00000044
> > > > relocated to: 00405C24 00405C38
> > > > zimage at: 00406290 004A08FF
> > > > initrd at: 004A1000 006097CA
> > > > avail ram: 0060E000 007F8000
> > > >
> > > > Linux/PPC load: console=ttyS0,9600 console=tty1
> > > > ip=on
> > > > root=/dev/xsysace/disc0/pa
> > > > rt3 rw
> > > > Uncompressing Linux...done.
> > > > Now booting the kernel
> > > > -------------------------------------------
> > > >
> > > > After the last line, it hangs. I get a feeling
> > > that,
> > > > the uncompressing process is not writing in the
> > > > memory
> > > > starting from 0x00000000 and, after uncompressing,
> > > > it
> > > > is jumping into 0x00000000 and is not able to find
> > > > anything.
> > > >
> > > > My questions are,
> > > > 1. How can i make sure that, the uncompressing
> > > > process
> > > > is going to start writing the data from
> > > 0x00000000.
> > > >
> > > > 2. How big a space this uncompressing process
> > > needs?
> > > > And also how much overall memory is required for
> > > > running linux. I just have 8MB SDRAM.
> > > >
> > > > 3. What is the next step in the booting process?
> > > > Which
> > > > Device (eth, pci, ide, ???) Initialization?
> > > >
> > > > Your help is appreciated.
> > > >
> > > > thanks,
> > > > Prakash
> > > >
> > > >
> > >
> > >
> > >
> >
>
> --
> Sincerely,
>
> Jim Potter
> 45th Parallel Processing
>
> Firefighting: Bustin' ours, Savin' yours.
>
--
Sincerely,
Jim Potter
45th Parallel Processing
Firefighting: Bustin' ours, Savin' yours.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH] Fix CPU bitmask truncation
From: William Lee Irwin III @ 2002-12-20 17:12 UTC (permalink / raw)
To: Andreas Schwab; +Cc: torvalds, linux-kernel, bjorn_helgaas
In-Reply-To: <je7ke4yje3.fsf@sykes.suse.de>
William Lee Irwin III <wli@holomorphy.com> writes:
|> ===== include/linux/init_task.h 1.19 vs edited =====
|> --- 1.19/include/linux/init_task.h Sun Sep 29 07:02:55 2002
|> +++ edited/include/linux/init_task.h Fri Dec 20 02:22:04 2002
|> @@ -63,7 +63,7 @@
|> .prio = MAX_PRIO-20, \
|> .static_prio = MAX_PRIO-20, \
|> .policy = SCHED_NORMAL, \
|> - .cpus_allowed = -1, \
|> + .cpus_allowed = ~0UL, \
On Fri, Dec 20, 2002 at 01:17:24PM +0100, Andreas Schwab wrote:
> This is useless. Assigning -1 to any unsigned type is garanteed to give
> you all bits one, and with two's complement this also holds for any signed
> type.
Not so on all gcc versions. The rest of the world can figure out what
to do about the versions that do not.
Bill
^ permalink raw reply
* Re: After Uncompresseing Linux..., what's next
From: Prakash kanthi @ 2002-12-20 17:06 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc embedded
In-Reply-To: <1040403153.32282.6220.camel@hermes.chez-thomas.org>
Gary,
I really appreciate your help. Here is what i am
doing. Sorry it is little long. But was necessasry.
1. I have a boot loader(xrom.elf) of size around 400KB
which basically have menu driven tests along with an
option to jump to linux kernel(zImage.initrd.elf).
2. xrom.elf is compiled to start at 0xfffffffc and
jump to 0x00000000 to have rest of functionality.
zImage.initrd.elf is compiled to start at 0x00400000.
3. I load zImage.initrd.elf first and then xrom.elf
(xilinx tool makes sure that they are loaded to
corresponding locations based on ELF header).
4. After loading both, i start running xrom.elf and it
shows up a menu in my UART terminal. I jump to linux
(0x00400000).
5. I see that linux is basically reading the board
info, setting UART, prints some boot messages onto it
and then performs uncompression (gunzip function takes
the rest of linux image and puts the uncompressed code
starting from 0x0).
6. Up untill, everything is ok. After this, control
jumps to 0x0 and starts executing.
My problems are,
a. Once the uncompression process is done, i am not
sure if the image is copied to 0x0 (i do see value
changes in memory starting from 0x0).
b. As uncompression process is embedded into
zImage.initrd.elf, i do not objdump does not tell me
which function it is going to execute after
uncompression.
Please suggest.
Thanks,
Prakash
--- Gary Thomas <gary@chez-thomas.org> wrote:
> On Fri, 2002-12-20 at 09:48, Prakash kanthi wrote:
> > I do have xilinx tools and i am working with their
> V2P
> > product. I completely understands what you are
> said.
> > But the problem is, right after the uncompression
> and
> > cpy to 0x00000000, i loose total control because i
> > don't have any clue what is getting executed.
> >
>
> What sort of things can you do with the Xilinx
> tools? Is
> there any way to set [hardware] breakpoints or
> single step?
>
> > And also, i have my boot monitor code at
> 0x00000000,
> > before uncompress process overwrites it. I see
> that
> > some of that code is getting executed after jump
> to
> > 0x0. I reason i am overwriting 0x0 is because, i
> only
> > have 8MB RAM.
> >
>
> 8M should be plenty of RAM.
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH][2.4] generic cluster APIC support for systems with m ore than 8 CPUs
From: William Lee Irwin III @ 2002-12-20 17:16 UTC (permalink / raw)
To: Van Maren, Kevin
Cc: Christoph Hellwig, James Cleverdon, Pallipadi, Venkatesh,
Linux Kernel, Martin Bligh, John Stultz, Nakajima, Jun,
Mallick, Asit K, Saxena, Sunil, Protasevich, Natalie
In-Reply-To: <3FAD1088D4556046AEC48D80B47B478C0101F55D@usslc-exch-4.slc.unisys.com>
On Fri, Dec 20, 2002 at 09:46:19AM -0600, Van Maren, Kevin wrote:
> I mostly work on our 16-32p IA64 machines. Natalie or someone else will
> have to comment on the clustered-apic code.
Okay, that's not too big a deal. I didn't expect you'd field it directly.
On Fri, Dec 20, 2002 at 09:46:19AM -0600, Van Maren, Kevin wrote:
> Also, as a clarification, our 32-processor systems are NOT NUMA: there
> is a full non-blocking crossbar to memory. So clustered APIC support
> should not be dependant on NUMA.
That one's easy to fix (and apparently for you to spot despite not
actually working on the things).
Thanks,
Bill
^ permalink raw reply
* Re: [PATCH]Timer list init is done AFTER use
From: george anzinger @ 2002-12-20 17:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel@vger.kernel.org, Linus Torvalds
In-Reply-To: <3E02F073.BF57207C@digeo.com>
Andrew Morton wrote:
>
> george anzinger wrote:
> >
> > On SMP systems the timer list init is done by way of a
> > cpu_notifier call. This has two problems:
> >
> > 1.) Timers are started WAY before the cpu_notifier call
> > chain is executed. In particular the console blanking timer
> > is deleted and inserted every time printk() is called. That
> > this does not fail is only because the kernel has yet to
> > protect location zero.
>
> But init_timers() directly calls timer_cpu_notify(), which directly
> calls init_timers_cpu().
>
> So your patch appears to be a no-op for the boot CPU.
That is correct. The problem is when cpu_init is called for
the secondary cpus. It almost immediately calls printk.
You can put a break point here, wait for the second entry
and then in mod_timer. You will see that mod_timer grabs
the "base" for the second cpu which is not initialized.
>
> > 2.) This notifier is called when a cpu comes up. I suspect
> > that initializing the timer list when a hot swap of a cpu is
> > done is NOT the right thing to do. In any case, if this is
> > a desired action, the list still needs to be initialized
> > prior to its use.
>
> It should be OK as-is? The CPU_UP_PREPARE callout is performed
> before the secondary starts doing things. Its timers are initialised.
Yes, but not really. As noted, the timers are called as a
result of printk. (I use a standard pc for this so the
console is on the standard pc tube. I don't know about
other consoles...) My comments here are a wonderment if
this is the right thing to do when doing a hot swap of the
cpu. I sort of doubt that this is correct.
>
> > The attached patch initializes all the timer lists at
> > init_timers time and does not put code in the notify list.
>
> But the patch assumes that the per-cpu data exists for all CPUs - even
> the !cpu_possible() ones.
True.
>
> This is true at present. But the intent here is that the per-cpu
> storage be allocated as the CPUs come up, and in their node-local
> memory. That saves memory and presumably having the cpu-local timers
> in the cpu-local memory is a good thing.
>
I agree. It is possible that we may want to hold off
printks until the cpu is up. There is a stub to do this,
but it is a nop on the i386.
> I have working code which did all that, but it sort-of got lost
> because there was a lot going on at the time.
>
> Have you actually observed any problem?
Yes, with my High-res-timers patch (all 4 of them) with
CONFIG_HIGH_RES turned off fails to boot. I traced the
timer insert as I suggested above and it somehow gets away
with writing into *NULL. I am not sure how this happens,
but when I ask KGDB to read it back, it also is able to read
it. The inserted timer (this is on an unpatched system,
i.e. no high-res or anything but the kgdb patch) looks like
this:
(gdb) p *timer
$13 = {entry = {next = 0xc11455b8, prev = 0x0}, expires =
605082, lock = {
lock = 1}, magic = 1267182958, function = 0xc01d8510
<blank_screen>,
data = 0, base = 0x0}
The base of 0 is ok as that is updated after the insert by
mod_timer. The prev =0, however is not cool.
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: use bdi on board with ppcbug
From: Wolfgang Denk @ 2002-12-20 17:10 UTC (permalink / raw)
To: Steven Blakeslee; +Cc: ??, linuxppc-embedded
In-Reply-To: <D73A25AA6E54D511AD74009027B1110F3C050D@ORION>
In message <D73A25AA6E54D511AD74009027B1110F3C050D@ORION> you wrote:
> Also, wouldn't the INIT section of the config script have to be empty?
This depends on the hardware. On many boards a minimal initialization
MUST be performed (like switching off the watchdog timer :-)
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
"Wish not to seem, but to be, the best." - Aeschylus
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: USB 2.0 is too slow?
From: David Brownell @ 2002-12-20 16:42 UTC (permalink / raw)
To: linux-kernel
> Some problems I met as follows.
You didn't mention what kernel or driver version you used.
I'd expect more success with the latest 2.5 code, which
should appear as a patch against 2.4.21pre soon.
> (1)Sometimes it can copy completely in 30 seconds.
300 MB, 30 seconds ... 10 MB/sec, faster can be had;
that shouldn't tax the usb2 hardware at all. But some
PCI systems might not like that additional load.
> Is the echi-hcd module instable or immature now?
> Or the VIA USB 2.0 host controller is bad support?
Some of both. It's explicitly so on 2.4 (CONFIG_EXPERIMENTAL)
and has on 2.5 has recently been regaining stability. Not that
long ago we switched over so usb-storage uses scatterlists to
do queued I/O, stressing the driver and hardware a lot more ...
the expected kinds of bugs did show up, and are being squished.
And you need relatively recent drivers for the VIA support
to behave, in any case. Or even Intel; there's a timeout
that Intel expects to be relatively long, and current kernels
have it quite short. We learned that just this week... :)
- Dave
^ permalink raw reply
* Re: 2.5.52: Many, many unresolved symbols!?
From: Alex Goddard @ 2002-12-20 12:24 UTC (permalink / raw)
To: axel; +Cc: linux-kernel
In-Reply-To: <20021220104644.GA637@neon.pearbough.net>
On Fri, 20 Dec 2002 axel@pearbough.net wrote:
> Hi,
>
> after kernel build of 2.5.52-bk4 snapshot, depmod results in a very long
> list of unresolved symbols.
>
> if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.5.52bk4; fi
> depmod: *** Unresolved symbols in
> /lib/modules/2.5.52bk4/kernel/drivers/block/floppy.ko
Make sure you have the latest module-init-tools installed, and that
/sbin/depmod points to the newest version of depmod from the
module-init-tools package you just (re)installed.
--
Alex Goddard
agoddard@purdue.edu
^ permalink raw reply
* Re: [PATCH] joydev: fix HZ->millisecond transformation
From: george anzinger @ 2002-12-20 17:24 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Bjorn Helgaas, Marcelo Tosatti, linux-kernel
In-Reply-To: <20021220142443.A26184@ucw.cz>
Vojtech Pavlik wrote:
>
> On Fri, Dec 20, 2002 at 02:41:50AM -0800, george anzinger wrote:
> > Bjorn Helgaas wrote:
> > >
> > > * fix a problem with HZ->millisecond transformation on
> > > non-x86 archs (from 2.5 change by vojtech@suse.cz)
> > >
> > > Applies to 2.4.20.
> > >
> > > diff -Nru a/drivers/input/joydev.c b/drivers/input/joydev.c
> > > --- a/drivers/input/joydev.c Mon Dec 16 12:16:32 2002
> > > +++ b/drivers/input/joydev.c Mon Dec 16 12:16:32 2002
> > > @@ -50,6 +50,8 @@
> > > #define JOYDEV_MINORS 32
> > > #define JOYDEV_BUFFER_SIZE 64
> > >
> > > +#define MSECS(t) (1000 * ((t) / HZ) + 1000 * ((t) % HZ) / HZ)
> > Uh...
> > ^^^^^^^^^^^^^^^^
> > by definition this is zero, is it not?
>
> No, both parts of the equaition can be nonzero.
I don't think so. s%HZ has to be less than HZ. Then
dividing that by HZ should result in zero. Where is my
thinking flawed?
>
> Though it might be easier to say (1000 * t) / HZ, now that I think about
> it.
That overflows... As does the other if HZ is less than
1000....
>
> --
> Vojtech Pavlik
> SuSE Labs
> -
> 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/
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: After Uncompresseing Linux..., what's next
From: Gary Thomas @ 2002-12-20 17:22 UTC (permalink / raw)
To: Prakash kanthi; +Cc: linuxppc embedded
In-Reply-To: <20021220170607.22771.qmail@web41207.mail.yahoo.com>
On Fri, 2002-12-20 at 10:06, Prakash kanthi wrote:
>
> Gary,
>
> I really appreciate your help. Here is what i am
> doing. Sorry it is little long. But was necessasry.
>
> 1. I have a boot loader(xrom.elf) of size around 400KB
> which basically have menu driven tests along with an
> option to jump to linux kernel(zImage.initrd.elf).
>
> 2. xrom.elf is compiled to start at 0xfffffffc and
> jump to 0x00000000 to have rest of functionality.
> zImage.initrd.elf is compiled to start at 0x00400000.
>
> 3. I load zImage.initrd.elf first and then xrom.elf
> (xilinx tool makes sure that they are loaded to
> corresponding locations based on ELF header).
>
> 4. After loading both, i start running xrom.elf and it
> shows up a menu in my UART terminal. I jump to linux
> (0x00400000).
>
> 5. I see that linux is basically reading the board
> info, setting UART, prints some boot messages onto it
> and then performs uncompression (gunzip function takes
> the rest of linux image and puts the uncompressed code
> starting from 0x0).
>
This is just the secondary bootstrap, whose job is to
unpack the kernel image and put it at location 0x0.
> 6. Up untill, everything is ok. After this, control
> jumps to 0x0 and starts executing.
>
> My problems are,
>
> a. Once the uncompression process is done, i am not
> sure if the image is copied to 0x0 (i do see value
> changes in memory starting from 0x0).
> b. As uncompression process is embedded into
> zImage.initrd.elf, i do not objdump does not tell me
> which function it is going to execute after
> uncompression.
>
The code that executes first is found in arch/ppc/kernel/head.S
Try looking at it, and tracing the execution. If your hardware
(debug environment) can't do things like set breakpoints and
single step, then you're probably limited to very simple
debug techniques like leaving breadcrumbs (write some number
or pattern to a known location which hopefully you can look
at when it dies).
Also, as Jim Potter pointed out, the kernel needs to be started in
the most privileged execution mode since it will be taking
over the CPU completely.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Best vpn w/ iptables.
From: Rowan Reid @ 2002-12-20 17:23 UTC (permalink / raw)
To: 'iptables-list'
I'm gonna be implimenting a VPN between two offices. Both gateways being
the Firewall also. Which uses Netfilter I'm looking for secure straight
forward routable setup and 100% compatability with netfilter ie not
pptp. It also has to be open source. I know this isn't a vpn group but I
figured you would have valuable input. Thanks Right now I'm looking at
freeswan
Rowan Reid
Job Captain,
Systems Administrator
STUDIO 3 ARCHITECTS
909 982 1717
^ permalink raw reply
* Re: 2.4.20: Broken AGP initialization for i845G chipset [patch]
From: Michael Milligan @ 2002-12-20 17:31 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel
In-Reply-To: <20021220102715.GE24782@suse.de>
Dave Jones wrote:
> On Thu, Dec 19, 2002 at 04:38:00PM -0700, Michael Milligan wrote:
> >
> > Patch below. Calls the 845 initialization function instead of the 830MP,
> > and a small formatting cleanup. This is verified working.
>
> With testgart/some other AGP using app ?
Patched, It boots on my shiny new ASUS P4B533-VM motherboard with
GeForce 4 TI 4200 AGP card. Identifies the chipset properly and
proceeds to boot fine. X works (nvidia driver), OpenGL works. Without
patch, it hangs (the PCI bus I think) after AGP initialization.
> It looks totally logical. I'm just wondering if it was a cut-n-paste
> accident, or someone had a genuine reason for doing that in the
> first place.
I have no idea if the 830MP initialization is supposedly more compatible
with the 845G chipset than the 845 initialization. I just know it
didn't work and took a guess as to what it should be.
Regards,
Mike
--
Michael Milligan -- Free Agent -- milli@acmeps.com
^ 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.