Re: failed 'ljmp' in linear addressing mode
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 > runs from identically mapped page) and tries to jump to an absolute > address at 0x1000. It appears the machine would reboot when running > "ljmp" instruction. > > Any pointers? > Pageexec gave me an excellent explanation on why "ljmp" fails. See below. It is so obvious once you see it. :) Thanks. Jun - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 01 Dec 2006 14:35:09 +0200 Subject: failed 'ljmp' in linear addressing mode hello, just saw your post on lkml. your original problem was that when you executed the far jump, the CPU's internal GDT base register was still loaded with the kernel's virtual address of gdt_table - an address somewhere high in the (then virtual) address space which when interpreted as a physical address (you turned off paging, remember) contained nothing, let alone a valid GDT. so when the CPU tried to look up __KERNEL_CS in the GDT, it found nothing there, that in turn triggered an exception which in turn double then triple faulted as the IDT couldn't be accessed either for the same reason. later you posted code that shows that you reload the IDT/GDT with a constant 0, i doubt that will do much good either on the long run as there's no valid GDT/IDT set up there normally. in short, the normal course of action when going from paged protected mode into non-paged protected mode is to reload IDT/GDT with physical addresses pointing to valid tables then reload the segment registers (if they're different from those used in paged mode) then you can go on with the rest. note that the reload operation uses *two* addresses (one for the memory operand of lgdt/lidt and one for the actual table address), both of which had better be of the same kind (physical or virtual). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: failed 'ljmp' in linear addressing mode
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 finally got it working, even though I don't understand at all. :)
I realized that after paging mode is turned off, 0x1000- is actually
at the same flag 4G code segment as caller code. So I tried to just
"call" and that worked.
Here is the excerpt of the related code in case someone else needs to
do the same:
In arch/i386/kernel/machine_kexec.c:
extern void do_os_switching(void);
void os_switch(void)
{
void (*foo)(void);
/* absolutely no irq */
local_irq_disable();
/* create identity mapping */
foo=virt_to_phys(do_os_switching);
identity_map_page((unsigned long)foo);
/* jump to the real address */
load_segments();
set_gdt(phys_to_virt(0),0);
set_idt(phys_to_virt(0),0);
foo();
}
In arch/i386/kernel/acpi/wakeup.S:
.align 4096
ENTRY(do_os_switching)
/* JSUN, 0x11 was the boot up value for cr0. */
movl$0x11, %eax
movl%eax, %cr0
/* clear cr4 */
movl$0, %eax
movl%eax, %cr4
/* clear cr3, flush TLB */
movl$0, %eax
movl%eax, %cr3
movl$0x1000,%eax
call*%eax
I have a second Linux kernel loaded at 0x1000-. Now the only matter
remaining is to figure out why the tsc timer stopped working ... :)
Cheers.
Jun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: failed 'ljmp' in linear addressing mode
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 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 safe place is somewhere below 1 megabyte. Then you need to set up a
> >>>> call descriptor so you can call that code (you can ljump if you never
> >>>> plan to get back). You then need to clear interrupts on all CPUs (use a
> >>>> spin-lock). Once you are executing from the new area, you reset your
> >>>> segments to the new area. The call descriptor would have already set
> >>>> CS, as would have the long-jump. At this time you can turn off paging
> >>>> and flush the TLB. You are now in linear-address protected mode.
> >>>>
> >>>
> >>> Thanks for the reply. But I am pretty much sure I did above correctly.
> >>> I use single-instruction infinite loop in the call path to verify
> >>> that control does reach last 'ljmp' but not the jump destination.
> >>>
> >>> Below is the hack I made to machine_kexec.c file. As you can see, I
> >>> managed to make the identical mapping between virtual and physical
> >>> addresses.
> >>>
> >>> Note I did not copy the code into the first 1M. In fact the code
> >>> is located at 0xc0477000 (0x00477000 in physical). I thought that should
> >>> be
> >>> OK as I did not really go all the way back to real-address mode.
> >>>
> >>> That last suspect I have now is the wrong value in CS descriptor. Does
> >>> kernel
> >>> have a suitable CS descriptor for the last ljmep to 0x1000 in linear
> >>> addressing mode? The CS descriptor seems to be a pretty dark magic to me
> >>> ...
> >>>
> >>> Cheers.
> >>>
> >>> Jun
> >>>
> >>> -
> >>> diff -Nru linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c.orig
> >>> linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c
> >>> --- linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c.orig
> >>> 2006-10-13 11:55:04.0 -0700
> >>> +++ linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c
> >>> 2006-11-22 15:01:45.0 -0800
> >>> @@ -212,3 +212,19 @@
> >>>rnk = (relocate_new_kernel_t) reboot_code_buffer;
> >>>(*rnk)(page_list, reboot_code_buffer, image->start, cpu_has_pae);
> >>> }
> >>> +
> >>> +extern void do_os_switching(void);
> >>> +void os_switch(void)
> >>> +{
> >>> + void (*foo)(void);
> >>> +
> >>> + /* absolutely no irq */
> >>> + local_irq_disable();
> >>> +
> >>> + /* create identity mapping */
> >>> + foo=virt_to_phys(do_os_switching);
> >>> + identity_map_page((unsigned long)foo);
> >>> +
> >>> + /* jump to the real address */
> >>> + foo();
> >>> +}
> >>>
> >> Get a copy of the Intel 486 Microprocessor Reference Manual or read it on-
> >> line. There is no way that you can make a call like that.
> >
> > By "a call like that", you mean "foo()"? Are you sure about that?
> >
> > The machine_kexec() function in the same file is basically doing the
> > same way (i.e., use "call *$eax" instead of "ljmp"). That is where I got
> > my idea from.
> >
> > In addition, if I put "1: jmp 1b" instruction anywhere *inside*
> > do_os_switching() I would get infinite hanging instead of reboot,
> > which seems to suggest I *did* jump into do_os_switching() successfully.
> >
> > According to Intel Architecture Software Developer's Manual (1997), Vol 3,
> > page 8-14:
> >
> > "2. If paging is enabled perform the following operations:
> >
> > - Transfer program control to linear addresses that are identity mapped to
> >
Re: failed 'ljmp' in linear addressing mode
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 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 safe place is somewhere below 1 megabyte. Then you need to set up a
> >> call descriptor so you can call that code (you can ljump if you never
> >> plan to get back). You then need to clear interrupts on all CPUs (use a
> >> spin-lock). Once you are executing from the new area, you reset your
> >> segments to the new area. The call descriptor would have already set
> >> CS, as would have the long-jump. At this time you can turn off paging
> >> and flush the TLB. You are now in linear-address protected mode.
> >>
> >
> > Thanks for the reply. But I am pretty much sure I did above correctly.
> > I use single-instruction infinite loop in the call path to verify
> > that control does reach last 'ljmp' but not the jump destination.
> >
> > Below is the hack I made to machine_kexec.c file. As you can see, I
> > managed to make the identical mapping between virtual and physical
> > addresses.
> >
> > Note I did not copy the code into the first 1M. In fact the code
> > is located at 0xc0477000 (0x00477000 in physical). I thought that should be
> > OK as I did not really go all the way back to real-address mode.
> >
> > That last suspect I have now is the wrong value in CS descriptor. Does
> > kernel
> > have a suitable CS descriptor for the last ljmep to 0x1000 in linear
> > addressing mode? The CS descriptor seems to be a pretty dark magic to me
> > ...
> >
> > Cheers.
> >
> > Jun
> >
> > -
> > diff -Nru linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c.orig
> > linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c
> > --- linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c.orig 2006-10-13
> > 11:55:04.0 -0700
> > +++ linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c2006-11-22
> > 15:01:45.0 -0800
> > @@ -212,3 +212,19 @@
> >rnk = (relocate_new_kernel_t) reboot_code_buffer;
> >(*rnk)(page_list, reboot_code_buffer, image->start, cpu_has_pae);
> > }
> > +
> > +extern void do_os_switching(void);
> > +void os_switch(void)
> > +{
> > + void (*foo)(void);
> > +
> > + /* absolutely no irq */
> > + local_irq_disable();
> > +
> > + /* create identity mapping */
> > + foo=virt_to_phys(do_os_switching);
> > + identity_map_page((unsigned long)foo);
> > +
> > + /* jump to the real address */
> > + foo();
> > +}
> >
> Get a copy of the Intel 486 Microprocessor Reference Manual or read it on-
> line. There is no way that you can make a call like that.
By "a call like that", you mean "foo()"? Are you sure about that?
The machine_kexec() function in the same file is basically doing the
same way (i.e., use "call *$eax" instead of "ljmp"). That is where I got
my idea from.
In addition, if I put "1: jmp 1b" instruction anywhere *inside*
do_os_switching() I would get infinite hanging instead of reboot,
which seems to suggest I *did* jump into do_os_switching() successfully.
According to Intel Architecture Software Developer's Manual (1997), Vol 3,
page 8-14:
"2. If paging is enabled perform the following operations:
- Transfer program control to linear addresses that are identity mapped to
physical addresses (that is, linear addresses equal physical addresses)
...
"
it does not indicate one has to use "ljmp" to do this control transfer.
> You would need to
> call through a task-gate or otherwise set the code-segment and the
> instruction
> pointer at the same instant. First, look at the startup code for a GDT entry
> that maps the linear address-space you are using, PLUS allows execution. If
> there isn't such an entry, modify an existing one to allow execution.
> Remember
> that CS value, 'segment' in this example. It is probably 0x08, but I don't
> have
> the kernel source on this machine. Do a far jump through something
> created as:
> .byte 0xea; Jmp instruction
> .short $segment; Your
Re: failed 'ljmp' in linear addressing mode
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 safe place is somewhere below 1 megabyte. Then you need to set up a
> call descriptor so you can call that code (you can ljump if you never
> plan to get back). You then need to clear interrupts on all CPUs (use a
> spin-lock). Once you are executing from the new area, you reset your
> segments to the new area. The call descriptor would have already set
> CS, as would have the long-jump. At this time you can turn off paging
> and flush the TLB. You are now in linear-address protected mode.
>
Thanks for the reply. But I am pretty much sure I did above correctly.
I use single-instruction infinite loop in the call path to verify
that control does reach last 'ljmp' but not the jump destination.
Below is the hack I made to machine_kexec.c file. As you can see, I
managed to make the identical mapping between virtual and physical addresses.
Note I did not copy the code into the first 1M. In fact the code
is located at 0xc0477000 (0x00477000 in physical). I thought that should be
OK as I did not really go all the way back to real-address mode.
That last suspect I have now is the wrong value in CS descriptor. Does kernel
have a suitable CS descriptor for the last ljmep to 0x1000 in linear
addressing mode? The CS descriptor seems to be a pretty dark magic to me ...
Cheers.
Jun
-
diff -Nru linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c.orig
linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c
--- linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c.orig 2006-10-13
11:55:04.0 -0700
+++ linux-2.6.17.14-1st/arch/i386/kernel/machine_kexec.c2006-11-22
15:01:45.0 -0800
@@ -212,3 +212,19 @@
rnk = (relocate_new_kernel_t) reboot_code_buffer;
(*rnk)(page_list, reboot_code_buffer, image->start, cpu_has_pae);
}
+
+extern void do_os_switching(void);
+void os_switch(void)
+{
+ void (*foo)(void);
+
+ /* absolutely no irq */
+ local_irq_disable();
+
+ /* create identity mapping */
+ foo=virt_to_phys(do_os_switching);
+ identity_map_page((unsigned long)foo);
+
+ /* jump to the real address */
+ foo();
+}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I hit the BUG() in schedule() ...
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) BUG(); <==
next->active_mm = oldmm;
atomic_inc(&oldmm->mm_count);
enter_lazy_tlb(oldmm, next, this_cpu);
} else {
if (next->active_mm != mm) BUG();
switch_mm(oldmm, mm, next, this_cpu);
}
The "next" processor is swapper.
I have not looked at it hard enough, but an initial investigation seems
to reveal the cause trivially.
In include/linux/sched.h, the "swapper" task is set such that 'mm' is
NULL and 'active_mm' is &init_mm. So obviously when we switch back to
"swapper" task, we will hit the BUG().
That sounds little too obvious to be true. What am I missing here?
Thanks in advance. Please cc your reply to this email account. I
appreciate that.
Jun
__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ack() and end() in hw_irq_controller
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 about ack() and end(). 1. It seems to me that in ack() we need to clear any latched, edge triggerred interrupt AND disable the irq. True? 2. Similarly end() should re-enable the irq. 3. I don't quite understand the comment about end(). Any explanation? Does that imply we should check if it is disable before we re-enable the irq? However, it seems such complication can only happen on a SMP, right? /* * The ->end() handler has to deal with interrupts which got * disabled while the handler was running. */ Thanks in advance. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: eepro100 question: why SCBCmd byte is 0x80?
christophe barbe wrote: > > Which kernel are you using. > > I've had a similar problem with 2.2.18. > I've backported 2.2.19pre changes to it. > (i.e. apply on 2.2.18 a diff of the file drivers/net/eepro100.c made between 2.2.18 >and the last 2.2.19pre) > And since I've never seen this problem again. > > Christophe > Kernel is 2.4.2. It is a MIPS machine. I don't really think it is a driver problem, because the same dirver works fine on many other boards (including MIPS boards). In addition, I also tested with tulip cards and I had the same symptom. I am convinced it is a low-level problem (bus timing, PCI setting, buggy hardware, etc). On the other hand, it could be a driver problem which is only exposed in this particular board, although very unlikely. BTW, does the eepro100 patch for 2.2.19pre apply to 2.4.2? Or it is 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 while > > (usually 2 sec to 15 sec) network communication suddenly stops and I start see > > error message like "eepro100: wait_for_cmd_done timeout!". > > > > I looked into this, and it appears that the SCBCmd byte in the command word > > has value 0x80 instead of the expected 0. I looked at the Intel manual, and > > it says nothing about the value being 0x80. > > > > Does anybody have a clue here? I suspect some timing is wrong or a buggy PCI > > controller. > > > > Please cc your reply to my email address. Thanks. > > > > Jun > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > -- > Christophe Barbé > Software Engineer > Lineo High Availability Group > 42-46, rue Médéric > 92110 Clichy - France > phone (33).1.41.40.02.12 > fax (33).1.41.40.02.01 > www.lineo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
eepro100 question: why SCBCmd byte is 0x80?
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_done timeout!". I looked into this, and it appears that the SCBCmd byte in the command word has value 0x80 instead of the expected 0. I looked at the Intel manual, and it says nothing about the value being 0x80. Does anybody have a clue here? I suspect some timing is wrong or a buggy PCI controller. Please cc your reply to my email address. Thanks. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
rx_copybreak value for non-i386 architectures
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 understand whether for MIPS architectures we need to set this value as well. Please CC your reply to my email address. TIA. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nfs_refresh_inode: inode number mismatch
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 > > > workstation. Everything works fine except that after a few reboots I start to > > > see the error messages like the following: > > > > What verison of Linux? If it is less than 2.2.18, then an upgrade > > will help you a lot. > > > > If it is >= 2.2.18, I will look some more. > > Note that you need to upgrade the server, not the client. Also, make sure > you don't reboot the client more than once in a 2 minute time window. My server was 2.2.14. I upgraded it to 2.2.18. It appears that the problem is gone, although it will probably take a while to be sure. I do find the "no more than once in 2 minutes" requirement amusing ... :-) Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
nfs_refresh_inode: inode number mismatch
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: Freeing unused kernel memory: 24k freed INIT: version 2.77 booting nfs_refresh_inode: inode number mismatch expected (0x308/0x28b3d2), got (0x308/0x12b91b) INIT: Entering runlevel: 3 sh-2.03# Restarting the nfs server on the host does not get rid of the messages. Things will get better if I reboot the host. I traced the network packets, and it seems obvious that the server is returning wrong fileid in the "write reply" message. Below is a segment of the extracted packet trace. It is obvious that the nfs server returns a wrong fileid for the same handle it returned earlier to the client. The confusing part is the nfs server actually serves the first write request, and a couple of other requests, correctly but failed for the second time, returning a wrong fileid. In my particular setup, it seems only certain files (inodes) tend to get screwed up. Does anybody have an idea as to what is wrong here? Please cc your reply to my email address. TIA. Jun -- round 3: case 1: 2177 lookup: ioctl.save 2178 lookup reply: fileid: 2667474 handle: cabaebfed2b32800e6ab28000803080354c21100b2302b0c 2181 write: offset:0 total count: 60 handle: cabaebfed2b32800e6ab28000803080354c21100b2302b0c 2182 write reply: fileid: 2667474 size: 60 2183 setattr: handle: cabaebfed2b32800e6ab28000803080354c21100b2302b0c 2184 setattr reply: fileid: 2667474 2185 write: handle: cabaebfed2b32800e6ab28000803080354c21100b2302b0c 2186 write reply: fileid 1227035 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: lost need_resched flag re-introduced?]
[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_resched; > > > > > > I looked at the latest kernel and found this one is gone. Is the lost > > > need_resched problem taken care of in some other way? Or is it re-introduced? > > It is removed not only because it was wrong (which you have found too), > but because it was useless even if copied correctly. > > current->need_resched is not changed in interrupt context outside > runqueue lock except for scheduler timer, where copying results > in nothing but spurious reschedule. > > Alexey Alexey, I think wake_up_process() is called in interrupt routine quite often and it will set need_resched flag (through reschedule_idle()). ??? I did several run time tests and confirmed the missing need_resched flag was happening. Ether some new code takes care of it. Or it is still there. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[Fwd: lost need_resched flag re-introduced?]
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 ( 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_resched;
>
> I looked at the latest kernel and found this one is gone. Is the lost
> need_resched problem taken care of in some other way? Or is it re-introduced?
>
> In any case, I was going to propose a minor fix over the original one-line
> fix. See the patch below.
>
> On RISC machines, the original fix leaves a small window for setting the wrong
> flag. A pseudo assembly code for the original fix is shown as follows:
>
> 1. load current->need_resched to R1
> 2. load prev->need_resched to R2
> 3. R1 = R1 | R2
> 4. store R1 to current->need_resched
>
> If at 1) both need_resched flags are 0, and an interrupt happens between 1)
> and 4), which sets current->resched to 1, we will have wrong result for
> current->need_resched after step 4).
>
> Jun
>
> inux/kernel/sched.c: 1.1 1.2 jsun 00/10/31 10:22:44 (modified, needs delta)
>
> @@ -455,7 +455,9 @@
> */
> static inline void __schedule_tail(struct task_struct *prev)
> {
> - current->need_resched |= prev->need_resched;
> + if (prev->need_resched) {
> + current->need_resched = 1;
> + }
> #ifdef CONFIG_SMP
> if ((prev->state == TASK_RUNNING) &&
> (prev != idle_task(smp_processor_id( {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
BUG : alloc_skb called nonatomically from interrupt
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(); (gdb) bt #0 alloc_skb (size=1531, gfp_mask=7) at skbuff.c:175 #1 0x8012ffc8 in sock_alloc_send_skb (sk=0x81179640, size=1531, fallback=0, noblock=60, errcode=0x811f3cd0) at sock.c:816 #2 0x80142308 in ip_build_xmit_slow (sk=0x81179640, getfrag=0x80158634 , frag=0x811f3d98, length=60, ipc=0x811f3d88, rt=0x811f71c0, flags=16448) at ip_output.c:555 #3 0x801427d4 in ip_build_xmit (sk=0x81179640, getfrag=0x80158634 , frag=0x811f3d98, length=4248, ipc=0x811f3d88, rt=0x811f71c0, flags=16448) at ip_output.c:687 #4 0x80158b88 in udp_sendmsg (sk=0x81179640, msg=0x811f3e50, len=4220) at udp.c:585 #5 0x8015f50c in inet_sendmsg (sock=0x801adf54, msg=0x811f3e50, size=4220, scm=0x3c) at af_inet.c:727 #6 0x8012d35c in sock_sendmsg (sock=0x8110a8b0, msg=0x811f3e50, size=4220) at socket.c:509 #7 0x8016dd1c in do_xprt_transmit (task=0x836a47c0) at xprt.c:215 #8 0x8016db6c in xprt_transmit (task=0x836a47c0) at xprt.c:1190 #9 0x8016b564 in call_transmit (task=0x836a47c0) at clnt.c:554 #10 0x8016f968 in __rpc_execute (task=0x836a47c0) at sched.c:574 #11 0x8016fde4 in __rpc_schedule () at sched.c:712 #12 0x801709d4 in rpciod (ptr=0x801adf54) at sched.c:1065 #13 0x8008c2f0 in kernel_thread (fn=0x80170810 , arg=0x801bb08c, flags=5) at process.c:158 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
"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 >making it look worse. > > It's a well established fixed kernel API, any app whatsoever can make > use of it. > > I advise you to stop trying to find ways to make your "quick and easy" > solution viable and work on the usable solution which will not break > userland. > David, You get my intension wrong. Actually I believe over the time it will destroy Linux if people keep introducing ifmap2 and ifmap3 and etc. My question was to find out if the problem is still in the stage where we can fix it cleanly, or it is already too late to do so - like many window's API. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] change ifmap.base_addr to u_long type
"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 > applications, thus you cannot simply just change the > type in this structure to get the change you need. > > This change thus cannot be made as-is. > > You must find some other way, let me give you one example > of a potentially acceptable solution: > > 1) Add new member to union inside of ifreq where ifmap >currently lives. Add new member, perhaps called ifmap2 >which uses more appropriate types for base_addr member. > > 2) Add new ifreq call which looks at ifmap2 instead of ifmap. > > This way, existing userland applications still work as they > did before hand, and new ones can be written to use the ifmap2 > version of the interface. > > Also be sure that the glibc maintainers get this change once it > is in the kernel. > > Later, > David S. Miller > [EMAIL PROTECTED] Hmm, that is a whole lot more complicated than I thought. 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 making it look worse. Jun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] change ifmap.base_addr to u_long type
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 represent.
ifmap.base_addr is mainly used to initialize net_device base_addr, which
is already a u_long.
This change does not increase the memory size for struct ifmap.
In the same spirit, ifmap.irq should probably be changed to u_int as
well, but that would increase the size, and I don't have the need yet.
:-)
Jun
diff -Nru linux/include/linux/if.h.orig linux/include/linux/if.h
--- linux/include/linux/if.h.orig Thu Sep 7 14:20:47 2000
+++ linux/include/linux/if.hThu Sep 7 14:24:06 2000
@@ -59,11 +59,11 @@
{
unsigned long mem_start;
unsigned long mem_end;
- unsigned short base_addr;
+ unsigned long base_addr;
unsigned char irq;
unsigned char dma;
unsigned char port;
- /* 3 bytes spare */
+ /* 1 byte spare */
};
/*
diff -Nru linux/drivers/net/net_init.c.orig linux/drivers/net/net_init.c
--- linux/drivers/net/net_init.c.orig Thu Sep 7 14:20:55 2000
+++ linux/drivers/net/net_init.cThu Sep 7 14:21:41 2000
@@ -397,7 +397,7 @@
dev->mem_start = map->mem_start;
if (map->mem_end != (u_long)(-1))
dev->mem_end = map->mem_end;
- if (map->base_addr != (u_short)(-1))
+ if (map->base_addr != (u_long)(-1))
dev->base_addr = map->base_addr;
if (map->irq != (u_char)(-1))
dev->irq = map->irq;
