On Wed, Nov 22, 2006 at 03:41:11PM -0800, Jun Sun wrote:
>
> I am plowing along as I am learning about the in'n'outs about i386. I am
> totally stuck on this one. I would appreciate any help.
>
> As you can see, the function turns off paging mode (of course it
>
On Tue, Nov 28, 2006 at 05:40:56PM -0800, Jun Sun wrote:
>
> Can you elaborate more why this last ljmp will fail? I thought at this point
> the paging is turned off, and 0x1000- would simply mean a physical
> address - which is a valid physical address in RAM, btw.
>
I
On Tue, Nov 28, 2006 at 06:49:17PM -0500, linux-os (Dick Johnson) wrote:
>
> On Tue, 28 Nov 2006, Jun Sun wrote:
>
> > On Tue, Nov 28, 2006 at 08:46:44AM -0500, linux-os (Dick Johnson) wrote:
> >>
> >> On Mon, 27 Nov 2006, Jun Sun wrote:
> >>
> >&
On Tue, Nov 28, 2006 at 08:46:44AM -0500, linux-os (Dick Johnson) wrote:
>
> On Mon, 27 Nov 2006, Jun Sun wrote:
>
> >
> > On Mon, Nov 27, 2006 at 08:58:57AM -0500, linux-os (Dick Johnson) wrote:
> >>
> >> I think it probably resets the instant that you t
On Mon, Nov 27, 2006 at 08:58:57AM -0500, linux-os (Dick Johnson) wrote:
>
> I think it probably resets the instant that you turn off paging. To
> turn off paging, you need to copy some code (properly linked) to an
> area where there is a 1:1 mapping between virtual and physical addresses.
> A sa
I am running a MIPS machine and hit the following BUG() in
kernel/sched.c:650:
prepare_to_switch();
{
struct mm_struct *mm = next->mm;
struct mm_struct *oldmm = prev->active_mm;
if (!mm) {
if (next->active_mm
I am trying to adopt the new irq.c under arch/i386/kernel to a MIPS board and
hopefully to MIPS common code in general. This is in the anticipation that
the irq.c file will be moved to common kernel directory in 2.5.
While the rest look pretty self-explanatory, I do have a couple of questions
a
s already
in it?
Thanks.
Jun
> On jeu, 22 mar 2001 22:04:45 Jun Sun wrote:
> >
> > I am trying to get netgear card working on a new (read as potentially buggy
> > hardware) MIPS board.
> >
> > The eepro100 driver basically works fine. It is just after a little wh
I am trying to get netgear card working on a new (read as potentially buggy
hardware) MIPS board.
The eepro100 driver basically works fine. It is just after a little while
(usually 2 sec to 15 sec) network communication suddenly stops and I start see
error message like "eepro100: wait_for_cmd_d
I notice that many net drivers set rx_copybreak to 1518 (the max packet size)
for non-i386 architectures. Once I thought I understood it and it seems
related to cache line alignment. However, I am not sure exactly about the
reason now. Can someone enlighten me a little bit?
Basically I try to
Russell King wrote:
>
> Neil Brown writes:
> > On Wednesday February 7, [EMAIL PROTECTED] wrote:
> > > This is a weird problem that I am looking at right. It seems to indicate a
> > > bug in the nfs server.
> > >
> > > I have a MIPS machine that boots from a NFS root fs hosted on a redhat 6.2
>
This is a weird problem that I am looking at right. It seems to indicate a
bug in the nfs server.
I have a MIPS machine that boots from a NFS root fs hosted on a redhat 6.2
workstation. Everything works fine except that after a few reboots I start to
see the error messages like the following:
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > > A while back I reported the lost need_resched flag bug ( it happens if
> > > need_resched is set right before switch_to() is called). Later on a one-line
> > > fix is added to __schedule_tail().
> > >
> > > current->need_resched |= prev->need_
I did not get reply from Linus. Now try my luck with the kernel mailing
list. Please cc your reply to my email account. I stopped watching the
mailing list anymore.
Thanks.
Jun
Jun Sun wrote:
>
> Linus,
>
> A while back I reported the lost need_resched flag bug ( i
I am running Linux v2.4-test5 on MIPS (NEC DDB5476). I got the above
run-time BUG report. See the call stack below. Can someone shed a
light on this problem? Thanks.
Jun
--
reakpoint 2, alloc_skb (size=1531, gfp_mask=7) at skbuff.c:175
175 BUG();
(gd
"David S. Miller" wrote:
>
>Date: Thu, 07 Sep 2000 17:35:22 -0700
>From: Jun Sun <[EMAIL PROTECTED]>
>
>Do we know exactly what userland apps/libs use ifmap? Maybe the
>damage is not so bad, so that we can fix this problem without
>m
"David S. Miller" wrote:
>
>Date:Thu, 07 Sep 2000 14:36:02 -0700
>From: Jun Sun <[EMAIL PROTECTED]>
>
>Here is a small patch which is needed on non-i386 platforms.
>
> The layout of this structure is exported to userspace
> applicat
Linus,
Here is a small patch which is needed on non-i386 platforms.
base_addr in ifmap allows one to specify as a kernel boot argument the
base io addr of the net device. It is currently defined as u_short.
However, on a non-i386 platforms, this addr can be greater than what
u_short can repre
18 matches
Mail list logo
