[PATCH]new_TSC_based_delay_tsc()
Hi all,
This is a patch based on the Ingo's idea/patch to track
delay_tsc() migration to another cpu by comparing
smp_processor_id(). It is against kernel-2.6.24-rc3.
What is different:
1. Using unsigned (instead of long) to unify for i386/x86_64.
2. Minimal preempt_disable/enable() critical sections
(more room for preemption)
3. some statements have been rearranged, to account for
possible under/overflow of left/TSC
Tested on both: 32/64 bit SMP PREEMPT kernel-2.6.24-rc3
Hope it is correct. Comments, please.
Signed-off-by: Marin Mitov <[EMAIL PROTECTED]>
=
--- a/arch/x86/lib/delay_32.c 2007-11-18 10:20:45.0 +0200
+++ b/arch/x86/lib/delay_32.c 2007-11-18 10:20:44.0 +0200
@@ -38,18 +38,41 @@
:"0" (loops));
}
-/* TSC based delay: */
+/* TSC based delay:
+ *
+ * We are careful about preemption as TSC's are per-CPU.
+ */
static void delay_tsc(unsigned long loops)
{
- unsigned long bclock, now;
+ unsigned prev, now;
+ unsigned left = loops;
+ unsigned prev_cpu, cpu;
+
+ preempt_disable();
+ rdtscl(prev);
+ prev_cpu = smp_processor_id();
+ preempt_enable();
+ now = prev;
- preempt_disable(); /* TSC's are per-cpu */
- rdtscl(bclock);
do {
rep_nop();
+
+ left -= now - prev;
+ prev = now;
+
+ preempt_disable();
rdtscl(now);
- } while ((now-bclock) < loops);
- preempt_enable();
+ cpu = smp_processor_id();
+ preempt_enable();
+
+ if (prev_cpu != cpu){
+ /*
+* We have migrated, we skip this small amount of time:
+*/
+ prev = now;
+ prev_cpu = cpu;
+ }
+ } while ((now-prev) < left);
}
/*
--- a/arch/x86/lib/delay_64.c 2007-11-18 10:20:44.0 +0200
+++ b/arch/x86/lib/delay_64.c 2007-11-18 10:20:44.0 +0200
@@ -26,18 +26,42 @@
return 0;
}
+/* TSC based delay:
+ *
+ * We are careful about preemption as TSC's are per-CPU.
+ */
void __delay(unsigned long loops)
{
- unsigned bclock, now;
+ unsigned prev, now;
+ unsigned left = loops;
+ unsigned prev_cpu, cpu;
+
+ preempt_disable();
+ rdtscl(prev);
+ prev_cpu = smp_processor_id();
+ preempt_enable();
+ now = prev;
- preempt_disable(); /* TSC's are pre-cpu */
- rdtscl(bclock);
do {
- rep_nop();
+ rep_nop();
+
+ left -= now - prev;
+ prev = now;
+
+ preempt_disable();
rdtscl(now);
+ cpu = smp_processor_id();
+ preempt_enable();
+
+ if (prev_cpu != cpu){
+ /*
+* We have migrated, we skip this small amount of time:
+*/
+prev = now;
+prev_cpu = cpu;
+ }
}
- while ((now-bclock) < loops);
- preempt_enable();
+ while ((now-prev) < left);
}
EXPORT_SYMBOL(__delay);
-
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: sb live (emu10k1) stops working between 2.6.23.1 and 2.6.23.7
> I've done some more testing this morning, and it appears that the "ALSA: > emu10k1 - Fix memory corruption" patch from 2.6.23.6 has broken digital > output on my SB Live Value card. Simply replacing the 2.6.23.7 emumixer.c > with the version included in 2.6.23.1 I was able to get digital output > working again under 2.6.23.7. Hi Jim, Just to prove you are not alone, I also get the exactly the same issue: lspci: 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) log: Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC). PCI: Found IRQ 5 for device :00:0f.0 ALSA device list: #0: SBLive 5.1 [SB0060] (rev.7, serial:0x80611102) at 0xe000, irq 5 I use a restore file at boot, so run /sbin/alsactl restore And updating this morning to 2.6.23.8 produces: /usr/sbin/alsactl: set_control:991: warning: name mismatch (IEC958 Playback Mask/IEC958 Playback Default) for control #228 /usr/sbin/alsactl: set_control:993: warning: index mismatch (3/0) for control #228 /usr/sbin/alsactl: set_control:993: warning: index mismatch (0/1) for control #229 /usr/sbin/alsactl: set_control:993: warning: index mismatch (1/2) for control #230 /usr/sbin/alsactl: set_control:985: warning: iface mismatch (3/2) for control #231 /usr/sbin/alsactl: set_control:987: warning: device mismatch (2/0) for control #231 /usr/sbin/alsactl: set_control:989: warning: subdevice mismatch (0/0) for control #231 /usr/sbin/alsactl: set_control:991: warning: name mismatch (IEC958 Playback Default/SB Live Analog/Digital Output Jack) for control #231 Nick > On Fri, 16 Nov 2007, Jim Faulkner wrote: > > Hello, > > I have an SB Live Value card which uses the emu10k1 driver. I use digital > output to an external amplifier. This has worked fine for many years, up > to and including kernel 2.6.23.1. Under 2.6.23.7, I have been unable > to get any audio output. I get the following errors when loading my > asound.state under 2.6.23.7 using `alsactl restore`: > alsactl: set_control:991: warning: name mismatch (IEC958 Playback > Mask/IEC958 Playback Default) for control #222 > alsactl: set_control:993: warning: index mismatch (3/0) for control #222 > alsactl: set_control:993: warning: index mismatch (0/1) for control #223 > alsactl: set_control:993: warning: index mismatch (1/2) for control #224 > alsactl: set_control:985: warning: iface mismatch (3/2) for control #225 > alsactl: set_control:987: warning: device mismatch (2/0) for control #225 > alsactl: set_control:989: warning: subdevice mismatch (0/0) for control > #225 > alsactl: set_control:991: warning: name mismatch (IEC958 Playback > Default/SB Live Analog/Digital Output Jack) for control #225 > alsactl: set_control:993: warning: index mismatch (2/0) for control #225 > alsactl: set_control:995: failed to obtain info for control #225 > (Operation not permitted) > > I receive no errors when I load my asound.state under 2.6.23.1. -- Free Software Foundation Associate Member 5508 - 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 2/3] wait_task_stopped: tidy up the noreap case
On Sat, 2007-11-17 at 19:38 +0300, Oleg Nesterov wrote: > > While you're at it, you could fix the status argument to > wait_noreap_copyout. > > It should be just exit_code, not the WIFSTOPPED bit format it does now. > > OK, unless Scott is going to do this. > Have sent this patch separately to the list -- since it's actually my first ever, I hope I got the format/sign-off/etc. right. Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
[PATCH] wait_task_stopped: pass correct exit_code to wait_noreap_copyout
In wait_task_stopped() exit_code already contains the right value for the si_status member of siginfo, and this is simply set in the non WNOWAIT case. Pass it unchanged to wait_noreap_copyout(); we would only need to shift it and add 0x7f if we were returning it in the user status field and that isn't used for any function that permits WNOWAIT. Signed-off-by: Scott James Remnant <[EMAIL PROTECTED]> Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]> Signed-off-by: Roland McGrath <[EMAIL PROTECTED]> --- a/kernel/exit.c +++ b/kernel/exit.c @@ -1389,7 +1389,7 @@ static int wait_task_stopped(struct task_struct *p, int delayed_group_leader, if (unlikely(!exit_code) || unlikely(p->exit_state)) goto bail_ref; return wait_noreap_copyout(p, pid, uid, - why, (exit_code << 8) | 0x7f, + why, exit_code, infop, ru); } signature.asc Description: This is a digitally signed message part
[PATCH] checkpatch: Print filenames of patches
checkpatch: Print filenames of patches instead of the very uninformative
`Your patch'.
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
This patch is not `checkpatch' clean :-)
Although I shortened 2 lines, they're still longer than 80 characters...
scripts/checkpatch.pl |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1408,10 +1408,10 @@ sub process {
}
}
if ($clean == 1 && $quiet == 0) {
- print "Your patch has no obvious style problems and is ready
for submission.\n"
+ print "$filename has no obvious style problems and is ready for
submission.\n"
}
if ($clean == 0 && $quiet == 0) {
- print "Your patch has style problems, please review. If any of
these errors\n";
+ print "$filename has style problems, please review. If any of
these errors\n";
print "are false positives report them to the maintainer,
see\n";
print "CHECKPATCH in MAINTAINERS.\n";
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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: [PATCHv3 0/4] sys_indirect system call
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 H. Peter Anvin wrote: > It seems to me that we could accomplish the same thing by passing the > number of parameters in the upper bits of the system call number > register (%eax in the case of x86.) This isn't really a generic solution. The number of parameters is limited to six. There are syscalls with six parameters already. There are many more with five which could only handle one more parameter. Also, is it really simpler? You'd need to have another table which contains the default number of parameters a system call takes so that you can fill in the default value of zero. This extra memory access has to be performed for every system call. I think it is unlikely that this approach is faster. To the contrary, I'd guess. I don't have much invested into this but it seems the sys_indirect approach is so much simpler. Overhead is only paid if you really need it which is rarely the case. Plus, you might have heard Linus and Zack talk about syslets again. Starting syslets can be done using the same interface, I guess. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHQAez2ijCOnn/RHQRAjoHAJ4/Qq4ygaZ4uq6uCIVNq4hfN1m2pACgpJFi Z/vBsGFpUc/EUz+VW66jEIY= =B19x -END PGP SIGNATURE- - 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 3/3] mac68k: mailing list addresss
From: Finn Thain <[EMAIL PROTECTED]>
The mail service for the mac.linux-m68k.org domain is defunct.
Signed-off-by: Finn Thain <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
MAINTAINERS |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2446,7 +2446,7 @@ M68K ON APPLE MACINTOSH
P: Joshua Thompson
M: [EMAIL PROTECTED]
W: http://www.mac.linux-m68k.org/
-L: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
S: Maintained
M68K ON HP9000/300
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 00/13] m68k patches for 2.6.25
Hi Andrew,
Here are some m68k patches for 2.6.25:
[1] m68k: ARRAY_SIZE() cleanup
[2] dio: ARRAY_SIZE() cleanup
[3] m68k: Balance ioremap and iounmap in m68k/atari/hades-pci.c
[4] nubus: kill drivers/nubus/nubus_syms.c
[5] m68k: kill arch/m68k/mac/mac_ksyms.c
[6] m68k: kill arch/m68k/hp300/ksyms.c
[7] m68k: kill arch/m68k/amiga/amiga_ksyms.c
[8] m68k: kill arch/m68k/atari/atari_ksyms.c
[9] m68k: kill arch/m68k/mvme16x/mvme16x_ksyms.c
[10] mac68k: macii adb comment correction
[11] mac68k: remove dead code
[12] mac68k: add nubus card definitions and a typo fix
[13] mac68k: remove dead MAC_ADBKEYCODES
Please queue for 2.6.25. Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 02/13] dio: ARRAY_SIZE() cleanup
From: Alejandro Martinez Ruiz <[EMAIL PROTECTED]>
dio: ARRAY_SIZE() cleanup
Signed-off-by: Alejandro Martinez Ruiz <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/dio/dio.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dio/dio.c
+++ b/drivers/dio/dio.c
@@ -88,7 +88,7 @@ static struct dioname names[] =
#undef DIONAME
#undef DIOFBNAME
-#define NUMNAMES (sizeof(names) / sizeof(struct dioname))
+#define NUMNAMES ARRAY_SIZE(names)
static const char *unknowndioname
= "unknown DIO board -- please email <[EMAIL PROTECTED]>!";
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 09/13] m68k: kill arch/m68k/mvme16x/mvme16x_ksyms.c
From: Adrian Bunk <[EMAIL PROTECTED]>
m68k: kill arch/m68k/mvme16x/mvme16x_ksyms.c
EXPORT_SYMBOL's belong to the actual code.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/m68k/mvme16x/Makefile|2 +-
arch/m68k/mvme16x/config.c|2 ++
arch/m68k/mvme16x/mvme16x_ksyms.c |6 --
3 files changed, 3 insertions(+), 7 deletions(-)
--- a/arch/m68k/mvme16x/Makefile
+++ b/arch/m68k/mvme16x/Makefile
@@ -2,4 +2,4 @@
# Makefile for Linux arch/m68k/mvme16x source directory
#
-obj-y := config.o rtc.o mvme16x_ksyms.o
+obj-y := config.o rtc.o
--- a/arch/m68k/mvme16x/config.c
+++ b/arch/m68k/mvme16x/config.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -58,6 +59,7 @@ static irq_handler_t tick_handler;
unsigned short mvme16x_config;
+EXPORT_SYMBOL(mvme16x_config);
int mvme16x_parse_bootinfo(const struct bi_record *bi)
--- a/arch/m68k/mvme16x/mvme16x_ksyms.c
+++ /dev/null
@@ -1,6 +0,0 @@
-#include
-#include
-#include
-#include
-
-EXPORT_SYMBOL(mvme16x_config);
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 08/13] m68k: kill arch/m68k/atari/atari_ksyms.c
From: Adrian Bunk <[EMAIL PROTECTED]>
m68k: kill arch/m68k/atari/atari_ksyms.c
EXPORT_SYMBOL's belong to the actual code.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/m68k/atari/Makefile |2 +-
arch/m68k/atari/ataints.c |3 +++
arch/m68k/atari/atari_ksyms.c | 35 ---
arch/m68k/atari/atasound.c|2 ++
arch/m68k/atari/config.c | 11 +++
arch/m68k/atari/debug.c |6 ++
arch/m68k/atari/stdma.c |5 +
arch/m68k/atari/stram.c |3 +++
8 files changed, 31 insertions(+), 36 deletions(-)
--- a/arch/m68k/atari/Makefile
+++ b/arch/m68k/atari/Makefile
@@ -3,7 +3,7 @@
#
obj-y := config.o time.o debug.o ataints.o stdma.o \
- atasound.o stram.o atari_ksyms.o
+ atasound.o stram.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_HADES)+= hades-pci.o
--- a/arch/m68k/atari/ataints.c
+++ b/arch/m68k/atari/ataints.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
@@ -446,6 +447,7 @@ unsigned long atari_register_vme_int(voi
free_vme_vec_bitmap |= 1 << i;
return VME_SOURCE_BASE + i;
}
+EXPORT_SYMBOL(atari_register_vme_int);
void atari_unregister_vme_int(unsigned long irq)
@@ -455,5 +457,6 @@ void atari_unregister_vme_int(unsigned l
free_vme_vec_bitmap &= ~(1 << irq);
}
}
+EXPORT_SYMBOL(atari_unregister_vme_int);
--- a/arch/m68k/atari/atari_ksyms.c
+++ /dev/null
@@ -1,35 +0,0 @@
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-extern void atari_microwire_cmd( int cmd );
-extern int atari_MFP_init_done;
-extern int atari_SCC_init_done;
-extern int atari_SCC_reset_done;
-
-EXPORT_SYMBOL(atari_mch_cookie);
-EXPORT_SYMBOL(atari_mch_type);
-EXPORT_SYMBOL(atari_hw_present);
-EXPORT_SYMBOL(atari_switches);
-EXPORT_SYMBOL(atari_dont_touch_floppy_select);
-EXPORT_SYMBOL(atari_register_vme_int);
-EXPORT_SYMBOL(atari_unregister_vme_int);
-EXPORT_SYMBOL(stdma_lock);
-EXPORT_SYMBOL(stdma_release);
-EXPORT_SYMBOL(stdma_others_waiting);
-EXPORT_SYMBOL(stdma_islocked);
-EXPORT_SYMBOL(atari_stram_alloc);
-EXPORT_SYMBOL(atari_stram_free);
-
-EXPORT_SYMBOL(atari_MFP_init_done);
-EXPORT_SYMBOL(atari_SCC_init_done);
-EXPORT_SYMBOL(atari_SCC_reset_done);
-
-EXPORT_SYMBOL(atari_microwire_cmd);
--- a/arch/m68k/atari/atasound.c
+++ b/arch/m68k/atari/atasound.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -43,6 +44,7 @@ void atari_microwire_cmd (int cmd)
while( tt_microwire.mask != 0x7ff)
;
}
+EXPORT_SYMBOL(atari_microwire_cmd);
/* PSG base frequency */
--- a/arch/m68k/atari/config.c
+++ b/arch/m68k/atari/config.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -43,10 +44,20 @@
#include
u_long atari_mch_cookie;
+EXPORT_SYMBOL(atari_mch_cookie);
+
u_long atari_mch_type;
+EXPORT_SYMBOL(atari_mch_type);
+
struct atari_hw_present atari_hw_present;
+EXPORT_SYMBOL(atari_hw_present);
+
u_long atari_switches;
+EXPORT_SYMBOL(atari_switches);
+
int atari_dont_touch_floppy_select;
+EXPORT_SYMBOL(atari_dont_touch_floppy_select);
+
int atari_rtc_year_offset;
/* local function prototypes */
--- a/arch/m68k/atari/debug.c
+++ b/arch/m68k/atari/debug.c
@@ -15,17 +15,23 @@
#include
#include
#include
+#include
#include
#include
/* Flag that Modem1 port is already initialized and used */
int atari_MFP_init_done;
+EXPORT_SYMBOL(atari_MFP_init_done);
+
/* Flag that Modem1 port is already initialized and used */
int atari_SCC_init_done;
+EXPORT_SYMBOL(atari_SCC_init_done);
+
/* Can be set somewhere, if a SCC master reset has already be done and should
* not be repeated; used by kgdb */
int atari_SCC_reset_done;
+EXPORT_SYMBOL(atari_SCC_reset_done);
static struct console atari_console_driver = {
.name = "debug",
--- a/arch/m68k/atari/stdma.c
+++ b/arch/m68k/atari/stdma.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -91,6 +92,7 @@ void stdma_lock(irq_handler_t handler, v
stdma_isr_data = data;
local_irq_restore(flags);
}
+EXPORT_SYMBOL(stdma_lock);
/*
@@ -117,6 +119,7 @@ void stdma_release(void)
local_irq_restore(flags);
}
+EXPORT_SYMBOL(stdma_release);
/*
@@ -134,6 +137,7 @@ int stdma_others_waiting(void)
{
return waitqueue_active(&stdma_wait);
}
+EXPORT_SYMBOL(stdma_others_waiting);
/*
@@ -155,6 +159,7 @@ int stdma_islocked(void)
{
return stdma_locked;
}
+EXPORT_SYMBOL(stdma_islocked);
/*
--- a/arch/m68k/atari/stram.c
+++ b/arch/m68k/atari/stram.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -208,6 +209,7 @@ void *atari_stram_alloc(long size, const
}
return( addr );
}
+EXPORT_SYMB
[patch 03/13] m68k: Balance ioremap and iounmap in m68k/atari/hades-pci.c
From: Roel Kluin <[EMAIL PROTECTED]>
m68k: Balance ioremap and iounmap in m68k/atari/hades-pci.c
Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/m68k/atari/hades-pci.c | 56 +---
1 file changed, 27 insertions(+), 29 deletions(-)
--- a/arch/m68k/atari/hades-pci.c
+++ b/arch/m68k/atari/hades-pci.c
@@ -376,8 +376,8 @@ struct pci_bus_info * __init init_hades_
*/
bus = kzalloc(sizeof(struct pci_bus_info), GFP_KERNEL);
- if (!bus)
- return NULL;
+ if (unlikely(!bus))
+ goto iounmap_base_virt;
/*
* Claim resources. The m68k has no separate I/O space, both
@@ -385,43 +385,25 @@ struct pci_bus_info * __init init_hades_
* the I/O resources are requested in memory space as well.
*/
- if (request_resource(&iomem_resource, &config_space) != 0)
- {
- kfree(bus);
- return NULL;
- }
-
- if (request_resource(&iomem_resource, &io_space) != 0)
- {
- release_resource(&config_space);
- kfree(bus);
- return NULL;
- }
+ if (unlikely(request_resource(&iomem_resource, &config_space) != 0))
+ goto free_bus;
+
+ if (unlikely(request_resource(&iomem_resource, &io_space) != 0))
+ goto release_config_space;
bus->mem_space.start = HADES_MEM_BASE;
bus->mem_space.end = HADES_MEM_BASE + HADES_MEM_SIZE - 1;
bus->mem_space.name = pci_mem_name;
#if 1
- if (request_resource(&iomem_resource, &bus->mem_space) != 0)
- {
- release_resource(&io_space);
- release_resource(&config_space);
- kfree(bus);
- return NULL;
- }
+ if (unlikely(request_resource(&iomem_resource, &bus->mem_space) != 0))
+ goto release_io_space;
#endif
bus->io_space.start = pci_io_base_virt;
bus->io_space.end = pci_io_base_virt + HADES_VIRT_IO_SIZE - 1;
bus->io_space.name = pci_io_name;
#if 1
- if (request_resource(&ioport_resource, &bus->io_space) != 0)
- {
- release_resource(&bus->mem_space);
- release_resource(&io_space);
- release_resource(&config_space);
- kfree(bus);
- return NULL;
- }
+ if (unlikely(request_resource(&ioport_resource, &bus->io_space) != 0))
+ goto release_bus_mem_space;
#endif
/*
* Set hardware dependent functions.
@@ -438,5 +420,21 @@ struct pci_bus_info * __init init_hades_
tt_mfp.active_edge &= ~0x27;
return bus;
+
+release_bus_mem_space:
+ release_resource(&bus->mem_space);
+release_io_space:
+ release_resource(&io_space);
+release_config_space:
+ release_resource(&config_space);
+free_bus:
+ kfree(bus);
+iounmap_base_virt:
+ iounmap((void *)pci_io_base_virt);
+
+ for (i = 0; i < N_SLOTS; i++)
+ iounmap((void *)pci_conf_base_virt[i]);
+
+ return NULL;
}
#endif
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 0/3] m68k patches for 2.6.24
Hi Linus, Andrew,
Here are 3 m68k patches for 2.6.24:
[1] m68k: export atari_keyb_init
[2] Amiga zorro bus: Add missing zorro_device_remove()
[3] mac68k: mailing list addresss
Please apply. Thx!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 1/3] m68k: export atari_keyb_init
From: Adrian Bunk <[EMAIL PROTECTED]>
m68k: export atari_keyb_init
This patch fixes the following build error:
<-- snip -->
..
MODPOST 25 modules
ERROR: "atari_keyb_init" [drivers/input/mouse/atarimouse.ko] undefined!
ERROR: "atari_keyb_init" [drivers/input/keyboard/atakbd.ko] undefined!
make[2]: *** [__modpost] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/m68k/atari/atakeyb.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/m68k/atari/atakeyb.c
+++ b/arch/m68k/atari/atakeyb.c
@@ -565,7 +565,7 @@ void atari_kbd_leds(unsigned int leds)
static int atari_keyb_done = 0;
-int __init atari_keyb_init(void)
+int atari_keyb_init(void)
{
if (atari_keyb_done)
return 0;
@@ -631,6 +631,7 @@ int __init atari_keyb_init(void)
atari_keyb_done = 1;
return 0;
}
+EXPORT_SYMBOL_GPL(atari_keyb_init);
int atari_kbd_translate(unsigned char keycode, unsigned char *keycodep, char
raw_mode)
{
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 2/3] Amiga zorro bus: Add missing zorro_device_remove()
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
Amiga zorro bus: Add missing zorro_device_remove(). Without this ifconfig and
/proc/net/dev oops after unloading a Zorro network device driver module.
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/zorro/zorro-driver.c | 15 +++
1 file changed, 15 insertions(+)
--- a/drivers/zorro/zorro-driver.c
+++ b/drivers/zorro/zorro-driver.c
@@ -60,6 +60,20 @@ static int zorro_device_probe(struct dev
}
+static int zorro_device_remove(struct device *dev)
+{
+ struct zorro_dev *z = to_zorro_dev(dev);
+ struct zorro_driver *drv = to_zorro_driver(dev->driver);
+
+ if (drv) {
+ if (drv->remove)
+ drv->remove(z);
+ z->driver = NULL;
+ }
+ return 0;
+}
+
+
/**
* zorro_register_driver - register a new Zorro driver
* @drv: the driver structure to register
@@ -128,6 +142,7 @@ struct bus_type zorro_bus_type = {
.name = "zorro",
.match = zorro_bus_match,
.probe = zorro_device_probe,
+ .remove = zorro_device_remove,
};
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 01/13] m68k: ARRAY_SIZE() cleanup
From: Alejandro Martinez Ruiz <[EMAIL PROTECTED]>
m68k: ARRAY_SIZE() cleanup
Signed-off-by: Alejandro Martinez Ruiz <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/m68k/amiga/amisound.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/m68k/amiga/amisound.c
+++ b/arch/m68k/amiga/amisound.c
@@ -21,7 +21,7 @@ static const signed char sine_data[] = {
0, 39, 75, 103, 121, 127, 121, 103, 75, 39,
0, -39, -75, -103, -121, -127, -121, -103, -75, -39
};
-#define DATA_SIZE (sizeof(sine_data)/sizeof(sine_data[0]))
+#define DATA_SIZE ARRAY_SIZE(sine_data)
#define custom amiga_custom
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 04/13] nubus: kill drivers/nubus/nubus_syms.c
From: Adrian Bunk <[EMAIL PROTECTED]>
nubus: kill drivers/nubus/nubus_syms.c
EXPORT_SYMBOL's belong to the actual code.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/nubus/Makefile |1 -
drivers/nubus/nubus.c | 13 +
drivers/nubus/nubus_syms.c | 28
drivers/nubus/proc.c |4
4 files changed, 17 insertions(+), 29 deletions(-)
--- a/drivers/nubus/Makefile
+++ b/drivers/nubus/Makefile
@@ -4,5 +4,4 @@
obj-y := nubus.o
-obj-$(CONFIG_MODULES) += nubus_syms.o
obj-$(CONFIG_PROC_FS) += proc.o
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -186,6 +187,7 @@ void nubus_get_rsrc_mem(void *dest, cons
len--;
}
}
+EXPORT_SYMBOL(nubus_get_rsrc_mem);
void nubus_get_rsrc_str(void *dest, const struct nubus_dirent* dirent,
int len)
@@ -200,6 +202,7 @@ void nubus_get_rsrc_str(void *dest, cons
len--;
}
}
+EXPORT_SYMBOL(nubus_get_rsrc_str);
int nubus_get_root_dir(const struct nubus_board* board,
struct nubus_dir* dir)
@@ -209,6 +212,7 @@ int nubus_get_root_dir(const struct nubu
dir->mask = board->lanes;
return 0;
}
+EXPORT_SYMBOL(nubus_get_root_dir);
/* This is a slyly renamed version of the above */
int nubus_get_func_dir(const struct nubus_dev* dev,
@@ -219,6 +223,7 @@ int nubus_get_func_dir(const struct nubu
dir->mask = dev->board->lanes;
return 0;
}
+EXPORT_SYMBOL(nubus_get_func_dir);
int nubus_get_board_dir(const struct nubus_board* board,
struct nubus_dir* dir)
@@ -237,6 +242,7 @@ int nubus_get_board_dir(const struct nub
return -1;
return 0;
}
+EXPORT_SYMBOL(nubus_get_board_dir);
int nubus_get_subdir(const struct nubus_dirent *ent,
struct nubus_dir *dir)
@@ -246,6 +252,7 @@ int nubus_get_subdir(const struct nubus_
dir->mask = ent->mask;
return 0;
}
+EXPORT_SYMBOL(nubus_get_subdir);
int nubus_readdir(struct nubus_dir *nd, struct nubus_dirent *ent)
{
@@ -274,12 +281,14 @@ int nubus_readdir(struct nubus_dir *nd,
ent->mask = nd->mask;
return 0;
}
+EXPORT_SYMBOL(nubus_readdir);
int nubus_rewinddir(struct nubus_dir* dir)
{
dir->ptr = dir->base;
return 0;
}
+EXPORT_SYMBOL(nubus_rewinddir);
/* Driver interface functions, more or less like in pci.c */
@@ -303,6 +312,7 @@ nubus_find_device(unsigned short categor
}
return NULL;
}
+EXPORT_SYMBOL(nubus_find_device);
struct nubus_dev*
nubus_find_type(unsigned short category,
@@ -320,6 +330,7 @@ nubus_find_type(unsigned short category,
}
return NULL;
}
+EXPORT_SYMBOL(nubus_find_type);
struct nubus_dev*
nubus_find_slot(unsigned int slot,
@@ -335,6 +346,7 @@ nubus_find_slot(unsigned int slot,
}
return NULL;
}
+EXPORT_SYMBOL(nubus_find_slot);
int
nubus_find_rsrc(struct nubus_dir* dir, unsigned char rsrc_type,
@@ -346,6 +358,7 @@ nubus_find_rsrc(struct nubus_dir* dir, u
}
return -1;
}
+EXPORT_SYMBOL(nubus_find_rsrc);
/* Initialization functions - decide which slots contain stuff worth
looking at, and print out lots and lots of information from the
--- a/drivers/nubus/nubus_syms.c
+++ /dev/null
@@ -1,28 +0,0 @@
-/* Exported symbols for NuBus services
-
- (c) 1999 David Huggins-Daines <[EMAIL PROTECTED]> */
-
-#include
-#include
-#include
-
-#ifdef CONFIG_PROC_FS
-EXPORT_SYMBOL(nubus_proc_attach_device);
-EXPORT_SYMBOL(nubus_proc_detach_device);
-#endif
-
-MODULE_LICENSE("GPL");
-
-EXPORT_SYMBOL(nubus_find_device);
-EXPORT_SYMBOL(nubus_find_type);
-EXPORT_SYMBOL(nubus_find_slot);
-EXPORT_SYMBOL(nubus_get_root_dir);
-EXPORT_SYMBOL(nubus_get_board_dir);
-EXPORT_SYMBOL(nubus_get_func_dir);
-EXPORT_SYMBOL(nubus_readdir);
-EXPORT_SYMBOL(nubus_find_rsrc);
-EXPORT_SYMBOL(nubus_rewinddir);
-EXPORT_SYMBOL(nubus_get_subdir);
-EXPORT_SYMBOL(nubus_get_rsrc_mem);
-EXPORT_SYMBOL(nubus_get_rsrc_str);
-
--- a/drivers/nubus/proc.c
+++ b/drivers/nubus/proc.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+
#include
#include
@@ -140,6 +142,7 @@ int nubus_proc_attach_device(struct nubu
return 0;
}
+EXPORT_SYMBOL(nubus_proc_attach_device);
/* FIXME: this is certainly broken! */
int nubus_proc_detach_device(struct nubus_dev *dev)
@@ -154,6 +157,7 @@ int nubus_proc_detach_device(struct nubu
}
return 0;
}
+EXPORT_SYMBOL(nubus_proc_detach_device);
void __init proc_bus_nubus_add_devices(void)
{
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I
[patch 06/13] m68k: kill arch/m68k/hp300/ksyms.c
From: Adrian Bunk <[EMAIL PROTECTED]>
m68k: kill arch/m68k/hp300/ksyms.c
It was empty.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/m68k/hp300/Makefile |2 +-
arch/m68k/hp300/ksyms.c |9 -
2 files changed, 1 insertion(+), 10 deletions(-)
--- a/arch/m68k/hp300/Makefile
+++ b/arch/m68k/hp300/Makefile
@@ -2,4 +2,4 @@
# Makefile for Linux arch/m68k/hp300 source directory
#
-obj-y := ksyms.o config.o time.o reboot.o
+obj-y := config.o time.o reboot.o
--- a/arch/m68k/hp300/ksyms.c
+++ /dev/null
@@ -1,9 +0,0 @@
-/*
- * linux/arch/m68k/hp300/ksyms.c
- *
- * Copyright (C) 1998 Philip Blundell <[EMAIL PROTECTED]>
- *
- * This file contains the HP300-specific kernel symbols. None yet. :-)
- */
-
-#include
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 05/13] m68k: kill arch/m68k/mac/mac_ksyms.c
From: Adrian Bunk <[EMAIL PROTECTED]>
m68k: kill arch/m68k/mac/mac_ksyms.c
EXPORT_SYMBOL's belong to the actual code.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/m68k/mac/Makefile|2 +-
arch/m68k/mac/mac_ksyms.c |8
arch/m68k/mac/via.c |5 -
3 files changed, 5 insertions(+), 10 deletions(-)
--- a/arch/m68k/mac/Makefile
+++ b/arch/m68k/mac/Makefile
@@ -3,4 +3,4 @@
#
obj-y := config.o bootparse.o macints.o iop.o via.o oss.o psc.o \
- baboon.o macboing.o debug.o misc.o mac_ksyms.o
+ baboon.o macboing.o debug.o misc.o
--- a/arch/m68k/mac/mac_ksyms.c
+++ /dev/null
@@ -1,8 +0,0 @@
-#include
-#include
-#include
-
-/* Says whether we're using A/UX interrupts or not */
-extern int via_alt_mapping;
-
-EXPORT_SYMBOL(via_alt_mapping);
--- a/arch/m68k/mac/via.c
+++ b/arch/m68k/mac/via.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -41,7 +42,9 @@ volatile __u8 *via1, *via2;
/* See note in mac_via.h about how this is possibly not useful */
volatile long *via_memory_bogon=(long *)&via_memory_bogon;
#endif
-int rbv_present, via_alt_mapping;
+int rbv_present;
+int via_alt_mapping;
+EXPORT_SYMBOL(via_alt_mapping);
__u8 rbv_clear;
/*
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 10/13] mac68k: macii adb comment correction
From: Finn Thain <[EMAIL PROTECTED]>
Corrects a mistake I made in a comment.
Signed-off-by: Finn Thain <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
drivers/macintosh/via-macii.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/macintosh/via-macii.c
+++ b/drivers/macintosh/via-macii.c
@@ -111,7 +111,7 @@ static enum macii_state {
static struct adb_request *current_req; /* first request struct in the queue */
static struct adb_request *last_req; /* last request struct in the queue */
static unsigned char reply_buf[16];/* storage for autopolled replies */
-static unsigned char *reply_ptr; /* next byte in req->data or reply_buf */
+static unsigned char *reply_ptr; /* next byte in reply_buf or req->reply */
static int reading_reply;/* store reply in reply_buf else req->reply */
static int data_index; /* index of the next byte to send from req->data */
static int reply_len; /* number of bytes received in reply_buf or req->reply */
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 07/13] m68k: kill arch/m68k/amiga/amiga_ksyms.c
From: Adrian Bunk <[EMAIL PROTECTED]>
m68k: kill arch/m68k/amiga/amiga_ksyms.c
EXPORT_SYMBOL's belong to the actual code.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/m68k/amiga/Makefile |2 +-
arch/m68k/amiga/amiga_ksyms.c | 33 -
arch/m68k/amiga/amisound.c|3 +++
arch/m68k/amiga/chipram.c |7 +++
arch/m68k/amiga/config.c | 12
arch/m68k/amiga/pcmcia.c |9 +
6 files changed, 32 insertions(+), 34 deletions(-)
--- a/arch/m68k/amiga/Makefile
+++ b/arch/m68k/amiga/Makefile
@@ -2,6 +2,6 @@
# Makefile for Linux arch/m68k/amiga source directory
#
-obj-y := config.o amiints.o cia.o chipram.o amisound.o amiga_ksyms.o
+obj-y := config.o amiints.o cia.o chipram.o amisound.o
obj-$(CONFIG_AMIGA_PCMCIA) += pcmcia.o
--- a/arch/m68k/amiga/amiga_ksyms.c
+++ /dev/null
@@ -1,33 +0,0 @@
-#include
-#include
-#include
-#include
-#include
-#include
-
-extern volatile u_short amiga_audio_min_period;
-extern u_short amiga_audio_period;
-
-/*
- * Add things here when you find the need for it.
- */
-EXPORT_SYMBOL(amiga_model);
-EXPORT_SYMBOL(amiga_chipset);
-EXPORT_SYMBOL(amiga_hw_present);
-EXPORT_SYMBOL(amiga_eclock);
-EXPORT_SYMBOL(amiga_colorclock);
-EXPORT_SYMBOL(amiga_chip_alloc);
-EXPORT_SYMBOL(amiga_chip_free);
-EXPORT_SYMBOL(amiga_chip_avail);
-EXPORT_SYMBOL(amiga_chip_size);
-EXPORT_SYMBOL(amiga_audio_period);
-EXPORT_SYMBOL(amiga_audio_min_period);
-
-#ifdef CONFIG_AMIGA_PCMCIA
- EXPORT_SYMBOL(pcmcia_reset);
- EXPORT_SYMBOL(pcmcia_copy_tuple);
- EXPORT_SYMBOL(pcmcia_program_voltage);
- EXPORT_SYMBOL(pcmcia_access_speed);
- EXPORT_SYMBOL(pcmcia_write_enable);
- EXPORT_SYMBOL(pcmcia_write_disable);
-#endif
--- a/arch/m68k/amiga/amisound.c
+++ b/arch/m68k/amiga/amisound.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -31,6 +32,7 @@ static const signed char sine_data[] = {
*/
volatile unsigned short amiga_audio_min_period = 124; /* Default for pre-OCS */
+EXPORT_SYMBOL(amiga_audio_min_period);
#define MAX_PERIOD (65535)
@@ -40,6 +42,7 @@ volatile unsigned short amiga_audio_min_
*/
unsigned short amiga_audio_period = MAX_PERIOD;
+EXPORT_SYMBOL(amiga_audio_period);
static unsigned long clock_constant;
--- a/arch/m68k/amiga/chipram.c
+++ b/arch/m68k/amiga/chipram.c
@@ -13,10 +13,13 @@
#include
#include
#include
+#include
+
#include
#include
unsigned long amiga_chip_size;
+EXPORT_SYMBOL(amiga_chip_size);
static struct resource chipram_res = {
.name = "Chip RAM", .start = CHIP_PHYSADDR
@@ -67,6 +70,7 @@ void *amiga_chip_alloc(unsigned long siz
#endif
return (void *)ZTWO_VADDR(res->start);
}
+EXPORT_SYMBOL(amiga_chip_alloc);
/*
@@ -120,6 +124,7 @@ void amiga_chip_free(void *ptr)
}
printk("amiga_chip_free: trying to free nonexistent region at %p\n", ptr);
}
+EXPORT_SYMBOL(amiga_chip_free);
unsigned long amiga_chip_avail(void)
@@ -129,3 +134,5 @@ unsigned long amiga_chip_avail(void)
#endif
return chipavail;
}
+EXPORT_SYMBOL(amiga_chip_avail);
+
--- a/arch/m68k/amiga/config.c
+++ b/arch/m68k/amiga/config.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -36,13 +37,24 @@
#include
unsigned long amiga_model;
+EXPORT_SYMBOL(amiga_model);
+
unsigned long amiga_eclock;
+EXPORT_SYMBOL(amiga_eclock);
+
unsigned long amiga_masterclock;
+
unsigned long amiga_colorclock;
+EXPORT_SYMBOL(amiga_colorclock);
+
unsigned long amiga_chipset;
+EXPORT_SYMBOL(amiga_chipset);
+
unsigned char amiga_vblank;
unsigned char amiga_psfreq;
+
struct amiga_hw_present amiga_hw_present;
+EXPORT_SYMBOL(amiga_hw_present);
static char s_a500[] __initdata = "A500";
static char s_a500p[] __initdata = "A500+";
--- a/arch/m68k/amiga/pcmcia.c
+++ b/arch/m68k/amiga/pcmcia.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+
#include
#include
@@ -30,6 +32,7 @@ void pcmcia_reset(void)
while (time_before(jiffies, reset_start_time + 1*HZ/100));
b = gayle_reset;
}
+EXPORT_SYMBOL(pcmcia_reset);
/* copy a tuple, including tuple header. return nb bytes copied */
@@ -61,6 +64,7 @@ int pcmcia_copy_tuple(unsigned char tupl
return 0;
}
+EXPORT_SYMBOL(pcmcia_copy_tuple);
void pcmcia_program_voltage(int voltage)
{
@@ -84,6 +88,7 @@ void pcmcia_program_voltage(int voltage)
gayle.config = cfg_byte;
}
+EXPORT_SYMBOL(pcmcia_program_voltage);
void pcmcia_access_speed(int speed)
{
@@ -101,13 +106,17 @@ void pcmcia_access_speed(int speed)
cfg_byte = (cfg_byte & 0xf3) | s;
gayle.config = cfg_byte;
}
+EXPORT_SYMBOL(pcmcia_access_speed);
void pcmcia_write_enable(void)
{
gayle.cardstatus = GAYLE_CS_WR|GAYLE_CS_DA;
}
+EXPORT_SYMBOL(pcmcia_write_enable);
void pcmcia_write_disable(void)
{
gay
[patch 12/13] mac68k: add nubus card definitions and a typo fix
From: Finn Thain <[EMAIL PROTECTED]>
Add some new card definitions and fix a typo (from Eugen Paiuc).
Signed-off-by: Finn Thain <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
include/linux/nubus.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/include/linux/nubus.h
+++ b/include/linux/nubus.h
@@ -132,10 +132,12 @@ enum nubus_drhw {
NUBUS_DRHW_RDIUS_DCGX = 0x027C, /* Radius DirectColor/GX */
NUBUS_DRHW_RDIUS_PC8 = 0x0291, /* Radius PrecisionColor 8 */
NUBUS_DRHW_LAPIS_PCS8 = 0x0292, /* Lapis ProColorServer 8 */
- NUBUS_DRHW_RASTER_24LXI = 0x02A0, /* RasterOps 8/24 XLi */
+ NUBUS_DRHW_RASTER_24XLI = 0x02A0, /* RasterOps 8/24 XLi */
NUBUS_DRHW_RASTER_PBPGT = 0x02A5, /* RasterOps PaintBoard Prism GT */
NUBUS_DRHW_EMACH_FSX = 0x02AE, /* E-Machines Futura SX */
+ NUBUS_DRHW_RASTER_24XLTV = 0x02B7, /* RasterOps 24XLTV */
NUBUS_DRHW_SMAC_THUND24 = 0x02CB, /* SuperMac Thunder/24 */
+ NUBUS_DRHW_SMAC_THUNDLGHT = 0x03D9, /* SuperMac ThunderLight */
NUBUS_DRHW_RDIUS_PC24XP = 0x0406, /* Radius PrecisionColor 24Xp */
NUBUS_DRHW_RDIUS_PC24X= 0x040A, /* Radius PrecisionColor 24X */
NUBUS_DRHW_RDIUS_PC8XJ= 0x040B, /* Radius PrecisionColor 8XJ */
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 13/13] mac68k: remove dead MAC_ADBKEYCODES
From: Stanislav Brabec <[EMAIL PROTECTED]>
It seems, that current kernel source code contains no traces of
MAC_ADBKEYCODES and no reference to keyboard_sends_linux_keycodes any
more.
Attached patch removes them from configuration files.
Signed-off-by: Stanislav Brabec <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/m68k/Kconfig | 14 --
arch/m68k/configs/mac_defconfig |1 -
2 files changed, 15 deletions(-)
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -582,20 +582,6 @@ config MAC_HID
depends on INPUT_ADBHID
default y
-config MAC_ADBKEYCODES
- bool "Support for ADB raw keycodes"
- depends on INPUT_ADBHID
- help
- This provides support for sending raw ADB keycodes to console
- devices. This is the default up to 2.4.0, but in future this may be
- phased out in favor of generic Linux keycodes. If you say Y here,
- you can dynamically switch via the
- /proc/sys/dev/mac_hid/keyboard_sends_linux_keycodes
- sysctl and with the "keyboard_sends_linux_keycodes=" kernel
- argument.
-
- If unsure, say Y here.
-
config ADB_KEYBOARD
bool "Support for ADB keyboard (old driver)"
depends on MAC && !INPUT_ADBHID
--- a/arch/m68k/configs/mac_defconfig
+++ b/arch/m68k/configs/mac_defconfig
@@ -678,7 +678,6 @@ CONFIG_LOGO_MAC_CLUT224=y
#
CONFIG_MAC_SCC=y
CONFIG_MAC_HID=y
-CONFIG_MAC_ADBKEYCODES=y
CONFIG_SERIAL_CONSOLE=y
#
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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 11/13] mac68k: remove dead code
From: Finn Thain <[EMAIL PROTECTED]>
Remove dead code.
Signed-off-by: Finn Thain <[EMAIL PROTECTED]>
Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
---
arch/m68k/mac/config.c |2 --
include/asm-m68k/macintosh.h |2 --
2 files changed, 4 deletions(-)
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -58,8 +58,6 @@ extern struct mem_info m68k_memory[NUM_M
extern struct mem_info m68k_ramdisk;
-extern char m68k_command_line[CL_SIZE];
-
void *mac_env; /* Loaded by the boot asm */
/* The phys. video addr. - might be bogus on some machines */
--- a/include/asm-m68k/macintosh.h
+++ b/include/asm-m68k/macintosh.h
@@ -14,8 +14,6 @@ extern void mac_init_IRQ(void);
extern int mac_irq_pending(unsigned int);
extern void mac_identify(void);
extern void mac_report_hardware(void);
-extern void mac_debugging_penguin(int);
-extern void mac_boom(int);
/*
* Floppy driver magic hook - probably shouldnt be here
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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: [RFC HIFN 00/02]: RNG support
On Sunday 18 November 2007 05:04:01 Herbert Xu wrote: > On Sun, Nov 18, 2007 at 04:30:40AM +0100, Patrick McHardy wrote: > > > > On a related issue, I think the rng interface is not very suitable > > for chips like HIFN that have a constant random bandwidth, it would > > make a lot more sense to return the time to wait to the core, instead > > of waiting 10us in all cases. 256 cycles at a speed of 266MHz comes > > down to 0.96us, so we're waiting about 10 times as long as necessary. > > Since its busy waiting anyway, I'd think that from a performance POV > > constant polling or returning the exact amount of time would be more > > reasonable. > > I agree, a better interface would be to let the hardware do the > blocking where necessary. > > Michael, what do you think about this? Patches are welcome. ;) -- Greetings Michael. - 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: [kvm-devel] [PATCH] - drivers/kvm/* - remove ptr comparisons to 0
Joe Perches wrote: fix sparse warnings "Using plain integer as NULL pointer" Applied, thanks. -- error compiling committee.c: too many arguments to function - 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: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)
On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote: > > > --- Peter Dolding <[EMAIL PROTECTED]> wrote: > > > On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote: > > > Peter Dolding wrote: > > > >>> What is left unspecified here is 'how' a child 'with its own profile' > > is > > > >>> confined here. Are it is confined to just its own profile, it may that > > > >>> the "complicit process" communication may need to be wider specified > > > >>> to > > > >>> include this. > > > >>> > > > > Sorry have to bring this up. cgroups why not? > > > Because I can't find any documentation for cgroups? :) > > > > > > > Assign application to > > > > a cgroup that contains there filesystem access permissions. Done > > > > right this could even be stacked. Only give less access to > > > > application unless LSM particularly overrides. > > > > > > > This comes no where close to AppArmor's functionality: > > > > > > * Can't do learning mode > > > * Can't do wildcards > > > * Sucks up huge loads of memory to do that much FS mounting (imagine > > > thousands of bind mounts) > > > * I'm not sure, but I don't think you can do file granularity, only > > > directories > > > > > Ok sorry to say so far almost percent wrong. Please note netlabels > > falls into a control group. All function of Apparmor is doable bar > > exactly learning mode. For learning mode that would have to be a > > hook back to a LSM I would expect. > > > > Done right should suck up no more memory than current apparmor. But > > it will required all LSM's doing file access to come to common > > agreement how to do it. Not just hooks into the kernel system any > > more. > > The ability to provide alternative access control schemes is the > purpose of LSM. The fact that we insane security people can't come > to the agreement you require is why we have LSM. You can not have > what you are asking for. Please suggest an alternative design. Part of the building the alternative design requires aggreeing to build sections common. Like the netlabels. We need this for other parts like filesystems. > > > At the container entrance point there needs file granularity applied > > for complete and correct container isolation to be done. > > > > > > > There are reasons why I keep on bring containers up it changes the > > > > model. Yes I know coming to a common agreement in these sections will > > > > not be simple. But at some point it has to be done. > > > > > > > Containers and access controls provide related but different functions. > > > Stop trying to force containers to be an access control system, it does > > > not fit well at all. > > > > > > Rather, we need to ensure that LSM and containers play well together. > > > What you proposed in the past was to have an LSM module per container, > > > but I find that absurdly complex: if you want that, then use a real VMM > > > like Xen or something. Containers are mostly used for massive virtual > > > domain hosting, and what you want there is as much sharing as possible > > > while maintaining isolation. so why would you corrupt that with separate > > > LSM modules per container? > > > > Please stop being foolish. Xen and the like don't share memory. You > > are basically saying blow out memory usage just because someone wants > > to use a different LSM. > > Yup. No one ever said security was cheap. Most real, serious security > solutions implemented today rely on separate physical machines for > isolation. Some progressive installations are using virtualization, > and the lunatic fringe uses the sort of systems well served by LSM. > Let's face it, people who really care are willing to pay a premium. Bigger problem Containers are processor neutral Xen and lot of the other solutions are not. There are advantages for people who don't need full blown. There needs to be two levels. Ie VM for the heavy. Containers for where the security is needed but no to the point of needing two different kernels. Now restricting what can be in a Container due to some poor reason that has not been attempted to be worked around is not a valid reason. In theory using Containers you should be able to run every Linux distro on earth under one kernel as long as it supports that series kernel. Ie 2.6 2.4... Now that is only the base level of Containers. More advanced Zones like solaris will see other platforms running in a container under the same kernel. Current designing around containers is not dealing with what I can do. It more how will we hack it to work. Not make sure it will support where Container design can go. > > > Besides file access control is part of running containers isolated in > > the first place and need to be LSM neutral. > > File access control is within the scope of the LSM. If your feature > can't deal with that you need to fix your feature. This is the problem for containers File access controls need to be like netlabels common between
Re: [PATCH] Fix PCIe double initialization bug
On Sunday, 18 of November 2007, Mark Lord wrote:
> pciehp_fix_double_init_bug.patch:
>
> Earlier patches to split out the hardware init for PCIe hotplug
> resulted in some one-time initializations being redone on every
> resume cycle. Eg. irq/polling initialization.
>
> This patch splits the hardware init into two parts,
> and separates the one-time initializations from those
> so that they only ever get done once, as intended.
>
> Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
Which kernel is it against?
> ---
>
> This patch is for -mm and for Kristen's queue. Not for 2.6.24.
>
> drivers/pci/hotplug/pciehp.h |2
> drivers/pci/hotplug/pciehp_core.c |2
> drivers/pci/hotplug/pciehp_hpc.c | 119 +++-
> 3 files changed, 69 insertions(+), 54 deletions(-)
>
> --- linux/drivers/pci/hotplug/pciehp.h.orig 2007-11-13 23:57:09.0
> -0500
> +++ linux/drivers/pci/hotplug/pciehp.h2007-11-17 19:10:01.0
> -0500
> @@ -163,7 +163,7 @@
> int pcie_init(struct controller *ctrl, struct pcie_device *dev);
> int pciehp_enable_slot(struct slot *p_slot);
> int pciehp_disable_slot(struct slot *p_slot);
> -int pcie_init_hardware(struct controller *ctrl, struct pcie_device *dev);
> +int pcie_init_hardware_part2(struct controller *ctrl, struct pcie_device
> *dev);
>
> static inline struct slot *pciehp_find_slot(struct controller *ctrl, u8
> device)
> {
> --- linux/drivers/pci/hotplug/pciehp_core.c.orig 2007-11-13
> 23:57:09.0 -0500
> +++ linux/drivers/pci/hotplug/pciehp_core.c 2007-11-17 19:09:43.0
> -0500
> @@ -521,7 +521,7 @@
> u8 status;
>
> /* reinitialize the chipset's event detection logic */
> - pcie_init_hardware(ctrl, dev);
> + pcie_init_hardware_part2(ctrl, dev);
>
> t_slot = pciehp_find_slot(ctrl, ctrl->slot_device_offset);
>
> --- linux/drivers/pci/hotplug/pciehp_hpc.c.orig 2007-11-13
> 23:57:09.0 -0500
> +++ linux/drivers/pci/hotplug/pciehp_hpc.c2007-11-17 19:13:49.0
> -0500
> @@ -1067,28 +1067,25 @@
> }
> #endif
>
> -int pcie_init_hardware(struct controller *ctrl, struct pcie_device *dev)
> +static int pcie_init_hardware_part1(struct controller *ctrl,
> + struct pcie_device *dev)
> {
> int rc;
> u16 temp_word;
> - u16 intr_enable = 0;
> u32 slot_cap;
> u16 slot_status;
> - struct pci_dev *pdev;
> -
> - pdev = dev->port;
>
> rc = pciehp_readl(ctrl, SLOTCAP, &slot_cap);
> if (rc) {
> err("%s: Cannot read SLOTCAP register\n", __FUNCTION__);
> - goto abort_free_ctlr;
> + return -1;
> }
>
> /* Mask Hot-plug Interrupt Enable */
> rc = pciehp_readw(ctrl, SLOTCTRL, &temp_word);
> if (rc) {
> err("%s: Cannot read SLOTCTRL register\n", __FUNCTION__);
> - goto abort_free_ctlr;
> + return -1;
> }
>
> dbg("%s: SLOTCTRL %x value read %x\n",
> @@ -1099,62 +1096,46 @@
> rc = pciehp_writew(ctrl, SLOTCTRL, temp_word);
> if (rc) {
> err("%s: Cannot write to SLOTCTRL register\n", __FUNCTION__);
> - goto abort_free_ctlr;
> + return -1;
> }
>
> rc = pciehp_readw(ctrl, SLOTSTATUS, &slot_status);
> if (rc) {
> err("%s: Cannot read SLOTSTATUS register\n", __FUNCTION__);
> - goto abort_free_ctlr;
> + return -1;
> }
>
> temp_word = 0x1F; /* Clear all events */
> rc = pciehp_writew(ctrl, SLOTSTATUS, temp_word);
> if (rc) {
> err("%s: Cannot write to SLOTSTATUS register\n", __FUNCTION__);
> - goto abort_free_ctlr;
> + return -1;
> }
> + return 0;
> +}
>
> - if (pciehp_poll_mode) {
> - /* Install interrupt polling timer. Start with 10 sec delay */
> - init_timer(&ctrl->poll_timer);
> - start_int_poll_timer(ctrl, 10);
> - } else {
> - /* Installs the interrupt handler */
> - rc = request_irq(ctrl->pci_dev->irq, pcie_isr, IRQF_SHARED,
> - MY_NAME, (void *)ctrl);
> - dbg("%s: request_irq %d for hpc%d (returns %d)\n",
> - __FUNCTION__, ctrl->pci_dev->irq,
> - atomic_read(&pciehp_num_controllers), rc);
> - if (rc) {
> - err("Can't get irq %d for the hotplug controller\n",
> - ctrl->pci_dev->irq);
> - goto abort_free_ctlr;
> - }
> - }
> - dbg("pciehp ctrl b:d:f:irq=0x%x:%x:%x:%x\n", pdev->bus->number,
> - PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn), dev->irq);
> -
> - /*
> - * If this is the first controller to be initialized,
> - * initialize the pciehp work queue
> - */
> - if (atomic_add_return(1, &pc
Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals
On Sat, 2007-11-17 at 10:12 -0800, Daniel Walker wrote: > What specifically is wrong with dev->sem ? Nothing really, other than that they use semaphores to avoid lockdep :-/ I think I know how to annotate this, after Alan Stern explained all the use cases, but I haven't come around to implementing it. Hope to do that soonish. Another real semaphore user is XFS, they really use the down/up asymmetry that semaphores allow, last time I spoke with Dave Chinner he didn't know a way around this. - 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: laptop reboots right after hibernation
Hi! > echo disk > /sys/power/state > > successfully saves that state to the disk, but just as the laptop is > about to turn itself off, it reboots (successfully, so the > hibernation/resume process works well, even with X running! which is > awesome :) ). But I'd rather like the computer turned off after I > hibernate it. Where could the problem be? > > It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few > days, both suspend and hibernate worked there (with one or two crashes, > probably due to X, I've read that the intel driver got some > suspend/resume improvements recently). Now I'm running gentoo, kernel > 2.6.24-rc2. I'm using newer versions of almost all software now compared > to the ubuntu system. If it works in older ubuntu, you can probably do bisect. Does normal shutdown work? You can try platform vs. shutdown mode... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: broken suspend [Was: 2.6.24-rc2-mm1]
Alan Stern napsal(a):
> On Sat, 17 Nov 2007, Rafael J. Wysocki wrote:
>> On Saturday, 17 of November 2007, Jiri Slaby wrote:
>>> On 11/16/2007 05:10 PM, Alan Stern wrote:
The thing to do is figure out which driver is causing the problem.
Jiri, try enabling CONFIG_DEBUG_DRIVER.
>>> Sadly no output.
Nice update scripts wiped kern.* from syslog config file out, hence no
output before.
> Back to the main topic... My system hibernates and resumes with no
> apparent problem. Jiri, it looks like you'll have to do some debug
> tracing of the routines in drivers/base/power/main.c.
Beside this two nothing strange:
dpm_suspend: b 00:06
WARNING: at /home/l/latest/bughunt/kernel/resource.c:185 __release_resource()
Call Trace:
[] release_resource+0xb5/0xf0
[] pnp_release_resources+0x70/0x130
[] pnp_stop_dev+0x45/0x90
[] pnp_bus_suspend+0x92/0xb0
[] suspend_device+0x113/0x180
[] device_suspend+0x200/0x320
[] suspend_devices_and_enter+0xa5/0x170
[] enter_state+0x209/0x270
[] state_store+0xaf/0xf0
[] kobj_attr_store+0x17/0x20
[] sysfs_write_file+0xce/0x140
[] vfs_write+0xc7/0x170
[] sys_write+0x50/0x90
[] system_call+0x7e/0x83
WARNING: at /home/l/latest/bughunt/kernel/resource.c:189 __release_resource()
Call Trace:
[] release_resource+0xe0/0xf0
[] pnp_release_resources+0x70/0x130
[] pnp_stop_dev+0x45/0x90
[] pnp_bus_suspend+0x92/0xb0
[] suspend_device+0x113/0x180
[] device_suspend+0x200/0x320
[] suspend_devices_and_enter+0xa5/0x170
[] enter_state+0x209/0x270
[] state_store+0xaf/0xf0
[] kobj_attr_store+0x17/0x20
[] sysfs_write_file+0xce/0x140
[] vfs_write+0xc7/0x170
[] sys_write+0x50/0x90
[] system_call+0x7e/0x83
...
dpm_suspend: b :00:1f.5
ACPI Error (psargs-0355): [FZHD] Namespace lookup failure, AE_NOT_FOUND
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.SAT1.CHN0._GTM] (Node 81007D000220), AE_NOT_FOUND
ACPI Error (psargs-0355): [FZHD] Namespace lookup failure, AE_NOT_FOUND
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.SAT1.CHN1._GTM] (Node 81007D000360), AE_NOT_FOUND
It's stuck at _cpu_down (enter_state -> suspend_devices_and_enter ->
disable_nonboot_cpus -> _cpu_down) after calling raw_notifier_call_chain
printk("%s: s\n", __func__);
/* Wait for it to sleep (leaving idle task). */
while (!idle_cpu(cpu))
yield();
printk("%s: t\n", __func__);
/* This actually kills the CPU. */
__cpu_die(cpu);
printk("%s: u\n", __func__);
BUBAK=1;
/* CPU is completely dead: tell everyone. Too late to complain. */
if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | mod,
hcpu) == NOTIFY_BAD)
BUG();
BUBAK=0;
printk("%s: v\n", __func__);
See shot of prints here:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
notifier_call_chain looks like:
while (nb && nr_to_call) {
next_nb = rcu_dereference(nb->next);
ret = nb->notifier_call(nb, val, v);
if (unlikely(BUBAK && cnt < 20 && (ret != lastr ||
lastp != nb->notifier_call))) {
printk("%s: c %p %d\n", __func__, nb->notifier_call,
ret);
lastr = ret;
lastp = nb->notifier_call;
cnt++;
}
if (nr_calls)
(*nr_calls)++;
if ((ret & NOTIFY_STOP_MASK) == NOTIFY_STOP_MASK)
break;
nb = next_nb;
nr_to_call--;
}
System.map is here if you are curoius what are the pointers from the snapshot:
http://www.fi.muni.cz/~xslaby/sklad/System.map
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
-
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/
size of git repository (was Re: [BUG] New Kernel Bugs)
On Tue 2007-11-13 12:50:08, Mark Lord wrote: > Ingo Molnar wrote: > > > >for example git-bisect was godsent. I remember that > >years ago bisection of a bug was a very laborous task > >so that it was only used as a final, last-ditch > >approach for really nasty bugs. Today we can > >autonomouly bisect build bugs via a simple shell > >command around "git-bisect run", without any human > >interaction! This freed up testing resources > .. > > It's only a godsend for the few people who happen to be > kernel developers > and who happen to already use git. > > It's a 540MByte download over a slow link for everyone > else. Hmmm, clean-cg is 7.7G on my machine, and yes I tried git-prune-packed. What am I doing wrong? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: broken suspend [Was: 2.6.24-rc2-mm1]
On 11/18/2007 01:42 PM, Jiri Slaby wrote: > See shot of prints here: > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png BTW output from that tree minus the patch: _cpu_down: s _cpu_down: t CPU 1 is now offline SMP alternatives: switching to UP code _cpu_down: u notifier_call_chain: c 80232370 1 notifier_call_chain: c 8026EF10 1 notifier_call_chain: c 8024B8F0 1 notifier_call_chain: c 802419E0 1 notifier_call_chain: c 80255B50 1 notifier_call_chain: c 80250C40 1 notifier_call_chain: c 8028E8F0 1 notifier_call_chain: c 802B59C0 1 notifier_call_chain: c 80323460 1 notifier_call_chain: c 80270990 0 notifier_call_chain: c 8023D5D0 1 notifier_call_chain: c 80266090 1 notifier_call_chain: c 802320A0 1 notifier_call_chain: c 80249DA0 1 notifier_call_chain: c 80318440 1 notifier_call_chain: c 8047BE80 1 notifier_call_chain: c 80212F40 0 notifier_call_chain: c 80216350 1 notifier_call_chain: c 80217220 1 notifier_call_chain: c 80218120 1 _cpu_down: v _cpu_down: w _cpu_down: x _cpu_down: y _cpu_down: z disable_nonboot_cpus: 3 0 regards, -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University - 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: size of git repository (was Re: [BUG] New Kernel Bugs)
On 18-11-07 13:44, Pavel Machek wrote: On Tue 2007-11-13 12:50:08, Mark Lord wrote: It's a 540MByte download over a slow link for everyone else. Hmmm, clean-cg is 7.7G on my machine, and yes I tried git-prune-packed. What am I doing wrong? clean-cg? But failure to run "git repack -a -d" every once in a while? Rene. - 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: broken suspend [Was: 2.6.24-rc2-mm1]
On Sunday, 18 of November 2007, Jiri Slaby wrote: > On 11/18/2007 01:42 PM, Jiri Slaby wrote: > > See shot of prints here: > > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png > > BTW output from that tree minus the patch: Hm, it looks like one of the CPU hotplug notifiers is doing something wrong. Can you try to see what happens (with the patch applied) if thermal_throttle_cpu_callback() is not registered? > _cpu_down: s > _cpu_down: t > CPU 1 is now offline > SMP alternatives: switching to UP code > _cpu_down: u > notifier_call_chain: c 80232370 1 > notifier_call_chain: c 8026EF10 1 > notifier_call_chain: c 8024B8F0 1 > notifier_call_chain: c 802419E0 1 > notifier_call_chain: c 80255B50 1 > notifier_call_chain: c 80250C40 1 > notifier_call_chain: c 8028E8F0 1 > notifier_call_chain: c 802B59C0 1 > notifier_call_chain: c 80323460 1 > notifier_call_chain: c 80270990 0 > notifier_call_chain: c 8023D5D0 1 > notifier_call_chain: c 80266090 1 > notifier_call_chain: c 802320A0 1 > notifier_call_chain: c 80249DA0 1 > notifier_call_chain: c 80318440 1 > notifier_call_chain: c 8047BE80 1 > notifier_call_chain: c 80212F40 0 > notifier_call_chain: c 80216350 1 > notifier_call_chain: c 80217220 1 > notifier_call_chain: c 80218120 1 > _cpu_down: v > _cpu_down: w > _cpu_down: x > _cpu_down: y > _cpu_down: z > disable_nonboot_cpus: 3 0 - 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: increased number of cycles
> But for last 4 days the consumed cycles have suddenly increased to > around 35 cycles . I'm using RDTSC instruction to profile the > code.There is no change in code and the kernel version is also the > same .I am assuming that there must be something wrong with hardware. > > Please guide me how can i figure out the root cause.What areas should Maybe you have a new version of GCC now? (auto-update or something?) - 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: broken suspend [Was: 2.6.24-rc2-mm1]
On 11/18/2007 02:42 PM, Rafael J. Wysocki wrote: > On Sunday, 18 of November 2007, Jiri Slaby wrote: >> On 11/18/2007 01:42 PM, Jiri Slaby wrote: >>> See shot of prints here: >>> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png >> BTW output from that tree minus the patch: > > Hm, it looks like one of the CPU hotplug notifiers is doing something wrong. > > Can you try to see what happens (with the patch applied) if > thermal_throttle_cpu_callback() is not registered? After commenting out //device_initcall(thermal_throttle_init_device); it looks like this: http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png regards, -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University - 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/
[BUG] Oops in 2.6.24-rc2-mm1
First of all, a disclaimer. I am new to the kernel and this is my first report. As such I can make mistakes. In doubt feel free to assume that the fault lies with me or my system. A computer I have crashes during the boot process. My .config is attached, I have generated it with oldconfig from a 24-rc2 kernel plus a few changes with menuconfig. Because I was not able to get a picture or the text of the oops, I have written down the most important stuff. A lot of it varies between reboots. I had to use reboot=1000 in my kernel command line to catch it, because the computer would power off at once without it. My kernel is not tained by blobs. The oops message has either [#1] or [#2] in it. The pid it reports varies. The call trace looks totally uninformative. For each chunk only the part in the [] is changing, the other bit being always <0>. Finally I get this line: usb usb5: suspend_rh (auto-stop) After this all output stops. I'm not subscribed to the list, so please CC me. If I had made any mistakes with this report, please tell me. Thank you. Karol Swietlicki # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc2-mm1 # Sun Nov 18 13:31:45 2007 # CONFIG_X86_32=y 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_X86=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # 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=18 # CONFIG_CGROUPS is not set # CONFIG_FAIR_GROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y # CONFIG_KALLSYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y # CONFIG_BUG is not set # CONFIG_ELF_CORE is not set 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 is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROC_PAGE_MONITOR is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y 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 is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y # CONFIG_IOSCHED_DEADLINE is not set # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_RDC321X 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_SCHED_NO_NO_OMIT_FRAME_POINTER=y # 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_MCORE2=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # 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_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y 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_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_
Re: size of git repository (was Re: [BUG] New Kernel Bugs)
On Sun, 2007-11-18 at 13:58 +0100, Rene Herman wrote: > On 18-11-07 13:44, Pavel Machek wrote: > > > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > >> It's a 540MByte download over a slow link for everyone > >> else. > > > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > > git-prune-packed. What am I doing wrong? > > clean-cg? But failure to run "git repack -a -d" every once in a while? Actually, the best command is git gc which does a repack (into a single pack file rather than an incremenal), and then removes all the objects now in the pack. If, like me, you work on temporary branches which you keep rebasing, you can add a --prune to gc which will erase all unreferenced objects as it packs (use this one with care. I usually never use it but run a git prune -n just to see what would be removed, and then run git prune separately if it looks OK). James - 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] task_pid_nr_ns() breaks proc_pid_readdir()
On 11/17, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > Make sure that task_pid_nr_ns() returns !0 before updating tgid. Note that
> > next_tgid(tgid + 1) can find the same "struct pid" again, but we shouldn't
> > go into the endless loop because pid_task(PIDTYPE_PID) must return NULL in
> > this case, so next_tgid() can't return the same task.
> >
> Oleg I think I would rather update next_tgid to return the tgid (which
> removes the need to call task_pid_nr_ns). This keeps all of the task
> iteration logic together in next_tgid.
Yes sure, I think your patch is also correct, please use it.
Personally, I hate the functions which use pointers to return another value.
(yes, yes, I know, my taste is perverted). Why don't we return structure in
this case? We can even make a common helper struct, say,
struct pair {
union {
long val1;
void *ptr1;
};
union {
long val2;
void *ptr2;
};
};
#define PAIR(x1, x2)(struct pair){{ . x1 }, { . x2 }}
Now, next_tgid() can do
return PAIR(ptr1 = task, val2 = tgid);
With -freg-struct-return the generated code is nice.
Of course, another option is to rewrite the kernle in perl, in that case
proc_pid_readdir() can just do
(task, tgid) = next_tgid();
> Although looking at this in more detail, I'm half wondering if
> proc_pid_make_inode() should take a struct pid instead of a task.
Yes, I also thought about this. Needs more changes, and still not perfect.
I am starting to think we need a more generic change. How about the patch
below? With this change the stable task_struct implies we have the stable
pids, this allows us to do a lot of cleanups.
Oleg.
--- kernel/pid.c2007-10-25 16:22:12.0 +0400
+++ - 2007-11-18 16:56:30.682555454 +0300
@@ -323,7 +323,7 @@ int fastcall attach_pid(struct task_stru
struct pid_link *link;
link = &task->pids[type];
- link->pid = pid;
+ link->pid = get_pid(pid);
hlist_add_head_rcu(&link->node, &pid->tasks[type]);
return 0;
@@ -339,7 +339,6 @@ void fastcall detach_pid(struct task_str
pid = link->pid;
hlist_del_rcu(&link->node);
- link->pid = NULL;
for (tmp = PIDTYPE_MAX; --tmp >= 0; )
if (!hlist_empty(&pid->tasks[tmp]))
@@ -348,6 +347,14 @@ void fastcall detach_pid(struct task_str
free_pid(pid);
}
+void task_put_pids(struct pid_link *pids)
+{
+ int type = PIDTYPE_MAX;
+
+ while (type--)
+ put_pid(pids[type].pid);
+}
+
/* transfer_pid is an optimization of attach_pid(new), detach_pid(old) */
void fastcall transfer_pid(struct task_struct *old, struct task_struct *new,
enum pid_type type)
--- kernel/fork.c 2007-11-09 12:57:31.0 +0300
+++ - 2007-11-18 16:57:34.037105563 +0300
@@ -121,6 +121,7 @@ void __put_task_struct(struct task_struc
WARN_ON(atomic_read(&tsk->usage));
WARN_ON(tsk == current);
+ task_put_pids(tsk->pids);
security_task_free(tsk);
free_uid(tsk->user);
put_group_info(tsk->group_info);
-
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] Fix PCIe double initialization bug
Rafael J. Wysocki wrote: .. Which kernel is it against? .. This patch is for -mm and for Kristen's queue. Not for 2.6.24. .. Patch was generated against 2.6.24-rc2-git4. - 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: broken suspend [Was: 2.6.24-rc2-mm1]
On Sunday, 18 of November 2007, Jiri Slaby wrote: > On 11/18/2007 02:42 PM, Rafael J. Wysocki wrote: > > On Sunday, 18 of November 2007, Jiri Slaby wrote: > >> On 11/18/2007 01:42 PM, Jiri Slaby wrote: > >>> See shot of prints here: > >>> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png > >> BTW output from that tree minus the patch: > > > > Hm, it looks like one of the CPU hotplug notifiers is doing something wrong. > > > > Can you try to see what happens (with the patch applied) if > > thermal_throttle_cpu_callback() is not registered? > > After commenting out > //device_initcall(thermal_throttle_init_device); > it looks like this: > http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png Can you also make the new System-map available, please? - 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: broken suspend [Was: 2.6.24-rc2-mm1]
On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote: > Can you also make the new System-map available, please? Sure: http://www.fi.muni.cz/~xslaby/sklad/System.map1 - 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: broken suspend [Was: 2.6.24-rc2-mm1]
On Sunday, 18 of November 2007, Jiri Slaby wrote: > On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote: > > Can you also make the new System-map available, please? > > Sure: > http://www.fi.muni.cz/~xslaby/sklad/System.map1 The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png is apparently cpu_swap_callback() which is not called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png . Can you verify that cpu_swap_callback() gets called if the patch is not applied? - 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: increased number of cycles
kernel coder wrote: hi, I'm trying to add some code to netif_receive_skb function in dev.c file . The cycles consumed by that code was around 16 cycles on Dual Core Opetron machine.I'm working on that code for last 6 months now and the consumed cycles have always been around 16 cycles .I don't touch any other part of kernel . But for last 4 days the consumed cycles have suddenly increased to around 35 cycles . I'm using RDTSC instruction to profile the code.There is no change in code and the kernel version is also the same .I am assuming that there must be something wrong with hardware. .. A cache miss ? - 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] Fix PCIe double initialization bug
Mark Lord wrote: Rafael J. Wysocki wrote: .. Which kernel is it against? .. This patch is for -mm and for Kristen's queue. Not for 2.6.24. .. Patch was generated against 2.6.24-rc2-git4. .. That is, against 2.6.24-rc2-git4 with the earlier PCIe hotplug patches also already applied, as they are in -mm and in Kristen's tree. - 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: 2.6.24-rc2 XFS nfsd hang
On Fri, 16 Nov 2007, Chris Wedgwood wrote: Oops, I meant it for NFSD... and I'm somewhat serious. I'm not saying it's a good long term solution, but a potentially safer short-term workaround. I've opened http://bugzilla.kernel.org/show_bug.cgi?id=9400 to track this one (and to not forget about it :)). I wonder why so few people are seeing this, I'd have assumed that NFSv3 && XFS is not sooo exotic... Christian. -- BOFH excuse #273: The cord jumped over and hit the power switch. - 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: size of git repository (was Re: [BUG] New Kernel Bugs)
* Pavel Machek <[EMAIL PROTECTED]> wrote: > On Tue 2007-11-13 12:50:08, Mark Lord wrote: > > Ingo Molnar wrote: > > > > > >for example git-bisect was godsent. I remember that > > >years ago bisection of a bug was a very laborous task > > >so that it was only used as a final, last-ditch > > >approach for really nasty bugs. Today we can > > >autonomouly bisect build bugs via a simple shell > > >command around "git-bisect run", without any human > > >interaction! This freed up testing resources > > .. > > > > It's only a godsend for the few people who happen to be > > kernel developers > > and who happen to already use git. > > > > It's a 540MByte download over a slow link for everyone > > else. > > Hmmm, clean-cg is 7.7G on my machine, and yes I tried > git-prune-packed. What am I doing wrong? "git-repack -a -d" gives me ~220 MB: $ du -s .git 222064 .git anyone who can download a 43 MB tar.bz2 tarball for a kernel release should be able to afford a _one time_ download size of 250 MB (the size of the current kernel.org git repository). If not, burning a CD or DVD and carrying it home ought to do the trick. Git is very bandwidth-efficient after that point - lots of people behind narrow pipes are using it - it's just the initial clone that takes time. And given all the history and metadata that the git repository carries (full changelogs, annotations, etc.) it's a no-brainer that kernel developers should be using it. (and you can shrink the 250 MB further down by using shallow clones, etc.) yes, some people complained when distros stopped doing floppy installs. Some people complained when distros stopped doing CD installs. Yes, i've myself done a 250+ MB download over a 56 kbit modem in the past, and while it indeed took overnight to finish, it's very much doable. It's not really qualitatively different from the 1.5 hours a kernel tar.bz2 took to download. 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: broken suspend [Was: 2.6.24-rc2-mm1]
On 11/18/2007 04:23 PM, Rafał J. Wysocki wrote: > On Sunday, 18 of November 2007, Jiri Slaby wrote: >> On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote: >>> Can you also make the new System-map available, please? >> Sure: >> http://www.fi.muni.cz/~xslaby/sklad/System.map1 > > The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png Last... Note, that it's only first 20 invokations of notifiers, there are bazillion of them when I remove the condition '< 20'. > is apparently cpu_swap_callback() which is not called in > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png . > > Can you verify that cpu_swap_callback() gets called if the patch is not > applied? Does this still apply? - 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: size of git repository (was Re: [BUG] New Kernel Bugs)
On 18-11-07 15:35, James Bottomley wrote: clean-cg? But failure to run "git repack -a -d" every once in a while? Actually, the best command is git gc which does a repack (into a single pack file rather than an incremenal), and then removes all the objects now in the pack. If, like me, you work on temporary branches which you keep rebasing, you can add a --prune to gc which will erase all unreferenced objects as it packs (use this one with care. I usually never use it but run a git prune -n just to see what would be removed, and then run git prune separately if it looks OK). Thanks for the comment. That managed to indeed shave a few extra bytes off my already "repack -a -d" packed repo still. Rene. - 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: 2.6.24-rc2 XFS nfsd hang
On Sun, 18 Nov 2007, Christian Kujau wrote: On Fri, 16 Nov 2007, Chris Wedgwood wrote: Oops, I meant it for NFSD... and I'm somewhat serious. I'm not saying it's a good long term solution, but a potentially safer short-term workaround. I've opened http://bugzilla.kernel.org/show_bug.cgi?id=9400 to track this one (and to not forget about it :)). I wonder why so few people are seeing this, I'd have assumed that NFSv3 && XFS is not sooo exotic... Still on 2.6.23.x here (also use nfsv3 + xfs). Christian. -- BOFH excuse #273: The cord jumped over and hit the power switch. - 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] Clustering indirect blocks in Ext3
Thanks for the suggestion Matt. It took me some time to get compilebench working due to the known issue with drop_caches due to circular lock dependency between j_list_lock and inode_lock (compilebench triggers drop_caches quite frequently). Here are the results for compilebench run with options "-i 30 -r 30". I repeated the test 5 times on each of vanilla and mc configurations. Setup: 4 cpu, 8GB RAM, 400GB disk. Average vanilla results == intial create total runs 30 avg 46.49 MB/s (user 1.12s sys 2.25s) create total runs 5 avg 12.90 MB/s (user 1.08s sys 1.97s) patch total runs 4 avg 8.70 MB/s (user 0.60s sys 2.31s) compile total runs 7 avg 21.44 MB/s (user 0.32s sys 2.95s) clean total runs 4 avg 59.91 MB/s (user 0.05s sys 0.26s) read tree total runs 2 avg 21.85 MB/s (user 1.12s sys 2.89s) read compiled tree total runs 1 avg 23.47 MB/s (user 1.45s sys 4.89s) delete tree total runs 2 avg 13.18 seconds (user 0.64s sys 1.02s) no runs for delete compiled tree stat tree total runs 4 avg 4.76 seconds (user 0.70s sys 0.50s) stat compiled tree total runs 1 avg 7.84 seconds (user 0.74s sys 0.54s) Average metaclustering results == intial create total runs 30 avg 45.04 MB/s (user 1.13s sys 2.42s) create total runs 5 avg 15.64 MB/s (user 1.08s sys 1.98s) patch total runs 4 avg 10.50 MB/s (user 0.61s sys 3.11s) compile total runs 7 avg 28.07 MB/s (user 0.33s sys 4.06s) clean total runs 4 avg 83.27 MB/s (user 0.04s sys 0.27s) read tree total runs 2 avg 21.17 MB/s (user 1.15s sys 2.91s) read compiled tree total runs 1 avg 22.79 MB/s (user 1.38s sys 4.89s) delete tree total runs 2 avg 9.23 seconds (user 0.62s sys 1.01s) no runs for delete compiled tree stat tree total runs 4 avg 4.72 seconds (user 0.71s sys 0.50s) stat compiled tree total runs 1 avg 6.50 seconds (user 0.79s sys 0.53s) Overall, metaclustering does better than vanilla except in a few cases. Thanks, Abhishek On Nov 15, 2007 11:37 PM, Matt Mackall <[EMAIL PROTECTED]> wrote: > On Thu, Nov 15, 2007 at 11:02:19PM -0800, Andrew Morton wrote: > > On Thu, 15 Nov 2007 21:02:46 -0800 "Abhishek Rai" <[EMAIL PROTECTED]> wrote: > ... > > > 3. e2fsck speedup with metaclustering varies from disk > > > to disk with most benefit coming from disks which have a large number > > > of indirect blocks. For disks which have few indirect blocks, fsck > > > usually doesn't take too long anyway and hence it's OK not to deliver > > > a huge speedup there. But in all cases, metaclustering doesn't cause > > > any degradation in IO performance as seen in the benchmarks above. > > > > Less speedup, for more-and-smaller files, it appears. > > > > An important question is: how does it stand up over time? Simply laying > > files out a single time on a fresh fs is the easy case. But what happens > > if that disk has been in continuous create/delete/truncate/append usage for > > six months? > > Try Chris Mason's compilebench, which is a decent aging simulation. > > -- > Mathematics is the supreme nostalgia of our time. > - 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: laptop reboots right after hibernation
Pavel Machek wrote: > Hi! > >> echo disk > /sys/power/state >> >> successfully saves that state to the disk, but just as the laptop is >> about to turn itself off, it reboots (successfully, so the >> hibernation/resume process works well, even with X running! which is >> awesome :) ). But I'd rather like the computer turned off after I >> hibernate it. Where could the problem be? >> >> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few >> days, both suspend and hibernate worked there (with one or two crashes, >> probably due to X, I've read that the intel driver got some >> suspend/resume improvements recently). Now I'm running gentoo, kernel >> 2.6.24-rc2. I'm using newer versions of almost all software now compared >> to the ubuntu system. > > If it works in older ubuntu, you can probably do bisect. Does normal > shutdown work? You can try platform vs. shutdown mode... > I don't have ubuntu anymore, though I'll try if hibernate works with the livecd. One interesting thing I've found out: hibernate reboots the laptop _only_ if it is in the docking station. If I hibernate while outside of the docking station, it properly shuts down the laptop. The default mode seems to be 'platform', after I echoed 'shutdown' to /sys/power/disk the notebook correctly shuts down after hibernation! Some interesting facts. All tests were done with 2.6.24-rc2, custom tailored kernel with just the options needed for my notebook (ThinkPad X61 Tablet) - without drm modules and bluetooth but with iwl4965 loaded. All tests were done without X running, from the console. If I say something 'works' it means I tested it at least three/four times in a row (if not even more). (1) Both STR and STD work correctly if I keep the notebook outside of the docking station (both in platform and shutdown mode). (2) Both STR and STD work correctly if I keep the notebook in the docking station (both in platform and shutdown mode - with the small glitch in platform mode that the notebook won't power off after hibernation). (3) Once the notebook was in the docking station (whether I boot it while in the dock or boot it outside and then put it into the dock) and I take it out (press the 'undock' button on the dock, wait for the green led, then take out the notebook) things get interesting: (a) I initiate STR, notebook correctly goes to sleep, but it only wakes up if I have it in the docking station. If I try to wake it up outside of the docking station it will fail. (b) I initiate STD, and it locks up after a few seconds, at that time only the cursor in the top left screen is visible (not blinking). If I put the notebook in its locked up state into the dock, it will reboot after a few seconds. (4) If the notebook is in the dock and I initiate STR and then press the undock button, it resumes (I assume that is 'working as intended'). (5) If the notebook is in the dock, I press the undock button and wait for the green led then initiate STR, I can take the notebook out but resuming doesn't work - unless I resume it while the notebook is back in the docking station (see point 3a) (6) If the notebook is in the dock, I press the undock button and wait for the green led, then initiate STD: (a) in platform mode: I can take the notebook out but resuming doesn't work - unless I resume it while the notebook is back in the docking station (contrary to point 3b). It seems as the notebook 'locks' itself into the docking station during STD, I see the green led change into red during the hibernation process (just before heavy HD activity starts). (b) in shutdown mode: STD fails with a completely black screen, not even the cursor is visible. There doesn't seem to be a difference between platform and shutdown mode other than the reboot glitch when the laptop is in the docking station or as described in point 6. tom - 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: [BUG] Strange 1-second pauses during Resume-from-RAM
* Mark Lord <[EMAIL PROTECTED]> wrote:
> Since Ingo's latency trace patches lock up the machine on resume, the
> next thing I'll try instead is to re-enable CONFIG_IRQBALANCE=y.
hm, which patch did you try? Could you check whether all chunks from the
patch below are applied? (these are the fixed i did when i was doing
cross-suspend traces - this is not something i've done before, so the
tracer had to be adjusted)
i suspect if you turn off CONFIG_FUNCTION_TRACING then you wont get any
hung resume - and the resulting trace would still be pretty useful. (it
will show scheduling and irq activities, etc.)
Ingo
---
arch/x86/kernel/stacktrace.c |2 +-
arch/x86/power/cpu.c |3 ++-
drivers/acpi/namespace/nsutils.c |2 +-
drivers/acpi/namespace/nswalk.c |2 +-
include/linux/sched.h|2 ++
kernel/latency_trace.c | 26 +++---
kernel/softirq.c |6 +++---
7 files changed, 33 insertions(+), 10 deletions(-)
Index: linux/arch/x86/kernel/stacktrace.c
===
--- linux.orig/arch/x86/kernel/stacktrace.c
+++ linux/arch/x86/kernel/stacktrace.c
@@ -22,7 +22,7 @@ static int save_stack_stack(void *data,
return -1;
}
-static void save_stack_address(void *data, unsigned long addr)
+static void notrace save_stack_address(void *data, unsigned long addr)
{
struct stack_trace *trace = (struct stack_trace *)data;
if (trace->skip > 0) {
Index: linux/arch/x86/power/cpu.c
===
--- linux.orig/arch/x86/power/cpu.c
+++ linux/arch/x86/power/cpu.c
@@ -123,8 +123,9 @@ void __restore_processor_state(struct sa
mcheck_init(&boot_cpu_data);
}
-void restore_processor_state(void)
+void notrace restore_processor_state(void)
{
+ trace_resume();
__restore_processor_state(&saved_context);
}
Index: linux/drivers/acpi/namespace/nsutils.c
===
--- linux.orig/drivers/acpi/namespace/nsutils.c
+++ linux/drivers/acpi/namespace/nsutils.c
@@ -923,7 +923,7 @@ struct acpi_namespace_node *acpi_ns_get_
*
**/
-struct acpi_namespace_node *acpi_ns_get_next_valid_node(struct
+struct acpi_namespace_node * notrace acpi_ns_get_next_valid_node(struct
acpi_namespace_node
*node)
{
Index: linux/drivers/acpi/namespace/nswalk.c
===
--- linux.orig/drivers/acpi/namespace/nswalk.c
+++ linux/drivers/acpi/namespace/nswalk.c
@@ -65,7 +65,7 @@ ACPI_MODULE_NAME("nswalk")
* within Scope is returned.
*
**/
-struct acpi_namespace_node *acpi_ns_get_next_node(acpi_object_type type,
struct acpi_namespace_node
+struct acpi_namespace_node * notrace acpi_ns_get_next_node(acpi_object_type
type, struct acpi_namespace_node
*parent_node, struct
acpi_namespace_node
*child_node)
{
Index: linux/include/linux/sched.h
===
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -337,6 +337,7 @@ static inline void touch_all_softlockup_
extern long user_trace_stop(void);
extern void trace_cmdline(void);
extern void init_tracer(void);
+ extern void trace_resume(void);
#else
# define mcount_enabled0
# define trace_enabled 0
@@ -358,6 +359,7 @@ static inline void touch_all_softlockup_
# define user_trace_stop() do { } while (0)
# define trace_cmdline() do { } while (0)
# define init_tracer() do { } while (0)
+# define trace_resume()do { } while (0)
#endif
#ifdef CONFIG_WAKEUP_TIMING
Index: linux/kernel/latency_trace.c
===
--- linux.orig/kernel/latency_trace.c
+++ linux/kernel/latency_trace.c
@@ -258,19 +258,28 @@ static struct cpu_trace cpu_traces[NR_CP
#endif
} };
-static notrace cycle_t now(struct cpu_trace *tr, int monotonic)
+static inline notrace cycle_t __now(int monotonic)
{
- cycles_t now, delta, last = tr->last_cycles;
+ cycles_t now;
if (trace_use_raw_cycles && !monotonic)
now = get_cycles();
else
now = get_monotonic_cycles();
+ return now;
+}
+
+static notrace cycle_t now(struct cpu_trace *tr, int monotonic)
+{
+ cycles_t now, delta, last = tr->last_cycles;
+
+ now = __now(monotonic);
+
Re: [BUG] Strange 1-second pauses during Resume-from-RAM
Mark Lord wrote: I have been reporting this off and on since 2.6.23 was released. This problem was not apparent up to perhaps 2.6.23-rc8, but definitely became common in 2.6.23 and 2.6.23.1. Most of the time, a resume-from-RAM on my notebook takes about 2.1 seconds of kernel time to complete. Once in a while, it takes *much* longer, in the 14-20 second range. These long events *seem* to be mostly after the notebook has been in suspend for a longish time, but there's really nothing consistent here. So git-bisect isn't going to work for this one. I recently rebuilt the kernel to include printk timestamps, and then it went 2 days without the issue happening, until this morning (after an overnight suspend) finally. The machine is a Dell Inspiron 9400, Intel chipset + Core2Duo 2.1GHZ w/3GB DDR2. PCIe express chipset, ATI graphics, SATA hard drive. 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express PCI Express Root Port (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd Unknown device 0832 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 03:01.2 System peripheral: Ricoh Co Ltd Unknown device 0843 (rev 01) 03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) 03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 05) 0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) There's also a USB2 hub connected, with the Logitech mouse being the only thing plugged into it at present. The best clue I have of what is happening, other than that it was first seen during the late 2.6.23-rc* series, are the following two sets of kernel logs. The first set is from a "normal" fast wake-up, and the second set is from the "slow" wake-up seen this morning. Both logs show the same information, in pretty much the same order. The BIG difference is a bunch of unexplained pauses of exactly 1-second each that occur during the slow wakeup. The only other difference is that the SATA disk messages are placed differently within the two logs. I'm thinking on that one but it doesn't look significant to me. The real question is, why the 1-sec pauses? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * HERE IS THE NORMAL RESUME LOG. [ 820.147914] CPU1 is down [0.355669] Back to C! [0.356120] Enabling non-boot CPUs ... [0.377167] SMP alternatives: switching to SMP code [0.378565] Booting processor 1/1 eip 3000 [0.378568] CPU 1 irqstacks, hard=c0375000 soft=c0373000 [0.389374] Initializing CPU#1 [0.470225] Calibrating delay using timer specific routine.. 4324.85 BogoMIPS (lpj=7204571) [0.470235] CPU: After generic identify, caps: bfebfbff 2010 e3bd 0001 [0.470244] monitor/mwait feature present. [0.470248] CPU: L1 I cache: 32K, L1 D cache: 32K [0.470252] CPU: L2 cache: 4096K [0.470255] CPU: Physical Processor ID: 0 [0.470257] CPU: Processor Core ID: 1 [0.470260] CPU: After all inits, caps: bfebfbff 2010 3940 e3bd 0001 [0.471330] CPU1: Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz stepping 06 [0.471724] CPU1 is up [0.474787] Switched to high resolution mode on CPU 1 [0.483415] PM: Writing back config space on device :00:01.0 at offset a (was f, writing 0) [0.483422] PM: Writing back config space on device :00:01.0 at offset 7 (was e0e0,
Re: laptop reboots right after hibernation
Tomas Carnecky wrote: > Pavel Machek wrote: >> Hi! >> >>> echo disk > /sys/power/state >>> >>> successfully saves that state to the disk, but just as the laptop is >>> about to turn itself off, it reboots (successfully, so the >>> hibernation/resume process works well, even with X running! which is >>> awesome :) ). But I'd rather like the computer turned off after I >>> hibernate it. Where could the problem be? >>> >>> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few >>> days, both suspend and hibernate worked there (with one or two crashes, >>> probably due to X, I've read that the intel driver got some >>> suspend/resume improvements recently). Now I'm running gentoo, kernel >>> 2.6.24-rc2. I'm using newer versions of almost all software now compared >>> to the ubuntu system. >> If it works in older ubuntu, you can probably do bisect. Does normal >> shutdown work? You can try platform vs. shutdown mode... >> > > I don't have ubuntu anymore, though I'll try if hibernate works with the > livecd. One interesting thing I've found out: hibernate reboots the > laptop _only_ if it is in the docking station. If I hibernate while > outside of the docking station, it properly shuts down the laptop. > > The default mode seems to be 'platform', after I echoed 'shutdown' to > /sys/power/disk the notebook correctly shuts down after hibernation! > > Some interesting facts. All tests were done with 2.6.24-rc2, custom > tailored kernel with just the options needed for my notebook (ThinkPad > X61 Tablet) - without drm modules and bluetooth but with iwl4965 loaded. > All tests were done without X running, from the console. If I say > something 'works' it means I tested it at least three/four times in a > row (if not even more). > > (1) Both STR and STD work correctly if I keep the notebook outside of > the docking station (both in platform and shutdown mode). > > (2) Both STR and STD work correctly if I keep the notebook in the > docking station (both in platform and shutdown mode - with the small > glitch in platform mode that the notebook won't power off after > hibernation). > > (3) Once the notebook was in the docking station (whether I boot it > while in the dock or boot it outside and then put it into the dock) and > I take it out (press the 'undock' button on the dock, wait for the green > led, then take out the notebook) things get interesting: > > (a) I initiate STR, notebook correctly goes to sleep, but it only wakes > up if I have it in the docking station. If I try to wake it up outside > of the docking station it will fail. That fails with a non-blinking cursor in the top left screen, just like in point 3b. > > (b) I initiate STD, and it locks up after a few seconds, at that time > only the cursor in the top left screen is visible (not blinking). If I > put the notebook in its locked up state into the dock, it will reboot > after a few seconds. > > (4) If the notebook is in the dock and I initiate STR and then press the > undock button, it resumes (I assume that is 'working as intended'). > > (5) If the notebook is in the dock, I press the undock button and wait > for the green led then initiate STR, I can take the notebook out but > resuming doesn't work - unless I resume it while the notebook is back in > the docking station (see point 3a) > > (6) If the notebook is in the dock, I press the undock button and wait > for the green led, then initiate STD: > > (a) in platform mode: I can take the notebook out but resuming doesn't > work - unless I resume it while the notebook is back in the docking > station (contrary to point 3b). It seems as the notebook 'locks' itself > into the docking station during STD, I see the green led change into red > during the hibernation process (just before heavy HD activity starts). > > (b) in shutdown mode: STD fails with a completely black screen, not even > the cursor is visible. > > There doesn't seem to be a difference between platform and shutdown mode > other than the reboot glitch when the laptop is in the docking station > or as described in point 6. > > tom - 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: broken suspend [Was: 2.6.24-rc2-mm1]
On Sun, 18 Nov 2007, Jiri Slaby wrote: > On 11/18/2007 04:23 PM, RafaÅ J. Wysocki wrote: > > On Sunday, 18 of November 2007, Jiri Slaby wrote: > >> On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote: > >>> Can you also make the new System-map available, please? > >> Sure: > >> http://www.fi.muni.cz/~xslaby/sklad/System.map1 > > > > The last notifier called in > > http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png > > Last... Note, that it's only first 20 invokations of notifiers, there are > bazillion of them when I remove the condition '< 20'. > > > is apparently cpu_swap_callback() which is not called in > > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png . > > > > Can you verify that cpu_swap_callback() gets called if the patch is not > > applied? > > Does this still apply? You'll get more useful results if you redo your changes to notifier_call_chain(). Have it print out the address of the routine _before_ making the call, and don't limit it to 20. That way you'll know exactly which notifier routine ends up hanging. Alan Stern - 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] use __set_task_state() for TRACED/STOPPED tasks
1. It is much easier to grep for ->state change if __set_task_state() is used
instead of the direct assignment.
2. ptrace_stop() and handle_group_stop() use set_task_state() which adds the
unneeded mb() (btw even if we use mb() it is still possible that do_wait()
sees the new ->state but not ->exit_code, but this is ok).
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- 24/kernel/fork.c~state 2007-11-09 12:57:31.0 +0300
+++ 24/kernel/fork.c2007-11-18 19:27:38.0 +0300
@@ -1462,7 +1462,7 @@ long do_fork(unsigned long clone_flags,
if (!(clone_flags & CLONE_STOPPED))
wake_up_new_task(p, clone_flags);
else
- p->state = TASK_STOPPED;
+ __set_task_state(p, TASK_STOPPED);
if (unlikely (trace)) {
current->ptrace_message = nr;
--- 24/kernel/ptrace.c~state2007-10-25 16:22:12.0 +0400
+++ 24/kernel/ptrace.c 2007-11-18 19:30:20.0 +0300
@@ -53,7 +53,7 @@ void ptrace_untrace(struct task_struct *
spin_lock(&child->sighand->siglock);
if (child->state == TASK_TRACED) {
if (child->signal->flags & SIGNAL_STOP_STOPPED) {
- child->state = TASK_STOPPED;
+ __set_task_state(child, TASK_STOPPED);
} else {
signal_wake_up(child, 1);
}
@@ -104,7 +104,7 @@ int ptrace_check_attach(struct task_stru
ret = 0;
spin_lock_irq(&child->sighand->siglock);
if (child->state == TASK_STOPPED) {
- child->state = TASK_TRACED;
+ __set_task_state(child, TASK_TRACED);
} else if (child->state != TASK_TRACED && !kill) {
ret = -ESRCH;
}
--- 24/kernel/signal.c~state2007-11-09 12:57:31.0 +0300
+++ 24/kernel/signal.c 2007-11-18 19:33:19.0 +0300
@@ -1617,7 +1617,7 @@ static void ptrace_stop(int exit_code, i
current->exit_code = exit_code;
/* Let the debugger run. */
- set_current_state(TASK_TRACED);
+ __set_current_state(TASK_TRACED);
spin_unlock_irq(¤t->sighand->siglock);
try_to_freeze();
read_lock(&tasklist_lock);
@@ -1781,7 +1781,7 @@ static int handle_group_stop(void)
if (stop_count == 0)
current->signal->flags = SIGNAL_STOP_STOPPED;
current->exit_code = current->signal->group_exit_code;
- set_current_state(TASK_STOPPED);
+ __set_current_state(TASK_STOPPED);
spin_unlock_irq(¤t->sighand->siglock);
finish_stop(stop_count);
return 1;
-
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: laptop reboots right after hibernation
Pavel Machek wrote: > Hi! > >> echo disk > /sys/power/state >> >> successfully saves that state to the disk, but just as the laptop is >> about to turn itself off, it reboots (successfully, so the >> hibernation/resume process works well, even with X running! which is >> awesome :) ). But I'd rather like the computer turned off after I >> hibernate it. Where could the problem be? >> >> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few >> days, both suspend and hibernate worked there (with one or two crashes, >> probably due to X, I've read that the intel driver got some >> suspend/resume improvements recently). Now I'm running gentoo, kernel >> 2.6.24-rc2. I'm using newer versions of almost all software now compared >> to the ubuntu system. > > If it works in older ubuntu, you can probably do bisect. Does normal > shutdown work? You can try platform vs. shutdown mode... I forgot, normal shutdown (init 0) works, the 'shutdown' command fails somewhere in the gentoo init scripts, but that has nothing to do with the kernel. 'init 6' also works. Both regardless of where the notebook is (dock or outside). tom - 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] keyspan: init termios properly
On Thu, Nov 15, 2007 at 01:10:16PM -0800, Lucy McCoy wrote:
> static int keyspan_open (struct usb_serial_port *port, struct file *filp)
> {
> struct keyspan_port_private *p_priv;
> struct keyspan_serial_private *s_priv;
> struct usb_serial *serial = port->serial;
> const struct keyspan_device_details *d_details;
> int i, err;
> struct urb *urb;
>
> s_priv = usb_get_serial_data(serial);
> p_priv = usb_get_serial_port_data(port);
> d_details = p_priv->device_details;
>
> dbg("%s - port%d.", __FUNCTION__, port->number);
>
> /* Set some sane defaults */
> p_priv->rts_state = 1;
> p_priv->dtr_state = 1;
> p_priv->baud = 9600;
>
> /* set CTS/RTS handshake etc. */
> p_priv->cflag = CS8; /* 8/N/1 */
> p_priv->flow_control = flow_none;
>
> /* force baud and lcr to be set on open */
> p_priv->old_baud = 0;
> p_priv->old_cflag = 0;
>
> p_priv->out_flip = 0;
> p_priv->in_flip = 0;
>
> /* Reset low level data toggle and start reading from endpoints */
> for (i = 0; i < 2; i++) {
> if ((urb = p_priv->in_urbs[i]) == NULL)
> continue;
> urb->dev = serial->dev;
>
> /* make sure endpoint data toggle is synchronized with the
> device */
>
> usb_clear_halt(urb->dev, urb->pipe);
>
> if ((err = usb_submit_urb(urb, GFP_KERNEL)) != 0) {
> dbg("%s - submit urb %d failed (%d)", __FUNCTION__, i,
> err);
> }
> }
>
> /* Reset low level data toggle on out endpoints */
> for (i = 0; i < 2; i++) {
> if ((urb = p_priv->out_urbs[i]) == NULL)
> continue;
> urb->dev = serial->dev;
> /* usb_settoggle(urb->dev, usb_pipeendpoint(urb->pipe),
> usb_pipeout(urb->pipe), 0); */
> }
>
> keyspan_send_setup(port, 1);
> //mdelay(100);
> //keyspan_set_termios(port, NULL);
>
> return (0);
> }
>
yes, after testing this i can confirm that this one fixes the NULL ptr
problem here so you might want to submit a proper patch to Greg.
--
Regards/Gruß,
Boris.
-
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] Printk kernel version in WARN_ON
On Sat, 17 Nov 2007 16:57:19 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > Should be done for all architectures, methinks. > > If so, an appropriate way to do that would be to do > s/dump_stack/arch_dump_stack/ and do a single all-arch implementation > of dump_stack(). (Where we might add new goodies in the future). > > Problem is that this will add a new an pointless entry to all the > stack dumps, unless the arch_dump_stack() implementation is smart > enough to skip the innermost frame. it also adds a stackframe to the "oh my god I'm low on stack space lets get a dump out" codepath ;( > -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - 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][retry-2] init: Introduce rootdir bootparm to select which dir to sys_chroot
Second try; this time with a doc-update, and the ability to remount normally.
Tested against 2.6.23.
---
This patch introduces a rootdir kernel boot parameter, which specifies the
path to the kernel sys_chroot boot dir.
This is useful for systems that have more than one distribution installed on
the same fs/partition.
Cc: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Al Boldi <[EMAIL PROTECTED]>
---
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1506,6 +1506,10 @@ and is between 256 and 4096 characters.
Useful for devices that are detected asynchronously
(e.g. USB and MMC devices).
+ rootdir=[KNL] Set root dir to chroot to on bootup.
+ Useful for systems that have more than one distribution
+ installed on the same filesystem.
+
rw [KNL] Mount root device read-write on boot
S [KNL] Run init in single mode
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -252,6 +252,16 @@ __setup("rootflags=", root_data_setup);
__setup("rootfstype=", fs_names_setup);
__setup("rootdelay=", root_delay_setup);
+static char __initdata root_dir[128];
+static int __init root_dir_setup(char *str)
+{
+ strcpy(root_dir, "./");
+ strlcat(root_dir, str, sizeof(root_dir));
+ return 1;
+}
+
+__setup("rootdir=", root_dir_setup);
+
static void __init get_fs_names(char *page)
{
char *s = page;
@@ -469,6 +479,12 @@ void __init prepare_namespace(void)
mount_root();
out:
sys_mount(".", "/", NULL, MS_MOVE, NULL);
+
+ if (root_dir) {
+ sys_mount(root_dir, root_dir, NULL, MS_BIND, NULL);
+ sys_chdir(root_dir);
+ }
+
sys_chroot(".");
security_sb_post_mountroot();
}
-
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: [rfc-patch 0/9] Immediate Values for 2.6.24-rc2-git5
* Borislav Petkov ([EMAIL PROTECTED]) wrote: > On Fri, Nov 16, 2007 at 03:02:38PM -0500, Mathieu Desnoyers wrote: > Hi, > just a conventions proposal: have you thought of shortening all those > "immediate_foo" prefixes to 'imm_foo', for example? This'll make the > code much more readable, i think. > Well, if there are enough supporters of this idea, I'd be happy to change "immediate_" for "imm_", since it's indeed shorter, easier to type, and looks better in the code. Anyone else agrees/disagrees ? Mathieu > - > Regards/Gruß, > Boris. -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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/
HP Pavilion DV6408nr timer/irq related? hard lockup
(I'm not on the list, please CC me in your replies) I have a HP DV6409nr Pavilion notebook that came preloaded with Windows Vista that Linux doesn't seem to want to boot properly on. Currently, 'noapic noirqdebug' sort-of works for x86_64 kernels, but Vista seems to be able to use the APIC just fine. I've disassembled the BIOS to pull out the bios pirq and routing table and from what I can tell, it's pretty flexible -- Linux and Vista both set up the same IRQs when in APIC mode, save for the HPET. Vista sticks the HPET on IRQ 0 and 8, Linux sticks it on 2, 8, and 31. The two USB controllers get assigned IRQ 22 in both Vista and Linux, but under Linux a few seconds after accessing a USB device causes the system to lock up solid without an oops. Most of all I'm trying to get this laptop running in APIC mode so I can run Xen. This system has no serial port, and USB seems to be problematic; can anyone suggest how to figure out what is causing the lock up? When the system freezes, it locks up so solid that sysrq doesn't work. - 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: [BUG] Strange 1-second pauses during Resume-from-RAM
Ingo Molnar wrote: * Mark Lord <[EMAIL PROTECTED]> wrote: Since Ingo's latency trace patches lock up the machine on resume, the next thing I'll try instead is to re-enable CONFIG_IRQBALANCE=y. hm, which patch did you try? Could you check whether all chunks from the patch below are applied? (these are the fixed i did when i was doing cross-suspend traces - this is not something i've done before, so the tracer had to be adjusted) .. Hi Ingo! I was using your 2.6.23.1 version of the patches, plus the fix you posted. The new patch you gave just now is for 2.6.24, which won't apply to the older kernel. I'm not switching kernels yet, as doing so might mask the problem without actually resolving it for good. Cheers - 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: [BUG] New Kernel Bugs
On Sat, Nov 17, 2007 at 01:20:10PM +0100, Adrian Bunk wrote: > > But a bisect takes around 7 compiles. > >... > > I don't understand that number. > > The common case are regressions in -rc1, and a bisection of > at about 7000 commits takes around 13 compiles. Worst case it would take 13. In practice I've seen less. Part of it is I suspect that I'm starting with something more recent than the previous 2.6.23, but rather a daily -git13 or -git14 tree. Part of it may be because git can sometimes be more efficient by cutting off entire branches with trail builds, since git history isn't completely linear, but rather pulls of various branches together. - Ted - 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/
Need help with register_page_fault_notifier() replacement in 2.6.24
Hello! I'm trying to update a special tracing version of madwifi (driver for Atheros wireless cards) for Linux 2.6.24. This version was created to help reverse engineering the non-free part of the driver (also known as HAL, hardware abstraction layer). The problem is that functions register_page_fault_notifier() and unregister_page_fault_notifier() are gone in the current kernel git repository. They are needed to intercept access to the card by causing page fault and intercepting it. Those functions were removed on i386 platform because kprobes now registers the flat handler directly. The log says that other callers are supposed to use kprobes now. But what would be the right way to do it? I can intercept do_page_fault() with kprobes, but that looks unsafe, since do_page_fault() is used by kprobes internally. Or maybe I should install a fault handler with register_kprobe()? The problem is, it is only called for faults in kp->pre_handler and kp->post_handler and for single-stepping. I don't want to single-step anything, and moving all driver functionality in kp->pre_handler would be strange. Perhaps I'm missing something obvious. Any help will be appreciated. -- Regards, Pavel Roskin - 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 00/33] Swap over NFS -v14
On Wed, Oct 31, 2007 at 01:56:53PM +0100, Peter Zijlstra wrote: >On Wed, 2007-10-31 at 08:16 -0400, Jeff Garzik wrote: >> Thoughts: >> 1) I absolutely agree that NFS is far more prominent and useful than any >> network block device, at the present time. >> >> 2) Nonetheless, swap over NFS is a pretty rare case. I view this work >> as interesting, but I really don't see a huge need, for swapping over >> NBD or swapping over NFS. I tend to think swapping to a remote resource >> starts to approach "migration" rather than merely swapping. Yes, we can >> do it... but given the lack of burning need one must examine the price. > >There is a large corporate demand for this, which is why I'm doing this. > >The typical usage scenarios are: > - cluster/blades, where having local disks is a cost issue (maintenance > of failures, heat, etc) HPC clusters are increasingly diskless, especially at the high end. for all the reasons you mention, but also because networks are faster than disks. >But please, people who want this (I'm sure some of you are reading) do >speak up. I'm just the motivated corporate drone implementing the >feature :-) swap to iSCSI has worked well in the past with your anti-deadlock patches, and I'd definitely like to see that continue and to be merged into mainline!! swap-to-network is a highly desirable feature for modern clusters. performance and scalability of NFS is poor, so it's not a good option. actually swap to a file on Lustre(*) would be best, but iSER and iSCSI would be my next choices. iSER is better than iSCSI as it's ~5x faster in practice, and InfiniBand seems to be here to stay. hmmm - any idea what the issues are with RDMA in low memory situations? presumably if DMA regions are mapped early then there's not actually much of a problem? I might try it with tgtd's iSER... cheers, robin (*) obviously not your responsibility. although Lustre (Sun/CFS) could presumably use your infrastructure once you have it in mainline. >> 3) You note >> > Swap over network has the problem that the network subsystem does not use >> > fixed >> > sized allocations, but heavily relies on kmalloc(). This makes mempools >> > unusable. >> >> True, but IMO there are mitigating factors that should be researched and >> taken into account: >> >> a) To give you some net driver background/history, most mainstream net >> drivers were coded to allocate RX skbs of size 1538, under the theory >> that they would all be allocating out of the same underlying slab cache. >> It would not be difficult to update a great many of the [non-jumbo] >> cases to create a fixed size allocation pattern. > >One issue that comes to mind is how to ensure we'd still overflow the >IP-reassembly buffers. Currently those are managed on the number of >bytes present, not the number of fragments. > >One of the goals of my approach was to not rewrite the network subsystem >to accomodate this feature (and I hope I succeeded). > >> b) Spare-time experiments and anecdotal evidence points to RX and TX skb >> recycling as a potentially valuable area of research. If you are able >> to do something like that, then memory suddenly becomes a lot more >> bounded and predictable. >> >> >> So my gut feeling is that taking a hard look at how net drivers function >> in the field should give you a lot of good ideas that approach the >> shared goal of making network memory allocations more predictable and >> bounded. > >Note that being bounded only comes from dropping most packets before >trying them to a socket. That is the crucial part of the RX path, to >receive all packets from the NIC (regardless their size) but to not pass >them on to the network stack - unless they belong to a 'special' socket >that promises undelayed processing. > >Thanks for these ideas, I'll look into them. - 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: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
On Nov 18, 2007 12:05 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> I've been staring at this NFS code for a while an can't make any sense
> out of it. It seems to correctly initialize the waitqueue. So this would
> indicate corruption of some sort.
No, it does not "correctly" initialize the waitqueue. It doesn't even
try to initialize it.
I now found the guilty patch and what is wrong with it.
nfs-stop-sillyname-renames-and-unmounts-from-racing.patch adds:
@@ -110,8 +112,22 @@ struct nfs_server {
filesystem */
#endif
void (*destroy)(struct nfs_server *);
+
+ atomic_t active; /* Keep trace of any activity to this server */
+ wait_queue_head_t active_wq; /* Wait for any activity to stop */
and tries to initialize it:
@@ -593,6 +593,10 @@ static int nfs_init_server(struct nfs_server *server,
server->namelen = data->namlen;
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
+
+ init_waitqueue_head(&server->active_wq);
+ atomic_set(&server->active, 0);
+
and then uses it via nfs_sb_active and nfs_sb_deactive:
@@ -29,6 +29,7 @@ struct nfs_unlinkdata {
static void
nfs_free_unlinkdata(struct nfs_unlinkdata *data)
{
+ nfs_sb_deactive(NFS_SERVER(data->dir));
iput(data->dir);
put_rpccred(data->cred);
kfree(data->args.name.name);
@@ -151,6 +152,7 @@ static int nfs_do_call_unlink(struct dentry
*parent, struct inode *dir, struct n
nfs_dec_sillycount(dir);
return 0;
}
+ nfs_sb_active(NFS_SERVER(dir));
data->args.fh = NFS_FH(dir);
nfs_fattr_init(&data->res.dir_attr);
But it does not notice this:
struct dentry_operations nfs_dentry_operations = {
.d_revalidate = nfs_lookup_revalidate,
.d_delete = nfs_dentry_delete,
.d_iput = nfs_dentry_iput,
};
struct dentry_operations nfs4_dentry_operations = {
.d_revalidate = nfs_open_revalidate,
.d_delete = nfs_dentry_delete,
.d_iput = nfs_dentry_iput,
};
NFSv2/3 and NFSv4 share the same dentry_iput and so share the same
unlink and sillyrename logic.
But they do not share nfs_init_server()!
I wonder why this doesn't blow up more violently, but only hangs...
But as I don't know if it is correct to add the workqueue
initialization to nfs4_init_server() or remove the nfs_sb_active /
nfs_sb_deactive for the NFSv4 case, I can't offer a patch to fix this.
Torsten
-
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 Bug in 2.6.23 ? SOLUTION ?
Trond, The problem is in nfs_mountpoint_timeout. After this time dentry_delete(/,4) removes the mountpoint, then it is very difficult to automount (at least with CFSD), one has got to try 2 or three times cd'ing into the mount point. Applications wont ever had the chance to autoremount (ENOTDIR). I have some questions: - nfs_mountpoint_timeout seems to be set in sysctl.c even if nfsv4 is not. Is this correct ? I've read somewhere that it was introduced for v4. - Why this sysctl is not registered in my 2.6.20 kernel where it should be registered ? - Why this parameter has not a 'disabled' value (i mean kind of -1) ? Thanks, Gianluca - 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: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)
Peter Dolding wrote: > On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote: > >> --- Peter Dolding <[EMAIL PROTECTED]> wrote: >>> On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote: >>> Peter Dolding wrote: > Assign application to > a cgroup that contains there filesystem access permissions. Done > right this could even be stacked. Only give less access to > application unless LSM particularly overrides This comes no where close to AppArmor's functionality: * Can't do learning mode * Can't do wildcards * Sucks up huge loads of memory to do that much FS mounting (imagine thousands of bind mounts) * I'm not sure, but I don't think you can do file granularity, only directorie >>> Ok sorry to say so far almost percent wrong. Please note netlabels >>> falls into a control group. All function of Apparmor is doable bar >>> exactly learning mode. For learning mode that would have to be a >>> hook back to a LSM I would expect. >>> >>> Done right should suck up no more memory than current apparmor. But >>> it will required all LSM's doing file access to come to common >>> agreement how to do it. Not just hooks into the kernel system any >>> more. >>> >> The ability to provide alternative access control schemes is the >> purpose of LSM. The fact that we insane security people can't come >> to the agreement you require is why we have LSM. You can not have >> what you are asking for. Please suggest an alternative design. >> > Part of the building the alternative design requires aggreeing to > build sections common. > Ok. I vehemently disagree with your design ideas. So do lots of other people, and I have not seen one single person ever speak up in favor of your ideas. So far, you have no agreement at all. Containers and access controls provide related but different functions. Stop trying to force containers to be an access control system, it does not fit well at all. Rather, we need to ensure that LSM and containers play well together. What you proposed in the past was to have an LSM module per container, but I find that absurdly complex: if you want that, then use a real VMM like Xen or something. Containers are mostly used for massive virtual domain hosting, and what you want there is as much sharing as possible while maintaining isolation. so why would you corrupt that with separate LSM modules per container? >>> Please stop being foolish. Xen and the like don't share memory. You >>> are basically saying blow out memory usage just because someone wants >>> to use a different LSM. >>> >> Yup. No one ever said security was cheap. Most real, serious security >> solutions implemented today rely on separate physical machines for >> isolation. Some progressive installations are using virtualization, >> and the lunatic fringe uses the sort of systems well served by LSM. >> Let's face it, people who really care are willing to pay a premium. >> > > Bigger problem Containers are processor neutral Xen and lot of the > other solutions are not. There are advantages for people who don't > need full blown. There needs to be two levels. Ie VM for the heavy. > Containers for where the security is needed but no to the point of > needing two different kernels. Remarkable. I agree completely with this paragraph, but draw the opposite conclusion that you do. Having private LSMs per container means having a separate kernel per container. That would seem to put that idea in the "heavy" category. Which is why I suggested that people who want to do what you desire should use full VMM instead of containers. > Now restricting what can be in a > Container due to some poor reason that has not been attempted to be > worked around is not a valid reason. It is rejected for perfectly sound engineering reasons like complexity bloat and memory bloat. Come back with a workable design or STFU. >In theory using Containers you > should be able to run every Linux distro on earth under one kernel as > long as it supports that series kernel. Ie 2.6 2.4... In "theory" as long as this theory ignores the fact that all distros patch their kernel. So yeah, you can run different "distros" as long as you don't care about device support, and you ignore which LSM you want to use. Containers fundamentally share the kernel, and the LSM module(s) loaded are part of the kernel, and therefore are fundamentally shared among the Containers. >>> Besides file access control is part of running containers isolated in >>> the first place and need to be LSM neutral. >>> >> File access control is within the scope of the LSM. If your feature >> can't deal with that you need to fix your feature. >> > This is the problem for containers File access controls need to be > like netlabels common between LSM's.
Re: broken suspend [Was: 2.6.24-rc2-mm1]
On 11/18/2007 06:07 PM, Alan Stern wrote:
> You'll get more useful results if you redo your changes to
> notifier_call_chain(). Have it print out the address of the routine
> _before_ making the call, and don't limit it to 20. That way you'll
> know exactly which notifier routine ends up hanging.
The problem is, that notifier_call_chain is called again and again zillion times
by somebody else...
Anyway you led me to another idea:
* _cpu_down
printk("%s: u\n", __func__);
BUBAK=1;
/* CPU is completely dead: tell everyone. Too late to complain. */
if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | 0x88000 | mod,
hcpu) == NOTIFY_BAD)
BUG();
BUBAK=0;
-
* notifier_call_chain
unsigned int a = val & 0x88000;
unsigned int yes = a == 0x88000;
nb = rcu_dereference(*nl);
if (a && a != 0x88000)
printk("Somebody calls with val: %lx\n", val);
else
val &= ~0x88000;
while (nb && nr_to_call) {
next_nb = rcu_dereference(nb->next);
if (unlikely(BUBAK && yes))
printk("%s: %p\n", __func__, nb->notifier_call);
ret = nb->notifier_call(nb, val, v);
-
gives coretemp_cpu_callback -> coretemp_device_remove ->
platform_device_unregister, so coretemp seems to be what I have and you don't.
-
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: [PATCHv3 0/4] sys_indirect system call
Ulrich Drepper wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 H. Peter Anvin wrote: It seems to me that we could accomplish the same thing by passing the number of parameters in the upper bits of the system call number register (%eax in the case of x86.) This isn't really a generic solution. The number of parameters is limited to six. There are syscalls with six parameters already. There are many more with five which could only handle one more parameter. Also, is it really simpler? You'd need to have another table which contains the default number of parameters a system call takes so that you can fill in the default value of zero. This extra memory access has to be performed for every system call. I think it is unlikely that this approach is faster. To the contrary, I'd guess. I don't have much invested into this but it seems the sys_indirect approach is so much simpler. Overhead is only paid if you really need it which is rarely the case. Plus, you might have heard Linus and Zack talk about syslets again. Starting syslets can be done using the same interface, I guess. What bothers me about the sys_indirect approach is that it will get increasingly expensive as time goes on, and in doing so it does a user-space memory reference, which are extra expensive. The extra table can be colocated with the main table (a structure, in effect) so they'll share the same cache line. -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/
[PATCH] Time-based RFC 4122 UUID generator
Andrew,
could you please consider adding this patch to your 2.6.25 patch series?
This is the third version of the patch in which I cleaned up and fixed quite
some stuff according to feedback from Ted.
I assume this version is OK, since I didn't received any further feedback since
two weeks: http://lkml.org/lkml/2007/11/4/128.
Thanks,
Helge
---
Title: Add time-based RFC 4122 UUID generator
The current Linux kernel currently contains the generate_random_uuid()
function, which creates - based on RFC 4122 - truly random UUIDs and
provides them to userspace through /proc/sys/kernel/random/boot_id and
/proc/sys/kernel/random/uuid.
This patch additionally adds the "Time-based UUID" variant of RFC 4122,
with which userspace applications can easily get real unique time-based
UUIDs through /proc/sys/kernel/random/uuid_time.
A new /proc/sys/kernel/random/uuid_time_clockseq sysfs entry is available,
so that the clock_seq value can be retained across system bootups (which
is required by RFC 4122).
The attached implementation uses getnstimeofday() to get very fine-grained
granularity. This helps, so that userspace tools can get a lot more UUIDs
(if needed) per time than before.
A mutex takes care of the proper locking against a mistaken double creation
of UUIDs for simultanious running processes.
Signed-off-by: Helge Deller <[EMAIL PROTECTED]>
drivers/char/random.c | 205 -
include/linux/sysctl.h |5 -
2 files changed, 190 insertions(+), 20 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 5fee056..fc48c29 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -6,6 +6,9 @@
* Copyright Theodore Ts'o, 1994, 1995, 1996, 1997, 1998, 1999. All
* rights reserved.
*
+ * Time based UUID (RFC 4122) generator:
+ * Copyright Helge Deller <[EMAIL PROTECTED]>, 2007
+ *
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
@@ -239,6 +242,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1174,12 +1178,169 @@ EXPORT_SYMBOL(generate_random_uuid);
static int min_read_thresh = 8, min_write_thresh;
static int max_read_thresh = INPUT_POOL_WORDS * 32;
static int max_write_thresh = INPUT_POOL_WORDS * 32;
-static char sysctl_bootid[16];
+static unsigned char sysctl_bootid[16] __read_mostly;
/*
- * These functions is used to return both the bootid UUID, and random
- * UUID. The difference is in whether table->data is NULL; if it is,
- * then a new UUID is generated and returned to the user.
+ * Helper functions and variables for time based UUID generator
+ */
+static unsigned int clock_seq;
+static const unsigned int clock_seq_max = 0x3fff; /* 14 bits */
+static int clock_seq_initialized __read_mostly;
+
+static void init_clockseq(void)
+{
+ get_random_bytes(&clock_seq, sizeof(clock_seq));
+ clock_seq &= clock_seq_max;
+ clock_seq_initialized = 1;
+}
+
+static int proc_dointvec_clockseq(struct ctl_table *table, int write,
+ struct file *filp, void __user *buffer,
+ size_t *lenp, loff_t *ppos)
+{
+ int ret;
+
+ if (!write && !clock_seq_initialized)
+ init_clockseq();
+
+ ret = proc_dointvec(table, write, filp, buffer, lenp, ppos);
+
+ if (write && ret >= 0) {
+ clock_seq_initialized = 1;
+ clock_seq &= clock_seq_max;
+ }
+
+ return ret;
+}
+
+/*
+ * Generate time based UUID (RFC 4122)
+ *
+ * This function is protected with a mutex to ensure system-wide
+ * uniqiness of the new time based UUID.
+ */
+static void generate_random_uuid_time(unsigned char uuid_out[16])
+{
+ static DEFINE_MUTEX(uuid_mutex);
+ static u64 last_time_all;
+ static unsigned int clock_seq_started;
+ static unsigned char last_mac[ETH_ALEN];
+
+ struct timespec ts;
+ u64 time_all;
+ unsigned char *found_mac = NULL;
+ struct net_device *d __maybe_unused;
+ int inc_clock_seq = 0;
+
+ mutex_lock(&uuid_mutex);
+
+ /* Get the spatially unique node identifier */
+#ifdef CONFIG_NET
+ read_lock(&dev_base_lock);
+ for_each_netdev(&init_net, d) {
+ if (d->type == ARPHRD_ETHER && d->addr_len == ETH_ALEN
+ && d != init_net.loopback_dev) {
+ if (!memcmp(&last_mac, d->dev_addr, ETH_ALEN)) {
+ found_mac = last_mac;
+ break;
+ }
+ if (!found_mac)
+ found_mac = d->dev_addr;
+ }
+ }
+ if (found_mac)
+ memcpy(&uuid_out[10], found_mac, ETH_ALEN);
+ read_unlock(&dev_base_lock);
+#endif
+ if (unlikely(!found_mac)) {
+ /* use bootid's nodeID if no network interface found */
+ if (sys
Re: NFS Bug in 2.6.23 ? SOLUTION ?
On Sun, 2007-11-18 at 19:44 +0100, Gianluca Alberici wrote: > Trond, > > The problem is in nfs_mountpoint_timeout. After this time > dentry_delete(/,4) removes the mountpoint, then it is very difficult to > automount (at least with CFSD), one has got to try 2 or three times > cd'ing into the mount point. Applications wont ever had the chance to > autoremount (ENOTDIR). Sounds like CFSD has a bug w.r.t. what fsid it returns to the client. > I have some questions: > > - nfs_mountpoint_timeout seems to be set in sysctl.c even if nfsv4 is > not. Is this correct ? I've read somewhere that it was introduced for v4. Wrong. It applies to all mountpoint crossing. If the server tells us that the fsid has changed, then we create a new mountpoint. > - Why this sysctl is not registered in my 2.6.20 kernel where it should > be registered ? Prior to 2.6.21-rc5, we had a bug in register_nfs_fs() whereby it failed to register the sysctl table unless you enabled NFSv4. > - Why this parameter has not a 'disabled' value (i mean kind of -1) ? Why should it? The current behaviour is quite correct. If you cross a mountpoint, then you should remount in order to ensure that the inode numbers remain unique per-filesystem. We know that some ancient NFS servers had problems returning the correct fsid in readdirplus replies, so 2.6.22 adds support to disable readdirplus calls via a 'nordirplus' mount option. I guess you could try that... Trond - 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: [BUG] 2.6.24-rc2-mm1 - kernel bug on nfs v4
On Sun, 2007-11-18 at 19:44 +0100, Torsten Kaiser wrote:
> On Nov 18, 2007 12:05 AM, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > I've been staring at this NFS code for a while an can't make any sense
> > out of it. It seems to correctly initialize the waitqueue. So this would
> > indicate corruption of some sort.
>
> No, it does not "correctly" initialize the waitqueue. It doesn't even
> try to initialize it.
>
> I now found the guilty patch and what is wrong with it.
>
> nfs-stop-sillyname-renames-and-unmounts-from-racing.patch adds:
>
> @@ -110,8 +112,22 @@ struct nfs_server {
>filesystem */
> #endif
> void (*destroy)(struct nfs_server *);
> +
> + atomic_t active; /* Keep trace of any activity to this server */
> + wait_queue_head_t active_wq; /* Wait for any activity to stop */
>
> and tries to initialize it:
> @@ -593,6 +593,10 @@ static int nfs_init_server(struct nfs_server *server,
> server->namelen = data->namlen;
> /* Create a client RPC handle for the NFSv3 ACL management interface
> */
> nfs_init_server_aclclient(server);
> +
> + init_waitqueue_head(&server->active_wq);
> + atomic_set(&server->active, 0);
> +
>
> and then uses it via nfs_sb_active and nfs_sb_deactive:
>
> @@ -29,6 +29,7 @@ struct nfs_unlinkdata {
> static void
> nfs_free_unlinkdata(struct nfs_unlinkdata *data)
> {
> + nfs_sb_deactive(NFS_SERVER(data->dir));
> iput(data->dir);
> put_rpccred(data->cred);
> kfree(data->args.name.name);
> @@ -151,6 +152,7 @@ static int nfs_do_call_unlink(struct dentry
> *parent, struct inode *dir, struct n
> nfs_dec_sillycount(dir);
> return 0;
> }
> + nfs_sb_active(NFS_SERVER(dir));
> data->args.fh = NFS_FH(dir);
> nfs_fattr_init(&data->res.dir_attr);
>
>
> But it does not notice this:
> struct dentry_operations nfs_dentry_operations = {
> .d_revalidate = nfs_lookup_revalidate,
> .d_delete = nfs_dentry_delete,
> .d_iput = nfs_dentry_iput,
> };
> struct dentry_operations nfs4_dentry_operations = {
> .d_revalidate = nfs_open_revalidate,
> .d_delete = nfs_dentry_delete,
> .d_iput = nfs_dentry_iput,
> };
>
> NFSv2/3 and NFSv4 share the same dentry_iput and so share the same
> unlink and sillyrename logic.
> But they do not share nfs_init_server()!
>
> I wonder why this doesn't blow up more violently, but only hangs...
>
> But as I don't know if it is correct to add the workqueue
> initialization to nfs4_init_server() or remove the nfs_sb_active /
> nfs_sb_deactive for the NFSv4 case, I can't offer a patch to fix this.
>
> Torsten
I had already fixed that one in my own stack. Attached are the 3 patches
that I've got. 1 from SteveD, 2 fixes.
Andrew, could you please unapply the sillyrename patches you've got, and
apply these 3 instead?
Trond
--- Begin Message ---
Added an active/deactive mechanism to the nfs_server structure
allowing async operations to hold off umount until the
operations are done.
Signed-off-by: Steve Dickson <[EMAIL PROTECTED]>
Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
---
fs/nfs/client.c |4
fs/nfs/super.c| 13 +
fs/nfs/unlink.c |2 ++
include/linux/nfs_fs_sb.h | 17 +
4 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/fs/nfs/client.c b/fs/nfs/client.c
index 70587f3..2ecf726 100644
--- a/fs/nfs/client.c
+++ b/fs/nfs/client.c
@@ -593,6 +593,10 @@ static int nfs_init_server(struct nfs_server *server,
server->namelen = data->namlen;
/* Create a client RPC handle for the NFSv3 ACL management interface */
nfs_init_server_aclclient(server);
+
+ init_waitqueue_head(&server->active_wq);
+ atomic_set(&server->active, 0);
+
dprintk("<-- nfs_init_server() = 0 [new %p]\n", clp);
return 0;
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 71067d1..833aed8 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -202,6 +202,7 @@ static int nfs_get_sb(struct file_system_type *, int, const
char *, void *, stru
static int nfs_xdev_get_sb(struct file_system_type *fs_type,
int flags, const char *dev_name, void *raw_data, struct
vfsmount *mnt);
static void nfs_kill_super(struct super_block *);
+static void nfs_put_super(struct super_block *);
static struct file_system_type nfs_fs_type = {
.owner = THIS_MODULE,
@@ -223,6 +224,7 @@ static const struct super_operations nfs_sops = {
.alloc_inode= nfs_alloc_inode,
.destroy_inode = nfs_destroy_inode,
.write_inode= nfs_write_inode,
+ .put_super = nfs_put_super,
.statfs = nfs_statfs,
.clear_inode= nfs_clear_inode,
.umount_begin = nfs_umount_begin,
@@ -1772,6 +1774,17 @@ static void nfs4_kil
Re: [PATCH][retry-2] init: Introduce rootdir bootparm to select which dir to sys_chroot
Al Boldi <[EMAIL PROTECTED]> wrote: > Second try; this time with a doc-update, and the ability to remount normally. > > Tested against 2.6.23. > > --- > > This patch introduces a rootdir kernel boot parameter, which specifies the > path to the kernel sys_chroot boot dir. > > This is useful for systems that have more than one distribution installed on > the same fs/partition. 1) This is useful for booting a rescue or test system, too. In those cases, you might want to have the old root moved somewhere. (Always "$rootdir/oldroot"? Additional parameter? I'm not sure ...) 2) You use a static buffer, but you don't check for bad return values of strlcat(). - 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: apm emulation driver broken ?
Rafael J. Wysocki wrote: > On Saturday, 17 of November 2007, Franck Bui-Huu wrote: >> ok so now we agreed on this point, can we assert that a user >> land thread waiting for an event in an UNINTERRUPTIBLE state >> will prevent a suspend to happen ? > > Yes. > So this driver seems really broken and actually I'm wondering if it's used by anyone... See the call to wait_even() made by apm_ioctl(). If any processes run this, it will prevent the system to suspend... And no, I don't know why call wait_event() is called. Franck - 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: Use *poof* for linux-omap
* David Miller <[EMAIL PROTECTED]> [071116 16:46]: > From: Tony Lindgren <[EMAIL PROTECTED]> > Date: Fri, 16 Nov 2007 14:16:11 -0800 > > > Can you please use your *poof* trick one more time to set up > > [EMAIL PROTECTED] > > Done, enjoy. Thanks! Tony - 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][retry-2] init: Introduce rootdir bootparm to select which dir to sys_chroot
Bodo Eggert wrote: 1) This is useful for booting a rescue or test system, too. In those cases, you might want to have the old root moved somewhere. (Always "$rootdir/oldroot"? Additional parameter? I'm not sure ...) Again, this is a good example of why this really shouldn't be additional hacks in kernel space. -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: laptop reboots right after hibernation
Since this is becoming more an IDE/ATA issue, I added [EMAIL PROTECTED] to CC. I hope that's the right mailinglist. Tomas Carnecky wrote: > (3) Once the notebook was in the docking station (whether I boot it > while in the dock or boot it outside and then put it into the dock) and > I take it out (press the 'undock' button on the dock, wait for the green > led, then take out the notebook) things get interesting: > > (a) I initiate STR, notebook correctly goes to sleep, but it only wakes > up if I have it in the docking station. If I try to wake it up outside > of the docking station it will fail. Magic number: 0:971:888 hash matches drivers/base/power/main.c:82 hash matches device ptyuf hash matches device :00:1f.1 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03) > (5) If the notebook is in the dock, I press the undock button and wait > for the green led then initiate STR, I can take the notebook out but > resuming doesn't work - unless I resume it while the notebook is back in > the docking station (see point 3a) Magic number: 0:648:888 hash matches drivers/base/power/main.c:103 hash matches device ptyuf hash matches device :00:1f.1 00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03) I kindof had suspected that. The docking station has an ultrabay slot where I currently have a cdrom drive (since the notebook itself doesn't have any cdrom drive. Once I took the cdrom drive out, I was able to successfully perform what I wanted to do in points 3a and 5! The 'undock' button probably doesn't tell the kernel that it should unload the cdrom driver. Even though after pressing the undock button the drive becomes unusable (the green led that is on the side of the ultrabay disables and it's impossible to open the tray). Though pressing the undock button causes the usb ports to be removed from the kernel, at least that's what dmesg suggests (I put the notebook into the dock, waited a bit and then pressed the undock button): usb 1-4: new high speed USB device using ehci_hcd and address 11 usb 1-4: configuration #1 chosen from 1 choice hub 1-4:1.0: USB hub found hub 1-4:1.0: 4 ports detected ACPI: \_SB_.GDCK - docking ACPI: \_SB_.GDCK - undocking usb 1-4: USB disconnect, address 11 The notebook+dock+STR works as long as the notebook doesn't know about the ultrabay device. That can be because the notebook was started outside of the docking station, or inside the docking station but with the ultrabay removed. But once the notebook sees the ultrabay device it's over. As little as one suspend/resume cycle inside the docking station and with a ultrabay device plugged in is enough to make the kernel (partially) recognize the device - the kernel doesn't recognize the device as a cdrom drive, but only as an UDMA/33 device. After one suspend/resume cycle I see this in dmesg: ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata4: failed to recover some devices, retrying in 5 secs Coming out of suspend... [... snip ...] ata4.00: ACPI cmd ef/03:45:00:00:00:a0 failed (Emask=0x1 Stat=0x51 Err=0x04) ata4.00: ACPI on devcfg failed the second time, disabling (errno=-5) ata4.00: revalidation failed (errno=1) ata4: failed to recover some devices, retrying in 5 secs ata4.00: configured for UDMA/33 And after that I can't resume outside of the docking station. So the description of point 3 was incomplete, sorry about that. At least the two failures 3a and 5 can be explained... tom - 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] Fix UML broken (was Re: User Mode Linux still broken in 2.6.23.1)
On Saturday 17 November 2007 12:53:57 Jeff Dike wrote: > On Fri, Nov 16, 2007 at 04:00:22PM -0600, Rob Landley wrote: > > I wasn't cc'd, and missed it. I'd like to test this, do you have a > > link? (Or a bit more specificity than "a few weeks ago"?) > > Here are the three patches: > > http://marc.info/?l=linux-arch&m=119342916329510&w=2 Doesn't contain a patch. > http://marc.info/?l=linux-kernel&m=119342916529516&w=2 Doesn't apply to vanilla 2.6.23, it can't find two files and a couple other hunks failed. Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - 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] Clustering indirect blocks in Ext3
On Sun, Nov 18, 2007 at 07:52:36AM -0800, Abhishek Rai wrote: > Thanks for the suggestion Matt. > > It took me some time to get compilebench working due to the known > issue with drop_caches due to circular lock dependency between > j_list_lock and inode_lock (compilebench triggers drop_caches quite > frequently). Here are the results for compilebench run with options > "-i 30 -r 30". I repeated the test 5 times on each of vanilla and mc > configurations. > > Setup: 4 cpu, 8GB RAM, 400GB disk. > > Average vanilla results > == > intial create total runs 30 avg 46.49 MB/s (user 1.12s sys 2.25s) > create total runs 5 avg 12.90 MB/s (user 1.08s sys 1.97s) > patch total runs 4 avg 8.70 MB/s (user 0.60s sys 2.31s) > compile total runs 7 avg 21.44 MB/s (user 0.32s sys 2.95s) > clean total runs 4 avg 59.91 MB/s (user 0.05s sys 0.26s) > read tree total runs 2 avg 21.85 MB/s (user 1.12s sys 2.89s) > read compiled tree total runs 1 avg 23.47 MB/s (user 1.45s sys 4.89s) > delete tree total runs 2 avg 13.18 seconds (user 0.64s sys 1.02s) > no runs for delete compiled tree > stat tree total runs 4 avg 4.76 seconds (user 0.70s sys 0.50s) > stat compiled tree total runs 1 avg 7.84 seconds (user 0.74s sys 0.54s) > > Average metaclustering results > == > intial create total runs 30 avg 45.04 MB/s (user 1.13s sys 2.42s) > create total runs 5 avg 15.64 MB/s (user 1.08s sys 1.98s) > patch total runs 4 avg 10.50 MB/s (user 0.61s sys 3.11s) > compile total runs 7 avg 28.07 MB/s (user 0.33s sys 4.06s) > clean total runs 4 avg 83.27 MB/s (user 0.04s sys 0.27s) > read tree total runs 2 avg 21.17 MB/s (user 1.15s sys 2.91s) > read compiled tree total runs 1 avg 22.79 MB/s (user 1.38s sys 4.89s) > delete tree total runs 2 avg 9.23 seconds (user 0.62s sys 1.01s) > no runs for delete compiled tree > stat tree total runs 4 avg 4.72 seconds (user 0.71s sys 0.50s) > stat compiled tree total runs 1 avg 6.50 seconds (user 0.79s sys 0.53s) > > Overall, metaclustering does better than vanilla except in a few cases. Well it strikes me as about half up and half down, but the ups are indeed much more substantial. Looks quite promising. -- Mathematics is the supreme nostalgia of our time. - 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] Time-based RFC 4122 UUID generator
On Sun, 18 Nov 2007 20:38:21 +0100 Helge Deller <[EMAIL PROTECTED]> wrote: > Title: Add time-based RFC 4122 UUID generator > > The current Linux kernel currently contains the generate_random_uuid() > function, which creates - based on RFC 4122 - truly random UUIDs and > provides them to userspace through /proc/sys/kernel/random/boot_id and > /proc/sys/kernel/random/uuid. > > This patch additionally adds the "Time-based UUID" variant of RFC 4122, > with which userspace applications can easily get real unique time-based > UUIDs through /proc/sys/kernel/random/uuid_time. > A new /proc/sys/kernel/random/uuid_time_clockseq sysfs entry is available, > so that the clock_seq value can be retained across system bootups (which > is required by RFC 4122). > > The attached implementation uses getnstimeofday() to get very fine-grained > granularity. This helps, so that userspace tools can get a lot more UUIDs > (if needed) per time than before. > A mutex takes care of the proper locking against a mistaken double creation > of UUIDs for simultanious running processes. Who will use this feature, and for what? (In fact, who uses the existing UUID generators, and for what?) Thanks. - 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] Fix UML broken (was Re: User Mode Linux still broken in 2.6.23.1)
On Sun, Nov 18, 2007 at 02:17:49PM -0600, Rob Landley wrote: > On Saturday 17 November 2007 12:53:57 Jeff Dike wrote: > > On Fri, Nov 16, 2007 at 04:00:22PM -0600, Rob Landley wrote: > > > I wasn't cc'd, and missed it. I'd like to test this, do you have a > > > link? (Or a bit more specificity than "a few weeks ago"?) > > > > Here are the three patches: > > > > http://marc.info/?l=linux-arch&m=119342916329510&w=2 > > Doesn't contain a patch. Took me one minute to locate PATCH 1 + 2: http://marc.info/?l=linux-arch&m=119342916429513&w=2 http://marc.info/?l=linux-arch&m=119342916229500&w=2 Maybe this helps you. Sam - 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] Time-based RFC 4122 UUID generator
On Sun, Nov 18, 2007 at 01:05:03PM -0800, Andrew Morton wrote: > On Sun, 18 Nov 2007 20:38:21 +0100 Helge Deller <[EMAIL PROTECTED]> wrote: > > > Title: Add time-based RFC 4122 UUID generator > > > > The current Linux kernel currently contains the generate_random_uuid() > > function, which creates - based on RFC 4122 - truly random UUIDs and > > provides them to userspace through /proc/sys/kernel/random/boot_id and > > /proc/sys/kernel/random/uuid. > > > > This patch additionally adds the "Time-based UUID" variant of RFC 4122, > > with which userspace applications can easily get real unique time-based > > UUIDs through /proc/sys/kernel/random/uuid_time. > > A new /proc/sys/kernel/random/uuid_time_clockseq sysfs entry is available, > > so that the clock_seq value can be retained across system bootups (which > > is required by RFC 4122). > > > > The attached implementation uses getnstimeofday() to get very fine-grained > > granularity. This helps, so that userspace tools can get a lot more UUIDs > > (if needed) per time than before. > > A mutex takes care of the proper locking against a mistaken double creation > > of UUIDs for simultanious running processes. > > Who will use this feature, and for what? > > (In fact, who uses the existing UUID generators, and for what?) I use libuuid and I assume libuuid uses some uuid generator support from the kernel. libuuid comes from a package that Ted's maintain IIRC. I (my company) use uuid to uniquely identify objects in a distributed database. [Proprietary closed source stuff]. Sam - 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/
[HIFN 00/03]: RNG support v2
These patches add support for using the HIFN rng. The first patch changes the hwrng API to move waiting for availability of new random into the drivers. This allows to use driver-specific delays instead of the constant 10us delay used previously, increasing the HIFN speed from 2.5mbit to almost 15mbit, which is nearly the theoretical maximum. The second patch improves the PLL initialization by making the reference clock configurable and its speed known to the driver, which is needed to calculate the amount of time to wait between two RNG reads. Since there is no way to find out the frequency reliably (especially for the external clock), it adds some sane looking defaults and a module parameter to override it. It also changes the PLL initialization to follow the procedure described in the HIFN documentation. The third patch adds hw_random support. To use the rng, the HW_RANDOM config option has to be enabled. Running rngtest on the random number generator indicates that it works properly, with an average failure ratio of about 1:1000 at ~15mbit: rngtest: bits received from input: 315532 rngtest: FIPS 140-2 successes: 157621 rngtest: FIPS 140-2 failures: 129 rngtest: FIPS 140-2(2001-10-10) Monobit: 20 rngtest: FIPS 140-2(2001-10-10) Poker: 13 rngtest: FIPS 140-2(2001-10-10) Runs: 54 rngtest: FIPS 140-2(2001-10-10) Long run: 43 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=441.005; avg=14730.378; max=21510.187)Kibits/s rngtest: FIPS tests speed: (min=1.228; avg=55.967; max=62.742)Mibits/s rngtest: Program run time: 263373905 microseconds Changes this last posting: - follow PLL initialization procedure as described in the documentation - allow to specify clock source without a frequency - rename pll_ref module parameter to hifn_pll_ref - discard first rng value after initialization as suggested by the documentation - use ktime instead of get_cycles for delaying rng reads - adapt to the hwrng API changes - fix cleanup in initialization error path Michael, if you're OK with the RNG changes, I'd suggest that all three patches go through Herbert since the HIFN patches depend on that part. drivers/char/hw_random/amd-rng.c| 12 ++- drivers/char/hw_random/core.c | 24 + drivers/char/hw_random/geode-rng.c | 12 ++- drivers/char/hw_random/intel-rng.c | 15 ++- drivers/char/hw_random/omap-rng.c | 13 ++- drivers/char/hw_random/pasemi-rng.c | 14 ++- drivers/char/hw_random/via-rng.c| 19 ++-- drivers/crypto/hifn_795x.c | 192 ++- include/linux/hw_random.h |2 +- 9 files changed, 262 insertions(+), 41 deletions(-) Patrick McHardy (3): [HWRNG]: move status polling loop to data_present callbacks [HIFN]: Improve PLL initialization [HIFN]: Add support for using the random number generator - 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/
[HWRNG 01/03]: move status polling loop to data_present callbacks
[HWRNG]: move status polling loop to data_present callbacks
Handle waiting for new random within the drivers themselves, this allows to
use better suited timeouts for the individual rngs.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 5632554998aafc5605635f842bca50d5353cd9d4
tree 161324874febaf01d70ab2dd0b434db962108265
parent 92704884669e1af381feb364bc83985a63934c56
author Patrick McHardy <[EMAIL PROTECTED]> Sun, 18 Nov 2007 22:09:05 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Sun, 18 Nov 2007 22:09:05 +0100
drivers/char/hw_random/amd-rng.c| 12 ++--
drivers/char/hw_random/core.c | 24 ++--
drivers/char/hw_random/geode-rng.c | 12 ++--
drivers/char/hw_random/intel-rng.c | 15 ---
drivers/char/hw_random/omap-rng.c | 13 +++--
drivers/char/hw_random/pasemi-rng.c | 14 +++---
drivers/char/hw_random/via-rng.c| 19 ---
include/linux/hw_random.h |2 +-
8 files changed, 73 insertions(+), 38 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 556fd81..c422e87 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
@@ -52,11 +53,18 @@ MODULE_DEVICE_TABLE(pci, pci_tbl);
static struct pci_dev *amd_pdev;
-static int amd_rng_data_present(struct hwrng *rng)
+static int amd_rng_data_present(struct hwrng *rng, int wait)
{
u32 pmbase = (u32)rng->priv;
+ int data, i;
- return !!(inl(pmbase + 0xF4) & 1);
+ for (i = 0; i < 20; i++) {
+ data = !!(inl(pmbase + 0xF4) & 1);
+ if (data || !wait)
+ break;
+ udelay(10);
+ }
+ return data;
}
static int amd_rng_data_read(struct hwrng *rng, u32 *data)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 26a860a..0118b98 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -66,11 +66,11 @@ static inline void hwrng_cleanup(struct hwrng *rng)
rng->cleanup(rng);
}
-static inline int hwrng_data_present(struct hwrng *rng)
+static inline int hwrng_data_present(struct hwrng *rng, int wait)
{
if (!rng->data_present)
return 1;
- return rng->data_present(rng);
+ return rng->data_present(rng, wait);
}
static inline int hwrng_data_read(struct hwrng *rng, u32 *data)
@@ -94,8 +94,7 @@ static ssize_t rng_dev_read(struct file *filp, char __user
*buf,
{
u32 data;
ssize_t ret = 0;
- int i, err = 0;
- int data_present;
+ int err = 0;
int bytes_read;
while (size) {
@@ -107,21 +106,10 @@ static ssize_t rng_dev_read(struct file *filp, char
__user *buf,
err = -ENODEV;
goto out;
}
- if (filp->f_flags & O_NONBLOCK) {
- data_present = hwrng_data_present(current_rng);
- } else {
- /* Some RNG require some time between data_reads to
gather
-* new entropy. Poll it.
-*/
- for (i = 0; i < 20; i++) {
- data_present = hwrng_data_present(current_rng);
- if (data_present)
- break;
- udelay(10);
- }
- }
+
bytes_read = 0;
- if (data_present)
+ if (hwrng_data_present(current_rng,
+ !(filp->f_flags & O_NONBLOCK)))
bytes_read = hwrng_data_read(current_rng, &data);
mutex_unlock(&rng_mutex);
diff --git a/drivers/char/hw_random/geode-rng.c
b/drivers/char/hw_random/geode-rng.c
index 8e8658d..fed4ef5 100644
--- a/drivers/char/hw_random/geode-rng.c
+++ b/drivers/char/hw_random/geode-rng.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
@@ -61,11 +62,18 @@ static int geode_rng_data_read(struct hwrng *rng, u32 *data)
return 4;
}
-static int geode_rng_data_present(struct hwrng *rng)
+static int geode_rng_data_present(struct hwrng *rng, int wait)
{
void __iomem *mem = (void __iomem *)rng->priv;
+ int data, i;
- return !!(readl(mem + GEODE_RNG_STATUS_REG));
+ for (i = 0; i < 20; i++) {
+ data = !!(readl(mem + GEODE_RNG_STATUS_REG));
+ if (data || !wait)
+ break;
+ udelay(10);
+ }
+ return data;
}
diff --git a/drivers/char/hw_random/intel-rng.c
b/drivers/char/hw_random/intel-rng.c
index 753f460..5cc651e 100644
--- a/drivers/char/hw_random/intel-rng.c
+++ b/drivers/char/hw_random/intel-rng.c
@@ -29,6 +29,7 @@
#include
[HIFN 02/03]: Improve PLL initialization
[HIFN]: Improve PLL initialization
The current PLL initalization has a number of deficiencies:
- uses fixed multiplier of 8, which overclocks the chip when using a
reference clock that operates at frequencies above 33MHz. According
to a comment in the BSD source, this is true for the external clock
on almost all every board.
- writes to a reserved bit
- doesn't follow the initialization procedure specified in chapter
6.11.1 of the HIFN hardware users guide
- doesn't allow to use the PCI clock
This patch adds a module parameter to specify the reference clock
(pci or external) and its frequency and uses that to calculate the
optimum multiplier to reach the maximal speed. By default it uses
the external clock and assumes a speed of 66MHz, which effectively
halfs the frequency currently used.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 70467fae3a656562f86adefdfe6d54e3ca20feeb
tree 9fc347d453e04e21f243693ede743f6a8e280ef2
parent 5632554998aafc5605635f842bca50d5353cd9d4
author Patrick McHardy <[EMAIL PROTECTED]> Sun, 18 Nov 2007 22:09:17 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Sun, 18 Nov 2007 22:09:17 +0100
drivers/crypto/hifn_795x.c | 110 +++-
1 files changed, 108 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index bf817d4..de594bc 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#include
#include
@@ -47,6 +48,11 @@
#define dprintk(f, a...) do {} while (0)
#endif
+static char hifn_pll_ref[sizeof("extNNN")] = "ext";
+module_param_string(hifn_pll_ref, hifn_pll_ref, sizeof(hifn_pll_ref), 0444);
+MODULE_PARM_DESC(hifn_pll_ref,
+"PLL reference clock (pci[freq] or ext[freq], default ext)");
+
static atomic_t hifn_dev_number;
#define ACRYPTO_OP_DECRYPT 0
@@ -286,7 +292,26 @@ static atomic_t hifn_dev_number;
#defineHIFN_DMACNFG_DMARESET 0x0002 /* DMA Reset # */
#defineHIFN_DMACNFG_MSTRESET 0x0001 /* Master Reset # */
-#defineHIFN_PLL_7956 0x1d18 /* 7956 PLL config
value */
+/* PLL configuration register */
+#define HIFN_PLL_REF_CLK_HBI 0x /* HBI reference clock */
+#define HIFN_PLL_REF_CLK_PLL 0x0001 /* PLL reference clock */
+#define HIFN_PLL_BP0x0002 /* Reference clock bypass */
+#define HIFN_PLL_PK_CLK_HBI0x /* PK engine HBI clock */
+#define HIFN_PLL_PK_CLK_PLL0x0008 /* PK engine PLL clock */
+#define HIFN_PLL_PE_CLK_HBI0x /* PE engine HBI clock */
+#define HIFN_PLL_PE_CLK_PLL0x0010 /* PE engine PLL clock */
+#define HIFN_PLL_RESERVED_10x0400 /* Reserved bit, must be 1 */
+#define HIFN_PLL_ND_SHIFT 11 /* Clock multiplier shift */
+#define HIFN_PLL_ND_MULT_2 0x /* PLL clock multiplier 2 */
+#define HIFN_PLL_ND_MULT_4 0x0800 /* PLL clock multiplier 4 */
+#define HIFN_PLL_ND_MULT_6 0x1000 /* PLL clock multiplier 6 */
+#define HIFN_PLL_ND_MULT_8 0x1800 /* PLL clock multiplier 8 */
+#define HIFN_PLL_ND_MULT_100x2000 /* PLL clock multiplier 10 */
+#define HIFN_PLL_ND_MULT_120x2800 /* PLL clock multiplier 12 */
+#define HIFN_PLL_IS_1_80x /* charge pump (mult.
1-8) */
+#define HIFN_PLL_IS_9_12 0x0001 /* charge pump (mult. 9-12) */
+
+#define HIFN_PLL_FCK_MAX 266 /* Maximum PLL frequency */
/* Public key reset register (HIFN_1_PUB_RESET) */
#defineHIFN_PUBRST_RESET 0x0001 /* reset public/rng
unit */
@@ -871,6 +896,64 @@ static void hifn_init_dma(struct hifn_device *dev)
dma->cmdk = dma->srck = dma->dstk = dma->resk = 0;
}
+/*
+ * Initialize the PLL. We need to know the frequency of the reference clock
+ * to calculate the optimal multiplier. For PCI we assume 66MHz, since that
+ * allows us to operate without the risk of overclocking the chip. If it
+ * actually uses 33MHz, the chip will operate at half the speed, this can be
+ * overriden by specifying the frequency as module parameter (pci33).
+ *
+ * Unfortunately the PCI clock is not very suitable since the HIFN needs a
+ * stable clock and the PCI clock frequency may vary, so the default is the
+ * external clock. There is no way to find out its frequency, we default to
+ * 66MHz since according to Mike Ham of HiFn, almost every board in existence
+ * has an external crystal populated at 66MHz.
+ */
+static void hifn_init_pll(struct hifn_device *dev)
+{
+ unsigned int freq, m;
+ u32 pllcfg;
+
+ pllcfg = HIFN_1_PLL | HIFN_PLL_RESERVED_1;
+
+ if (strncmp(hifn_pll_ref, "ext", 3) == 0)
+ pllcfg |= HIFN_PLL_REF_CLK_PLL;
+ else
+ pllcfg |= HIFN_PLL_REF_CLK_HBI;
+
+
[HIFN 03/03]: Add support for using the random number generator
[HIFN]: Add support for using the random number generator
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 352a65d036f53c1e124bef4205d6fcedb78eac2c
tree 190bb0b4a1795e55096552f743af996df2766070
parent 70467fae3a656562f86adefdfe6d54e3ca20feeb
author Patrick McHardy <[EMAIL PROTECTED]> Sun, 18 Nov 2007 22:09:17 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Sun, 18 Nov 2007 22:09:17 +0100
drivers/crypto/hifn_795x.c | 82 +++-
1 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index de594bc..1a19700 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -31,6 +31,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -458,6 +460,14 @@ struct hifn_device
struct crypto_queue queue;
struct list_headalg_list;
+
+ unsigned intpk_clk_freq;
+
+#if defined(CONFIG_HW_RANDOM) || defined(CONFIG_HW_RANDOM_MODULE)
+ unsigned intrng_wait_time;
+ ktime_t rngtime;
+ struct hwrngrng;
+#endif
};
#defineHIFN_D_LENGTH 0x
@@ -785,6 +795,56 @@ static struct pci2id {
}
};
+#if defined(CONFIG_HW_RANDOM) || defined(CONFIG_HW_RANDOM_MODULE)
+static int hifn_rng_data_present(struct hwrng *rng, int wait)
+{
+ struct hifn_device *dev = (struct hifn_device *)rng->priv;
+ s64 nsec;
+
+ nsec = ktime_to_ns(ktime_sub(ktime_get(), dev->rngtime));
+ nsec -= dev->rng_wait_time;
+ if (nsec <= 0)
+ return 1;
+ if (!wait)
+ return 0;
+ ndelay(nsec);
+ return 1;
+}
+
+static int hifn_rng_data_read(struct hwrng *rng, u32 *data)
+{
+ struct hifn_device *dev = (struct hifn_device *)rng->priv;
+
+ *data = hifn_read_1(dev, HIFN_1_RNG_DATA);
+ dev->rngtime = ktime_get();
+ return 4;
+}
+
+static int hifn_register_rng(struct hifn_device *dev)
+{
+ /*
+* We must wait at least 256 Pk_clk cycles between two reads of the rng.
+*/
+ dev->rng_wait_time = DIV_ROUND_UP(NSEC_PER_SEC, dev->pk_clk_freq) *
+ 256;
+
+ dev->rng.name = dev->name;
+ dev->rng.data_present = hifn_rng_data_present,
+ dev->rng.data_read = hifn_rng_data_read,
+ dev->rng.priv = (unsigned long)dev;
+
+ return hwrng_register(&dev->rng);
+}
+
+static void hifn_unregister_rng(struct hifn_device *dev)
+{
+ hwrng_unregister(&dev->rng);
+}
+#else
+#define hifn_register_rng(dev) 0
+#define hifn_unregister_rng(dev)
+#endif
+
static int hifn_init_pubrng(struct hifn_device *dev)
{
int i;
@@ -820,6 +880,11 @@ static int hifn_init_pubrng(struct hifn_device *dev)
dprintk("Chip %s: RNG engine has been successfully initialised.\n",
dev->name);
+#if defined(CONFIG_HW_RANDOM) || defined(CONFIG_HW_RANDOM_MODULE)
+ /* First value must be discarded */
+ hifn_read_1(dev, HIFN_1_RNG_DATA);
+ dev->rngtime = ktime_get();
+#endif
return 0;
}
@@ -952,6 +1017,14 @@ static void hifn_init_pll(struct hifn_device *dev)
/* Switch the engines to the PLL */
hifn_write_1(dev, HIFN_1_PLL, pllcfg |
HIFN_PLL_PK_CLK_PLL | HIFN_PLL_PE_CLK_PLL);
+
+ /*
+* The Fpk_clk runs at half the total speed. Its frequency is needed to
+* calculate the minimum time between two reads of the rng. Since 33MHz
+* is actually 33.333... we overestimate the frequency here, resulting
+* in slightly larger intervals.
+*/
+ dev->pk_clk_freq = 100 * (freq + 1) * m / 2;
}
static void hifn_init_registers(struct hifn_device *dev)
@@ -2609,10 +2682,14 @@ static int hifn_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
if (err)
goto err_out_stop_device;
- err = hifn_register_alg(dev);
+ err = hifn_register_rng(dev);
if (err)
goto err_out_stop_device;
+ err = hifn_register_alg(dev);
+ if (err)
+ goto err_out_unregister_rng;
+
INIT_DELAYED_WORK(&dev->work, hifn_work);
schedule_delayed_work(&dev->work, HZ);
@@ -2622,6 +2699,8 @@ static int hifn_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
return 0;
+err_out_unregister_rng:
+ hifn_unregister_rng(dev);
err_out_stop_device:
hifn_reset_dma(dev, 1);
hifn_stop_device(dev);
@@ -2662,6 +2741,7 @@ static void hifn_remove(struct pci_dev *pdev)
cancel_delayed_work(&dev->work);
flush_scheduled_work();
+ hifn_unregister_rng(dev);
hifn_unregister_alg(dev);
hifn_reset_dma(dev, 1);
hifn_stop_device(dev);
-
To unsubscribe from this list: s
Re: [PATCH] drivers/ide/ide-probe.c Skip ide_wait_not_busy on noprobe-disks. was: [PATCH][RESUBMIT] drivers/ide/ide-probe.c, kernel 2.6.23.1
On Friday 16 November 2007, Jonas Stare wrote: > There is a problem in some hardware where the kernel will stall for > 35 seconds waiting for disks that dont exist. This patch will skip > waiting for the BSY-bit on ide-drives to go away if you set > hdx=noprobe as a kernel option and the disk is not marked > as 'present' (like when you set the geometry by hand). > > If no noprobe-option is set the code will work (more or less) as the > original but if set the code will skip the ide_wait_not_busy() for that > drive. Even if there would be a drive there and it is still BSY > afterwards it should not matter since it isn't probed for later. > > (The code also honors the MAX_DRIVES variable instead of assuming that > there will be two harddrives on the bus.) > > > Signed-off-by: Jonas Stare <[EMAIL PROTECTED]> Thanks! PS There were still some whitespace problems (all tabs were replaced by spaces) so I just applied it by hand (and made few minor cleanups while at it). Bart - 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] Time-based RFC 4122 UUID generator
On Sunday 18 November 2007, Andrew Morton wrote: > On Sun, 18 Nov 2007 20:38:21 +0100 Helge Deller <[EMAIL PROTECTED]> wrote: > > > Title: Add time-based RFC 4122 UUID generator > > > > The current Linux kernel currently contains the generate_random_uuid() > > function, which creates - based on RFC 4122 - truly random UUIDs and > > provides them to userspace through /proc/sys/kernel/random/boot_id and > > /proc/sys/kernel/random/uuid. > > > > This patch additionally adds the "Time-based UUID" variant of RFC 4122, > > with which userspace applications can easily get real unique time-based > > UUIDs through /proc/sys/kernel/random/uuid_time. > > A new /proc/sys/kernel/random/uuid_time_clockseq sysfs entry is available, > > so that the clock_seq value can be retained across system bootups (which > > is required by RFC 4122). > > > > The attached implementation uses getnstimeofday() to get very fine-grained > > granularity. This helps, so that userspace tools can get a lot more UUIDs > > (if needed) per time than before. > > A mutex takes care of the proper locking against a mistaken double creation > > of UUIDs for simultanious running processes. > Who will use this feature, and for what? > (In fact, who uses the existing UUID generators, and for what?) Current users I know of (but there are more): - e2fsprogs uses it e.g. to create unique UUIDs for disks (it ships an own library for that) - http://commons.apache.org/sandbox/id/uuid.html uses it with own libraries - SAP Netweaver on Linux uses it (http://www.sap.com/platform/netweaver/index.epx) I'm mostly interested in fixing problems I see with SAP (I'm working for SAP). SAP Netweaver often needs during a very short time frame lots of unique UUIDs (to reference the data afterwards) when new data is imported into the database. Main problem with current implementations is, is that they don't 100% guarantee uniqness of the generated UUIDs. Sometimes, esp. on very fast multi-processor machines, double UUIDs are generated and returned to the application which is very bad and may result in unreliable behaviour. Current implemenations use userspace-libraries. In userspace you e.g. can't easily protect the uniquness of a UUID against other running _processes_. If you try do, you'll need to do locking e.g. with shared memory, which can get very expensive. My in-kernel implementation does guarantee the uniquness through the mutex. The problem will get even worse with virtualization technologies like XEN and containers. There it's even impossible to protect against processes in other VMs. Another user which could benefit from it are embedded devices. They could drop their userspace-implementations in favour of this smaller kernel version to create UUIDs for their disks, using it in the webservers, ... Best regards, Helge PS: I did created bugreports against the e2fsprogs userspace implementation at Red Hat and Novell (only accessible for RH/Novell employees), but as I explained above, the userspace-implementation may not be sufficient: https://bugzilla.redhat.com/show_bug.cgi?id=233471 https://bugzilla.redhat.com/show_bug.cgi?id=218606 https://bugzilla.novell.com/show_bug.cgi?id=189640 - 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] Time-based RFC 4122 UUID generator
Sam Ravnborg wrote: > On Sun, Nov 18, 2007 at 01:05:03PM -0800, Andrew Morton wrote: >> On Sun, 18 Nov 2007 20:38:21 +0100 Helge Deller <[EMAIL PROTECTED]> wrote: >> >> > Title: Add time-based RFC 4122 UUID generator >> > >> > The current Linux kernel currently contains the generate_random_uuid() >> > function, which creates - based on RFC 4122 - truly random UUIDs and >> > provides them to userspace through /proc/sys/kernel/random/boot_id and >> > /proc/sys/kernel/random/uuid. >> > >> > This patch additionally adds the "Time-based UUID" variant of RFC 4122, >> > with which userspace applications can easily get real unique time-based >> > UUIDs through /proc/sys/kernel/random/uuid_time. >> > A new /proc/sys/kernel/random/uuid_time_clockseq sysfs entry is >> > available, so that the clock_seq value can be retained across system >> > bootups (which is required by RFC 4122). >> > >> > The attached implementation uses getnstimeofday() to get very >> > fine-grained granularity. This helps, so that userspace tools can get a >> > lot more UUIDs (if needed) per time than before. >> > A mutex takes care of the proper locking against a mistaken double >> > creation of UUIDs for simultanious running processes. >> >> Who will use this feature, and for what? >> >> (In fact, who uses the existing UUID generators, and for what?) > > I use libuuid and I assume libuuid uses some uuid generator support > from the kernel. No, it does not. It's pure userspace and may produce double UUIDs. > libuuid comes from a package that Ted's maintain IIRC. > > I (my company) use uuid to uniquely identify objects in a distributed > database. > [Proprietary closed source stuff]. Same here. Helge - 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/
radeonfb i2c regression post-2.6.18.
Hi folks, I'm using an Apple Cinema Display connected via DVI to an Apple Mac Mini with Radeon 9200 graphics. This used to work fine, but with kernels >= 2.6.19, the monitor powers off as soon as the framebuffer is initialised, making for a less than usable system. I've tested with 2.6.(19|2[012]), and I didn't see any related changes in 2.6.23. The breakage occured in this commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7a45093b7caa9d3d5421274b4ba80fba5da17e19 Specifically, these lines: - /* Release the DDC lines when done or the Apple Cinema HD display -* will switch off -*/ - OUTREG(reg, INREG(reg) & ~(VGA_DDC_CLK_OUT_EN | VGA_DDC_DATA_OUT_EN)); - (void)INREG(reg); + u8 *edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter); BenH later applied a fix: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4f71c5de19c27f2198105d3b26b398494d5c353b but I'm not sure if this is related to the above, or was for a separate problem. Either way, the monitor is still getting powered off. Due to the code reorganisation when the i2c stuff got moved into the generic fbmon.c, I'm not sure where the workaround needs putting back (if indeed this is where the problem lies). I'm booting with video=ofonly to get a working system; video=radeonfb:[EMAIL PROTECTED] (with or without the additional parameters) always results in a dead monitor as soon as the framebuffer is set up. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpjlY5fHJLzJ.pgp Description: PGP signature
Re: apm emulation driver broken ?
On Sunday, 18 of November 2007, Franck Bui-Huu wrote: > Rafael J. Wysocki wrote: > > On Saturday, 17 of November 2007, Franck Bui-Huu wrote: > >> ok so now we agreed on this point, can we assert that a user > >> land thread waiting for an event in an UNINTERRUPTIBLE state > >> will prevent a suspend to happen ? > > > > Yes. > > > > So this driver seems really broken and actually I'm wondering if > it's used by anyone... Well, it doesn't seem so. > See the call to wait_even() made by apm_ioctl(). If any processes > run this, it will prevent the system to suspend... True, but does it actually happen in practice? > And no, I don't know why call wait_event() is called. I hope somebody knows. :-) At this point the second branch of the "if (as->suspend_state == SUSPEND_READ)" can be fixed by replacing wait_event_interruptible() with wait_event_freezable(), but the fix for the first branch depends on whether or not the wait_event() is really necessary. If it can be replaced with an interruptible sleep, we can use wait_event_freezable() in this case too. Otherwise, the only woking fix would be to reintroduce the PF_NOFREEZE in there. Honestly, I'm leaning towards replacing wait_event() in apm_ioctl() with wait_event_freezable() and seeing what happens ... Greetings, Rafael - 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: 2.6.24-rc2 XFS nfsd hang
On Sun, 18 Nov 2007, Justin Piszcz wrote: I wonder why so few people are seeing this, I'd have assumed that NFSv3 && XFS is not sooo exotic... Still on 2.6.23.x here (also use nfsv3 + xfs). So, it's the "too few people are testing -rc kernels" issue again :( Christian. -- BOFH excuse #118: the router thinks its a printer. - 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: broken suspend [Was: 2.6.24-rc2-mm1]
On Sunday, 18 of November 2007, Jiri Slaby wrote: > On 11/18/2007 06:07 PM, Alan Stern wrote: > > You'll get more useful results if you redo your changes to > > notifier_call_chain(). Have it print out the address of the routine > > _before_ making the call, and don't limit it to 20. That way you'll > > know exactly which notifier routine ends up hanging. > > The problem is, that notifier_call_chain is called again and again zillion > times > by somebody else... You can use a global variable to switch the logging only before the CPU hotunplug done by the suspend code. You just need to hack disable_nonboot_cpus() for that. - 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: broken suspend [Was: 2.6.24-rc2-mm1]
On 11/18/2007 11:27 PM, Rafael J. Wysocki wrote: > You can use a global variable to switch the logging only before the CPU > hotunplug done by the suspend code. You just need to hack > disable_nonboot_cpus() for that. If I understand you correctly, that's what BUBAK variable is there for. But it is still called again and again while the suspend code runs... regards, -- Jiri Slaby ([EMAIL PROTECTED]) Faculty of Informatics, Masaryk University - 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: laptop reboots right after hibernation
On Sunday, 18 of November 2007, Tomas Carnecky wrote: > Pavel Machek wrote: > > Hi! > > > >> echo disk > /sys/power/state > >> > >> successfully saves that state to the disk, but just as the laptop is > >> about to turn itself off, it reboots (successfully, so the > >> hibernation/resume process works well, even with X running! which is > >> awesome :) ). But I'd rather like the computer turned off after I > >> hibernate it. Where could the problem be? > >> > >> It's a new laptop, TP X61 tablet, I tried ubuntu (7.10, gutsy) for a few > >> days, both suspend and hibernate worked there (with one or two crashes, > >> probably due to X, I've read that the intel driver got some > >> suspend/resume improvements recently). Now I'm running gentoo, kernel > >> 2.6.24-rc2. I'm using newer versions of almost all software now compared > >> to the ubuntu system. > > > > If it works in older ubuntu, you can probably do bisect. Does normal > > shutdown work? You can try platform vs. shutdown mode... > > I forgot, normal shutdown (init 0) works, the 'shutdown' command fails > somewhere in the gentoo init scripts, but that has nothing to do with > the kernel. 'init 6' also works. Both regardless of where the notebook > is (dock or outside). Please verify if you have the ehci_hcd driver loaded when the box is in the dock. If so, please try to unload it before hibernation and see if the box will reboot. Greetings, Rafael - 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: Need help with register_page_fault_notifier() replacement in 2.6.24
On Sun, 18 Nov 2007 12:40:16 -0500 Pavel Roskin <[EMAIL PROTECTED]> wrote: > Hello! > > I'm trying to update a special tracing version of madwifi (driver for > Atheros wireless cards) for Linux 2.6.24. This version was created to > help reverse engineering the non-free part of the driver (also known > as HAL, hardware abstraction layer). > > The problem is that functions register_page_fault_notifier() and > unregister_page_fault_notifier() are gone in the current kernel git > repository. > > They are needed to intercept access to the card by causing page fault > and intercepting it. > > Those functions were removed on i386 platform because kprobes now > registers the flat handler directly. The log says that other callers > are supposed to use kprobes now. > > But what would be the right way to do it? I can intercept > do_page_fault() with kprobes, but that looks unsafe, since > do_page_fault() is used by kprobes internally. > > Or maybe I should install a fault handler with register_kprobe()? The > problem is, it is only called for faults in kp->pre_handler and > kp->post_handler and for single-stepping. I don't want to single-step > anything, and moving all driver functionality in kp->pre_handler would > be strange. > > Perhaps I'm missing something obvious. Any help will be appreciated. > if it's just for a custom case (as it sounds like).. a simple small change to the pagefault handler sounds like the easiest thing to do... (eg just a direct function call to what would have been your notifier) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - 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/
