Re: [PATCH] x86: fix ioport unification on 32-bit [was: Re: hwclock failure in x86.git]
* Chris Wright <[EMAIL PROTECTED]> wrote: > * Ingo Molnar ([EMAIL PROTECTED]) wrote: > > thanks for tracking it down. I pulled that commit for now. But it would > > be nice to figure out what's going on there. > > Zach was right. The unification was broken for 32-bit; it was missing > the actual pushf/popf EFLAGS manipluation (set_iopl_mask()) and > would've broken task switching between processes w/ different iopl in > paravirt guests too. 64-bit sys_iopl just does pt_regs->flags > modification and lets syscall/sysret plus ptregscall sync and do > EFLAGS update. > > Also, use of volatile looks like leftover cruft. > > This patch in on top of Miguel's (can respin to standalone if that's > better). [...] thanks, applied. Ingo -- 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: [PATCH] x86: fix ioport unification on 32-bit [was: Re: hwclock failure in x86.git]
* Chris Wright [EMAIL PROTECTED] wrote: * Ingo Molnar ([EMAIL PROTECTED]) wrote: thanks for tracking it down. I pulled that commit for now. But it would be nice to figure out what's going on there. Zach was right. The unification was broken for 32-bit; it was missing the actual pushf/popf EFLAGS manipluation (set_iopl_mask()) and would've broken task switching between processes w/ different iopl in paravirt guests too. 64-bit sys_iopl just does pt_regs-flags modification and lets syscall/sysret plus ptregscall sync and do EFLAGS update. Also, use of volatile looks like leftover cruft. This patch in on top of Miguel's (can respin to standalone if that's better). [...] thanks, applied. Ingo -- 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/
[PATCH] x86: fix ioport unification on 32-bit [was: Re: hwclock failure in x86.git]
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> thanks for tracking it down. I pulled that commit for now. But it would
> be nice to figure out what's going on there.
Zach was right. The unification was broken for 32-bit; it was missing
the actual pushf/popf EFLAGS manipluation (set_iopl_mask()) and would've
broken task switching between processes w/ different iopl in paravirt
guests too. 64-bit sys_iopl just does pt_regs->flags modification and
lets syscall/sysret plus ptregscall sync and do EFLAGS update.
Also, use of volatile looks like leftover cruft.
This patch in on top of Miguel's (can respin to standalone if that's better).
Tested (on both 32 and 64-bit) with simple:
#include
#include
main()
{
if (iopl(3) == 0)
asm ("cli\nsti\n"::);
}
thanks,
-chris
--
From: Chris Wright <[EMAIL PROTECTED]>
Subject: [PATCH] x86: fix ioport unification on 32-bit
ioport unification was broken for 32-bit; it was missing
the acutal pushf/popf EFLAGS manipulation (set_iopl_mask()).
Also, use of volatile looks like leftover cruft.
Cc: [EMAIL PROTECTED]
Cc: Kevin Winchester <[EMAIL PROTECTED]>
Cc: Zach Brown <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: "H. Peter Anvin" <[EMAIL PROTECTED]>
Cc: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Chris Wright <[EMAIL PROTECTED]>
---
arch/x86/kernel/ioport.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index e723ff3..be72d80 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -116,9 +116,10 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned
long num, int turn_on)
#ifdef CONFIG_X86_32
asmlinkage long sys_iopl(unsigned long regsp)
{
- volatile struct pt_regs *regs = (struct pt_regs *)
+ struct pt_regs *regs = (struct pt_regs *)
unsigned int level = regs->bx;
unsigned int old = (regs->flags >> 12) & 3;
+ struct thread_struct *t = >thread;
if (level > 3)
return -EINVAL;
@@ -127,8 +128,9 @@ asmlinkage long sys_iopl(unsigned long regsp)
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
+ t->iopl = level << 12;
regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
-
+ set_iopl_mask(t->iopl);
return 0;
}
#else
--
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: hwclock failure in x86.git
On Friday 11 January 2008 15:03:47 Ingo Molnar wrote:
> * Kevin Winchester <[EMAIL PROTECTED]> wrote:
> > Bisect says...
> >
> > 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b is first bad commit
> > commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
> > Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> > Date: Wed Jan 9 13:31:11 2008 +0100
> >
> > x86: ioport_{32|64}.c unification
>
> thanks for tracking it down. I pulled that commit for now. But it would
> be nice to figure out what's going on there.
>
> Ingo
mmm, i'll try to reproduce it tomorrow and find a fix.
thanks for notifying this problem.
--
Miguel Botón
--
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: hwclock failure in x86.git
* Kevin Winchester <[EMAIL PROTECTED]> wrote:
> Bisect says...
>
> 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b is first bad commit
> commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
> Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Wed Jan 9 13:31:11 2008 +0100
>
> x86: ioport_{32|64}.c unification
thanks for tracking it down. I pulled that commit for now. But it would
be nice to figure out what's going on there.
Ingo
--
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: hwclock failure in x86.git
* Kevin Winchester [EMAIL PROTECTED] wrote:
Bisect says...
4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b is first bad commit
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
thanks for tracking it down. I pulled that commit for now. But it would
be nice to figure out what's going on there.
Ingo
--
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: hwclock failure in x86.git
On Friday 11 January 2008 15:03:47 Ingo Molnar wrote:
* Kevin Winchester [EMAIL PROTECTED] wrote:
Bisect says...
4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b is first bad commit
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
thanks for tracking it down. I pulled that commit for now. But it would
be nice to figure out what's going on there.
Ingo
mmm, i'll try to reproduce it tomorrow and find a fix.
thanks for notifying this problem.
--
Miguel Botón
--
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/
[PATCH] x86: fix ioport unification on 32-bit [was: Re: hwclock failure in x86.git]
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
thanks for tracking it down. I pulled that commit for now. But it would
be nice to figure out what's going on there.
Zach was right. The unification was broken for 32-bit; it was missing
the actual pushf/popf EFLAGS manipluation (set_iopl_mask()) and would've
broken task switching between processes w/ different iopl in paravirt
guests too. 64-bit sys_iopl just does pt_regs-flags modification and
lets syscall/sysret plus ptregscall sync and do EFLAGS update.
Also, use of volatile looks like leftover cruft.
This patch in on top of Miguel's (can respin to standalone if that's better).
Tested (on both 32 and 64-bit) with simple:
#include stdlib.h
#include sys/io.h
main()
{
if (iopl(3) == 0)
asm (cli\nsti\n::);
}
thanks,
-chris
--
From: Chris Wright [EMAIL PROTECTED]
Subject: [PATCH] x86: fix ioport unification on 32-bit
ioport unification was broken for 32-bit; it was missing
the acutal pushf/popf EFLAGS manipulation (set_iopl_mask()).
Also, use of volatile looks like leftover cruft.
Cc: [EMAIL PROTECTED]
Cc: Kevin Winchester [EMAIL PROTECTED]
Cc: Zach Brown [EMAIL PROTECTED]
Cc: Ingo Molnar [EMAIL PROTECTED]
Cc: H. Peter Anvin [EMAIL PROTECTED]
Cc: Thomas Gleixner [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL PROTECTED]
---
arch/x86/kernel/ioport.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
index e723ff3..be72d80 100644
--- a/arch/x86/kernel/ioport.c
+++ b/arch/x86/kernel/ioport.c
@@ -116,9 +116,10 @@ asmlinkage long sys_ioperm(unsigned long from, unsigned
long num, int turn_on)
#ifdef CONFIG_X86_32
asmlinkage long sys_iopl(unsigned long regsp)
{
- volatile struct pt_regs *regs = (struct pt_regs *)regsp;
+ struct pt_regs *regs = (struct pt_regs *)regsp;
unsigned int level = regs-bx;
unsigned int old = (regs-flags 12) 3;
+ struct thread_struct *t = current-thread;
if (level 3)
return -EINVAL;
@@ -127,8 +128,9 @@ asmlinkage long sys_iopl(unsigned long regsp)
if (!capable(CAP_SYS_RAWIO))
return -EPERM;
}
+ t-iopl = level 12;
regs-flags = (regs-flags ~X86_EFLAGS_IOPL) | (level 12);
-
+ set_iopl_mask(t-iopl);
return 0;
}
#else
--
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: hwclock failure in x86.git
I'm no expert, but I happened to notice this go by.
> The first thing I notice about the path is that ioport_32.c and the unified
> ioport.c use __clear_bit,
> while ioport_64.c uses clear_bit.
That doesn't seem too critical.
> +#ifdef CONFIG_X86_32
> +asmlinkage long sys_iopl(unsigned long regsp)
> +{
> + volatile struct pt_regs *regs = (struct pt_regs *)
> + unsigned int level = regs->bx;
> + unsigned int old = (regs->flags >> 12) & 3;
> +
> + if (level > 3)
> + return -EINVAL;
> + /* Trying to gain more privileges? */
> + if (level > old) {
> + if (!capable(CAP_SYS_RAWIO))
> + return -EPERM;
> + }
> + regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
> +
> + return 0;
> +}
> -asmlinkage long sys_iopl(unsigned long regsp)
> -{
> - volatile struct pt_regs *regs = (struct pt_regs *)
> - unsigned int level = regs->bx;
> - unsigned int old = (regs->flags >> 12) & 3;
> - struct thread_struct *t = >thread;
> -
> - if (level > 3)
> - return -EINVAL;
> - /* Trying to gain more privileges? */
> - if (level > old) {
> - if (!capable(CAP_SYS_RAWIO))
> - return -EPERM;
> - }
> -
> - t->iopl = level << 12;
> - regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | t->iopl;
> - set_iopl_mask(t->iopl);
> -
> - return 0;
> -}
Is it OK that we lost the different final steps of those two functions?
It looks like someone might have missed the differing tail sections of
the function when copying and pasting and updating just the start of the
functions?
Sorry if I missed why this is OK and intended, I didn't read very closely.
- z
--
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: hwclock failure in x86.git
On Thu, 10 Jan 2008 17:13:51 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Kevin Winchester wrote:
> > H. Peter Anvin wrote:
> >> Kevin Winchester wrote:
> >>> My first time building and booting the mm branch of x86.git was pretty
> >>> successful. The only error I noticed was the following in my dmesg:
> >>>
> >>> hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
> >>>
> >>> I'm not sure exactly how to debug this. I could bisect, but there seems
> >>> to be some useful debug information in there, so there might be
> >>> something better to try first.
> >>>
> >> That's a userspace IP; it implies the userspace hwclock binary did
> >> something bad, or the kernel didn't permit it to do something it should
> >> have. The best thing to do would probably to strace hwclock and see
> >> what it did when it died.
> >>
> >
> > Unfortunately, but the time I can get a chance to run hwclock, the
> > problem seems to have fixed itself. I tried booting into single user
> > mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.
> >
>
> The other thing you can do is to download the debug information and
> source code for hwclock from your particular distro, and find out
> exactly what operation inside the hwclock binary is triggering the segfault.
>
> The only other option is to bisect.
>
The first thing I notice about the path is that ioport_32.c and the unified
ioport.c use __clear_bit,
while ioport_64.c uses clear_bit.
>From include/asm-x86/bitops.h:
static inline void clear_bit(int nr, volatile void *addr)
{
asm volatile(LOCK_PREFIX "btr %1,%0"
: ADDR
: "Ir" (nr));
}
static inline void __clear_bit(int nr, volatile void *addr)
{
asm volatile("btr %1,%0" : ADDR : "Ir" (nr));
}
so it looks like we removed a lock prefix for the 64-bit case. Was that
intentional? Since I'm building for 32-bit, I'm not sure why I was affected,
so maybe my problem is different. Ingo, didn't you have a script somewhere to
test the before and after of unification patches (or am I remembering something
else)?
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 8b4a8de..91a1795 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -10,7 +10,7 @@ CFLAGS_vsyscall_64.o := $(PROFILING) -g0
obj-y := process_$(BITS).o signal_$(BITS).o entry_$(BITS).o
obj-y += traps_$(BITS).o irq_$(BITS).o
-obj-y += time_$(BITS).o ioport_$(BITS).o ldt.o
+obj-y += time_$(BITS).o ioport.o ldt.o
obj-y += setup_$(BITS).o i8259_$(BITS).o
obj-$(CONFIG_X86_32) += sys_i386_32.o i386_ksyms_32.o
obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
new file mode 100644
index 000..e723ff3
--- /dev/null
+++ b/arch/x86/kernel/ioport.c
@@ -0,0 +1,150 @@
+/*
+ * This contains the io-permission bitmap code - written by obz, with changes
+ * by Linus. 32/64 bits code unification by Miguel Botón.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Set EXTENT bits starting at BASE in BITMAP to value TURN_ON. */
+static void set_bitmap(unsigned long *bitmap, unsigned int base,
+ unsigned int extent, int new_value)
+{
+ unsigned int i;
+
+ for (i = base; i < base + extent; i++) {
+ if (new_value)
+ __set_bit(i, bitmap);
+ else
+ __clear_bit(i, bitmap);
+ }
+}
+
+/*
+ * this changes the io permissions bitmap in the current task.
+ */
+asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on)
+{
+ struct thread_struct * t = >thread;
+ struct tss_struct * tss;
+ unsigned int i, max_long, bytes, bytes_updated;
+
+ if ((from + num <= from) || (from + num > IO_BITMAP_BITS))
+ return -EINVAL;
+ if (turn_on && !capable(CAP_SYS_RAWIO))
+ return -EPERM;
+
+ /*
+* If it's the first ioperm() call in this thread's lifetime, set the
+* IO bitmap up. ioperm() is much less timing critical than clone(),
+* this is why we delay this operation until now:
+*/
+ if (!t->io_bitmap_ptr) {
+ unsigned long *bitmap = kmalloc(IO_BITMAP_BYTES, GFP_KERNEL);
+
+
Re: hwclock failure in x86.git
On Thu, 10 Jan 2008 17:13:51 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Kevin Winchester wrote:
> > H. Peter Anvin wrote:
> >> Kevin Winchester wrote:
> >>> My first time building and booting the mm branch of x86.git was pretty
> >>> successful. The only error I noticed was the following in my dmesg:
> >>>
> >>> hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
> >>>
> >>> I'm not sure exactly how to debug this. I could bisect, but there seems
> >>> to be some useful debug information in there, so there might be
> >>> something better to try first.
> >>>
> >> That's a userspace IP; it implies the userspace hwclock binary did
> >> something bad, or the kernel didn't permit it to do something it should
> >> have. The best thing to do would probably to strace hwclock and see
> >> what it did when it died.
> >>
> >
> > Unfortunately, but the time I can get a chance to run hwclock, the
> > problem seems to have fixed itself. I tried booting into single user
> > mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.
> >
>
> The other thing you can do is to download the debug information and
> source code for hwclock from your particular distro, and find out
> exactly what operation inside the hwclock binary is triggering the segfault.
>
> The only other option is to bisect.
>
Bisect says...
4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b is first bad commit
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
I'll take a look at the unification and see if I can see anything obvious.
--
Kevin Winchester <[EMAIL PROTECTED]>
--
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: hwclock failure in x86.git
Kevin Winchester wrote: H. Peter Anvin wrote: Kevin Winchester wrote: My first time building and booting the mm branch of x86.git was pretty successful. The only error I noticed was the following in my dmesg: hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 I'm not sure exactly how to debug this. I could bisect, but there seems to be some useful debug information in there, so there might be something better to try first. That's a userspace IP; it implies the userspace hwclock binary did something bad, or the kernel didn't permit it to do something it should have. The best thing to do would probably to strace hwclock and see what it did when it died. Unfortunately, but the time I can get a chance to run hwclock, the problem seems to have fixed itself. I tried booting into single user mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt. The other thing you can do is to download the debug information and source code for hwclock from your particular distro, and find out exactly what operation inside the hwclock binary is triggering the segfault. The only other option is to bisect. -hpa -- 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: hwclock failure in x86.git
H. Peter Anvin wrote: > Kevin Winchester wrote: >> My first time building and booting the mm branch of x86.git was pretty >> successful. The only error I noticed was the following in my dmesg: >> >> hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 >> >> I'm not sure exactly how to debug this. I could bisect, but there seems >> to be some useful debug information in there, so there might be >> something better to try first. >> > > That's a userspace IP; it implies the userspace hwclock binary did > something bad, or the kernel didn't permit it to do something it should > have. The best thing to do would probably to strace hwclock and see > what it did when it died. > Unfortunately, but the time I can get a chance to run hwclock, the problem seems to have fixed itself. I tried booting into single user mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt. A few other facts: - This is an Athlon64 box running X83_32 - I use hpet=force for the Via chipset - A little more of the demsg is: [ 17.511262] rtc_cmos 00:05: setting system clock to 2008-01-10 23:44:16 UTC (128656) [ 17.545948] EXT3-fs: mounted filesystem with ordered data mode. [ 17.545986] VFS: Mounted root (ext3 filesystem) readonly. [ 17.546142] Freeing unused kernel memory: 144k freed [ 17.546260] kjournald starting. Commit interval 5 seconds [ 21.861249] hwclock[622] general protection ip:804b226 sp:bfd98480 error:0 [ 22.416442] Velocity is AUTO mode [ 23.093416] Adding 1502036k swap on /dev/sda5. Priority:-1 extents:1 across:1502036k [ 23.416756] EXT3 FS on sda1, internal journal [ 24.009669] kjournald starting. Commit interval 5 seconds [ 24.009889] EXT3 FS on sda6, internal journal [ 24.009899] EXT3-fs: mounted filesystem with ordered data mode. [ 24.053164] eth0: Link auto-negotiation speed 100M bps full duplex [ 28.733360] agpgart: Found an AGP 3.0 compliant device at :00:00.0. [ 28.733872] agpgart: Putting AGP V3 device at :00:00.0 into 8x mode [ 28.734354] agpgart: Putting AGP V3 device at :01:00.0 into 8x mode [ 29.089412] [drm] Setting GART location based on new memory map [ 29.089842] [drm] Loading R200 Microcode [ 29.090172] [drm] writeback test succeeded in 1 usecs [ 143.076821] Marking TSC unstable due to: cpufreq changes. [ 143.084910] Time: hpet clocksource has been installed. [ 143.670905] Clocksource tsc unstable (delta = -231086796 ns) So the TSC is being marked unstable because of cpufreq changes. I have no idea when it comes to TSCs and HPETs and how the RTC works (other than what the abbreviations stand for), so this all may be meaningless. I'll try disabling cpufreq to see if that has an effect. -- Kevin Winchester -- 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: hwclock failure in x86.git
Kevin Winchester wrote: My first time building and booting the mm branch of x86.git was pretty successful. The only error I noticed was the following in my dmesg: hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 I'm not sure exactly how to debug this. I could bisect, but there seems to be some useful debug information in there, so there might be something better to try first. That's a userspace IP; it implies the userspace hwclock binary did something bad, or the kernel didn't permit it to do something it should have. The best thing to do would probably to strace hwclock and see what it did when it died. -hpa -- 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/
hwclock failure in x86.git
My first time building and booting the mm branch of x86.git was pretty successful. The only error I noticed was the following in my dmesg: hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 I'm not sure exactly how to debug this. I could bisect, but there seems to be some useful debug information in there, so there might be something better to try first. On a side note, if bisection is the best option, I have a cloned git repository of Linus' git, and I added the x86.git mm branch as a remote tracking branch. Are there any special rules I need to follow to bisect that, or would I still start with: git bisect start git bisect bad git bisect good v2.6.24-rc7 ?? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc7 # Thu Jan 10 19:03:13 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_ARCH_SETS_UP_PER_CPU_AREA is not set CONFIG_ARCH_SUPPORTS_OPROFILE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_PM_CPUINIT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y
hwclock failure in x86.git
My first time building and booting the mm branch of x86.git was pretty successful. The only error I noticed was the following in my dmesg: hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 I'm not sure exactly how to debug this. I could bisect, but there seems to be some useful debug information in there, so there might be something better to try first. On a side note, if bisection is the best option, I have a cloned git repository of Linus' git, and I added the x86.git mm branch as a remote tracking branch. Are there any special rules I need to follow to bisect that, or would I still start with: git bisect start git bisect bad git bisect good v2.6.24-rc7 ?? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc7 # Thu Jan 10 19:03:13 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_ARCH_SETS_UP_PER_CPU_AREA is not set CONFIG_ARCH_SUPPORTS_OPROFILE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_PM_CPUINIT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set CONFIG_BLK_DEV_BSG=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y
Re: hwclock failure in x86.git
Kevin Winchester wrote: My first time building and booting the mm branch of x86.git was pretty successful. The only error I noticed was the following in my dmesg: hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 I'm not sure exactly how to debug this. I could bisect, but there seems to be some useful debug information in there, so there might be something better to try first. That's a userspace IP; it implies the userspace hwclock binary did something bad, or the kernel didn't permit it to do something it should have. The best thing to do would probably to strace hwclock and see what it did when it died. -hpa -- 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: hwclock failure in x86.git
H. Peter Anvin wrote: Kevin Winchester wrote: My first time building and booting the mm branch of x86.git was pretty successful. The only error I noticed was the following in my dmesg: hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 I'm not sure exactly how to debug this. I could bisect, but there seems to be some useful debug information in there, so there might be something better to try first. That's a userspace IP; it implies the userspace hwclock binary did something bad, or the kernel didn't permit it to do something it should have. The best thing to do would probably to strace hwclock and see what it did when it died. Unfortunately, but the time I can get a chance to run hwclock, the problem seems to have fixed itself. I tried booting into single user mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt. A few other facts: - This is an Athlon64 box running X83_32 - I use hpet=force for the Via chipset - A little more of the demsg is: [ 17.511262] rtc_cmos 00:05: setting system clock to 2008-01-10 23:44:16 UTC (128656) [ 17.545948] EXT3-fs: mounted filesystem with ordered data mode. [ 17.545986] VFS: Mounted root (ext3 filesystem) readonly. [ 17.546142] Freeing unused kernel memory: 144k freed [ 17.546260] kjournald starting. Commit interval 5 seconds [ 21.861249] hwclock[622] general protection ip:804b226 sp:bfd98480 error:0 [ 22.416442] Velocity is AUTO mode [ 23.093416] Adding 1502036k swap on /dev/sda5. Priority:-1 extents:1 across:1502036k [ 23.416756] EXT3 FS on sda1, internal journal [ 24.009669] kjournald starting. Commit interval 5 seconds [ 24.009889] EXT3 FS on sda6, internal journal [ 24.009899] EXT3-fs: mounted filesystem with ordered data mode. [ 24.053164] eth0: Link auto-negotiation speed 100M bps full duplex [ 28.733360] agpgart: Found an AGP 3.0 compliant device at :00:00.0. [ 28.733872] agpgart: Putting AGP V3 device at :00:00.0 into 8x mode [ 28.734354] agpgart: Putting AGP V3 device at :01:00.0 into 8x mode [ 29.089412] [drm] Setting GART location based on new memory map [ 29.089842] [drm] Loading R200 Microcode [ 29.090172] [drm] writeback test succeeded in 1 usecs [ 143.076821] Marking TSC unstable due to: cpufreq changes. [ 143.084910] Time: hpet clocksource has been installed. [ 143.670905] Clocksource tsc unstable (delta = -231086796 ns) So the TSC is being marked unstable because of cpufreq changes. I have no idea when it comes to TSCs and HPETs and how the RTC works (other than what the abbreviations stand for), so this all may be meaningless. I'll try disabling cpufreq to see if that has an effect. -- Kevin Winchester -- 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: hwclock failure in x86.git
Kevin Winchester wrote: H. Peter Anvin wrote: Kevin Winchester wrote: My first time building and booting the mm branch of x86.git was pretty successful. The only error I noticed was the following in my dmesg: hwclock[622] general protection ip:804b226 sp:bff43e30 error:0 I'm not sure exactly how to debug this. I could bisect, but there seems to be some useful debug information in there, so there might be something better to try first. That's a userspace IP; it implies the userspace hwclock binary did something bad, or the kernel didn't permit it to do something it should have. The best thing to do would probably to strace hwclock and see what it did when it died. Unfortunately, but the time I can get a chance to run hwclock, the problem seems to have fixed itself. I tried booting into single user mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt. The other thing you can do is to download the debug information and source code for hwclock from your particular distro, and find out exactly what operation inside the hwclock binary is triggering the segfault. The only other option is to bisect. -hpa -- 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: hwclock failure in x86.git
On Thu, 10 Jan 2008 17:13:51 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Kevin Winchester wrote:
H. Peter Anvin wrote:
Kevin Winchester wrote:
My first time building and booting the mm branch of x86.git was pretty
successful. The only error I noticed was the following in my dmesg:
hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
I'm not sure exactly how to debug this. I could bisect, but there seems
to be some useful debug information in there, so there might be
something better to try first.
That's a userspace IP; it implies the userspace hwclock binary did
something bad, or the kernel didn't permit it to do something it should
have. The best thing to do would probably to strace hwclock and see
what it did when it died.
Unfortunately, but the time I can get a chance to run hwclock, the
problem seems to have fixed itself. I tried booting into single user
mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.
The other thing you can do is to download the debug information and
source code for hwclock from your particular distro, and find out
exactly what operation inside the hwclock binary is triggering the segfault.
The only other option is to bisect.
Bisect says...
4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b is first bad commit
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
I'll take a look at the unification and see if I can see anything obvious.
--
Kevin Winchester [EMAIL PROTECTED]
--
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: hwclock failure in x86.git
On Thu, 10 Jan 2008 17:13:51 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Kevin Winchester wrote:
H. Peter Anvin wrote:
Kevin Winchester wrote:
My first time building and booting the mm branch of x86.git was pretty
successful. The only error I noticed was the following in my dmesg:
hwclock[622] general protection ip:804b226 sp:bff43e30 error:0
I'm not sure exactly how to debug this. I could bisect, but there seems
to be some useful debug information in there, so there might be
something better to try first.
That's a userspace IP; it implies the userspace hwclock binary did
something bad, or the kernel didn't permit it to do something it should
have. The best thing to do would probably to strace hwclock and see
what it did when it died.
Unfortunately, but the time I can get a chance to run hwclock, the
problem seems to have fixed itself. I tried booting into single user
mode, but `/etc/init.d/hwclock.sh restart` succeeds once I have my prompt.
The other thing you can do is to download the debug information and
source code for hwclock from your particular distro, and find out
exactly what operation inside the hwclock binary is triggering the segfault.
The only other option is to bisect.
The first thing I notice about the path is that ioport_32.c and the unified
ioport.c use __clear_bit,
while ioport_64.c uses clear_bit.
From include/asm-x86/bitops.h:
static inline void clear_bit(int nr, volatile void *addr)
{
asm volatile(LOCK_PREFIX btr %1,%0
: ADDR
: Ir (nr));
}
static inline void __clear_bit(int nr, volatile void *addr)
{
asm volatile(btr %1,%0 : ADDR : Ir (nr));
}
so it looks like we removed a lock prefix for the 64-bit case. Was that
intentional? Since I'm building for 32-bit, I'm not sure why I was affected,
so maybe my problem is different. Ingo, didn't you have a script somewhere to
test the before and after of unification patches (or am I remembering something
else)?
commit 4b5ea240a0c05ff90c4959fd91f0caec7b9bef1b
Author: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Wed Jan 9 13:31:11 2008 +0100
x86: ioport_{32|64}.c unification
ioport_{32|64}.c unification.
This patch unifies the code from the ioport_32.c and ioport_64.c files.
Tested and working fine with i386 and x86_64 kernels.
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 8b4a8de..91a1795 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -10,7 +10,7 @@ CFLAGS_vsyscall_64.o := $(PROFILING) -g0
obj-y := process_$(BITS).o signal_$(BITS).o entry_$(BITS).o
obj-y += traps_$(BITS).o irq_$(BITS).o
-obj-y += time_$(BITS).o ioport_$(BITS).o ldt.o
+obj-y += time_$(BITS).o ioport.o ldt.o
obj-y += setup_$(BITS).o i8259_$(BITS).o
obj-$(CONFIG_X86_32) += sys_i386_32.o i386_ksyms_32.o
obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o
diff --git a/arch/x86/kernel/ioport.c b/arch/x86/kernel/ioport.c
new file mode 100644
index 000..e723ff3
--- /dev/null
+++ b/arch/x86/kernel/ioport.c
@@ -0,0 +1,150 @@
+/*
+ * This contains the io-permission bitmap code - written by obz, with changes
+ * by Linus. 32/64 bits code unification by Miguel Botón.
+ */
+
+#include linux/sched.h
+#include linux/kernel.h
+#include linux/capability.h
+#include linux/errno.h
+#include linux/types.h
+#include linux/ioport.h
+#include linux/smp.h
+#include linux/stddef.h
+#include linux/slab.h
+#include linux/thread_info.h
+#include linux/syscalls.h
+
+/* Set EXTENT bits starting at BASE in BITMAP to value TURN_ON. */
+static void set_bitmap(unsigned long *bitmap, unsigned int base,
+ unsigned int extent, int new_value)
+{
+ unsigned int i;
+
+ for (i = base; i base + extent; i++) {
+ if (new_value)
+ __set_bit(i, bitmap);
+ else
+ __clear_bit(i, bitmap);
+ }
+}
+
+/*
+ * this changes the io permissions bitmap in the current task.
+ */
+asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on)
+{
+ struct thread_struct * t = current-thread;
+ struct tss_struct * tss;
+ unsigned int i, max_long, bytes, bytes_updated;
+
+ if ((from + num = from) || (from + num IO_BITMAP_BITS))
+ return -EINVAL;
+ if (turn_on !capable(CAP_SYS_RAWIO))
+ return -EPERM;
+
+ /*
+* If it's the first ioperm() call in this thread's lifetime, set the
+* IO bitmap up. ioperm() is much less timing critical than clone(),
+* this is why we delay this operation until now:
+*/
+ if (!t-io_bitmap_ptr) {
+
Re: hwclock failure in x86.git
I'm no expert, but I happened to notice this go by.
The first thing I notice about the path is that ioport_32.c and the unified
ioport.c use __clear_bit,
while ioport_64.c uses clear_bit.
That doesn't seem too critical.
+#ifdef CONFIG_X86_32
+asmlinkage long sys_iopl(unsigned long regsp)
+{
+ volatile struct pt_regs *regs = (struct pt_regs *)regsp;
+ unsigned int level = regs-bx;
+ unsigned int old = (regs-flags 12) 3;
+
+ if (level 3)
+ return -EINVAL;
+ /* Trying to gain more privileges? */
+ if (level old) {
+ if (!capable(CAP_SYS_RAWIO))
+ return -EPERM;
+ }
+ regs-flags = (regs-flags ~X86_EFLAGS_IOPL) | (level 12);
+
+ return 0;
+}
-asmlinkage long sys_iopl(unsigned long regsp)
-{
- volatile struct pt_regs *regs = (struct pt_regs *)regsp;
- unsigned int level = regs-bx;
- unsigned int old = (regs-flags 12) 3;
- struct thread_struct *t = current-thread;
-
- if (level 3)
- return -EINVAL;
- /* Trying to gain more privileges? */
- if (level old) {
- if (!capable(CAP_SYS_RAWIO))
- return -EPERM;
- }
-
- t-iopl = level 12;
- regs-flags = (regs-flags ~X86_EFLAGS_IOPL) | t-iopl;
- set_iopl_mask(t-iopl);
-
- return 0;
-}
Is it OK that we lost the different final steps of those two functions?
It looks like someone might have missed the differing tail sections of
the function when copying and pasting and updating just the start of the
functions?
Sorry if I missed why this is OK and intended, I didn't read very closely.
- z
--
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/
