RE: 2.6 partition support driver methods
Dear Corbet, After loading my module that is partitioned supported & having defined a single FAT partition with #mkfs -tvfat /dev/tfa0 sfdisk show the disk info as follows. # sfdisk -l /dev/taf0 Disk /dev/tfa0: 448 cylinders, 2 heads, 32 sectors/track Units = cylinders of 32768 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls#blocks Id System /dev/tfa0p1 0 - 0 00 Empty /dev/tfa0p2 0 - 0 00 Empty /dev/tfa0p3 0 - 0 00 Empty /dev/tfa0p4 0 - 0 00 Empty Dear Corbet, Here are the details u might be interested in. I have explained my physical node creation logic below. #Cat/proc/partitions major minor #blocks name 3 0 78184008 hda 3 16144831 hda1 3 2 10241437 hda2 3 31285200 hda3 3 4 1 hda4 3 5 10241406 hda5 252 0 14336 tfa0 Can you just please explain me what can infer from the cat /proc/partitions? Do we expect all the 4 partitions to be show here? My node creation method is simple Kern code - gDisk->gd = alloc_disk(4); /* 3 -> 3 partitions */ gDisk->gd->first_minor = (iSock * 4); i.e. iSock = device no [0-3] ( 4 devices) Physical nodes design - To support partitions on device 0 - mknod /dev/tfa0 b 252 0 mknod /dev/tfa1 b 252 1 mknod /dev/tfa2 b 252 2 mknod /dev/tfa3 b 252 3 To support partitions on device 1 - mknod /dev/tfa4 b 252 4 mknod /dev/tfa5 b 252 5 mknod /dev/tfa6 b 252 6 mknod /dev/tfa7 b 252 7 To support partitions on device 2 - mknod /dev/tfa8 b 252 8 mknod /dev/tfa9 b 252 9 mknod /dev/tfa10 b 252 10 mknod /dev/tfa11 b 252 11 To support partitions on device 3 - mknod /dev/tfa12 b 252 12 mknod /dev/tfa13 b 252 13 mknod /dev/tfa14 b 252 14 mknod /dev/tfa15 b 252 15 Thanks & Regards, Mukund Jampala >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Sent: Thursday, August 04, 2005 8:09 PM >To: Mukund JB. >Cc: linux-kernel@vger.kernel.org >Subject: Re: 2.6 partition support driver methods > >Mukund JB. <[EMAIL PROTECTED]> wrote: > >> BUT, when a card is inserted in the socket 3, I am NOT able to mount and >> it says. >> Mount: /dev/tfa12 is not a valid block device >> >> Can you convey me where exactly I am missing or why is it failing? > >First step would be to look in /proc/partitions (and the system logfile) >to get an idea of what the kernel thinks is there. When you call >add_disk(), the kernel should emit some messages noting the partitions >that it sees. My guess is a mismatch of minor numbers between your >device nodes and what the kernel sees (it's hard for me to make complete >sense out of your minor number logic), but I could be wrong. > >jon - 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/
2.6 select doesn't notify readablity of /proc/loadavg.
Hi. select in Linux 2.6.12.3 doesn't notify readability of
/proc/loadavg and several other files under /proc.
It is reproducible as follows. The sample program follow blocks
because select doesn't notify readability.
% uname -a
Linux debiansarge 2.6.12.3 #1 Thu Aug 4 20:23:16 JST 2005 i686 GNU/Linux
% cat /proc/version
Linux version 2.6.12.3 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian
1:3.3.5-13)) #1 Thu Aug 4 20:23:16 JST 2005
% cat t.c
#include
#include
#include
#include
#include
int main(int argc, char **argv)
{
int fd, ret;
fd_set readfds;
fd = open(argv[1], O_RDONLY);
if (fd == -1) { perror("open"); exit(1); }
FD_ZERO();
FD_SET(fd, );
ret = select(fd+1, , NULL, NULL, NULL);
printf("select returns %d\n", ret);
return 0;
}
% gcc t.c
% ./a.out /proc/loadavg
This program blocks here.
/proc/loadavg can be read by cat.
% ./a.out /proc/loadavg
^C
% cat /proc/loadavg
0.00 0.00 0.00 2/36 2597
Also, /proc/cmdline, /proc/devices, /proc/execdomains, /proc/fb,
/proc/filesystems, /proc/locks, /proc/meminfo, /proc/uptime and
/proc/version are blocks too.
Is this behaviour intentional?
The output of ver_linux is follows.
% sh scripts/ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux debiansarge 2.6.12.3 #1 Thu Aug 4 20:23:16 JST 2005 i686 GNU/Linux
Gnu C 3.3.5
Gnu make 3.80
binutils 2.15
util-linux 2.12p
mount 2.12p
module-init-tools 3.2-pre1
e2fsprogs 1.37
reiserfsprogs line
reiser4progs line
nfs-utils 1.0.6
Linux C Library2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.2.1
Net-tools 1.60
Console-tools 0.2.3
Sh-utils 5.2.1
Modules Loaded md5 ipv6 evdev ehci_hcd usbcore shpchp pci_hotplug
intel_agp piix pcnet32 mii crc32 agpgart ide_disk ide_cd cdrom ide_core rtc unix
Note that select notify readability of /proc/loadavg on Linux 2.4.20.
% uname -a
Linux serein 2.4.20-686 #1 Mon Jan 13 22:22:30 EST 2003 i686 GNU/Linux
% ./a.out /proc/loadavg
select returns 1
--
Tanaka Akira
-
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] kernel: use kcalloc instead kmalloc/memset
Pekka Enberg <[EMAIL PROTECTED]> wrote: > > This patch converts kernel/ to use kcalloc instead of kmalloc/memset. > grr. > -struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL); > +struct resource *res = kcalloc(1, sizeof(*res), GFP_KERNEL); Notice how every conversion you did passes in `1' in the first argument? And that's going to happen again and again and again. Each callsite needlessly passing that silly third argument, adding more kernel text. If we're going to do this, we should add a two-arg helper function first, and use that, no? - 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] kernel: use kcalloc instead kmalloc/memset
This patch converts kernel/ to use kcalloc instead of kmalloc/memset.
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
intermodule.c |3 +--
params.c |4 ++--
power/pm.c|3 +--
resource.c|3 +--
workqueue.c |3 +--
5 files changed, 6 insertions(+), 10 deletions(-)
Index: 2.6/kernel/resource.c
===
--- 2.6.orig/kernel/resource.c
+++ 2.6/kernel/resource.c
@@ -430,10 +430,9 @@ EXPORT_SYMBOL(adjust_resource);
*/
struct resource * __request_region(struct resource *parent, unsigned long
start, unsigned long n, const char *name)
{
- struct resource *res = kmalloc(sizeof(*res), GFP_KERNEL);
+ struct resource *res = kcalloc(1, sizeof(*res), GFP_KERNEL);
if (res) {
- memset(res, 0, sizeof(*res));
res->name = name;
res->start = start;
res->end = start + n - 1;
Index: 2.6/kernel/intermodule.c
===
--- 2.6.orig/kernel/intermodule.c
+++ 2.6/kernel/intermodule.c
@@ -39,7 +39,7 @@ void inter_module_register(const char *i
struct list_head *tmp;
struct inter_module_entry *ime, *ime_new;
- if (!(ime_new = kmalloc(sizeof(*ime), GFP_KERNEL))) {
+ if (!(ime_new = kcalloc(1, sizeof(*ime), GFP_KERNEL))) {
/* Overloaded kernel, not fatal */
printk(KERN_ERR
"Aiee, inter_module_register: cannot kmalloc entry for
'%s'\n",
@@ -47,7 +47,6 @@ void inter_module_register(const char *i
kmalloc_failed = 1;
return;
}
- memset(ime_new, 0, sizeof(*ime_new));
ime_new->im_name = im_name;
ime_new->owner = owner;
ime_new->userdata = userdata;
Index: 2.6/kernel/params.c
===
--- 2.6.orig/kernel/params.c
+++ 2.6/kernel/params.c
@@ -542,8 +542,8 @@ static void __init kernel_param_sysfs_se
{
struct module_kobject *mk;
- mk = kmalloc(sizeof(struct module_kobject), GFP_KERNEL);
- memset(mk, 0, sizeof(struct module_kobject));
+ mk = kcalloc(1, sizeof(struct module_kobject), GFP_KERNEL);
+ BUG_ON(!mk);
mk->mod = THIS_MODULE;
kobj_set_kset_s(mk, module_subsys);
Index: 2.6/kernel/power/pm.c
===
--- 2.6.orig/kernel/power/pm.c
+++ 2.6/kernel/power/pm.c
@@ -60,9 +60,8 @@ struct pm_dev *pm_register(pm_dev_t type
unsigned long id,
pm_callback callback)
{
- struct pm_dev *dev = kmalloc(sizeof(struct pm_dev), GFP_KERNEL);
+ struct pm_dev *dev = kcalloc(1, sizeof(struct pm_dev), GFP_KERNEL);
if (dev) {
- memset(dev, 0, sizeof(*dev));
dev->type = type;
dev->id = id;
dev->callback = callback;
Index: 2.6/kernel/workqueue.c
===
--- 2.6.orig/kernel/workqueue.c
+++ 2.6/kernel/workqueue.c
@@ -310,10 +310,9 @@ struct workqueue_struct *__create_workqu
BUG_ON(strlen(name) > 10);
- wq = kmalloc(sizeof(*wq), GFP_KERNEL);
+ wq = kcalloc(1, sizeof(*wq), GFP_KERNEL);
if (!wq)
return NULL;
- memset(wq, 0, sizeof(*wq));
wq->name = name;
/* We don't need the distraction of CPUs appearing and vanishing. */
-
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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Fri, 5 Aug 2005 01:03 am, Vojtech Pavlik wrote: > On Wed, Aug 03, 2005 at 04:23:59PM +0200, Jan De Luyck wrote: > > On Wednesday 03 August 2005 14:14, Con Kolivas wrote: > > > On Wed, 3 Aug 2005 21:54, Jan De Luyck wrote: > > > > On Wednesday 03 August 2005 07:59, Con Kolivas wrote: > > > > > This is the dynamic ticks patch for i386 as written by Tony Lindgen > > > > > <[EMAIL PROTECTED]> and Tuukka Tikkanen > > > > > <[EMAIL PROTECTED]>. Patch for 2.6.13-rc5 > > > > > > > > Compiles and runs ok here. > > > > > > > > Is there actually any timer frequency that's advisable to set as > > > > maximum? (in the kernel config) > > > > > > I'd recommend 1000. > > > > Thanks. Currently the system - under X, KDE, no artsd, bottoms at around > > 300HZ. In total single mode with every module unloaded that I can unload > > it stops around 22HZ. > > > > I guess I'll have to go hunting whatever thing is causing the pollings. > > no timertop yet, I guess? :P > > i8042 runs a steady periodic 20Hz timer. You can make it slower to get > even the total low lower, and it will not affect performance under > normal (sane hardware) circumstances. Indeed and this patch (safely tried at home but serves no useful purpose really) confirms a reasonable drop without problems. After this, only fbcon polls at a similar rate (HZ/5). Of interest to those using an ondemand scaling governor, now that we have timertop, I have found that the default ondemand settings lead to delayed_work_timer_fn at about 140Hz and this can be dropped substantially by slowing the rate of polling (and subsequently slowing the speed with which the ondemand governor responds) down to <25 by echo 10 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate (the default is 1 and the value is confusing as the rate goes down as you increase this value). Cheers, Con Index: linux-2.6.13-rc5-ck2/drivers/input/serio/i8042.h === --- linux-2.6.13-rc5-ck2.orig/drivers/input/serio/i8042.h 2005-07-06 16:56:52.0 +1000 +++ linux-2.6.13-rc5-ck2/drivers/input/serio/i8042.h 2005-08-05 15:03:49.0 +1000 @@ -44,7 +44,7 @@ * polling. */ -#define I8042_POLL_PERIOD HZ/20 +#define I8042_POLL_PERIOD HZ/5 /* * Status register bits.
re: make modules Segfault
George Van Tuyl <[EMAIL PROTECTED]> wrote: > gcc: Internal error: Segmentation fault (program cpp0) > ... > make[3]: Leaving directory `/usr/src/linux-2.4.31/drivers/net/wan' > ... > Gnu C 2.96 > ... cpu family: 6 model : 4 model name: AMD Athlon(tm) Processor stepping : 4 cpu MHz : 1400.110 ... > I expect you to tell me to upgrade everything. Nah. Stop overclocking, and *then* upgrade everything :-) Seriously, it seems like your machine is flaky. And even if it were a kernel source problem, gcc should never have an internal error. But gcc-2.96 is so old that it's not supported anymore. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.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: make modules Segfault
On Thu, 04 Aug 2005 21:20:22 -0600 George Van Tuyl wrote: > > To: linux-kernel@vger.kernel.org > > > > [1.] One line summary of the problem: > >make modules failed Segfault (program cpp0) > > [2.] Full description of the problem/report: > > gcc: Internal error: Segmentation fault (program cpp0) > Please submit a full bug report. That (above) is requesting a full bug report on gcc, not Linux kernel. See URL below: > See http://bugzilla.redhat.com/bugzilla/> for instructions. > make[3]: *** [cycx_drv.o] Error 1 > make[3]: Leaving directory `/usr/src/linux-2.4.31/drivers/net/wan' > make[2]: *** [_modsubdir_wan] Error 2 > make[2]: Leaving directory `/usr/src/linux-2.4.31/drivers/net' > make[1]: *** [_modsubdir_net] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4.31/drivers' > make: *** [_mod_drivers] Error 2 > [EMAIL PROTECTED] linux-2.4.31]# In file included from > /usr/src/linux-2.4.31/include/linux/vmalloc.h:5, > from /usr/src/linux-2.4.31/include/asm/io.h:47, > from cycx_drv.c:60: > /usr/src/linux-2.4.31/include/linux/mm.h:155: parse error at end of input > /usr/src/linux-2.4.31/include/linux/mm.h:155: warning: no semicolon at > end of struct or union > > > [3.] Keywords (i.e., modules, networking, kernel): > Modules > > [4.] Kernel version (from /proc/version): > > [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/version > Linux version 2.4.20-28.7 ([EMAIL PROTECTED]) (gcc > version 2.96 2731 (Red Hat Linux 7.3 2.96-126)) #1 Thu Dec 18 > 11:18:28 EST 2003 > > [5.] Output of Oops.. message (if applicable) with symbolic information > resolved (see Documentation/oops-tracing.txt) > > [6.] A small shell script or example program which triggers the > problem (if possible) > Presently running RedHat 7.3 with kernel-athlon-2.4.20-28.7 from rpm > > cd /usr/src/linux-2.4.31 downloaded today at 6:45 PM MST 8/4/05 > make mrproper > cp /boot/config-2.4.20-28.7 /usr/src/linux-2.4.31/.config > make oldconfig (Took all of the defaults no changes) > make xconfig > make dep > make bzImage > make modules > > > [7.] Environment > ASUS A7M-266, Athlon 1.4GHz, 512M, Nvidia Riva TNT/2, Link-Sys 10/100, > D-Link 1000 Marvell, Promise tx/100 IDE controller. RedHat 7.3 with as > updates as currently available from RedHat, Grrr! > > [7.1.] Software (add the output of the ver_linux script here) > > [EMAIL PROTECTED] linux-2.4.31]$ sh scripts/ver_linux > If some fields are empty or look unusual you may have an old version. > Compare to the current minimal requirements in Documentation/Changes. > > Linux wulff 2.4.20-28.7 #1 Thu Dec 18 11:18:28 EST 2003 i686 unknown > > Gnu C 2.96 > Gnu make 3.79.1 > util-linux 2.11n > mount 2.11n > modutils 2.4.18 > e2fsprogs 1.27 > reiserfsprogs 3.x.0j > quota-tools3.06. > PPP2.4.1 > isdn4k-utils 3.1pre1 > Linux C Library2.2.5 > Dynamic linker (ldd) 2.2.5 > Procps 2.0.7 > Net-tools 1.60 > Console-tools 0.3.3 > Sh-utils 2.0.11 > Modules Loaded sr_mod cmpci soundcore binfmt_misc autofs tulip > ipchains ide-scsi scsi_mod ide-cd cdrom usb-uhci usbcore ext3 jbd > > > [7.2.] Processor information (from /proc/cpuinfo): > > [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/cpuinfo > processor: 0 > vendor_id: AuthenticAMD > cpu family: 6 > model: 4 > model name: AMD Athlon(tm) Processor > stepping: 4 > cpu MHz: 1400.110 > cache size: 256 KB > fdiv_bug: no > hlt_bug: no > f00f_bug: no > coma_bug: no > fpu: yes > fpu_exception: yes > cpuid level: 1 > wp: yes > flags: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov > pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow > bogomips: 2791.83 > > [7.3.] Module information (from /proc/modules): > > [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/modules > sr_mod 16216 2 (autoclean) > cmpci 32468 0 (autoclean) > soundcore 6436 4 (autoclean) [cmpci] > binfmt_misc 7204 1 > autofs 11780 0 (autoclean) (unused) > tulip 42272 1 > ipchains 49484 10 > ide-scsi 10816 1 > scsi_mod 107212 2 [sr_mod ide-scsi] > ide-cd 32064 0 > cdrom 31936 0 [sr_mod ide-cd] > usb-uhci 24356 0 (unused) > usbcore73504 1 [usb-uhci] > ext3 65280 2 > jbd47468 2 [ext3] > > [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) > > [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/ioports > -001f : dma1 > 0020-003f : pic1 > 0040-005f : timer > 0060-006f : keyboard > 0070-007f : rtc > 0080-008f : dma page reg > 00a0-00bf : pic2 >
[PATCH] Timer Top tweaks
On Fri, 5 Aug 2005 07:15 am, Daniel Petrini wrote:
> Hi,
>
> Here we have some support to have more tests on Dynamic Tick.
> We have some functions that exports timers information to a proc entry
> (/proc/top_info), in a kernel patch and a script that handles this
> info and give some output to analyse. We tried to make it less
> intrusive as possible.
>
> It is based in suggestions from Tony Lindgren.
>
> It is experimental and should evolve.
>
> Must be applied after 2.6.13-rc5-dtck-3.patch and 2.6.13-rc5.
>
> Usage: with kernel compiled with attached patch: "perl timer_top.pl
> 5", to have refresh time of 5s.
Yes that's very nice.
It's probably premature but here's a small patch to your timer_top patch.
Cheers,
Con
---
Index: linux-2.6.13-rc5-ck2/kernel/Makefile
===
--- linux-2.6.13-rc5-ck2.orig/kernel/Makefile 2005-08-05 13:41:26.0 +1000
+++ linux-2.6.13-rc5-ck2/kernel/Makefile 2005-08-05 13:49:23.0 +1000
@@ -7,7 +7,7 @@ obj-y = sched.o fork.o exec_domain.o
sysctl.o capability.o ptrace.o timer.o user.o \
signal.o sys.o kmod.o workqueue.o pid.o \
rcupdate.o intermodule.o extable.o params.o posix-timers.o \
- kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o timer_top.o
+ kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o
obj-$(CONFIG_FUTEX) += futex.o
obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
@@ -30,7 +30,7 @@ obj-$(CONFIG_SYSFS) += ksysfs.o
obj-$(CONFIG_GENERIC_HARDIRQS) += irq/
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_SECCOMP) += seccomp.o
-obj-$(CONFIG_NO_IDLE_HZ) += dyn-tick.o
+obj-$(CONFIG_NO_IDLE_HZ) += dyn-tick.o timer_top.o
ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
# According to Alan Modra <[EMAIL PROTECTED]>, the -fno-omit-frame-pointer is
Index: linux-2.6.13-rc5-ck2/kernel/timer.c
===
--- linux-2.6.13-rc5-ck2.orig/kernel/timer.c 2005-08-05 13:41:26.0 +1000
+++ linux-2.6.13-rc5-ck2/kernel/timer.c 2005-08-05 13:57:23.0 +1000
@@ -509,7 +509,9 @@ static inline void __run_timers(tvec_bas
#ifdef CONFIG_NO_IDLE_HZ
extern struct timer_top_info top_info;
-extern int account_timer(unsigned int function, struct timer_top_info * top_info);
+extern int account_timer(unsigned int function,
+ struct timer_top_info *top_info);
+
/*
* Find out when the next timer event is due to happen. This
* is used on S/390 to stop all activity when a cpus is idle.
Index: linux-2.6.13-rc5-ck2/kernel/timer_top.c
===
--- linux-2.6.13-rc5-ck2.orig/kernel/timer_top.c 2005-08-05 13:41:26.0 +1000
+++ linux-2.6.13-rc5-ck2/kernel/timer_top.c 2005-08-05 13:54:50.0 +1000
@@ -11,7 +11,6 @@
* published by the Free Software Foundation.
*/
-
#include
#include
#include
@@ -20,8 +19,8 @@ static LIST_HEAD(timer_list);
struct timer_top_info {
unsigned int func_pointer;
- unsigned int long counter;
- struct list_head list;
+ unsigned long counter;
+ struct list_head list;
};
struct timer_top_info top_info;
@@ -30,37 +29,38 @@ int account_timer(unsigned int function,
{
struct timer_top_info *top;
- list_for_each_entry (top, _list, list) {
+ list_for_each_entry(top, _list, list) {
/* if it is in the list increment its count */
if (top->func_pointer == function) {
- top->counter += 1;
- return 0;
+ top->counter++;
+ goto out;
}
}
-
+
/* if you are here then it didnt find so inserts in the list */
top = kmalloc(sizeof(struct timer_top_info), GFP_KERNEL);
- if (!top)
+ if (!top)
return -ENOMEM;
top->func_pointer = function;
top->counter = 1;
list_add(>list, _list);
+out:
return 0;
}
EXPORT_SYMBOL(account_timer);
struct top_info_poll {
- char value[18];
+ char value[18];
};
struct top_info_poll top_info_poll_dt;
struct proc_dir_entry *top_info_file;
static int proc_read_top_info(char *page, char **start, off_t off,
-int count, int *eof, void *data)
+int count, int *eof, void *data)
{
char aux[18];
struct timer_top_info *top;
@@ -69,21 +69,19 @@ static int proc_read_top_info(char *page
sprintf(page, "Function counter - %s\n", info_poll_data->value);
- list_for_each_entry (top, _list, list) {
+ list_for_each_entry(top, _list, list) {
sprintf(aux, "%x %lu\n", top->func_pointer, top->counter);
strcat(page, aux);
}
return strlen(page);
-
-}
+}
static int init_top_info(void)
{
top_info_file = create_proc_entry("top_info", 0666, NULL);
- if(top_info_file == NULL) {
- return -ENOMEM;
- }
+ if (top_info_file == NULL)
+ return -ENOMEM;
strcpy(top_info_poll_dt.value, "Timer Top v0.9.1");
@@ -96,6 +94,3 @@ static int init_top_info(void)
module_init(init_top_info);
//module_exit();
-
-
-
Re: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
Andrew Morton wrote: Dmitry Torokhov <[EMAIL PROTECTED]> wrote: On Thursday 04 August 2005 22:09, Frank Peters wrote: I'll use bugzilla to report any problems with 2.6.13-rc6. But since I've included the "usb-handoff" option at boot time, all my problems (except the long dhcp/eth0 connect time) are now gone. Right now I'm using 2.6.13-rc5. I understand the need to pinpoint the kernel version, but the "usb-handoff" option has even corrected some problems that started in linux-2.4.x. For example, my PS/2 mouse now functions normally. It has not worked with this motherboard since some time in the 2.4.x series. Also, my keyboard lights were malfunctioning under X-Window since early 2.6.x, but with the "usb-handoff" option they are working normally now. If I had known about the "usb-handoff" option earlier, this thread probalby would not even have come into existence. As long as "usb-handoff" keeps working, I would consider the issue closed. We really really need to make usb-handoff default. Even if there known boxes that don't like it the blacklist would be rather short, much shorter than a whitelist. Sounds like a fun thing for post-2.6.13. What does usb-handoff do, precisely? I just did a series tests. This is necessary, because the problem was intermittent for me. usb-handoff fixes all of my problems!!! without using usb-handoff, my ps/2 mouse works 1/10 times using usb-handoff, my ps/2 mouse works 10/10 times I consider the problem solved... If Dmitry wants to make usb-handoff the default, he has my support :-). -- Michael Krufky - 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
On Thursday 04 August 2005 22:54, Andrew Morton wrote: > Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > > > On Thursday 04 August 2005 22:09, Frank Peters wrote: > > > I'll use bugzilla to report any problems with 2.6.13-rc6. > > > > > > But since I've included the "usb-handoff" option at boot time, > > > all my problems (except the long dhcp/eth0 connect time) are > > > now gone. Right now I'm using 2.6.13-rc5. > > > > > > I understand the need to pinpoint the kernel version, but the > > > "usb-handoff" option has even corrected some problems that > > > started in linux-2.4.x. For example, my PS/2 mouse now functions > > > normally. It has not worked with this motherboard since some time > > > in the 2.4.x series. Also, my keyboard lights were malfunctioning > > > under X-Window since early 2.6.x, but with the "usb-handoff" option > > > they are working normally now. > > > > > > If I had known about the "usb-handoff" option earlier, this thread > > > probalby would not even have come into existence. As long as > > > "usb-handoff" > > > keeps working, I would consider the issue closed. > > > > > > > We really really need to make usb-handoff default. Even if there known boxes > > that don't like it the blacklist would be rather short, much shorter than > > a whitelist. > > Sounds like a fun thing for post-2.6.13. > > What does usb-handoff do, precisely? > It requests BIOS to hand off control of USB which disables USB legacy emulation and all troubles associated with it. We could start with -mm... -- Dmitry - 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
Dmitry Torokhov <[EMAIL PROTECTED]> wrote: > > On Thursday 04 August 2005 22:09, Frank Peters wrote: > > I'll use bugzilla to report any problems with 2.6.13-rc6. > > > > But since I've included the "usb-handoff" option at boot time, > > all my problems (except the long dhcp/eth0 connect time) are > > now gone. Right now I'm using 2.6.13-rc5. > > > > I understand the need to pinpoint the kernel version, but the > > "usb-handoff" option has even corrected some problems that > > started in linux-2.4.x. For example, my PS/2 mouse now functions > > normally. It has not worked with this motherboard since some time > > in the 2.4.x series. Also, my keyboard lights were malfunctioning > > under X-Window since early 2.6.x, but with the "usb-handoff" option > > they are working normally now. > > > > If I had known about the "usb-handoff" option earlier, this thread > > probalby would not even have come into existence. As long as "usb-handoff" > > keeps working, I would consider the issue closed. > > > > We really really need to make usb-handoff default. Even if there known boxes > that don't like it the blacklist would be rather short, much shorter than > a whitelist. Sounds like a fun thing for post-2.6.13. What does usb-handoff do, precisely? - 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: mthca and LinuxBIOS
Hmm, that output all looks fine. Can you run with the patch below to
see exactly where the QP table initialization fails? (I haven't
actually compiled this patch so you may have to fix a typo or two)
I'm guessing that the CONF_SPECIAL_QP command is failing, but let's
make sure.
Thanks,
Roland
diff --git a/drivers/infiniband/hw/mthca/mthca_qp.c
b/drivers/infiniband/hw/mthca/mthca_qp.c
--- a/drivers/infiniband/hw/mthca/mthca_qp.c
+++ b/drivers/infiniband/hw/mthca/mthca_qp.c
@@ -2214,13 +2214,16 @@ int __devinit mthca_init_qp_table(struct
(1 << 24) - 1,
dev->qp_table.sqp_start +
MTHCA_MAX_PORTS * 2);
- if (err)
+ if (err) {
+ mthca_err(dev, "mthca_init_qp_table: mthca_alloc_init failed
(%d)\n", err);
return err;
+ }
err = mthca_array_init(>qp_table.qp,
dev->limits.num_qps);
if (err) {
mthca_alloc_cleanup(>qp_table.alloc);
+ mthca_err(dev, "mthca_init_qp_table: mthca_array_init failed
(%d)\n", err);
return err;
}
@@ -2228,8 +2231,10 @@ int __devinit mthca_init_qp_table(struct
err = mthca_CONF_SPECIAL_QP(dev, i ? IB_QPT_GSI : IB_QPT_SMI,
dev->qp_table.sqp_start + i * 2,
);
- if (err)
+ if (err) {
+ mthca_err(dev, "mthca_init_qp_table:
mthca_CONF_SPECIAL_QP failed for %d/%d (%d)\n", i, dev->qp_table.sqp_start + i
* 2, err);
goto err_out;
+ }
if (status) {
mthca_warn(dev, "CONF_SPECIAL_QP returned "
"status %02x, aborting.\n",
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dyn-tick3 tweaks respin
On Fri, 2005-08-05 at 13:20 +1000, Con Kolivas wrote: > Like this I assume you meant? > Yeah that looks good. Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Fri, 5 Aug 2005 11:30 am, Paul wrote: > Con Kolivas <[EMAIL PROTECTED]>, on Wed Aug 03, 2005 [03:59:24 PM] said: > > This is the dynamic ticks patch for i386 as written by Tony Lindgen > > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. > > Patch for 2.6.13-rc5 > Ive been running this all afternoon on a pIIx2 @400mhz desktop > machine, SMP enabled Preempt kernel. > Initially, I tried it using APIC, got X up and tried to play > some music, but mplayer just hung and prompts in other terminals > were super slugish or blocked until I killed mplayer. (there were > no interrupts from the sound card during this time.) Without using > APIC, it seems to work just great. > With my regular desktop running and me not doing much, 'vmstat 5' > shows interrupts at 100-200 per entry. Loading the box completely with > 'make -j4' kernel build their are just over 1000 interrupts. Various other > loads show numbers in between. (eg. it seems to work as one would expect, > presuming the timer interupts dominate...) > Time seems fine. I havent noticed any interactivity problems. > Performance on 'kernbench' was within a percentage point of 2.6.12 > It does not seem to make any difference as far as the heat of the > cpus or mb, though. Thanks for the feedback. As Tony mentioned, it simply allows for better power management to be done rather than saving power on its own. At idle it allows the processor to enter a lower power state for example, which I doubt the pII does. Cheers, Con - 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] dyn-tick3 tweaks respin
On Fri, 5 Aug 2005 11:39 am, Con Kolivas wrote:
> On Fri, 5 Aug 2005 10:53 am, Nick Piggin wrote:
> > All else being equal, it is much better if you unlock in the
> > same function that takes the lock. For readability.
> >
> > It looks like you should be able to leave all the flow control
> > and locking the same, and use update_monotonic_base() to
> > do the actual update?
>
> Good advice, thanks. Will respin.
Like this I assume you meant?
Cheers,
Con
---
Index: linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c
===
--- linux-2.6.13-rc5-ck2.orig/arch/i386/kernel/timers/timer_tsc.c 2005-08-03 11:29:29.0 +1000
+++ linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c 2005-08-05 13:15:23.0 +1000
@@ -167,10 +167,19 @@ static void delay_tsc(unsigned long loop
} while ((now-bclock) < loops);
}
+/* update the monotonic base value */
+static inline void update_monotonic_base(unsigned long long last_offset)
+{
+ unsigned long long this_offset;
+
+ this_offset = ((unsigned long long)last_tsc_high << 32) | last_tsc_low;
+ monotonic_base += cycles_2_ns(this_offset - last_offset);
+}
+
#ifdef CONFIG_HPET_TIMER
static void mark_offset_tsc_hpet(void)
{
- unsigned long long this_offset, last_offset;
+ unsigned long long last_offset;
unsigned long offset, temp, hpet_current;
write_seqlock(_lock);
@@ -198,9 +207,7 @@ static void mark_offset_tsc_hpet(void)
}
hpet_last = hpet_current;
- /* update the monotonic base value */
- this_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low;
- monotonic_base += cycles_2_ns(this_offset - last_offset);
+ update_monotonic_base(last_offset);
write_sequnlock(_lock);
/* calculate delay_at_last_interrupt */
@@ -347,7 +354,7 @@ static void mark_offset_tsc(void)
int count;
int countmp;
static int count1 = 0;
- unsigned long long this_offset, last_offset;
+ unsigned long long last_offset;
static int lost_count = 0;
write_seqlock(_lock);
@@ -368,8 +375,11 @@ static void mark_offset_tsc(void)
rdtsc(last_tsc_low, last_tsc_high);
- if (dyn_tick_enabled())
- goto monotonic_base;
+ if (dyn_tick_enabled()) {
+ update_monotonic_base(last_offset);
+ write_sequnlock(_lock);
+ return;
+ }
spin_lock(_lock);
outb_p(0x00, PIT_MODE); /* latch the count ASAP */
@@ -439,16 +449,9 @@ static void mark_offset_tsc(void)
} else
lost_count = 0;
- monotonic_base:
-
- /* update the monotonic base value */
- this_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low;
- monotonic_base += cycles_2_ns(this_offset - last_offset);
+ update_monotonic_base(last_offset);
write_sequnlock(_lock);
- if (dyn_tick_enabled())
- return;
-
/* calculate delay_at_last_interrupt */
count = ((LATCH-1) - count) * TICK_SIZE;
delay_at_last_interrupt = (count + LATCH/2) / LATCH;
Re: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
On Thursday 04 August 2005 22:09, Frank Peters wrote: > I'll use bugzilla to report any problems with 2.6.13-rc6. > > But since I've included the "usb-handoff" option at boot time, > all my problems (except the long dhcp/eth0 connect time) are > now gone. Right now I'm using 2.6.13-rc5. > > I understand the need to pinpoint the kernel version, but the > "usb-handoff" option has even corrected some problems that > started in linux-2.4.x. For example, my PS/2 mouse now functions > normally. It has not worked with this motherboard since some time > in the 2.4.x series. Also, my keyboard lights were malfunctioning > under X-Window since early 2.6.x, but with the "usb-handoff" option > they are working normally now. > > If I had known about the "usb-handoff" option earlier, this thread > probalby would not even have come into existence. As long as "usb-handoff" > keeps working, I would consider the issue closed. > We really really need to make usb-handoff default. Even if there known boxes that don't like it the blacklist would be rather short, much shorter than a whitelist. -- Dmitry - 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: isa0060/serio0 problems -WAS- Re: Asus MB and 2.6.12 Problems
I'll use bugzilla to report any problems with 2.6.13-rc6. But since I've included the "usb-handoff" option at boot time, all my problems (except the long dhcp/eth0 connect time) are now gone. Right now I'm using 2.6.13-rc5. I understand the need to pinpoint the kernel version, but the "usb-handoff" option has even corrected some problems that started in linux-2.4.x. For example, my PS/2 mouse now functions normally. It has not worked with this motherboard since some time in the 2.4.x series. Also, my keyboard lights were malfunctioning under X-Window since early 2.6.x, but with the "usb-handoff" option they are working normally now. If I had known about the "usb-handoff" option earlier, this thread probalby would not even have come into existence. As long as "usb-handoff" keeps working, I would consider the issue closed. Frank Peters On Thu, 4 Aug 2005 16:28:12 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote: > > Frank, if any problems remain in 2.6.13-rc6 could you please raise new > bugzilla.kernel.org records for them? That way poor old me will be able to > keep tabs on progress more easily. > > (It's especially important to identify the most recent kernel version which > didn't have a particular bug) > > 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/
make modules Segfault
To: linux-kernel@vger.kernel.org [1.] One line summary of the problem: make modules failed Segfault (program cpp0) [2.] Full description of the problem/report: gcc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See http://bugzilla.redhat.com/bugzilla/> for instructions. make[3]: *** [cycx_drv.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.31/drivers/net/wan' make[2]: *** [_modsubdir_wan] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.31/drivers/net' make[1]: *** [_modsubdir_net] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.31/drivers' make: *** [_mod_drivers] Error 2 [EMAIL PROTECTED] linux-2.4.31]# In file included from /usr/src/linux-2.4.31/include/linux/vmalloc.h:5, from /usr/src/linux-2.4.31/include/asm/io.h:47, from cycx_drv.c:60: /usr/src/linux-2.4.31/include/linux/mm.h:155: parse error at end of input /usr/src/linux-2.4.31/include/linux/mm.h:155: warning: no semicolon at end of struct or union [3.] Keywords (i.e., modules, networking, kernel): Modules [4.] Kernel version (from /proc/version): [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/version Linux version 2.4.20-28.7 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-126)) #1 Thu Dec 18 11:18:28 EST 2003 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) [6.] A small shell script or example program which triggers the problem (if possible) Presently running RedHat 7.3 with kernel-athlon-2.4.20-28.7 from rpm cd /usr/src/linux-2.4.31 downloaded today at 6:45 PM MST 8/4/05 make mrproper cp /boot/config-2.4.20-28.7 /usr/src/linux-2.4.31/.config make oldconfig (Took all of the defaults no changes) make xconfig make dep make bzImage make modules [7.] Environment ASUS A7M-266, Athlon 1.4GHz, 512M, Nvidia Riva TNT/2, Link-Sys 10/100, D-Link 1000 Marvell, Promise tx/100 IDE controller. RedHat 7.3 with as updates as currently available from RedHat, Grrr! [7.1.] Software (add the output of the ver_linux script here) [EMAIL PROTECTED] linux-2.4.31]$ sh scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux wulff 2.4.20-28.7 #1 Thu Dec 18 11:18:28 EST 2003 i686 unknown Gnu C 2.96 Gnu make 3.79.1 util-linux 2.11n mount 2.11n modutils 2.4.18 e2fsprogs 1.27 reiserfsprogs 3.x.0j quota-tools3.06. PPP2.4.1 isdn4k-utils 3.1pre1 Linux C Library2.2.5 Dynamic linker (ldd) 2.2.5 Procps 2.0.7 Net-tools 1.60 Console-tools 0.3.3 Sh-utils 2.0.11 Modules Loaded sr_mod cmpci soundcore binfmt_misc autofs tulip ipchains ide-scsi scsi_mod ide-cd cdrom usb-uhci usbcore ext3 jbd [7.2.] Processor information (from /proc/cpuinfo): [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/cpuinfo processor: 0 vendor_id: AuthenticAMD cpu family: 6 model: 4 model name: AMD Athlon(tm) Processor stepping: 4 cpu MHz: 1400.110 cache size: 256 KB fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 1 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow bogomips: 2791.83 [7.3.] Module information (from /proc/modules): [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/modules sr_mod 16216 2 (autoclean) cmpci 32468 0 (autoclean) soundcore 6436 4 (autoclean) [cmpci] binfmt_misc 7204 1 autofs 11780 0 (autoclean) (unused) tulip 42272 1 ipchains 49484 10 ide-scsi 10816 1 scsi_mod 107212 2 [sr_mod ide-scsi] ide-cd 32064 0 cdrom 31936 0 [sr_mod ide-cd] usb-uhci 24356 0 (unused) usbcore73504 1 [usb-uhci] ext3 65280 2 jbd47468 2 [ext3] [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) [EMAIL PROTECTED] linux-2.4.31]$ cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(auto) 0330-0331 : cmpci Midi 0376-0376 : ide1 0388-038b : cmpci FM 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0cf8-0cff : PCI conf1 8000-80ff : Linksys Network Everywhere Fast Ethernet 10/100 model NC100 8000-80ff : tulip 8400-84ff : PCI device 1186:4c00 (D-Link System Inc) 8800-880f : Promise Technology, Inc. 20268 8800-8807 :
Re: File corruption on LVM2 on top of software RAID1
Andrew Morton <[EMAIL PROTECTED]> wrote: > > There's one fix against 2.6.12.3 which is needed, but 2.6.9 didn't have the > bug which this fix addresses. aargh, I see that it did fix it. Don't blame me. Blame people who screw up list threading by reading a mail->news gateway and hitting "reply". - 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: File corruption on LVM2 on top of software RAID1
"Simon Matter" <[EMAIL PROTECTED]> wrote: > > Hi, > > Please CC me as I'm not subscribed to the kernel list. > > I had a hard time identifying a serious problem in the 2.6 linux kernel. Yes, it is a serious problem. > It all started while evaluating RHEL4 for new servers. My data integrity > tests gave me bad results - which I couldn't believe - and my first idea > was - of course - bad hardware. I ordered new SCSI disks instead of the > IDE disks, took another server, spent some money again, tried again and > again. That's all long ago now... > > In my tests I get corrupt files on LVM2 which is on top of software raid1. > (This is a common setup even mentioned in the software RAID HOWTO and has > worked for me on RedHat 9 / kernel 2.4 for a long time now and it's my > favourite configuration). Now, I tested two different distributions, three > kernels, three different filesystems and three different hardware. I can > always reproduce it with the following easy scripts: > > LOGF=/root/diff.log > while true; do > rm -rf /home/XXX2 > rsync -a /home/XXX/ /home/XXX2 > date >> $LOGF > diff -r /home/XXX /home/XXX2 >> $LOGF > done > > the files in /home/XXX are ~15G of ISO images and rpms. > > diff.log looks like this: > Wed Aug 3 13:45:57 CEST 2005 > Binary files /home/XXX/ES3-U3/rhel-3-U3-i386-es-disc3.iso and > /home/XXX2/ES3-U3/rhel-3-U3-i386-es-disc3.iso differ > Wed Aug 3 14:09:14 CEST 2005 > Binary files /home/XXX/8.0/psyche-i386-disc1.iso and > /home/XXX2/8.0/psyche-i386-disc1.iso differ > Wed Aug 3 14:44:17 CEST 2005 > Binary files /home/XXX/7.3/valhalla-i386-disc3.iso and > /home/XXX2/7.3/valhalla-i386-disc3.iso differ > Wed Aug 3 15:15:05 CEST 2005 > Wed Aug 3 15:45:40 CEST 2005 > > > Tested software: > 1) RedHat EL4 > kernel-2.6.9-11.EL > vanilla 2.6.12.3 kernel > filesystems: EXT2, EXT3, XFS > > 2) NOVELL/SUSE 9.3 > kernel-default-2.6.11.4-21.7 > filesystem: EXT3 > > Tested Hardware: > 1) > - ASUS P2B-S board > - CPU PIII 450MHz > - Intel 440BX/ZX/DX Chipset > - 4x128M memory (ECC enabled) > - 2x IDE disks Seagate Barracuda 400G, connected to onboard "Intel PIIX4 > Ultra 33" > - Promise Ultra100TX2 adapter for additional tests > > 2) > - DELL PowerEdge 1400 > - CPU PIII 800MHz > - ServerWorks OSB4 Chipset > - 4x256M memory (ECC enabled) > - 2x U320 SCSI disks Maxtor Atlas 10K 146G > - onboard Adaptec aic7899 Ultra160 SCSI adapter > > 3) > - DELL PowerEdge 1850 > - CPU P4 XEON 2.8GHz > - 2G memory > - 2x U320 SCSI disks Maxtor Atlas 10K 73G SCA > - onboard LSI53C1030 SCSI adapter > > I've put some files toghether from the last test on the PE1850 server: > http://www.invoca.ch/bugs/linux-2.6-corruption-on-lvm2-on-raid1/ > > I've also filed a bug with RedHat: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164696 > > I have spent a lot of time on this bug because I consider it very serious. > I'm not a kernel hacker but if there is anything I can do to fix this, let > me know. > Thanks for doing that. There's one fix against 2.6.12.3 which is needed, but 2.6.9 didn't have the bug which this fix addresses. So unless 2.6.9 has a different problem, this won't help. But still, you should include this in testing please. diff -puN fs/bio.c~bio_clone-fix fs/bio.c --- devel/fs/bio.c~bio_clone-fix2005-07-28 00:39:40.0 -0700 +++ devel-akpm/fs/bio.c 2005-07-28 01:02:34.0 -0700 @@ -261,6 +261,7 @@ inline void __bio_clone(struct bio *bio, */ bio->bi_vcnt = bio_src->bi_vcnt; bio->bi_size = bio_src->bi_size; + bio->bi_idx = bio_src->bi_idx; bio_phys_segments(q, bio); bio_hw_segments(q, bio); } _ - 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/
[-mm patch] relayfs: update Documentation
This patch updates the relayfs documentation to reflect the latest API changes, and generally cleans up and adds much-needed clarification to many areas - many thanks to Bert Hubert for that. Andrew, please apply. Thanks, Tom Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]> diff -urpN -X dontdiff linux-2.6.13-rc4-mm1/Documentation/filesystems/relayfs.txt linux-2.6.13-rc4-mm1-cur/Documentation/filesystems/relayfs.txt --- linux-2.6.13-rc4-mm1/Documentation/filesystems/relayfs.txt 2005-08-05 10:14:33.0 -0500 +++ linux-2.6.13-rc4-mm1-cur/Documentation/filesystems/relayfs.txt 2005-08-05 15:47:10.0 -0500 @@ -23,6 +23,51 @@ This document provides an overview of th the function parameters are documented along with the functions in the filesystem code - please see that for details. +Semantics += + +Each relayfs channel has one buffer per CPU, each buffer has one or +more sub-buffers. Messages are written to the first sub-buffer until +it is too full to contain a new message, in which case it it is +written to the next (if available). Messages are never split across +sub-buffers. At this point, userspace can be notified so it empties +the first sub-buffer, while the kernel continues writing to the next. + +When notified that a sub-buffer is full, the kernel knows how many +bytes of it are padding i.e. unused. Userspace can use this knowledge +to copy only valid data. + +After copying it, userspace can notify the kernel that a sub-buffer +has been consumed. + +relayfs can operate in a mode where it will overwrite data not yet +collected by userspace, and not wait for it to consume it. + +relayfs itself does not provide for communication of such data between +userspace and kernel, allowing the kernel side to remain simple and not +impose a single interface on userspace. It does provide a separate +helper though, described below. + +klog, relay-app & librelay +== + +relayfs itself is ready to use, but to make things easier, two +additional systems are provided. klog is a simple wrapper to make +writing formatted text or raw data to a channel simpler, regardless of +whether a channel to write into exists or not, or whether relayfs is +compiled into the kernel or is configured as a module. relay-app is +the kernel counterpart of userspace librelay.c, combined these two +files provide glue to easily stream data to disk, without having to +bother with housekeeping. klog and relay-app can be used together, +with klog providing high-level logging functions to the kernel and +relay-app taking care of kernel-user control and disk-logging chores. + +It is possible to use relayfs without relay-app & librelay, but you'll +have to implement communication between userspace and kernel, allowing +both to convey the state of buffers (full, empty, amount of padding). + +klog, relay-app and librelay can be found in the relay-apps tarball on +http://relayfs.sourceforge.net The relayfs user space API == @@ -34,7 +79,13 @@ available and some comments regarding th open() enables user to open an _existing_ buffer. mmap() results in channel buffer being mapped into the caller's -memory space. +memory space. Note that you can't do a partial mmap - you must +map the entire file, which is NRBUF * SUBBUFSIZE. + +read() read the contents of a channel buffer. If there are active +channel writers, results may be unpredictable - users should +make sure that all logging to the channel has ended before +using read(). poll() POLLIN/POLLRDNORM/POLLERR supported. User applications are notified when sub-buffer boundaries are crossed. @@ -63,13 +114,15 @@ Here's a summary of the API relayfs prov channel management functions: relay_open(base_filename, parent, subbuf_size, n_subbufs, - overwrite, callbacks) + callbacks) relay_close(chan) relay_flush(chan) relay_reset(chan) relayfs_create_dir(name, parent) relayfs_remove_dir(dentry) -relay_commit(buf, reserved, count) + + channel management typically called on instigation of userspace: + relay_subbufs_consumed(chan, cpu, subbufs_consumed) write functions: @@ -80,16 +133,18 @@ Here's a summary of the API relayfs prov callbacks: -subbuf_start(buf, subbuf, prev_subbuf_idx, prev_subbuf) -deliver(buf, subbuf_idx, subbuf) +subbuf_start(buf, subbuf, prev_subbuf, prev_padding) buf_mapped(buf, filp) buf_unmapped(buf, filp) -buf_full(buf, subbuf_idx) + helper functions: + +relay_buf_full(buf) +subbuf_start_reserve(buf, length) -A relayfs channel is made of up one or more per-cpu channel buffers, -each implemented as a circular buffer subdivided into one or more -sub-buffers. + +Creating a channel +-- relay_open() is used to create a channel, along with its per-cpu channel buffers. Each channel buffer will have
[-mm patch] relayfs: add read() support
At the kernel summit, there was some discussion of relayfs and the
consensus was that it didn't make sense for relayfs to not implement
read(). So here's a read implementation...
Andrew, please apply.
Tom
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.13-rc4-mm1/fs/relayfs/inode.c
linux-2.6.13-rc4-mm1-cur/fs/relayfs/inode.c
--- linux-2.6.13-rc4-mm1/fs/relayfs/inode.c 2005-08-05 10:14:34.0
-0500
+++ linux-2.6.13-rc4-mm1-cur/fs/relayfs/inode.c 2005-08-05 10:17:47.0
-0500
@@ -232,7 +232,7 @@ int relayfs_remove_dir(struct dentry *de
*
* Increments the channel buffer refcount.
*/
-int relayfs_open(struct inode *inode, struct file *filp)
+static int relayfs_open(struct inode *inode, struct file *filp)
{
struct rchan_buf *buf = RELAYFS_I(inode)->buf;
kref_get(>kref);
@@ -247,7 +247,7 @@ int relayfs_open(struct inode *inode, st
*
* Calls upon relay_mmap_buf to map the file into user space.
*/
-int relayfs_mmap(struct file *filp, struct vm_area_struct *vma)
+static int relayfs_mmap(struct file *filp, struct vm_area_struct *vma)
{
struct inode *inode = filp->f_dentry->d_inode;
return relay_mmap_buf(RELAYFS_I(inode)->buf, vma);
@@ -260,7 +260,7 @@ int relayfs_mmap(struct file *filp, stru
*
* Poll implemention.
*/
-unsigned int relayfs_poll(struct file *filp, poll_table *wait)
+static unsigned int relayfs_poll(struct file *filp, poll_table *wait)
{
unsigned int mask = 0;
struct inode *inode = filp->f_dentry->d_inode;
@@ -286,7 +286,7 @@ unsigned int relayfs_poll(struct file *f
* Decrements the channel refcount, as the filesystem is
* no longer using it.
*/
-int relayfs_release(struct inode *inode, struct file *filp)
+static int relayfs_release(struct inode *inode, struct file *filp)
{
struct rchan_buf *buf = RELAYFS_I(inode)->buf;
kref_put(>kref, relay_remove_buf);
@@ -295,6 +295,157 @@ int relayfs_release(struct inode *inode,
}
/**
+ * relayfs_read_start - find the first available byte to read
+ *
+ * If the read_pos is in the middle of padding, return the
+ * position of the first actually available byte, otherwise
+ * return the original value.
+ */
+static inline unsigned int relayfs_read_start(unsigned int read_pos,
+ unsigned int avail,
+ unsigned int start_subbuf,
+ struct rchan_buf *buf)
+{
+ unsigned int read_subbuf, adj_read_subbuf;
+ unsigned int padding, padding_start, padding_end;
+ unsigned int subbuf_size = buf->chan->subbuf_size;
+ unsigned int n_subbufs = buf->chan->n_subbufs;
+
+ read_subbuf = read_pos / subbuf_size;
+ adj_read_subbuf = (read_subbuf + start_subbuf) % n_subbufs;
+
+ if ((read_subbuf + 1) * subbuf_size <= avail) {
+ padding = buf->padding[adj_read_subbuf];
+ padding_start = (read_subbuf + 1) * subbuf_size - padding;
+ padding_end = (read_subbuf + 1) * subbuf_size;
+ if (read_pos >= padding_start && read_pos < padding_end) {
+ read_subbuf = (read_subbuf + 1) % n_subbufs;
+ read_pos = read_subbuf * subbuf_size;
+ }
+ }
+
+ return read_pos;
+}
+
+/**
+ * relayfs_read_end - return the end of available bytes to read
+ *
+ * If the read_pos is in the middle of a full sub-buffer, return
+ * the padding-adjusted end of that sub-buffer, otherwise return
+ * the position after the last byte written to the buffer. At
+ * most, 1 sub-buffer can be read at a time.
+ *
+ */
+static inline unsigned int relayfs_read_end(unsigned int read_pos,
+ unsigned int avail,
+ unsigned int start_subbuf,
+ struct rchan_buf *buf)
+{
+ unsigned int padding, read_endpos, buf_offset;
+ unsigned int read_subbuf, adj_read_subbuf;
+ unsigned int subbuf_size = buf->chan->subbuf_size;
+ unsigned int n_subbufs = buf->chan->n_subbufs;
+
+ buf_offset = buf->offset > subbuf_size ? subbuf_size : buf->offset;
+ read_subbuf = read_pos / subbuf_size;
+ adj_read_subbuf = (read_subbuf + start_subbuf) % n_subbufs;
+
+ if ((read_subbuf + 1) * subbuf_size <= avail) {
+ padding = buf->padding[adj_read_subbuf];
+ read_endpos = (read_subbuf + 1) * subbuf_size - padding;
+ } else
+ read_endpos = read_subbuf * subbuf_size + buf_offset;
+
+ return read_endpos;
+}
+
+/**
+ * relayfs_read_avail - return total available along with buffer start
+ *
+ * Because buffers are circular, the 'beginning' of the buffer
+ * depends on where the buffer was last written. If the writer
+ *
[-mm patch] relayfs: API cleanup
This patch does a bit of cleanup of the relayfs API, as discussed
previously:
http://marc.theaimsgroup.com/?l=linux-kernel=112134773617086=2
To recap, it:
- removes the commit counts, relay_commit() and the deliver() callback
(the padding counts had to stay, for the read() implementation)
- removes the buffer_full() callback
- changes the subbuf_start() callback
- changes 'unsigned' to 'unsigned int'
- other similar and related changes
The examples have been updated to use the new API (there's also a new
example that does commit/deliver in the client):
http://prdownloads.sourceforge.net/relayfs/relay-apps-0.7.tar.gz?download
Andrew, please apply.
Thanks,
Tom
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
diff -urpN -X dontdiff linux-2.6.13-rc4-mm1/fs/relayfs/buffers.c
linux-2.6.13-rc4-mm1-cur/fs/relayfs/buffers.c
--- linux-2.6.13-rc4-mm1/fs/relayfs/buffers.c 2005-08-05 10:14:34.0
-0500
+++ linux-2.6.13-rc4-mm1-cur/fs/relayfs/buffers.c 2005-08-05
10:17:30.0 -0500
@@ -95,7 +95,7 @@ int relay_mmap_buf(struct rchan_buf *buf
static void *relay_alloc_buf(struct rchan_buf *buf, unsigned long size)
{
void *mem;
- int i, j, n_pages;
+ unsigned int i, j, n_pages;
size = PAGE_ALIGN(size);
n_pages = size >> PAGE_SHIFT;
@@ -141,20 +141,15 @@ struct rchan_buf *relay_create_buf(struc
if (!buf->padding)
goto free_buf;
- buf->commit = kmalloc(chan->n_subbufs * sizeof(unsigned *), GFP_KERNEL);
- if (!buf->commit)
- goto free_buf;
-
buf->start = relay_alloc_buf(buf, chan->alloc_size);
if (!buf->start)
goto free_buf;
-
+
buf->chan = chan;
kref_get(>chan->kref);
return buf;
free_buf:
- kfree(buf->commit);
kfree(buf->padding);
kfree(buf);
return NULL;
@@ -167,7 +162,7 @@ free_buf:
void relay_destroy_buf(struct rchan_buf *buf)
{
struct rchan *chan = buf->chan;
- int i;
+ unsigned int i;
if (likely(buf->start)) {
vunmap(buf->start);
@@ -176,7 +171,6 @@ void relay_destroy_buf(struct rchan_buf
kfree(buf->page_array);
}
kfree(buf->padding);
- kfree(buf->commit);
kfree(buf);
kref_put(>kref, relay_destroy_channel);
}
diff -urpN -X dontdiff linux-2.6.13-rc4-mm1/fs/relayfs/relay.c
linux-2.6.13-rc4-mm1-cur/fs/relayfs/relay.c
--- linux-2.6.13-rc4-mm1/fs/relayfs/relay.c 2005-08-05 10:14:34.0
-0500
+++ linux-2.6.13-rc4-mm1-cur/fs/relayfs/relay.c 2005-08-05 10:17:30.0
-0500
@@ -26,10 +26,7 @@
*/
int relay_buf_empty(struct rchan_buf *buf)
{
- int produced = atomic_read(>subbufs_produced);
- int consumed = atomic_read(>subbufs_consumed);
-
- return (produced - consumed) ? 0 : 1;
+ return (buf->subbufs_produced - buf->subbufs_consumed) ? 0 : 1;
}
/**
@@ -38,17 +35,10 @@ int relay_buf_empty(struct rchan_buf *bu
*
* Returns 1 if the buffer is full, 0 otherwise.
*/
-static inline int relay_buf_full(struct rchan_buf *buf)
+int relay_buf_full(struct rchan_buf *buf)
{
- int produced, consumed;
-
- if (buf->chan->overwrite)
- return 0;
-
- produced = atomic_read(>subbufs_produced);
- consumed = atomic_read(>subbufs_consumed);
-
- return (produced - consumed > buf->chan->n_subbufs - 1) ? 1 : 0;
+ unsigned int ready = buf->subbufs_produced - buf->subbufs_consumed;
+ return (ready >= buf->chan->n_subbufs) ? 1 : 0;
}
/*
@@ -65,19 +55,10 @@ static inline int relay_buf_full(struct
*/
static int subbuf_start_default_callback (struct rchan_buf *buf,
void *subbuf,
- unsigned prev_subbuf_idx,
- void *prev_subbuf)
-{
- return 0;
-}
-
-/*
- * deliver() default callback. Does nothing.
- */
-static void deliver_default_callback (struct rchan_buf *buf,
- unsigned subbuf_idx,
- void *subbuf)
+ void *prev_subbuf,
+ unsigned int prev_padding)
{
+ return 1;
}
/*
@@ -96,22 +77,11 @@ static void buf_unmapped_default_callbac
{
}
-/*
- * buf_full() default callback. Does nothing.
- */
-static void buf_full_default_callback(struct rchan_buf *buf,
- unsigned subbuf_idx,
- void *subbuf)
-{
-}
-
/* relay channel default callbacks */
static struct rchan_callbacks default_channel_callbacks = {
.subbuf_start = subbuf_start_default_callback,
- .deliver = deliver_default_callback,
.buf_mapped = buf_mapped_default_callback,
.buf_unmapped = buf_unmapped_default_callback,
- .buf_full = buf_full_default_callback,
};
/**
@@ -129,29
Re: [PATCH] dyn-tick3 tweaks
On Fri, 5 Aug 2005 10:53 am, Nick Piggin wrote:
> Con Kolivas wrote:
> > Something like this on top is cleaner and quieter. I'll add this to
> > pending changes for another version.
> >
> >
> >
> >
> > Index: linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c
> > ===
> > ---
> > linux-2.6.13-rc5-ck2.orig/arch/i386/kernel/timers/timer_tsc.c
> > 2005-08-03
> > 11:29:29.0 +1000 +++
> > linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c2005-08-05
> > 10:22:25.0 +1000 @@ -167,10 +167,20 @@ static void
> > delay_tsc(unsigned long loop
> > } while ((now-bclock) < loops);
> > }
> >
> > +/* update the monotonic base value */
> > +static inline void update_monotonic_base(unsigned long long last_offset)
> > +{
> > + unsigned long long this_offset;
> > +
> > + this_offset = ((unsigned long long)last_tsc_high << 32) | last_tsc_low;
> > + monotonic_base += cycles_2_ns(this_offset - last_offset);
> > + write_sequnlock(_lock);
> > +}
> > +
>
> All else being equal, it is much better if you unlock in the
> same function that takes the lock. For readability.
>
> It looks like you should be able to leave all the flow control
> and locking the same, and use update_monotonic_base() to
> do the actual update?
Good advice, thanks. Will respin.
Cheers,
Con
-
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] Speedup FAT filesystem directory reads
Karsten Wiese <[EMAIL PROTECTED]> writes: > Looks better, is smaller and works equally well here, thanks. > I had to hand apply it though as it was slightly scrambled > (by my mail client?) so patch couldn't handle it. > Please send patches as attachment. We like a plain text, not attachment, see Documentation/SubmittingPatches. Anyway, thanks for nice work. -- OGAWA Hirofumi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3
Con Kolivas <[EMAIL PROTECTED]>, on Wed Aug 03, 2005 [03:59:24 PM] said: > This is the dynamic ticks patch for i386 as written by Tony Lindgen > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. > Patch for 2.6.13-rc5 > > There were a couple of things that I wanted to change so here is an updated > version. This code should have stabilised enough for general testing now. > > The sysfs interface was moved to its own directory > in /sys/devices/system/dyn_tick and split into separate files to > enable/disable dynamic ticks and usage of apic on the fly. It makes sense to > enable dynamic ticks and usage of apic by default if they're actually built > into the kernel so that is now done. > > Cheers, > Con Hi; Ive been running this all afternoon on a pIIx2 @400mhz desktop machine, SMP enabled Preempt kernel. Initially, I tried it using APIC, got X up and tried to play some music, but mplayer just hung and prompts in other terminals were super slugish or blocked until I killed mplayer. (there were no interrupts from the sound card during this time.) Without using APIC, it seems to work just great. With my regular desktop running and me not doing much, 'vmstat 5' shows interrupts at 100-200 per entry. Loading the box completely with 'make -j4' kernel build their are just over 1000 interrupts. Various other loads show numbers in between. (eg. it seems to work as one would expect, presuming the timer interupts dominate...) Time seems fine. I havent noticed any interactivity problems. Performance on 'kernbench' was within a percentage point of 2.6.12 It does not seem to make any difference as far as the heat of the cpus or mb, though. Hope this datapoint is useful; Paul [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 3/5] USB: ub documentation update
From: Pete Zaitcev <[EMAIL PROTECTED]> The patch which went in was correct, but not quite what I had in mind. Here is a patch to update that a little bit. Original patch is at: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4749f32da939d4e4160541b2cadc22492bb507ec Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> --- Documentation/usb/usbmon.txt |2 +- drivers/usb/mon/Kconfig |9 - drivers/usb/mon/Makefile |1 + 3 files changed, 6 insertions(+), 6 deletions(-) --- gregkh-2.6.orig/Documentation/usb/usbmon.txt2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/Documentation/usb/usbmon.txt 2005-08-04 17:40:06.0 -0700 @@ -102,7 +102,7 @@ - URB Status. This field makes no sense for submissions, but is present to help scripts with parsing. In error case, it contains the error code. In case of a setup packet, it contains a Setup Tag. If scripts read a number - in this field, the proceed to read Data Length. Otherwise, they read + in this field, they proceed to read Data Length. Otherwise, they read the setup packet before reading the Data Length. - Setup packet, if present, consists of 5 words: one of each for bmRequestType, bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0. --- gregkh-2.6.orig/drivers/usb/mon/Kconfig 2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/drivers/usb/mon/Kconfig 2005-08-04 17:40:06.0 -0700 @@ -9,9 +9,8 @@ help If you say Y here, a component which captures the USB traffic between peripheral-specific drivers and HC drivers will be built. - The USB_MON is similar in spirit and may be compatible with Dave - Harding's USBMon. + For more information, see . - This is somewhat experimental at this time, but it should be safe, - as long as you aren't using modular USB and try to remove this - module. + This is somewhat experimental at this time, but it should be safe. + + If unsure, say Y. --- gregkh-2.6.orig/drivers/usb/mon/Makefile2005-08-04 17:37:11.0 -0700 +++ gregkh-2.6/drivers/usb/mon/Makefile 2005-08-04 17:40:06.0 -0700 @@ -4,4 +4,5 @@ usbmon-objs:= mon_main.o mon_stat.o mon_text.o +# This does not use CONFIG_USB_MON because we want this to use a tristate. obj-$(CONFIG_USB) += usbmon.o -- - 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 5/5] USB: Fix setup packet initialization in isp116x-hcd
From: Olav Kongas <[EMAIL PROTECTED]>
When recently addressing remarks by Alexey Dobriyan about
the isp116x-hcd, I introduced a bug in the driver. Please
apply the attached patch to fix it.
Signed-off-by: Olav Kongas <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/host/isp116x-hcd.c |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
--- gregkh-2.6.orig/drivers/usb/host/isp116x-hcd.c 2005-08-04
17:37:11.0 -0700
+++ gregkh-2.6/drivers/usb/host/isp116x-hcd.c 2005-08-04 17:40:10.0
-0700
@@ -229,9 +229,11 @@
struct isp116x_ep *ep;
struct urb *urb;
struct ptd *ptd;
- u16 toggle = 0, dir = PTD_DIR_SETUP, len;
+ u16 len;
for (ep = isp116x->atl_active; ep; ep = ep->active) {
+ u16 toggle = 0, dir = PTD_DIR_SETUP;
+
BUG_ON(list_empty(>hep->urb_list));
urb = container_of(ep->hep->urb_list.next,
struct urb, urb_list);
--
-
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 4/5] USB: ehci: microframe handling fix
From: David Brownell <[EMAIL PROTECTED]>
This patch has a one line oops fix, plus related cleanups.
- The bugfix uses microframe scheduling data given to the hardware to
test "is this a periodic QH", rather than testing for nonzero period.
(Prevents an oops by providing the correct answer.)
- The cleanup going along with the patch should make it clearer what's
going on whenever those bitfields are accessed.
The bug came about when, around January, two new kinds of EHCI interrupt
scheduling operation were added, involving both the high speed (24 KBytes
per millisec) and low/full speed (1-64 bytes per millisec) microframe
scheduling. A driver for the Edirol UA-1000 Audio Capture Unit ran into
the oops; it used one of the newly supported high speed modes.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
drivers/usb/host/ehci-dbg.c |2 +-
drivers/usb/host/ehci-q.c |5 +++--
drivers/usb/host/ehci-sched.c | 13 +++--
drivers/usb/host/ehci.h |5 +
4 files changed, 16 insertions(+), 9 deletions(-)
--- gregkh-2.6.orig/drivers/usb/host/ehci-dbg.c 2005-08-04 17:37:11.0
-0700
+++ gregkh-2.6/drivers/usb/host/ehci-dbg.c 2005-08-04 17:40:08.0
-0700
@@ -527,7 +527,7 @@
p.qh->period,
le32_to_cpup (>hw_info2)
/* uframe masks */
- & 0x,
+ & (QH_CMASK | QH_SMASK),
p.qh);
size -= temp;
next += temp;
--- gregkh-2.6.orig/drivers/usb/host/ehci.h 2005-08-04 17:37:11.0
-0700
+++ gregkh-2.6/drivers/usb/host/ehci.h 2005-08-04 17:40:08.0 -0700
@@ -385,6 +385,11 @@
__le32 hw_info1;/* see EHCI 3.6.2 */
#defineQH_HEAD 0x8000
__le32 hw_info2;/* see EHCI 3.6.2 */
+#defineQH_SMASK0x00ff
+#defineQH_CMASK0xff00
+#defineQH_HUBADDR 0x007f
+#defineQH_HUBPORT 0x3f80
+#defineQH_MULT 0xc000
__le32 hw_current; /* qtd list - see EHCI 3.6.4 */
/* qtd overlay (hardware parts of a struct ehci_qtd) */
--- gregkh-2.6.orig/drivers/usb/host/ehci-q.c 2005-08-04 17:37:11.0
-0700
+++ gregkh-2.6/drivers/usb/host/ehci-q.c2005-08-04 17:40:08.0
-0700
@@ -222,7 +222,7 @@
struct ehci_qh *qh = (struct ehci_qh *) urb->hcpriv;
/* S-mask in a QH means it's an interrupt urb */
- if ((qh->hw_info2 & __constant_cpu_to_le32 (0x00ff)) != 0) {
+ if ((qh->hw_info2 & __constant_cpu_to_le32 (QH_SMASK)) != 0) {
/* ... update hc-wide periodic stats (for usbfs) */
ehci_to_hcd(ehci)->self.bandwidth_int_reqs--;
@@ -428,7 +428,8 @@
/* should be rare for periodic transfers,
* except maybe high bandwidth ...
*/
- if (qh->period) {
+ if ((__constant_cpu_to_le32 (QH_SMASK)
+ & qh->hw_info2) != 0) {
intr_deschedule (ehci, qh);
(void) qh_schedule (ehci, qh);
} else
--- gregkh-2.6.orig/drivers/usb/host/ehci-sched.c 2005-08-04
17:37:11.0 -0700
+++ gregkh-2.6/drivers/usb/host/ehci-sched.c2005-08-04 17:40:08.0
-0700
@@ -301,7 +301,7 @@
dev_dbg (>dev->dev,
"link qh%d-%04x/%p start %d [%d/%d us]\n",
- period, le32_to_cpup (>hw_info2) & 0x,
+ period, le32_to_cpup (>hw_info2) & (QH_CMASK | QH_SMASK),
qh, qh->start, qh->usecs, qh->c_usecs);
/* high bandwidth, or otherwise every microframe */
@@ -385,7 +385,8 @@
dev_dbg (>dev->dev,
"unlink qh%d-%04x/%p start %d [%d/%d us]\n",
- qh->period, le32_to_cpup (>hw_info2) & 0x,
+ qh->period,
+ le32_to_cpup (>hw_info2) & (QH_CMASK | QH_SMASK),
qh, qh->start, qh->usecs, qh->c_usecs);
/* qh->qh_next still "live" to HC */
@@ -411,7 +412,7 @@
* active high speed queues may need bigger delays...
*/
if (list_empty (>qtd_list)
- || (__constant_cpu_to_le32 (0x0ff << 8)
+ || (__constant_cpu_to_le32 (QH_CMASK)
& qh->hw_info2) != 0)
wait = 2;
else
@@
Re: [TCP]: Fix TSO cwnd caching bug
Herbert Xu <[EMAIL PROTECTED]> wrote: > > On Thu, Aug 04, 2005 at 04:58:42PM -0700, Andrew Morton wrote: > > > > Thanks, Guillaume. Herbert, David is travelling and not able to do a lot > > of patchmonkeying. Could you please prepare and submit a final patch? > > OK, here is the final version. Thanks. > It depends on the patch that David > posted earlier on in this thread. Please let me know if you need a > copy of that. Yes 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/
[patch 2/5] pci and yenta: pcibios_bus_to_resource
From: Dominik Brodowski <[EMAIL PROTECTED]>
In yenta_socket, we default to using the resource setting of the CardBus
bridge. However, this is a PCI-bus-centric view of resources and thus needs
to be converted to generic resources first. Therefore, add a call to
pcibios_bus_to_resource() call in between. This function is a mere wrapper on
x86 and friends, however on some others it already exists, is added in this
patch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where
is its pcibios_resource_to_bus() ?).
Signed-off-by: Dominik Brodowski <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
arch/alpha/kernel/pci.c | 16
arch/arm/kernel/bios32.c | 17 +
arch/ppc/kernel/pci.c | 15 +++
arch/ppc64/kernel/pci.c | 20
drivers/pcmcia/yenta_socket.c | 15 ++-
include/asm-alpha/pci.h |3 +++
include/asm-arm/pci.h |4
include/asm-generic/pci.h |8
include/asm-parisc/pci.h |4
include/asm-ppc/pci.h |4
include/asm-ppc64/pci.h |4
11 files changed, 101 insertions(+), 9 deletions(-)
--- gregkh-2.6.orig/arch/alpha/kernel/pci.c 2005-08-04 17:46:04.0
-0700
+++ gregkh-2.6/arch/alpha/kernel/pci.c 2005-08-04 17:46:16.0 -0700
@@ -350,8 +350,24 @@
region->end = res->end - offset;
}
+void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+struct pci_bus_region *region)
+{
+ struct pci_controller *hose = (struct pci_controller *)dev->sysdata;
+ unsigned long offset = 0;
+
+ if (res->flags & IORESOURCE_IO)
+ offset = hose->io_space->start;
+ else if (res->flags & IORESOURCE_MEM)
+ offset = hose->mem_space->start;
+
+ res->start = region->start + offset;
+ res->end = region->end + offset;
+}
+
#ifdef CONFIG_HOTPLUG
EXPORT_SYMBOL(pcibios_resource_to_bus);
+EXPORT_SYMBOL(pcibios_bus_to_resource);
#endif
int
--- gregkh-2.6.orig/arch/arm/kernel/bios32.c2005-08-04 17:46:04.0
-0700
+++ gregkh-2.6/arch/arm/kernel/bios32.c 2005-08-04 17:46:16.0 -0700
@@ -447,9 +447,26 @@
region->end = res->end - offset;
}
+void __devinit
+pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+ struct pci_bus_region *region)
+{
+ struct pci_sys_data *root = dev->sysdata;
+ unsigned long offset = 0;
+
+ if (res->flags & IORESOURCE_IO)
+ offset = root->io_offset;
+ if (res->flags & IORESOURCE_MEM)
+ offset = root->mem_offset;
+
+ res->start = region->start + offset;
+ res->end = region->end + offset;
+}
+
#ifdef CONFIG_HOTPLUG
EXPORT_SYMBOL(pcibios_fixup_bus);
EXPORT_SYMBOL(pcibios_resource_to_bus);
+EXPORT_SYMBOL(pcibios_bus_to_resource);
#endif
/*
--- gregkh-2.6.orig/arch/ppc64/kernel/pci.c 2005-08-04 17:46:04.0
-0700
+++ gregkh-2.6/arch/ppc64/kernel/pci.c 2005-08-04 17:46:16.0 -0700
@@ -108,8 +108,28 @@
region->end = res->end - offset;
}
+void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+ struct pci_bus_region *region)
+{
+ unsigned long offset = 0;
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+
+ if (!hose)
+ return;
+
+ if (res->flags & IORESOURCE_IO)
+ offset = (unsigned long)hose->io_base_virt - pci_io_base;
+
+ if (res->flags & IORESOURCE_MEM)
+ offset = hose->pci_mem_offset;
+
+ res->start = region->start + offset;
+ res->end = region->end + offset;
+}
+
#ifdef CONFIG_HOTPLUG
EXPORT_SYMBOL(pcibios_resource_to_bus);
+EXPORT_SYMBOL(pcibios_bus_to_resource);
#endif
/*
--- gregkh-2.6.orig/arch/ppc/kernel/pci.c 2005-08-04 17:46:04.0
-0700
+++ gregkh-2.6/arch/ppc/kernel/pci.c2005-08-04 17:46:16.0 -0700
@@ -160,6 +160,21 @@
}
EXPORT_SYMBOL(pcibios_resource_to_bus);
+void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+struct pci_bus_region *region)
+{
+ unsigned long offset = 0;
+ struct pci_controller *hose = dev->sysdata;
+
+ if (hose && res->flags & IORESOURCE_IO)
+ offset = (unsigned long)hose->io_base_virt - isa_io_base;
+ else if (hose && res->flags & IORESOURCE_MEM)
+ offset = hose->pci_mem_offset;
+ res->start = region->start + offset;
+ res->end = region->end + offset;
+}
+EXPORT_SYMBOL(pcibios_bus_to_resource);
+
/*
* We need to avoid collisions with `mirrored' VGA ports
* and other strange ISA hardware, so we always want the
--- gregkh-2.6.orig/drivers/pcmcia/yenta_socket.c 2005-08-04
17:46:04.0 -0700
+++
[patch 1/5] PCI: restore BAR values after D3hot->D0 for devices that need it
From: "John W. Linville" <[EMAIL PROTECTED]>
Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
(including BARs) when transitioning from D3hot->D0. This leaves such
a device in an inaccessible state. The patch below causes the BARs
to be restored when enabling such a device, so that its driver will
be able to access it.
The patch also adds pci_restore_bars as a new global symbol, and adds a
correpsonding EXPORT_SYMBOL_GPL for that.
Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
(re)boot. Most drivers call pci_enable_device very early, so devices
left in D3hot that lose configuration during the D3hot->D0 transition
will be inaccessible to their drivers.
Drivers could be modified to account for this, but it would
be difficult to know which drivers need modification. This is
especially true since often many devices are covered by the same
driver. It likely would be necessary to replicate code across dozens
of drivers.
The patch below should trigger only when transitioning from D3hot->D0
(or at boot), and only for devices that have the "no soft reset" bit
cleared in the PM control register. I believe it is safe to include
this patch as part of the PCI infrastructure.
The cleanest implementation of pci_restore_bars was to call
pci_update_resource. Unfortunately, that does not currently exist
for the sparc64 architecture. The patch below includes a null
implemenation of pci_update_resource for sparc64.
Some have expressed interest in making general use of the the
pci_restore_bars function, so that has been exported to GPL licensed
modules.
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
---
arch/sparc64/kernel/pci.c |6
drivers/pci/pci.c | 59 ++
drivers/pci/setup-res.c |2 -
include/linux/pci.h |3 ++
4 files changed, 65 insertions(+), 5 deletions(-)
--- gregkh-2.6.orig/arch/sparc64/kernel/pci.c 2005-08-04 17:37:26.0
-0700
+++ gregkh-2.6/arch/sparc64/kernel/pci.c2005-08-04 17:46:13.0
-0700
@@ -413,6 +413,12 @@
return -EBUSY;
}
+void pci_update_resource(struct pci_dev *dev, struct resource *res, int resno)
+{
+ /* Not implemented for sparc64... */
+ BUG();
+}
+
int pci_assign_resource(struct pci_dev *pdev, int resource)
{
struct pcidev_cookie *pcp = pdev->sysdata;
--- gregkh-2.6.orig/drivers/pci/pci.c 2005-08-04 17:37:26.0 -0700
+++ gregkh-2.6/drivers/pci/pci.c2005-08-04 17:46:13.0 -0700
@@ -222,6 +222,37 @@
}
/**
+ * pci_restore_bars - restore a devices BAR values (e.g. after wake-up)
+ * @dev: PCI device to have its BARs restored
+ *
+ * Restore the BAR values for a given device, so as to make it
+ * accessible by its driver.
+ */
+void
+pci_restore_bars(struct pci_dev *dev)
+{
+ int i, numres;
+
+ switch (dev->hdr_type) {
+ case PCI_HEADER_TYPE_NORMAL:
+ numres = 6;
+ break;
+ case PCI_HEADER_TYPE_BRIDGE:
+ numres = 2;
+ break;
+ case PCI_HEADER_TYPE_CARDBUS:
+ numres = 1;
+ break;
+ default:
+ /* Should never get here, but just in case... */
+ return;
+ }
+
+ for (i = 0; i < numres; i ++)
+ pci_update_resource(dev, >resource[i], i);
+}
+
+/**
* pci_set_power_state - Set the power state of a PCI device
* @dev: PCI device to be suspended
* @state: PCI power state (D0, D1, D2, D3hot, D3cold) we're entering
@@ -239,7 +270,7 @@
int
pci_set_power_state(struct pci_dev *dev, pci_power_t state)
{
- int pm;
+ int pm, need_restore = 0;
u16 pmcsr, pmc;
/* bound the state we're entering */
@@ -278,14 +309,17 @@
return -EIO;
}
+ pci_read_config_word(dev, pm + PCI_PM_CTRL, );
+
/* If we're in D3, force entire word to 0.
* This doesn't affect PME_Status, disables PME_En, and
* sets PowerState to 0.
*/
- if (dev->current_state >= PCI_D3hot)
+ if (dev->current_state >= PCI_D3hot) {
+ if (!(pmcsr & PCI_PM_CTRL_NO_SOFT_RESET))
+ need_restore = 1;
pmcsr = 0;
- else {
- pci_read_config_word(dev, pm + PCI_PM_CTRL, );
+ } else {
pmcsr &= ~PCI_PM_CTRL_STATE_MASK;
pmcsr |= state;
}
@@ -308,6 +342,22 @@
platform_pci_set_power_state(dev, state);
dev->current_state = state;
+
+ /* According to section 5.4.1 of the "PCI BUS POWER MANAGEMENT
+* INTERFACE SPECIFICATION, REV. 1.2", a device transitioning
+* from D3hot to D0 _may_ perform an internal reset, thereby
+* going to "D0 Uninitialized" rather than "D0 Initialized".
+* For example, at least some versions of the 3c905B and the
+*
[patch 0/5] fixes for 2.6.13-rc5
Here are a series of patches against 2.6.13-rc5 that fix a few different bugs in the USB and PCI subsystems. thanks, greg k-h - 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/
[TCP]: Fix TSO cwnd caching bug
On Thu, Aug 04, 2005 at 04:58:42PM -0700, Andrew Morton wrote:
>
> Thanks, Guillaume. Herbert, David is travelling and not able to do a lot
> of patchmonkeying. Could you please prepare and submit a final patch?
OK, here is the final version. It depends on the patch that David
posted earlier on in this thread. Please let me know if you need a
copy of that.
[TCP]: Fix TSO cwnd caching bug
tcp_write_xmit caches the cwnd value indirectly in cwnd_quota.
When tcp_transmit_skb reduces the cwnd because of tcp_enter_cwr,
the cached value becomes invalid.
This patch ensures that the cwnd value is always reread after
each tcp_transmit_skb call.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -972,19 +972,18 @@ static int tcp_write_xmit(struct sock *s
if (unlikely(sk->sk_state == TCP_CLOSE))
return 0;
- skb = sk->sk_send_head;
- if (unlikely(!skb))
- return 0;
-
- tso_segs = tcp_init_tso_segs(sk, skb, mss_now);
- cwnd_quota = tcp_cwnd_test(tp, skb);
- if (unlikely(!cwnd_quota))
- goto out;
-
sent_pkts = 0;
- while (likely(tcp_snd_wnd_test(tp, skb, mss_now))) {
+ while ((skb = sk->sk_send_head)) {
+ tso_segs = tcp_init_tso_segs(sk, skb, mss_now);
BUG_ON(!tso_segs);
+ cwnd_quota = tcp_cwnd_test(tp, skb);
+ if (!cwnd_quota)
+ break;
+
+ if (unlikely(!tcp_snd_wnd_test(tp, skb, mss_now)))
+ break;
+
if (tso_segs == 1) {
if (unlikely(!tcp_nagle_test(tp, skb, mss_now,
(tcp_skb_is_last(sk, skb) ?
@@ -1026,27 +1025,12 @@ static int tcp_write_xmit(struct sock *s
tcp_minshall_update(tp, mss_now, skb);
sent_pkts++;
-
- /* Do not optimize this to use tso_segs. If we chopped up
-* the packet above, tso_segs will no longer be valid.
-*/
- cwnd_quota -= tcp_skb_pcount(skb);
-
- BUG_ON(cwnd_quota < 0);
- if (!cwnd_quota)
- break;
-
- skb = sk->sk_send_head;
- if (!skb)
- break;
- tso_segs = tcp_init_tso_segs(sk, skb, mss_now);
}
if (likely(sent_pkts)) {
tcp_cwnd_validate(sk, tp);
return 0;
}
-out:
return !tp->packets_out && sk->sk_send_head;
}
Re: [PATCH] Speedup FAT filesystem directory reads
Am Donnerstag, 4. August 2005 16:21 schrieb OGAWA Hirofumi:
> Karsten Wiese <[EMAIL PROTECTED]> writes:
>
> > Please give this a try and commit to -mm or mainline, if approved.
>
> Looks good. Thanks. However, I tweaked the patch.
>
> - replace __getblk() to sb_getblk()
> - exclude root-dir of FAT12/FAT16 from readahead
> - exclude (sec_per_clus == 1) from readahead
> - move the all readahead stuff to one inline function
>
> What do you think of the following patch?
Looks better, is smaller and works equally well here, thanks.
I had to hand apply it though as it was slightly scrambled
(by my mail client?) so patch couldn't handle it.
Please send patches as attachment.
Andrew,
please replace the initial version in -mm with this one.
Thanks,
Karsten
From: Karsten Wiese <[EMAIL PROTECTED]>
From: OGAWA Hirofumi <[EMAIL PROTECTED]>
This speeds up directory reads for large FAT partitions, if the buffercache
has to be filled from the drive. Following values were taken from:
$ time find path_to_freshly_mounted_fat > /dev/null
on an otherwise idle system.
FAT with 16KB Clusters on IDE attached drive: Factor 2
FAT with 32KB Clusters on USB2 attached drive: Factor 10 (!)
Its less than 1/10 slower, if the buffercache is uptodate.
The patch introduces the new function fat_dir_readahead().
fat_dir_readahead() calls sb_breadahead() to readahead a whole cluster,
if the requested sector is the first one in a cluster.
It is usefull to do this, because on FAT directories occupy whole
clusters, with the exception of FAT12/FAT16 root dirs.
Readahead is only done, if the cluster's first sector is not uptodate
to avoid overhead, when the buffer cache is already uptodate.
Note that under memory pressure, the maximal byte count wasted
(read: has to be red from disk twice) is 1 cluster's size. Thats 64KB.
fat_dir_readahead() is called from fat__get_entry().
There is also an unrelated cleanup at one spot:
if (bh)
brelse(bh);
is replaced with:
brelse(bh);
brelse() can handle NULL pointer arguments by itself.
Signed-off-by: Karsten Wiese <[EMAIL PROTECTED]>
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
diff -ur linux-2.6.13_orig/fs/fat/dir.c linux-2.6.13/fs/fat/dir.c
--- linux-2.6.13_orig/fs/fat/dir.c 2005-07-31 21:14:20.0 +0200
+++ linux-2.6.13/fs/fat/dir.c 2005-08-04 19:11:21.0 +0200
@@ -30,6 +30,29 @@
| (de - (struct msdos_dir_entry *)bh->b_data);
}
+static inline void fat_dir_readahead(struct inode *dir, sector_t iblock,
+ sector_t phys)
+{
+ struct super_block *sb = dir->i_sb;
+ struct msdos_sb_info *sbi = MSDOS_SB(sb);
+ struct buffer_head *bh;
+ int sec;
+
+ /* This is not a first sector of cluster, or sec_per_clus == 1 */
+ if ((iblock & (sbi->sec_per_clus - 1)) || sbi->sec_per_clus == 1)
+ return;
+ /* root dir of FAT12/FAT16 */
+ if ((sbi->fat_bits != 32) && (dir->i_ino == MSDOS_ROOT_INO))
+ return;
+
+ bh = sb_getblk(sb, phys);
+ if (bh && !buffer_uptodate(bh)) {
+ for (sec = 0; sec < sbi->sec_per_clus; sec++)
+ sb_breadahead(sb, phys + sec);
+ }
+ brelse(bh);
+}
+
/* Returns the inode number of the directory entry at offset pos. If bh is
non-NULL, it is brelse'd before. Pos is incremented. The buffer header is
returned in bh.
@@ -58,6 +81,8 @@
if (err || !phys)
return -1; /* beyond EOF or error */
+ fat_dir_readahead(dir, iblock, phys);
+
*bh = sb_bread(sb, phys);
if (*bh == NULL) {
printk(KERN_ERR "FAT: Directory bread(block %llu) failed\n",
@@ -635,8 +660,7 @@
EODir:
filp->f_pos = cpos;
FillFailed:
- if (bh)
- brelse(bh);
+ brelse(bh);
if (unicode)
free_page((unsigned long)unicode);
out:
Re: [PATCH] dyn-tick3 tweaks
Con Kolivas wrote:
Something like this on top is cleaner and quieter. I'll add this to pending
changes for another version.
Index: linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c
===
--- linux-2.6.13-rc5-ck2.orig/arch/i386/kernel/timers/timer_tsc.c
2005-08-03 11:29:29.0 +1000
+++ linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c2005-08-05
10:22:25.0 +1000
@@ -167,10 +167,20 @@ static void delay_tsc(unsigned long loop
} while ((now-bclock) < loops);
}
+/* update the monotonic base value */
+static inline void update_monotonic_base(unsigned long long last_offset)
+{
+ unsigned long long this_offset;
+
+ this_offset = ((unsigned long long)last_tsc_high << 32) | last_tsc_low;
+ monotonic_base += cycles_2_ns(this_offset - last_offset);
+ write_sequnlock(_lock);
+}
+
All else being equal, it is much better if you unlock in the
same function that takes the lock. For readability.
It looks like you should be able to leave all the flow control
and locking the same, and use update_monotonic_base() to
do the actual update?
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Fri, 5 Aug 2005 08:12 am, Marc Ballarin wrote: > On Wed, 3 Aug 2005 15:59:24 +1000 > > Con Kolivas <[EMAIL PROTECTED]> wrote: > > This is the dynamic ticks patch for i386 as written by Tony Lindgen > > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. > > Patch for 2.6.13-rc5 > > One issue (tested the -rc4 Version on -mm): > - on interrupt flood (ping -f) HZ goes down to 0-4 HZ. > This matches "ticks to skip" below. Coincidence? > > - ping -f complains: > .Warning: time of day goes back (-304us), taking countermeasures. > ... > .Warning: time of day goes back (-33us), taking countermeasures. > > Yet, system time _seems_ to be kept correctly. Interesting... It almost seems like if you throw enough interrupts at it the next_timer_interrupt function gets confused. I wonder if S390 and ARM are seeing this at all since (it seems to me) they use that function? Con - 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.13-rc4-git4: bluetooth oops on pcmcia shutdown
Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > > The attached bluetooth oops can be reliably reproduced on my x86_64 > laptop. It happens when hciattach is still running while a sequence of > "cardctl eject" and then "killproc /sbin/cardmgr" is executed. > Though this seems to point to preempt I could manage to cause similar > oopses on non-preemptible kernels a while ago. Again, it doesn't look like we'll have a quick fix for this, so a bugzilla entry would be appreciated, please. It would help if you can identify an earlier 2.6 kernel which didn't have the bug, 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/
[PATCH] dyn-tick3 tweaks
On Fri, 5 Aug 2005 10:05 am, Con Kolivas wrote:
> Looking yet further into this, if it gotos monotonic_base it will return
> without using any of these variables so it's a harmless warning but we may
> as well initialise them to quieten it.
Something like this on top is cleaner and quieter. I'll add this to pending
changes for another version.
Cheers,
Con
---
Index: linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c
===
--- linux-2.6.13-rc5-ck2.orig/arch/i386/kernel/timers/timer_tsc.c 2005-08-03 11:29:29.0 +1000
+++ linux-2.6.13-rc5-ck2/arch/i386/kernel/timers/timer_tsc.c 2005-08-05 10:22:25.0 +1000
@@ -167,10 +167,20 @@ static void delay_tsc(unsigned long loop
} while ((now-bclock) < loops);
}
+/* update the monotonic base value */
+static inline void update_monotonic_base(unsigned long long last_offset)
+{
+ unsigned long long this_offset;
+
+ this_offset = ((unsigned long long)last_tsc_high << 32) | last_tsc_low;
+ monotonic_base += cycles_2_ns(this_offset - last_offset);
+ write_sequnlock(_lock);
+}
+
#ifdef CONFIG_HPET_TIMER
static void mark_offset_tsc_hpet(void)
{
- unsigned long long this_offset, last_offset;
+ unsigned long long last_offset;
unsigned long offset, temp, hpet_current;
write_seqlock(_lock);
@@ -198,10 +208,7 @@ static void mark_offset_tsc_hpet(void)
}
hpet_last = hpet_current;
- /* update the monotonic base value */
- this_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low;
- monotonic_base += cycles_2_ns(this_offset - last_offset);
- write_sequnlock(_lock);
+ update_monotonic_base(last_offset);
/* calculate delay_at_last_interrupt */
/*
@@ -347,7 +354,7 @@ static void mark_offset_tsc(void)
int count;
int countmp;
static int count1 = 0;
- unsigned long long this_offset, last_offset;
+ unsigned long long last_offset;
static int lost_count = 0;
write_seqlock(_lock);
@@ -368,8 +375,10 @@ static void mark_offset_tsc(void)
rdtsc(last_tsc_low, last_tsc_high);
- if (dyn_tick_enabled())
- goto monotonic_base;
+ if (dyn_tick_enabled()) {
+ update_monotonic_base(last_offset);
+ return;
+ }
spin_lock(_lock);
outb_p(0x00, PIT_MODE); /* latch the count ASAP */
@@ -439,15 +448,7 @@ static void mark_offset_tsc(void)
} else
lost_count = 0;
- monotonic_base:
-
- /* update the monotonic base value */
- this_offset = ((unsigned long long)last_tsc_high<<32)|last_tsc_low;
- monotonic_base += cycles_2_ns(this_offset - last_offset);
- write_sequnlock(_lock);
-
- if (dyn_tick_enabled())
- return;
+ update_monotonic_base(last_offset);
/* calculate delay_at_last_interrupt */
count = ((LATCH-1) - count) * TICK_SIZE;
Re: 2.6.13-rc4: yenta_socket and swsusp
On Thu, 2005-08-04 at 17:15 -0700, Andrew Morton wrote: > Seems that the linux-kernel list has the same result ;( Are you serious, LKML is subscribers only now? Lee - 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.13-rc4: yenta_socket and swsusp
Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > > [now sending to lkml as sending to the pcmcia list without being > subscribed seems to go to /dev/null] Seems that the linux-kernel list has the same result ;( > I do have problems with yenta_socket on my x86_64 laptop which appear > when using swsusp (suspend to disk mode). > > 1. When I do not access any pcmcia device from initrd during boot >I have to terminate cardmgr, otherwise suspend to disk hangs. >For 2.6.11 it was sufficient to call 'cardctl eject'. > > 2. When I have to access a pcmcia device from initrd during boot >(there's required crypto keys stored on a pcmcia flash disk) >and I do not unload yenta_socket prior to suspend the laptop >spontaneously reboots or just hangs on resume when swsusp has >finished loading. > > 3. If I do not unload the pcmcia modules prior to suspend with >rmmod -w unloading yenta_socket fails. > > 4. If I do unload the pcmcia modules in a loop with rmmod -w >but no delay between unloading the modules it happens from >time to time that yenta_socket unloading hangs with a use >count of 2 when there is definitely no more user of the module. >A delay of 50 msec after unload of each pcmcia module seems >to cure this. > > 5. If I insert yenta_socket within the first few seconds after resume >the laptop spontaneously reboots. A 5 second delay seems to cure >this most of the time. OK so we have one solid regression there. Are the other problems also new since 2.6.11? Could you please retest 2.6.13-rc6 when it's out and if problems remain, raise a bugzilla.kernel.org entry so we can keep track of the problem? Thanks. (I'm trying to get all unattended and older-than-a-few-days bug reports pushed over to bugzilla so they don't get lost). > BTW: > Did I read this right? PCMCIA control ioctl (needed for pcmcia-cs > [cardmgr, cardctl]) scheduled for removal in november *this* year? So a > 3 month warning for everybody is sufficient? Probably only one kernel > release? So much for sufficient backwards compatability. Especially as > the tools stated to be required aren't even released as of today (hint: > module-init-tools 3.2). Grrr. Three months does sound optimistic. Dominik, wouldn't a year be better? - 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: How to get the physical page addresses from a kernel virtual address for DMA SG List?
You may want to take a look at the user-mode driver infrastructure patches, which do almost exactly what you're trying to do. Get them from http://www.gelato.unsw.edu.au/cgi-bin/viewcvs.cgi/cvs/kernel/usrdrivers/kernel-2.6.12-rc3/ -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au The technical we do immediately, the political takes *forever* - 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] no-idle-hz aka dynamic ticks-2
On Fri, 5 Aug 2005 10:02 am, Con Kolivas wrote: > On Thu, 4 Aug 2005 07:09 am, Pavel Machek wrote: > > Hi! > > > > > > > As promised, here is an updated patch for the newly released > > > > > 2.6.13-rc5. Boots and runs fine on P4HT (SMP+SMT kernel) built with > > > > > gcc 4.0.1. > > > > > > > > Doesn't compile for me w/ gcc 3.4.4: > > > > > > Thanks for the report. Tiny change required. Here is a respun patch. > > > > I'm not sure if you added them, but... > > > > CC arch/i386/kernel/timers/timer_tsc.o > > arch/i386/kernel/timers/timer_tsc.c: In function `mark_offset_tsc': > > arch/i386/kernel/timers/timer_tsc.c:345: warning: `lost' might be used > > uninitialized in this function arch/i386/kernel/timers/timer_tsc.c:345: > > warning: `delay' might be used uninitialized in this function > > arch/i386/kernel/timers/timer_tsc.c:347: warning: `count' might be used > > uninitialized in this function > > Indeed the goto will bypass the setting of these variables and they will be > uninitialised. Will fix with next version, thanks. Looking yet further into this, if it gotos monotonic_base it will return without using any of these variables so it's a harmless warning but we may as well initialise them to quieten it. Cheers, Con - 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] no-idle-hz aka dynamic ticks-2
On Thu, 4 Aug 2005 07:09 am, Pavel Machek wrote: > Hi! > > > > > As promised, here is an updated patch for the newly released > > > > 2.6.13-rc5. Boots and runs fine on P4HT (SMP+SMT kernel) built with > > > > gcc 4.0.1. > > > > > > Doesn't compile for me w/ gcc 3.4.4: > > > > Thanks for the report. Tiny change required. Here is a respun patch. > > I'm not sure if you added them, but... > > CC arch/i386/kernel/timers/timer_tsc.o > arch/i386/kernel/timers/timer_tsc.c: In function `mark_offset_tsc': > arch/i386/kernel/timers/timer_tsc.c:345: warning: `lost' might be used > uninitialized in this function arch/i386/kernel/timers/timer_tsc.c:345: > warning: `delay' might be used uninitialized in this function > arch/i386/kernel/timers/timer_tsc.c:347: warning: `count' might be used > uninitialized in this function Indeed the goto will bypass the setting of these variables and they will be uninitialised. Will fix with next version, thanks. Con - 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.13-rc4 - kernel panic - BUG at net/ipv4/tcp_output.c:918
Guillaume Pelat <[EMAIL PROTECTED]> wrote: > > Hi, > > Herbert Xu wrote: > > On Thu, Aug 04, 2005 at 01:33:29PM +1000, herbert wrote: > > > >>So I suppose we should reset cwnd_quota after tcp_transmit_skb? > > > > Please try this patch to see if this is really the problem or not. > > > > Thanks, > > I just applied your patch, and it seems to work :) > 2 hours uptime, and no crash yet (without the patch, it was crashing a > few mins only after booting). > So i think the bug is crushed :) > Thanks, Guillaume. Herbert, David is travelling and not able to do a lot of patchmonkeying. Could you please prepare and submit a final patch? 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/
[patch] Add write protection switch handling to the PXA MMC driver
Add a write protection switch handling code to the PXA MMC driver so
that platform specific code can provide it if available (extending the
MMC/SD patches in -mm).
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
Index: linux-2.6.12/include/asm-arm/arch-pxa/mmc.h
===
--- linux-2.6.12.orig/include/asm-arm/arch-pxa/mmc.h2005-08-05
00:29:17.0 +0100
+++ linux-2.6.12/include/asm-arm/arch-pxa/mmc.h 2005-08-05 00:29:43.0
+0100
@@ -10,6 +10,7 @@
struct pxamci_platform_data {
unsigned int ocr_mask; /* available voltages */
int (*init)(struct device *, irqreturn_t (*)(int, void *, struct
pt_regs *), void *);
+ int (*get_ro)(struct device *);
void (*setpower)(struct device *, unsigned int);
void (*exit)(struct device *, void *);
};
Index: linux-2.6.12/drivers/mmc/pxamci.c
===
--- linux-2.6.12.orig/drivers/mmc/pxamci.c 2005-08-05 00:29:17.0
+0100
+++ linux-2.6.12/drivers/mmc/pxamci.c 2005-08-05 00:29:43.0 +0100
@@ -362,6 +362,16 @@
pxamci_start_cmd(host, mrq->cmd, cmdat);
}
+static int pxamci_get_ro(struct mmc_host *mmc)
+{
+ struct pxamci_host *host = mmc_priv(mmc);
+
+ if (host->pdata && host->pdata->get_ro)
+ return host->pdata->get_ro(mmc->dev);
+ /* Host doesn't support read only detection so assume writeable */
+ return 0;
+}
+
static void pxamci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct pxamci_host *host = mmc_priv(mmc);
@@ -401,6 +411,7 @@
static struct mmc_host_ops pxamci_ops = {
.request= pxamci_request,
+ .get_ro = pxamci_get_ro,
.set_ios= pxamci_set_ios,
};
-
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] Corgi: Add MMC/SD write protection switch handling
Add MMC/SD write protection switch handling for the Corgi platform
(extending the MMC/SD patches in -mm).
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
Index: linux-2.6.12/arch/arm/mach-pxa/corgi.c
===
--- linux-2.6.12.orig/arch/arm/mach-pxa/corgi.c 2005-08-05 00:29:17.0
+0100
+++ linux-2.6.12/arch/arm/mach-pxa/corgi.c 2005-08-05 00:29:45.0
+0100
@@ -160,6 +160,11 @@
}
}
+static int corgi_mci_get_ro(struct device *dev)
+{
+ return GPLR(CORGI_GPIO_nSD_WP) & GPIO_bit(CORGI_GPIO_nSD_WP);
+}
+
static void corgi_mci_exit(struct device *dev, void *data)
{
free_irq(CORGI_IRQ_GPIO_nSD_DETECT, data);
@@ -169,6 +174,7 @@
static struct pxamci_platform_data corgi_mci_platform_data = {
.ocr_mask = MMC_VDD_32_33|MMC_VDD_33_34,
.init = corgi_mci_init,
+ .get_ro = corgi_mci_get_ro,
.setpower = corgi_mci_setpower,
.exit = corgi_mci_exit,
};
-
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: ahci, SActive flag, and the HD activity LED
On 8/3/05, Jens Axboe <[EMAIL PROTECTED]> wrote: > On Wed, Aug 03 2005, Martin Wilck wrote: > > Have you (or has anybody else) also seen the wrong behavior of the > > activity LED? > > No, but I have observed that SActive never gets cleared by the device > for non-NCQ commands (which is probably which gets you the stuck LED on > some systems?), which to me is another indication that we should not be > setting the tag bits for those commands. The drives won't send a SetBits FIS when not using NCQ, as it can really confuse some host adapters that don't understand NCQ. I'd imagine you're correct that the driver shouldn't be setting the bit in the first place. --eric - 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: NUMA policy interface
On Fri, 5 Aug 2005, Andi Kleen wrote: > None of them seem very attractive to me. I would prefer to just > not support external accesses keeping things lean and fast. That is a surprising statement given what we just discussed. Things are not lean and fast but weirdly screwed up. The policy layer is significantly impacted by historical contingencies rather than designed in a clean way. It cannot even deliver the functionality it was designed to deliver (see BIND). > Individual physical page migration is quite different from > address space migration. Address space migration? That is something new in this discussion. So could you explain what you mean by that? I have looked at page migration in a variety of contexts and could not see much difference. - 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] Corgi: Add keyboard and touchscreen device definitions
Add keyboard and touchscreen device definitions for corgi.
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
Index: linux-2.6.12/arch/arm/mach-pxa/corgi.c
===
--- linux-2.6.12.orig/arch/arm/mach-pxa/corgi.c 2005-08-05 00:29:45.0
+0100
+++ linux-2.6.12/arch/arm/mach-pxa/corgi.c 2005-08-05 00:29:47.0
+0100
@@ -99,6 +99,27 @@
/*
+ * Corgi Keyboard Device
+ */
+static struct platform_device corgikbd_device = {
+ .name = "corgi-keyboard",
+ .id = -1,
+};
+
+
+/*
+ * Corgi Touch Screen Device
+ */
+static struct platform_device corgits_device = {
+ .name = "corgi-ts",
+ .dev= {
+ .parent = _device.dev,
+ },
+ .id = -1,
+};
+
+
+/*
* MMC/SD Device
*
* The card detect interrupt isn't debounced so we delay it by HZ/4
@@ -180,6 +201,7 @@
};
+
/*
* USB Device Controller
*/
@@ -205,7 +227,9 @@
_device,
_device,
_device,
+ _device,
_device,
+ _device,
};
static void __init corgi_init(void)
-
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] IDE disks show invalid geometries in /proc/ide/hd*/geometry
On 8/4/05, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > All of these numbers are virtual, since CHS is not really used anymore, as > we know. But, which of these fake CHS values (16383/16/63 | 65535/16/63 | > 1023/255/63) is the right one? 255/63/4982 is another matter, since it > [almost] matches the actual size of the disk while the other three are just > "for the bios". What do you mean by right? Not one of those above values has any physical meaning --eric - 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: NUMA policy interface
On Thu, Aug 04, 2005 at 03:19:52PM -0700, Christoph Lameter wrote: > There are three possibilites: > > 1. do what cpusets is doing by versioning. > > 2. Have the task notifier access the task_struct information. > See http://lwn.net/Articles/145232/ "A new path to the refrigerator" > > 3. Maybe the easiest: Require mmap_sem to be taken for all policy > accesses. Currently its only require for vma policies. Then we need > to make a copy of the policy at some point so that alloc_pages can > access policy information lock free. This may also allow us to fix > the bind issue if we would f.e. keep a bitmap in the taskstruct or (ab)use > the cpusets map. None of them seem very attractive to me. I would prefer to just not support external accesses keeping things lean and fast. > > If they cannot afford enough disk space it might be possible > > to do the page migration in swap cache like Hugh proposed. > > This code already exist in the memory hotplug code base and Ray already > had a working implementation for page migration. The migration code will > also be necessary in order to relocate pages with ECC single bit failures > that Russ is working on (of course that will only work for some pages) and > for Mel Gorman's defragmentation approach (if we ever get the split into > differnet types of memory chunks in). Individual physical page migration is quite different from address space migration. -Andi - 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] PNPACPI: fix IRQ and 64-bit address decoding
Maybe the third time's the charm :-) Added a bugfix
(pcibios_penalize_isa_irq()) and a workaround for HP
HPET firmware description since last time. The workaround
accepts stuff that is illegal according to the spec,
so speak up if you think this is a problem. It seems
fairly safe to me.
Use types that match the ACPI resource structures. Previously
the u64 value from an RSTYPE_ADDRESS64 was passed as an int,
which corrupts the value.
Move pcibios_penalize_isa_irq() to pnpacpi_parse_allocated_irqresource().
Previously we passed the GSI, not the IRQ, and we did it even if parsing
the IRQ resource failed.
Parse IRQ descriptors that contain multiple interrupts. This violates
the spec (in _CRS, only one interrupt per descriptor is allowed), but
some firmware, e.g., HP rx7620 and rx8620 descriptions of HPET, has this
bug.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm/drivers/pnp/pnpacpi/rsparser.c
===
--- work-mm.orig/drivers/pnp/pnpacpi/rsparser.c 2005-08-04 16:41:04.0
-0600
+++ work-mm/drivers/pnp/pnpacpi/rsparser.c 2005-08-04 16:42:52.0
-0600
@@ -73,25 +73,35 @@
}
static void
-pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, int irq)
+pnpacpi_parse_allocated_irqresource(struct pnp_resource_table * res, u32 gsi,
+ int edge_level, int active_high_low)
{
int i = 0;
+ int irq;
+
+ if (!valid_IRQ(gsi))
+ return;
+
while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) &&
i < PNP_MAX_IRQ)
i++;
- if (i < PNP_MAX_IRQ) {
- res->irq_resource[i].flags = IORESOURCE_IRQ; //Also clears
_UNSET flag
- if (irq < 0) {
- res->irq_resource[i].flags |= IORESOURCE_DISABLED;
- return;
- }
- res->irq_resource[i].start =(unsigned long) irq;
- res->irq_resource[i].end = (unsigned long) irq;
+ if (i >= PNP_MAX_IRQ)
+ return;
+
+ res->irq_resource[i].flags = IORESOURCE_IRQ; // Also clears _UNSET flag
+ irq = acpi_register_gsi(gsi, edge_level, active_high_low);
+ if (irq < 0) {
+ res->irq_resource[i].flags |= IORESOURCE_DISABLED;
+ return;
}
+
+ res->irq_resource[i].start = irq;
+ res->irq_resource[i].end = irq;
+ pcibios_penalize_isa_irq(irq, 1);
}
static void
-pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, int dma)
+pnpacpi_parse_allocated_dmaresource(struct pnp_resource_table * res, u32 dma)
{
int i = 0;
while (i < PNP_MAX_DMA &&
@@ -103,14 +113,14 @@
res->dma_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->dma_resource[i].start =(unsigned long) dma;
- res->dma_resource[i].end = (unsigned long) dma;
+ res->dma_resource[i].start = dma;
+ res->dma_resource[i].end = dma;
}
}
static void
pnpacpi_parse_allocated_ioresource(struct pnp_resource_table * res,
- int io, int len)
+ u32 io, u32 len)
{
int i = 0;
while (!(res->port_resource[i].flags & IORESOURCE_UNSET) &&
@@ -122,14 +132,14 @@
res->port_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->port_resource[i].start = (unsigned long) io;
- res->port_resource[i].end = (unsigned long)(io + len - 1);
+ res->port_resource[i].start = io;
+ res->port_resource[i].end = io + len - 1;
}
}
static void
pnpacpi_parse_allocated_memresource(struct pnp_resource_table * res,
- int mem, int len)
+ u64 mem, u64 len)
{
int i = 0;
while (!(res->mem_resource[i].flags & IORESOURCE_UNSET) &&
@@ -141,8 +151,8 @@
res->mem_resource[i].flags |= IORESOURCE_DISABLED;
return;
}
- res->mem_resource[i].start = (unsigned long) mem;
- res->mem_resource[i].end = (unsigned long)(mem + len - 1);
+ res->mem_resource[i].start = mem;
+ res->mem_resource[i].end = mem + len - 1;
}
}
@@ -151,27 +161,28 @@
void *data)
{
struct pnp_resource_table * res_table = (struct pnp_resource_table
*)data;
+ int i;
switch (res->id) {
case ACPI_RSTYPE_IRQ:
- if ((res->data.irq.number_of_interrupts > 0) &&
- valid_IRQ(res->data.irq.interrupts[0])) {
- pnpacpi_parse_allocated_irqresource(res_table,
- acpi_register_gsi(res->data.irq.interrupts[0],
- res->data.irq.edge_level,
-
Re: [PATCH] push rounding up of relative request to schedule_timeout()
Hi,
On Thu, 4 Aug 2005, Nishanth Aravamudan wrote:
> > What makes you think the comment is correct? This comment was added at
> > 2.4.3, while schedule_timeout() has this behaviour since it was added at
> > 2.1.127.
>
> Fair enough. Should we change the comment?
It can't hurt to fix the comment.
> If a user requests schedule_timeout(HZ/100); which, if HZ is 1000, is 10
> jiffies, yes? But, since we are between ticks, we want to actually add
> that request to the next interval, not to the current one. Otherwise, we
> do have the possibility of returning early. Currently, we require
> callers to add the +1 to their request, and thus they only add it to the
> first one. The problem with my patch which pushed it to
> schedule_timeout(), is that we will do +1 to every request. I'm not
> sure, without some sort of "persistent" timeout control structure, how
> we get around that, though, in the schedule_timeout() case. Does that
> make any more sense?
I don't disagree, but please create some sane interfaces, e.g. something
like below. This allows to first convert as much as possible
schedule_timeout() users and then we can still change the
schedule_timeout() interface.
bye, Roman
include/linux/sched.h | 17 +++
kernel/timer.c| 71 +++---
2 files changed, 78 insertions(+), 10 deletions(-)
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h2005-06-18 15:00:59.0
+0200
+++ linux-2.6/include/linux/sched.h 2005-08-04 23:42:43.0 +0200
@@ -182,9 +182,24 @@ extern void scheduler_tick(void);
extern int in_sched_functions(unsigned long addr);
#defineMAX_SCHEDULE_TIMEOUTLONG_MAX
-extern signed long FASTCALL(schedule_timeout(signed long timeout));
+extern void schedule_until(unsigned long expire) fastcall;
+extern int schedule_until_intr(unsigned long expire) fastcall;
+extern int schedule_until_unintr(unsigned long expire) fastcall;
+extern signed long schedule_timeout(signed long timeout) fastcall;
+extern int schedule_timeout_intr(signed long timeout) fastcall;
+extern int schedule_timeout_unintr(signed long timeout) fastcall;
asmlinkage void schedule(void);
+static inline int schedule_timeout_msecs_intr(unsigned int timeout)
+{
+ return schedule_timeout_intr(msecs_to_jiffies(timeout));
+}
+
+static inline int schedule_timeout_msecs_unintr(unsigned int timeout)
+{
+ return schedule_timeout_unintr(msecs_to_jiffies(timeout));
+}
+
struct namespace;
/* Maximum number of active map areas.. This is a random (large) number */
Index: linux-2.6/kernel/timer.c
===
--- linux-2.6.orig/kernel/timer.c 2005-06-18 15:01:12.0 +0200
+++ linux-2.6/kernel/timer.c2005-08-04 23:42:36.0 +0200
@@ -1049,6 +1049,67 @@ static void process_timeout(unsigned lon
wake_up_process((task_t *)__data);
}
+fastcall __sched void schedule_until(unsigned long expire)
+{
+ struct timer_list timer;
+
+ init_timer();
+ timer.expires = expire;
+ timer.data = (unsigned long) current;
+ timer.function = process_timeout;
+
+ add_timer();
+ schedule();
+ del_singleshot_timer_sync();
+}
+EXPORT_SYMBOL(schedule_until);
+
+fastcall __sched int schedule_until_intr(unsigned long expire)
+{
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_until(expire);
+ return time_before(expire, jiffies);
+}
+EXPORT_SYMBOL(schedule_until_intr);
+
+fastcall __sched int schedule_until_unintr(unsigned long expire)
+{
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_until(expire);
+ return time_before(expire, jiffies);
+}
+EXPORT_SYMBOL(schedule_until_intr);
+
+fastcall __sched int schedule_timeout_intr(signed long timeout)
+{
+ unsigned long expire;
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ if (timeout >= MAX_SCHEDULE_TIMEOUT - 1) {
+ schedule();
+ return 1;
+ }
+ expire = jiffies + timeout + 1;
+ schedule_until(expire);
+ return time_before(expire, jiffies);
+}
+EXPORT_SYMBOL(schedule_timeout_intr);
+
+fastcall __sched int schedule_timeout_unintr(signed long timeout)
+{
+ unsigned long expire;
+
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ if (timeout >= MAX_SCHEDULE_TIMEOUT - 1) {
+ schedule();
+ return 1;
+ }
+ expire = jiffies + timeout + 1;
+ schedule_until(expire);
+ return time_before(expire, jiffies);
+}
+EXPORT_SYMBOL(schedule_timeout_unintr);
+
/**
* schedule_timeout - sleep until timeout
* @timeout: timeout value in jiffies
@@ -1077,7 +1138,6 @@ static void process_timeout(unsigned lon
*/
fastcall signed long __sched schedule_timeout(signed long timeout)
{
- struct timer_list timer;
[PATCH] fix voyager compile after machine_emergency_restart breakage
[PATCH] i386: Implement machine_emergency_reboot
introduced this new function into arch/i386/reboot.c. However,
subarchitectures are entitled to implement their own copies of reboot.c
from which this new function is now missing.
It looks like visws will also need a similar fixup
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
diff --git a/arch/i386/mach-voyager/voyager_basic.c
b/arch/i386/mach-voyager/voyager_basic.c
--- a/arch/i386/mach-voyager/voyager_basic.c
+++ b/arch/i386/mach-voyager/voyager_basic.c
@@ -279,6 +279,13 @@ machine_restart(char *cmd)
}
void
+machine_emergency_restart(void)
+{
+ /*for now, just hook this to a warm restart */
+ machine_restart(NULL);
+}
+
+void
mca_nmi_hook(void)
{
__u8 dumpval __attribute__((unused)) = inb(0xf823);
-
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.13-rc5-git2 does not boot on (my) amd64
On Fri, Aug 05, 2005 at 12:06:25AM +0100, Hugh Dickins wrote: > On Thu, 5 Aug 2005, Andi Kleen wrote: > > [EMAIL PROTECTED] (Danny ter Haar) writes: > > > > > > Freeing unused kernel memory: 248k freed > > > VM: killing process hotplug > > > VM: killing process hotplug > > > VM: killing process hotplug > > > VM: killing process hotplug > > > Unable to handle kernel paging request at fff28017b5be RIP: > > > [] > > > > Looks weird. Just to make sure can you do a make distclean and try > > again? It might be a bad compile. > > No, like Pavel's and Martin's reports, this is just an effect > of the not-quite-fully-baked do_wp_page/get_user_pages race fix in > 2.6.13-rc5-git2, which AlexN reported earlier. Should now be fully > fixed in Linus' current git, and in the 2.6.13-rc6 akpm prophesies > to be coming soon - please all test that. Yes. I didn't read the mail fully before replying to that one. -Andi - 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] no-idle-hz aka dynamic ticks-2
Hi! > > > As promised, here is an updated patch for the newly released 2.6.13-rc5. > > > Boots and runs fine on P4HT (SMP+SMT kernel) built with gcc 4.0.1. > > > > Doesn't compile for me w/ gcc 3.4.4: > > Thanks for the report. Tiny change required. Here is a respun patch. I tried setting DYN_TICK_USE_APIC, and it got even worse. Basically machine was frozen; if I pressed enough keys, it moved forward, then froze again. Pavel -- teflon -- maybe it is a trademark, but it should not be. - 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.13-rc5-git2 does not boot on (my) amd64
--Hugh Dickins <[EMAIL PROTECTED]> wrote (on Friday, August 05, 2005 00:06:25 +0100): > On Thu, 5 Aug 2005, Andi Kleen wrote: >> [EMAIL PROTECTED] (Danny ter Haar) writes: >> > >> > Freeing unused kernel memory: 248k freed >> > VM: killing process hotplug >> > VM: killing process hotplug >> > VM: killing process hotplug >> > VM: killing process hotplug >> > Unable to handle kernel paging request at fff28017b5be RIP: >> > [] >> >> Looks weird. Just to make sure can you do a make distclean and try >> again? It might be a bad compile. > > No, like Pavel's and Martin's reports, this is just an effect > of the not-quite-fully-baked do_wp_page/get_user_pages race fix in > 2.6.13-rc5-git2, which AlexN reported earlier. Should now be fully > fixed in Linus' current git, and in the 2.6.13-rc6 akpm prophesies > to be coming soon - please all test that. OK, nightly builds tests should auto-appear on http://test.kernel.org tommorow morning. I'll try to remember to look for it; if you remember before I wake up Hugh, should be published there ... ;-) Thanks for the feedback, M - 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/
networking problems when using gcc 4.0.1
On Wed, Aug 03, 2005 at 08:53:52PM -0400, Mathieu Chouquet-Stringer wrote: > > Moreover I get some weird networking problems which prevent setting up the > routes (RNETLINK invalid argument messages) when I compile my kernel with > 4.0.1 while the same kernel, same config works fine compiled with 3.2.3... > > So eventhough 4.0 is supposed to be supported, it doesn't work too well in > my case. I haven't heard of such a problem. Please give a complete bug report: - exact error messages - kernel version - self-compiled gcc or distrbution compiler? > Mathieu Chouquet-Stringer cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 patch] remove support for gcc < 3.2
On Thu, Aug 04, 2005 at 08:54:47AM +0200, Jan-Benedict Glaw wrote: >... > Current GCC from CVS (plus minor configury patches) seems to work. We > had -fno-unit-at-a-time missing in our arch Makefile which hides a bug > in kernel's sources. > > I guess that if you remove -fno-unit-at-a-time from i386 and use a > current GCC, you'll run into that fun, too. What bug exactly? I'm sometimes using kernels compiled with gcc 4.0 and without -fno-unit-at-a-time and except for the kernel image being smaller I haven't noticed any difference. Besides this, all architectures except i386 and um are not disabling unit-at-a-time. There are a few parts of the kernel that might still have stack problems with unit-at-a-time, but I assume that's not what you are talking about? > MfG, JBG >... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.13-rc5-git2 does not boot on (my) amd64
On Thu, 5 Aug 2005, Andi Kleen wrote: > [EMAIL PROTECTED] (Danny ter Haar) writes: > > > > Freeing unused kernel memory: 248k freed > > VM: killing process hotplug > > VM: killing process hotplug > > VM: killing process hotplug > > VM: killing process hotplug > > Unable to handle kernel paging request at fff28017b5be RIP: > > [] > > Looks weird. Just to make sure can you do a make distclean and try > again? It might be a bad compile. No, like Pavel's and Martin's reports, this is just an effect of the not-quite-fully-baked do_wp_page/get_user_pages race fix in 2.6.13-rc5-git2, which AlexN reported earlier. Should now be fully fixed in Linus' current git, and in the 2.6.13-rc6 akpm prophesies to be coming soon - please all test that. Hugh - 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: Getting rid of SHMMAX/SHMALL ?
Andi Kleen wrote on Thursday, August 04, 2005 3:54 PM > > This might be too low on large system. We usually stress shm pretty hard > > for db application and usually use more than 87% of total memory in just > > one shm segment. So I prefer either no limit or a tunable. > > With large system you mean >32GB right? Yes, between 32 GB - 128 GB. On larger numa box in the 256 GB and upward, we have to break shm segment into one per-numa-node and then the limit should be OK. I was concerned with SMP box with large memory. > I think on a large systems some tuning is reasonable because they likely > have trained admins. I'm more worried on reasonable defaults for the > class of systems with 0-4GB Sounds reasonable to me. - Ken - 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: Getting rid of SHMMAX/SHMALL ?
Andi Kleen wrote on Thursday, August 04, 2005 6:24 AM > I think we should just get rid of the per process limit and keep > the global limit, but make it auto tuning based on available memory. > That is still not very nice because that would likely keep it < available > memory/2, but I suspect databases usually want more than that. So > I would even make it bigger than tmpfs for reasonably big machines. > Let's say > > if (main memory >= 1GB) > maxmem = main memory - main memory/8 This might be too low on large system. We usually stress shm pretty hard for db application and usually use more than 87% of total memory in just one shm segment. So I prefer either no limit or a tunable. - Ken - 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: Getting rid of SHMMAX/SHMALL ?
On Thu, Aug 04, 2005 at 03:49:37PM -0700, Chen, Kenneth W wrote: > Andi Kleen wrote on Thursday, August 04, 2005 6:24 AM > > I think we should just get rid of the per process limit and keep > > the global limit, but make it auto tuning based on available memory. > > That is still not very nice because that would likely keep it < available > > memory/2, but I suspect databases usually want more than that. So > > I would even make it bigger than tmpfs for reasonably big machines. > > Let's say > > > > if (main memory >= 1GB) > > maxmem = main memory - main memory/8 > > This might be too low on large system. We usually stress shm pretty hard > for db application and usually use more than 87% of total memory in just > one shm segment. So I prefer either no limit or a tunable. With large system you mean >32GB right? I think on a large systems some tuning is reasonable because they likely have trained admins. I'm more worried on reasonable defaults for the class of systems with 0-4GB The /8 was to account for the overhead of page tables and mem_map and leave some other memory for the system, but you're right it might be less with hugetlbfs. -Andi - 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: [ACPI] Re: 2.6.13-rc3-mm3
Michael Thonke <[EMAIL PROTECTED]> wrote: > > Moore, Robert schrieb: > > >+ACPI-0287: *** Error: Region SystemMemory(0) has no handler > >+ACPI-0127: *** Error: acpi_load_tables: Could not load namespace: > >AE_NOT_EXIST > >+ACPI-0136: *** Error: acpi_load_tables: Could not load tables: > > > >This looks like a nasty case where some executable code in the table is > >attempting to access a SystemMemory operation region before any OpRegion > >handlers are initialized. > > > >We certainly want to see the output of acpidump to attempt to diagnose > >and/or reproduce the problem. > > > >Bob > > > > > > > > > Sorry for double post. > > With this mail I hand over the acpidump output with the pmtools > Andrew pointed me to. > > And a dmesg output with CONFIG_KALLSYMS=y. > > > I attached them in bz2 format, because of the length. > > I hope we find the problem. > Michael, I'm assuming that a) this problem remains in those -mm kernels which include git-acpi.patch and that b) the problems are not present in 2.6.13-rc5 or 2.6.13-rc6, yes? So I think we have a bug in git-acpi.patch? If that's all correct then can you please test the next -mm (which will include git-acpi.patch - the most recent -mm did not) and if the bug's still there can you raise a bugzilla.kernel.org entry for it? We seem to have a handful of bug reports against the -mm acpi patch. 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: Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
On Fri, 2005-08-05 at 00:03 +0200, Bodo Eggert wrote: > My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. > 2.6.12 does not show this behaviour. I'm out of town at the moment, could you maybe diff radeonfb between working & non-working and CC me the diff ? I don't have my work stuff at hand not my kernel images so... Thanks, Ben. - 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: NUMA policy interface
On Thu, Aug 04, 2005 at 03:19:52PM -0700, Christoph Lameter wrote: > This code already exist in the memory hotplug code base and Ray already > had a working implementation for page migration. The migration code will > also be necessary in order to relocate pages with ECC single bit failures > that Russ is working on (of course that will only work for some pages) and > for Mel Gorman's defragmentation approach (if we ever get the split into > differnet types of memory chunks in). Yup, we need page migration for memory hotplug. However, for hotplug we are not too concerned about where the pages are migrated to. Our primary concern is to move them out of the block/section that we want to offline. Suspect this is the same for pages with ECC single bit failures. In fact, this is one possible use of the hotplug code. Notice a failure. Migrate all pages off the containing DIMM. Offline section corresponding to DIMM. Replace the DIMM. Online section corresponding to DIMM. Of course, your hardware needs to be able to do this. -- Mike - 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: Fw: ati-remote strangeness from 2.6.12 onwards
Ryan Brown <[EMAIL PROTECTED]> wrote:
>
> Sorry Andrew, but the diff was incorrectly made, the updated patch,
> reverts the changes too TV, DVD and OK Button, from 2.6.12-rc1.
hm, this was about 20 patches and 300 emails ago and I've forgotten what
we're discussing. For poor old scatterbrains it really helps if people can
maintain a description of their patch alongside the patch itself.
> diff -ruN linux-2.6.12/drivers/usb/input/ati_remote.c
> linux-2.6.12-modified/drivers/usb/input/ati_remote.c
> --- linux-2.6.12/drivers/usb/input/ati_remote.c 2005-06-18
> 07:48:29.0 +1200
> +++ linux-2.6.12-modified/drivers/usb/input/ati_remote.c 2005-08-03
> 09:54:48.0 +1200
> @@ -252,8 +252,8 @@
> {KIND_FILTERED, 0xdd, 0x18, EV_KEY, KEY_KPENTER, 1},/* "check" */
> {KIND_FILTERED, 0xdb, 0x16, EV_KEY, KEY_MENU, 1}, /* "menu" */
> {KIND_FILTERED, 0xc7, 0x02, EV_KEY, KEY_POWER, 1}, /* Power */
> - {KIND_FILTERED, 0xc8, 0x03, EV_KEY, KEY_TV, 1}, /* TV */
> - {KIND_FILTERED, 0xc9, 0x04, EV_KEY, KEY_DVD, 1},/* DVD */
> + {KIND_FILTERED, 0xc8, 0x03, EV_KEY, KEY_PROG1, 1}, /* TV */
> + {KIND_FILTERED, 0xc9, 0x04, EV_KEY, KEY_PROG2, 1}, /* DVD */
> {KIND_FILTERED, 0xca, 0x05, EV_KEY, KEY_WWW, 1},/* WEB */
> {KIND_FILTERED, 0xcb, 0x06, EV_KEY, KEY_BOOKMARKS, 1}, /* "book" */
> {KIND_FILTERED, 0xcc, 0x07, EV_KEY, KEY_EDIT, 1}, /* "hand" */
> @@ -263,7 +263,7 @@
> {KIND_FILTERED, 0xe4, 0x1f, EV_KEY, KEY_RIGHT, 1}, /* right */
> {KIND_FILTERED, 0xe7, 0x22, EV_KEY, KEY_DOWN, 1}, /* down */
> {KIND_FILTERED, 0xdf, 0x1a, EV_KEY, KEY_UP, 1}, /* up */
> - {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_OK, 1}, /* "OK" */
> + {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_ENTER, 1}, /* "OK" */
> {KIND_FILTERED, 0xce, 0x09, EV_KEY, KEY_VOLUMEDOWN, 1}, /* VOL + */
> {KIND_FILTERED, 0xcd, 0x08, EV_KEY, KEY_VOLUMEUP, 1}, /* VOL - */
> {KIND_FILTERED, 0xcf, 0x0a, EV_KEY, KEY_MUTE, 1}, /* MUTE */
IOW: what does this (wordwrapped!) patch do?
-
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/
2.6.13-rc5-git2 on x86_64 slaughters all processes?
-git1 works fine, but -git2 fails in a strange way. Only on my AMD64 box, the other seem fine. Boots all the way up, then seems to slaughter any userspace process: -- EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 236k freed INIT: version 2.86 booting VM: killing process rcS INIT: Entering runlevel: 2 VM: killing process rc VM: killing process getty VM: killing process getty VM: killing process getty VM: killing process getty VM: killing process getty VM: killing process getty VM: killing process getty Debian GNU/Linux 3.1 (none) ttyS0 (none) login: -- 0:conmux-control -- time-stamp -- Aug/04/05 2:57:24 -- - full bootlog for -git2 is here: http://test.kernel.org/9966/debug/console.log -git1's bootlog looks like this: http://test.kernel.org/9804/debug/console.log tail is: - Freeing unused kernel memory: 236k freed input: PS/2 Logitech Mouse on isa0060/serio1 INIT: version 2.86 booting Activating swap. Adding 12104968k swap on /dev/sdb3. Priority:-1 extents:1 Checking root file system... fsck 1.35 (28-Feb-2004) e2fsck 1.35 (28-Feb-2004) /dev/shm/root: clean, 268023/977280 files, 1467207/19EXT3 FS on sda1, 53897 blocks internal journal System time was Wed Aug 3 09:56:18 UTC 2005. Setting the System Clock using the Hardware Clock as reference... System Clock set. System local time is now Wed Aug 3 09:56:20 UTC 2005. Calculating module dependencies... done. Loading modules... sd_mod FATAL: Module sd_mod not found. ide-cd FATAL: Module ide_cd not found. ide-detect FATAL: Module ide_detect not found. All modules loaded. Checking all file systems... fsck 1.35 (28-Feb-2004) Setting kernel variables ... ... done. Mounting local filesystems... Cleaning /tmp /var/run /var/lock. Running 0dns-down to make sure resolv.conf is ok...done. Cleaning: /etc/network/ifstate. Kernel hotplug support not enabled. Setting up IP spoofing protection: rp_filter. Configuring network interfaces...done. Starting portmap daemon: portmap. Loading the saved-state of the serial devices... /dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A Setting the System Clock using the Hardware Clock as reference... System Clock set. Local time: Wed Aug 3 02:56:22 PDT 2005 Running ntpdate to synchronize clocktg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is off for TX and off for RX. . Initializing random number generator...done. Recovering nvi editor sessions... done. Setting up X server socket directory /tmp/.X11-unix...done. Setting up ICE socket directory /tmp/.ICE-unix...done. INIT: Entering runlevel: 2 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. Starting portmap daemon: portmap. Starting MTA: exim4. Starting file alteration monitor: FAM. Starting internet superserver: inetd. Starting printer spooler: lpd . Starting OpenBSD Secure Shell server: sshd. Setting up X font server socket directory /tmp/.font-unix...done. Starting X font server: xfs. Starting Xprint servers: Xprt. Starting NFS common utilities: statd. Starting NTP server: ntpd. Starting deferred execution scheduler: atd. Starting periodic command scheduler: cron. Starting GNOME Display Manager: gdm. Starting staf: staf. Not starting X display manager (xdm); it is not the default display manager. XFree86: vm86 mode not supported on 64 bit kernel mtrr: type mismatch for e500,40 old: write-back new: write-combining Debian GNU/Linux 3.1 elm3b6 ttyS0 elm3b6 login: -- 0:conmux-control -- time-stamp -- Aug/03/05 2:58:57 -- - 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.12-rc6-mm1
On Friday 05 August 2005 00:28, Andrew Morton wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Dominik Karall <[EMAIL PROTECTED]> wrote:
> > > On Friday 29 July 2005 23:27, Andrew Morton wrote:
> > > > Dominik Karall <[EMAIL PROTECTED]> wrote:
> > > > > On Friday 29 July 2005 20:22, Andrew Morton wrote:
> > > > > > Dominik Karall <[EMAIL PROTECTED]> wrote:
> > > > > > > On Friday 29 July 2005 06:54, Andrew Morton wrote:
> > > > > > > > Dominik Karall <[EMAIL PROTECTED]> wrote:
> > > > > > > > > On Tuesday 07 June 2005 13:29, Andrew Morton wrote:
> > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches
> > > > > > > > > >/2.6/2 .6.1 2-rc 6/2. 6.12-rc6-mm1/
> > > > > > > > >
> > > > > > > > > After looking in my dmesg output today, I saw following
> > > > > > > > > error with 2.6.12-rc6-mm1, maybe it's usefull to you. I
> > > > > > > > > don't know when it exactly happens, cause I never used mono
> > > > > > > > > last time, I just did an emerge mono on my gentoo system,
> > > > > > > > > maybe this forced the failure.
> > > > > > > > >
> > > > > > > > > note: mono[26736] exited with preempt_count 1
> > > > > > > > > scheduling while atomic: mono/0x1001/26736
> > > > > > > > >
> > > > > > > > > Call Trace:{schedule+122}
> > > > > > > > > {vprintk+635}
> > > > > > > > > {cond_resched+56}
> > > > > > > > > {unmap_vmas+1587}
> > > > > > > > > {exit_mmap+128}
> > > > > > > > > {mmput+31}
> > > > > > > > > {do_exit+438}
> > > > > > > > > {__dequeue_signal+501}
> > > > > > > > >{do_group_exit+280}
> > > > > > > > > {get_signal_to_deliver+1575}
> > > > > > > > >{do_signal+162}
> > > > > > > > > {default_wake_function+0}
> > > > > > > > >{sys_rt_sigreturn+577}
> > > > > > > > > {sysret_signal+28}
> > > > > > > > >{ptregscall_common+103}
> > > > > > > >
> > > > > > > > A couple of people reported this, but all seems to have gone
> > > > > > > > quiet. Is it fixed in later -mm's? Is 2.6.13-rc4 running
> > > > > > > > OK?
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > >
> > > > > > > hi andrew!
> > > > > > >
> > > > > > > I'm sorry, but it's not fixed in current 2.6.13-rc3-mm3. I did
> > > > > > > an emerge mono right now to test it, and I got this one:
> > > > > > > Jul 29 15:26:37 [kernel] note: mono[11138] exited with
> > > > > > > preempt_count 1 Jul 29 15:26:50 [kernel] file[14627]: segfault
> > > > > > > at 2b453000 rip 2af652cf rsp 7fe43b50
> > > > > > > error 4
> > > > > > > Jul 29 15:26:50 [kernel] file[14633]: segfault at
> > > > > > > 2b453000 rip 2af652cf rsp 7fcc87a0
> > > > > > > error 4
> > > > > > > Jul 29 15:26:51 [kernel] file[14669]: segfault at
> > > > > > > 2b453000 rip 2af652cf rsp 7f905f80
> > > > > > > error 4
> > > > > > >
> > > > > > > DEBUG_KERNEL/ PREEMPT/ SPINLOCK are enabled, but I didn't get
> > > > > > > more info about the bug. Did I forget any debug option?
> > > > > >
> > > > > > Gee, I don't know how to find this one. Do you know if the
> > > > > > problem is specific to -mm?
> > > > >
> > > > > Tested with 2.6.13-rc4 and it seems to work. Didn't get any error.
> > > >
> > > > Great, thanks for that.
> > > >
> > > > > So it seems to be -mm related. Do you suspect any patch which could
> > > > > cause the error?
> > > >
> > > > I wouldn't know, sorry. Possible the scheduler patches, possibly an
> > > > x86_64-specific patch. Is the problem repeatable? If so, a binary
> > > > search would only take ten build-n-boots ;)
> > >
> > > Yes, it is repeatable. I tested on lastest -mm about 4 times. Ok, I
> > > will try to find the right patch tomorrow, 10 build-n-boots would end
> > > up in morning ;)
> > >
> > > btw, as the error occured in 2.6.12-rc6-mm1 too, it must be an old
> > > patch which wasn't merged to linus tree till now...hope there aren't a
> > > lot of them :)
> >
> > Any progress on this? It kinda measn that the whole of the -mm lineup is
> > stuck until we can identify the offending patch. We have a couple of
> > weeks in which to do this but if you can identify the bad patch it'd help
> > enormously, thanks.
>
> OK, Bartosz Taudul tells me that he's occasionally seeing this on stock
> 2.6.12 (thanks!). So there's not a lot of point in doing the -mm bisection
> search.
>
> I think Ingo was planning on coming up with some infrastructure which would
> allow us to debug this further.
I'm sorry that I couldn't do the tests earlier, but I had no time this week. I
did some tests now and noticed that the bug only occures when kde is
running...weird.
I'm going to continue testing tomorrow after work, exactly in 12 hours ;)
I will let you know if I have any news!
dominik
pgpvYfWXRWZH1.pgp
Description: PGP signature
Re: [PATCH] Re: 2.6.12: itimer_real timers don't survive execve() any more
That's wrong. It has to be done only by the last thread in the group to go. Just revert Ingo's change. Thanks, Roland - 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][PPP] ppp_generic: Add checks for NULL pointers
Hmamouche, Youssef writes:
> This patch adds two checks for NULL pointers.
OK, but get the whitespace right please - use tabs not spaces for
indentation, and put a space between "if" and "(". See
Documentation/CodingStyle.
Paul.
-
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 ACPI table discovery from EFI for x86
Bjorn Helgaas <> wrote: > On Wednesday 13 July 2005 7:09 pm, Matt Tolentino wrote: >> This patch addresses a problem on x86 EFI systems with larger memory >> configurations. Up until now, we've relied on the fact that the >> ACPI RSDT would reside somewhere in low memory that could be >> permanently >> mapped in kernel address space - so __va() has been sufficient. >> However, >> on EFI systems, the RSDT is often anywhere in the lower 4GB of >> physical >> address space. So, we may need to remap it on x86 systems. > > The hunk below breaks HP rx7620, rx8620, and Superdome (all ia64) > systems. This is from 2.6.13-rc4-mm1, in Ugh. Well, that's pretty ugly... Andrew, Len, please drop this one until I look at this closer. > acpi-fix-table-discovery-from-efi-for-x86.patch Thanks for testing Bjorn. matt - 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: NUMA policy interface
On Thu, 4 Aug 2005, Andi Kleen wrote: > > There is this scan over the page table that verifies if all nodes are > > allocated according to the policy. That scan could easily be used to > > provide a map to the application (and to /proc//smap) of where the > > The application can already get it. But it's an ugly feature > that I only used for debugging and I was actually considering > to remove it. > > Doing it for external users is a completely different thing though. > I still think those have business in messing with other people's > virtual addresses. In addition I expect it will cause problems > longer term > (did you ever look why mmap on /proc/*/mem is not allowed - it used > to be long ago, but it was impossible to make it work race free and > before that was always a gapping security hole) The proc stuff is fake anyways. I would not worry about that. The biggest worry is the locking mechanism to make this clean. There are three possibilites: 1. do what cpusets is doing by versioning. 2. Have the task notifier access the task_struct information. See http://lwn.net/Articles/145232/ "A new path to the refrigerator" 3. Maybe the easiest: Require mmap_sem to be taken for all policy accesses. Currently its only require for vma policies. Then we need to make a copy of the policy at some point so that alloc_pages can access policy information lock free. This may also allow us to fix the bind issue if we would f.e. keep a bitmap in the taskstruct or (ab)use the cpusets map. > If they cannot afford enough disk space it might be possible > to do the page migration in swap cache like Hugh proposed. This code already exist in the memory hotplug code base and Ray already had a working implementation for page migration. The migration code will also be necessary in order to relocate pages with ECC single bit failures that Russ is working on (of course that will only work for some pages) and for Mel Gorman's defragmentation approach (if we ever get the split into differnet types of memory chunks in). - 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.12-rc6-mm1
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> Dominik Karall <[EMAIL PROTECTED]> wrote:
> >
> > On Friday 29 July 2005 23:27, Andrew Morton wrote:
> > > Dominik Karall <[EMAIL PROTECTED]> wrote:
> > > > On Friday 29 July 2005 20:22, Andrew Morton wrote:
> > > > > Dominik Karall <[EMAIL PROTECTED]> wrote:
> > > > > > On Friday 29 July 2005 06:54, Andrew Morton wrote:
> > > > > > > Dominik Karall <[EMAIL PROTECTED]> wrote:
> > > > > > > > On Tuesday 07 June 2005 13:29, Andrew Morton wrote:
> > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2
> > > > > > > > >.6.1 2-rc 6/2. 6.12-rc6-mm1/
> > > > > > > >
> > > > > > > > After looking in my dmesg output today, I saw following error
> > > > > > > > with 2.6.12-rc6-mm1, maybe it's usefull to you. I don't know
> > > > > > > > when
> > > > > > > > it exactly happens, cause I never used mono last time, I just
> > > > > > > > did
> > > > > > > > an emerge mono on my gentoo system, maybe this forced the
> > > > > > > > failure.
> > > > > > > >
> > > > > > > > note: mono[26736] exited with preempt_count 1
> > > > > > > > scheduling while atomic: mono/0x1001/26736
> > > > > > > >
> > > > > > > > Call Trace:{schedule+122}
> > > > > > > > {vprintk+635}
> > > > > > > > {cond_resched+56}
> > > > > > > > {unmap_vmas+1587}
> > > > > > > > {exit_mmap+128} {mmput+31}
> > > > > > > > {do_exit+438}
> > > > > > > > {__dequeue_signal+501}
> > > > > > > >{do_group_exit+280}
> > > > > > > > {get_signal_to_deliver+1575}
> > > > > > > >{do_signal+162}
> > > > > > > > {default_wake_function+0}
> > > > > > > >{sys_rt_sigreturn+577}
> > > > > > > > {sysret_signal+28}
> > > > > > > >{ptregscall_common+103}
> > > > > > >
> > > > > > > A couple of people reported this, but all seems to have gone
> > > > > > > quiet.
> > > > > > > Is it fixed in later -mm's? Is 2.6.13-rc4 running OK?
> > > > > > >
> > > > > > > Thanks.
> > > > > >
> > > > > > hi andrew!
> > > > > >
> > > > > > I'm sorry, but it's not fixed in current 2.6.13-rc3-mm3. I did an
> > > > > > emerge mono right now to test it, and I got this one:
> > > > > > Jul 29 15:26:37 [kernel] note: mono[11138] exited with preempt_count
> > > > > > 1 Jul 29 15:26:50 [kernel] file[14627]: segfault at 2b453000
> > > > > > rip 2af652cf rsp 7fe43b50 error 4
> > > > > > Jul 29 15:26:50 [kernel] file[14633]: segfault at 2b453000
> > > > > > rip 2af652cf rsp 7fcc87a0 error 4
> > > > > > Jul 29 15:26:51 [kernel] file[14669]: segfault at 2b453000
> > > > > > rip 2af652cf rsp 7f905f80 error 4
> > > > > >
> > > > > > DEBUG_KERNEL/ PREEMPT/ SPINLOCK are enabled, but I didn't get more
> > > > > > info about the bug. Did I forget any debug option?
> > > > >
> > > > > Gee, I don't know how to find this one. Do you know if the problem is
> > > > > specific to -mm?
> > > >
> > > > Tested with 2.6.13-rc4 and it seems to work. Didn't get any error.
> > >
> > > Great, thanks for that.
> > >
> > > > So it seems to be -mm related. Do you suspect any patch which could
> > > > cause
> > > > the error?
> > >
> > > I wouldn't know, sorry. Possible the scheduler patches, possibly an
> > > x86_64-specific patch. Is the problem repeatable? If so, a binary search
> > > would only take ten build-n-boots ;)
> >
> > Yes, it is repeatable. I tested on lastest -mm about 4 times. Ok, I will
> > try
> > to find the right patch tomorrow, 10 build-n-boots would end up in morning
> > ;)
> >
> > btw, as the error occured in 2.6.12-rc6-mm1 too, it must be an old patch
> > which
> > wasn't merged to linus tree till now...hope there aren't a lot of them :)
> >
>
> Any progress on this? It kinda measn that the whole of the -mm lineup is
> stuck until we can identify the offending patch. We have a couple of weeks
> in which to do this but if you can identify the bad patch it'd help
> enormously, thanks.
>
OK, Bartosz Taudul tells me that he's occasionally seeing this on stock
2.6.12 (thanks!). So there's not a lot of point in doing the -mm bisection
search.
I think Ingo was planning on coming up with some infrastructure which would
allow us to debug this further.
-
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: Fw: ati-remote strangeness from 2.6.12 onwards
Sorry Andrew, but the diff was incorrectly made, the updated patch,
reverts the changes too TV, DVD and OK Button, from 2.6.12-rc1.
diff -ruN linux-2.6.12/drivers/usb/input/ati_remote.c
linux-2.6.12-modified/drivers/usb/input/ati_remote.c
--- linux-2.6.12/drivers/usb/input/ati_remote.c 2005-06-18
07:48:29.0 +1200
+++ linux-2.6.12-modified/drivers/usb/input/ati_remote.c2005-08-03
09:54:48.0 +1200
@@ -252,8 +252,8 @@
{KIND_FILTERED, 0xdd, 0x18, EV_KEY, KEY_KPENTER, 1},/* "check" */
{KIND_FILTERED, 0xdb, 0x16, EV_KEY, KEY_MENU, 1}, /* "menu" */
{KIND_FILTERED, 0xc7, 0x02, EV_KEY, KEY_POWER, 1}, /* Power */
- {KIND_FILTERED, 0xc8, 0x03, EV_KEY, KEY_TV, 1}, /* TV */
- {KIND_FILTERED, 0xc9, 0x04, EV_KEY, KEY_DVD, 1},/* DVD */
+ {KIND_FILTERED, 0xc8, 0x03, EV_KEY, KEY_PROG1, 1}, /* TV */
+ {KIND_FILTERED, 0xc9, 0x04, EV_KEY, KEY_PROG2, 1}, /* DVD */
{KIND_FILTERED, 0xca, 0x05, EV_KEY, KEY_WWW, 1},/* WEB */
{KIND_FILTERED, 0xcb, 0x06, EV_KEY, KEY_BOOKMARKS, 1}, /* "book" */
{KIND_FILTERED, 0xcc, 0x07, EV_KEY, KEY_EDIT, 1}, /* "hand" */
@@ -263,7 +263,7 @@
{KIND_FILTERED, 0xe4, 0x1f, EV_KEY, KEY_RIGHT, 1}, /* right */
{KIND_FILTERED, 0xe7, 0x22, EV_KEY, KEY_DOWN, 1}, /* down */
{KIND_FILTERED, 0xdf, 0x1a, EV_KEY, KEY_UP, 1}, /* up */
- {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_OK, 1}, /* "OK" */
+ {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_ENTER, 1}, /* "OK" */
{KIND_FILTERED, 0xce, 0x09, EV_KEY, KEY_VOLUMEDOWN, 1}, /* VOL + */
{KIND_FILTERED, 0xcd, 0x08, EV_KEY, KEY_VOLUMEUP, 1}, /* VOL - */
{KIND_FILTERED, 0xcf, 0x0a, EV_KEY, KEY_MUTE, 1}, /* MUTE */
On 8/5/05, Andrew Morton <[EMAIL PROTECTED]> wrote:
> mdew <[EMAIL PROTECTED]> wrote:
> >
> > I discovered a minor change in 2.6.10-mm1, changing this value back
> > corrects the "ok" button issue.
> >
> >
> > diff -urN linux/drivers/usb/input/ati_remote.c
> > linux-2.6.11/drivers/usb/input/ati_remote.c
> > --- linux/drivers/usb/input/ati_remote.c2005-08-02
> > 17:56:26.0 +1200
> > +++ linux-2.6.11/drivers/usb/input/ati_remote.c 2005-08-02
> > 17:54:34.0 +1200
> > @@ -263,7 +263,7 @@
> > {KIND_FILTERED, 0xe4, 0x1f, EV_KEY, KEY_RIGHT, 1}, /* right */
> > {KIND_FILTERED, 0xe7, 0x22, EV_KEY, KEY_DOWN, 1}, /* down */
> > {KIND_FILTERED, 0xdf, 0x1a, EV_KEY, KEY_UP, 1}, /* up */
> > - {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_ENTER, 1}, /* "OK" */
> > + {KIND_FILTERED, 0xe3, 0x1e, EV_KEY, KEY_OK, 1}, /* "OK" */
> > {KIND_FILTERED, 0xce, 0x09, EV_KEY, KEY_VOLUMEDOWN, 1}, /* VOL + */
> > {KIND_FILTERED, 0xcd, 0x08, EV_KEY, KEY_VOLUMEUP, 1}, /* VOL - */
> > {KIND_FILTERED, 0xcf, 0x0a, EV_KEY, KEY_MUTE, 1}, /* MUTE */
>
> This appears to be already applied in 2.6.12-rc5.
>
-
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: Old api files, rewrite or delete?
Adrian Bunk napsal(a): On Thu, Aug 04, 2005 at 02:00:05PM +0200, Jiri Slaby wrote: There might be users for many of the listed drivers - even if there are only very few. And what do you really gain by removing drivers? Nothing, I don't only want to rewrite driver, which others do not use. -- Jiri Slaby www.fi.muni.cz/~xslaby ~\-/~ [EMAIL PROTECTED] ~\-/~ 241B347EC88228DE51EE A49C4A73A25004CB2A10 - 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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Wed, 3 Aug 2005 15:59:24 +1000 Con Kolivas <[EMAIL PROTECTED]> wrote: > This is the dynamic ticks patch for i386 as written by Tony Lindgen > <[EMAIL PROTECTED]> and Tuukka Tikkanen <[EMAIL PROTECTED]>. > Patch for 2.6.13-rc5 One issue (tested the -rc4 Version on -mm): - on interrupt flood (ping -f) HZ goes down to 0-4 HZ. This matches "ticks to skip" below. Coincidence? - ping -f complains: .Warning: time of day goes back (-304us), taking countermeasures. ... .Warning: time of day goes back (-33us), taking countermeasures. Yet, system time _seems_ to be kept correctly. CPU is Pentium M. dmesg: Using pmtmr for high-res timesource dyn-tick: Found suitable timer: pmtmr dyn-tick: Maximum ticks to skip limited to 54 dyn-tick: Timer not enabled during boot sysfs: suitable: 1 enabled:1 using APIC: 0 Regards - 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 0/23] reboot-fixes
Hi. On Fri, 2005-08-05 at 07:45, Pavel Machek wrote: > Hi! > > > > > > > Good question. I'm not certain if Pavel intended to add > > > > > > device_suspend(PMSG_FREEZE) to the reboot path. It was > > > > > > there in only one instance. Pavel comments talk only about > > > > > > the suspend path. > > > > > > > > > > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path. > > > > > > > > Why? > > > > > > Many bioses are broken; if you leave hardware active during reboot, > > > they'll hang during reboot. It is so common problem that I think that > > > only sane solution is make hardware quiet before reboot. > > > > Sorry for my slow reply. > > > > If I remember correctly PMSG_FREEZE was intended solely for stopping > > activity when suspend to disk implementations are about to do their > > Well, I think that PMSG_FREEZE can be handy when we want to stop > activity for other reasons, too... > > > atomic copies. I thought that ide reacts to this message by putting a > > hold on queues, but doesn't otherwise do anything to prepare a drive for > > a restart. If that's true, using FREEZE here isn't going to stop drives > > from doing their emergency shutdown actions. Don't we need PMSG_SUSPEND > > instead? > > Spinning disk down is not neccessary for reboot. Users will be angry > if we do it before reboot... Yes, but I understood (perhaps wrongly) that we were discussing the shutdown path. Nevertheless, for rebooting, you don't want to simply freeze the queue - you want to flush the queue and tell the drive to flush too. For freeze, you may well flush the queue, but you might not necessarily force the drive to flush its queue too. Regards, Nigel -- Evolution. Enumerate the requirements. Consider the interdependencies. Calculate the probabilities. - 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.13-rc5-git2 does not boot on (my) amd64
[EMAIL PROTECTED] (Danny ter Haar) writes: > This is as far as it comes: > > > Freeing unused kernel memory: 248k freed > VM: killing process hotplug > VM: killing process hotplug > VM: killing process hotplug > VM: killing process hotplug > Unable to handle kernel paging request at fff28017b5be RIP: > [] Looks weird. Just to make sure can you do a make distclean and try again? It might be a bad compile. -Andi - 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] Re: 2.6.12: itimer_real timers don't survive execve() any more
Andrew Morton wrote:
Roland McGrath <[EMAIL PROTECTED]> wrote:
That's wrong. It has to be done only by the last thread in the group to go.
Just revert Ingo's change.
Hm... I was looking at 2.6.10 to figure it out. This looks more correct.
OK..
--- 25/kernel/exit.c~revert-timer-exit-cleanup Thu Aug 4 15:00:55 2005
+++ 25-akpm/kernel/exit.c Thu Aug 4 15:01:06 2005
@@ -829,8 +829,10 @@ fastcall NORET_TYPE void do_exit(long co
acct_update_integrals(tsk);
update_mem_hiwater(tsk);
group_dead = atomic_dec_and_test(>signal->live);
- if (group_dead)
+ if (group_dead) {
+ del_timer_sync(>signal->real_timer);
acct_process(code);
+ }
exit_mm(tsk);
exit_sem(tsk);
diff -puN kernel/posix-timers.c~revert-timer-exit-cleanup kernel/posix-timers.c
--- 25/kernel/posix-timers.c~revert-timer-exit-cleanup Thu Aug 4 15:00:55 2005
+++ 25-akpm/kernel/posix-timers.c Thu Aug 4 15:01:06 2005
@@ -1166,7 +1166,6 @@ void exit_itimers(struct signal_struct *
tmr = list_entry(sig->posix_timers.next, struct k_itimer, list);
itimer_delete(tmr);
}
- del_timer_sync(>real_timer);
}
/*
_
-
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/
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
-
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/
Documentation/ioctl-mess.txt and ida_ioctl() review (was Re: [PATCH 2/3] cpqarray: ioctl support to configure LUNs dynamically)
On Thu, Aug 04, 2005 at 10:15:29AM +0530, Saripalli, Venkata Ramanamurthy
(STSD) wrote:
> Patch 2 of 3
> This patch adds support for IDAREGNEWDISK, IDADEREGDISK, IDAGETLOGINFO
> ioctls required
> to configure LUNs dynamically on SA4200 controller using ACU.
drivers/block/cpqarray.c:
1131 static int ida_ioctl(struct inode *inode, struct file *filep, unsigned
int cmd, unsigned long arg)
1132 {
1133 drv_info_t *drv = get_drv(inode->i_bdev->bd_disk);
1134 ctlr_info_t *host = get_host(inode->i_bdev->bd_disk);
1135 int error;
1136 int diskinfo[4];
Hmm... diskinfo[3] seems to be enough.
1137 struct hd_geometry __user *geo = (struct hd_geometry __user
*)arg;
1138 ida_ioctl_t __user *io = (ida_ioctl_t __user *)arg;
1139 ida_ioctl_t *my_io;
1140
1141 switch(cmd) {
1142 case HDIO_GETGEO:
1143 if (drv->cylinders) {
1144 diskinfo[0] = drv->heads;
1145 diskinfo[1] = drv->sectors;
1146 diskinfo[2] = drv->cylinders;
1147 } else {
1148 diskinfo[0] = 0xff;
1149 diskinfo[1] = 0x3f;
1150 diskinfo[2] = drv->nr_blks / (0xff*0x3f);
1151 }
1152 put_user(diskinfo[0], >heads);
1153 put_user(diskinfo[1], >sectors);
1154 put_user(diskinfo[2], >cylinders);
1155 put_user(get_start_sect(inode->i_bdev), >start);
Mental note: export drv->heads, drv->sectors, drv->cylinders and
inode->i_bdev->bd_part->start_sect to userspace (with possible tweaking).
1156 return 0;
1157 case IDAGETDRVINFO:
1158 if (copy_to_user(>c.drv, drv, sizeof(drv_info_t)))
What does drv_info_t contain? From drivers/block/cpqarray.h:
47 typedef struct {
48 unsigned blk_size;
49 unsigned nr_blks;
50 unsigned cylinders;
51 unsigned heads;
52 unsigned sectors;
53 int usage_count;
54 } drv_info_t;
Great... Same heads, sectors, cylinders we can already export. Without magic
"if (!drv->cylinders)". With extra crap for free: "usage_count". Why should
userspace know about reference count of drive? This is
not even funny...
$ grep usage_count -w -r . | grep cpq
./drivers/block/cpqarray.c: host->usage_count++;
./drivers/block/cpqarray.c: host->usage_count--;
./drivers/block/cpqarray.c: if (host->usage_count > 1) {
./drivers/block/cpqarray.c: " revalidation (usage=%d)\n",
host->usage_count);
./drivers/block/cpqarray.c: host->usage_count++;
./drivers/block/cpqarray.c: host->usage_count--;
./drivers/block/cpqarray.h: int usage_count;
./drivers/block/cpqarray.h: int usage_count;
where the type of "host" is "struct ctlr_info", NOT drv_info_t.
1159 return -EFAULT;
1160 return 0;
1161 case IDAPASSTHRU:
1162 if (!capable(CAP_SYS_RAWIO))
1163 return -EPERM;
1164 my_io = kmalloc(sizeof(ida_ioctl_t), GFP_KERNEL);
1165 if (!my_io)
1166 return -ENOMEM;
1167 error = -EFAULT;
1168 if (copy_from_user(my_io, io, sizeof(*my_io)))
1169 goto out_passthru;
1170 error = ida_ctlr_ioctl(host, drv - host->drv, my_io);
1171 if (error)
1172 goto out_passthru;
1173 error = -EFAULT;
1174 if (copy_to_user(io, my_io, sizeof(*my_io)))
1175 goto out_passthru;
1176 error = 0;
1177 out_passthru:
1178 kfree(my_io);
1179 return error;
1180 case IDAGETCTLRSIG:
1181 if (!arg) return -EINVAL;
1182 put_user(host->ctlr_sig, (int __user *)arg);
1183 return 0;
1184 case IDAREVALIDATEVOLS:
1185 if (iminor(inode) != 0)
1186 return -ENXIO;
1187 return revalidate_allvol(host);
1188 case IDADRIVERVERSION:
1189 if (!arg) return -EINVAL;
1190 put_user(DRIVER_VERSION, (unsigned long __user *)arg);
1191 return 0;
Why should userspace know anything about module version?
1192 case IDAGETPCIINFO:
1193 {
1194
1195 ida_pci_info_struct pciinfo;
1196
1197 if (!arg) return -EINVAL;
1198 pciinfo.bus = host->pci_dev->bus->number;
1199 pciinfo.dev_fn = host->pci_dev->devfn;
1200 pciinfo.board_id =
Re: [patch] fix ACPI table discovery from EFI for x86
On Wednesday 13 July 2005 7:09 pm, Matt Tolentino wrote:
> This patch addresses a problem on x86 EFI systems with larger memory
> configurations. Up until now, we've relied on the fact that the
> ACPI RSDT would reside somewhere in low memory that could be permanently
> mapped in kernel address space - so __va() has been sufficient. However,
> on EFI systems, the RSDT is often anywhere in the lower 4GB of physical
> address space. So, we may need to remap it on x86 systems.
The hunk below breaks HP rx7620, rx8620, and Superdome (all ia64)
systems. This is from 2.6.13-rc4-mm1, in
acpi-fix-table-discovery-from-efi-for-x86.patch
> @@ -187,7 +187,9 @@ acpi_status
> acpi_os_map_memory(acpi_physical_address phys, acpi_size size, void __iomem
> **virt)
> {
> if (efi_enabled) {
> - if (EFI_MEMORY_WB & efi_mem_attributes(phys)) {
> + /* determine whether or not we need to call ioremap */
> + if ((EFI_MEMORY_WB & efi_mem_attributes(phys)) &&
> + ((unsigned long)phys < (unsigned
> long)__pa(high_memory))) {
> *virt = (void __iomem *) phys_to_virt(phys);
> } else {
> *virt = ioremap(phys, size);
If "phys >= __pa(high_memory)", we use ioremap(), but there's no
guarantee that phys is in memory that supports UC. On the systems
I mentioned, phys is above high_memory, but in memory that only
supports WB, which leads to an MCA.
Here's a bit of the memmap:
available 0001-0007FDFF 006FE000 0008
reserved 004A-004B 0020 0008
available 00408000-0040FED9 0007EDA0 0008
BS_data0040FEDA-0040FEDA1FFF 0002 0008
available 0040FEDA2000-0040FEDA7FFF 0006 0008
BS_data0040FEDA8000-0040FF1F 0458 0008
available 0040FF20-0040FF555FFF 0356 0008
RT_code0040FF556000-0040FF5B 006A 8008
BS_code0040FF5C-0040FF5F 0040 0008
available 0040FF60-0040FF641FFF 0042 0008
RT_code0040FF642000-0040FF67 003E 8008
available 0040FF68-0040FF7D 0160 0008
RT_data0040FF7E-0040FF7F 0020 8008
RT_code0703FF00-0703 1000 8008
PAL_code 0723FF00-0723FF03 0040 8008
RT_code0723FF04-0723FFBA 0B70 8008
reserved 0723FFBB-0723FFE8 02E0 8008
RT_code0723FFE9-0723 0170 8008
MemMapIO 0F00-0F003FFF 0004 8001
The firmware tables are up in the reserved section at 0x723FFBB:
EFI v1.10 by HP: SALsystab=0x723ff7e7640 ACPI 2.0=0x723ffbb
HCDP=0x723ffbf27f0 SMBIOS=0x7fffe000
But high_memory is only 0x0040ff00 because there's no available
memory for the OS to use above that point (there are a few pages marked
"available", but we ignore them to avoid attribute aliasing on ia64).
So we erroneously try to ioremap the ACPI tables, which causes uncached
accesses to them, which blows up because they really live in memory that
doesn't support UC.
-
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: Old api files, rewrite or delete?
On Thu, Aug 04, 2005 at 02:00:05PM +0200, Jiri Slaby wrote: > Hi. > I'm interested mainly in things that may be removed. I don't want to > rewrite drivers, which nobody uses. > Thanks for your opinion and knowledge about usage. >... There might be users for many of the listed drivers - even if there are only very few. And what do you really gain by removing drivers? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Regression: radeonfb: No synchronisation on CRT with linux-2.6.13-rc5
My CRT is out of sync after radeonfb from 2.6.13-rc5 is initialized. 2.6.12 does not show this behaviour. dmesg from both systems, trimmed down: 2.6.13-rc5: PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 PCI: Using IRQ router VIA [1106/0686] at :00:07.0 PCI: Bridge: :00:01.0 IO window: c000-cfff MEM window: e800-e9ff PREFETCH window: d000-dfff PCI: Setting latency timer of device :00:01.0 to 64 Machine check exception polling timer started. ... Applying VIA southbridge workaround. radeonfb_pci_register BEGIN radeonfb (:01:00.0): Found 131072k of DDR 128 bits wide videoram radeonfb (:01:00.0): mapped 16384k videoram radeonfb: Found Intel x86 BIOS ROM Image radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=200.00 MHz radeonfb: PLL min 2 max 4 1 chips in connector info - chip 1 has 2 connectors * connector 0 of type 2 (CRT) : 2300 * connector 1 of type 3 (DVI-I) : 3201 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: Monitor 1 type CRT found radeonfb: EDID probed radeonfb: Monitor 2 type no found hStart = 694, hEnd = 757, hTotal = 795 vStart = 402, vEnd = 408, vTotal = 418 h_total_disp = 0x590062hsync_strt_wid = 0x8702c0 v_total_disp = 0x18f01a1 vsync_strt_wid = 0x860191 pixclock = 85925 freq = 1163 freq = 1666, PLL min = 2, PLL max = 4 ref_div = 12, ref_clk = 2700, output_freq = 26656 ref_div = 12, ref_clk = 2700, output_freq = 26656 post div = 0x5 fb_div = 0x76 ppll_div_3 = 0x50076 Console: switching to colour frame buffer device 90x25 radeonfb (:01:00.0): ATI Radeon AS radeonfb_pci_register END PCI: Enabling device :00:09.0 ( -> 0003) PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:0d.0 fb: 3Dfx Banshee memory = 16384K Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Twister-K/KT133x/KM133 chipset agpgart: AGP aperture is 64M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:0d.0 [drm] Initialized tdfx 1.0.0 20010216 on minor 0: [drm] Initialized radeon 1.16.0 20050311 on minor 1: 2.6.12: PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 PCI: Using IRQ router VIA [1106/0686] at :00:07.0 ... Applying VIA southbridge workaround. radeonfb_pci_register BEGIN radeonfb (:01:00.0): Found 131072k of DDR 128 bits wide videoram radeonfb (:01:00.0): mapped 16384k videoram radeonfb: Found Intel x86 BIOS ROM Image radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=200.00 MHz radeonfb: PLL min 2 max 4 1 chips in connector info - chip 1 has 2 connectors * connector 0 of type 2 (CRT) : 2300 * connector 1 of type 3 (DVI-I) : 3201 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: Monitor 1 type CRT found radeonfb: EDID probed radeonfb: Monitor 2 type no found hStart = 737, hEnd = 808, hTotal = 896 vStart = 401, vEnd = 404, vTotal = 417 h_total_disp = 0x59006fhsync_strt_wid = 0x8802eb v_total_disp = 0x18f01a0 vsync_strt_wid = 0x830190 pixclock = 38210 freq = 2617 freq = 2617, PLL min = 2, PLL max = 4 ref_div = 12, ref_clk = 2700, output_freq = 20936 ref_div = 12, ref_clk = 2700, output_freq = 20936 post div = 0x3 fb_div = 0x5d ppll_div_3 = 0x3005d Console: switching to colour frame buffer device 90x25 radeonfb (:01:00.0): ATI Radeon AS radeonfb_pci_register END ... fb: 3Dfx Banshee memory = 16384K Linux agpgart interface v0.101 (c) Dave Jones agpgart: Detected VIA Twister-K/KT133x/KM133 chipset agpgart: AGP aperture is 64M @ 0xe000 [drm] Initialized drm 1.0.0 20040925 PCI: Found IRQ 5 for device :00:09.0 PCI: Sharing IRQ 5 with :00:0d.0 [drm] Initialized tdfx 1.0.0 20010216 on minor 0: [drm] Initialized radeon 1.16.0 20050311 on minor 1: -- Top 100 things you don't want the sysadmin to say: 10. I don't care what he says, I'm _NOT_ having it on _my_ network - 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] Re: 2.6.12: itimer_real timers don't survive execve() any more
Roland McGrath <[EMAIL PROTECTED]> wrote:
>
> That's wrong. It has to be done only by the last thread in the group to go.
> Just revert Ingo's change.
>
OK..
--- 25/kernel/exit.c~revert-timer-exit-cleanup Thu Aug 4 15:00:55 2005
+++ 25-akpm/kernel/exit.c Thu Aug 4 15:01:06 2005
@@ -829,8 +829,10 @@ fastcall NORET_TYPE void do_exit(long co
acct_update_integrals(tsk);
update_mem_hiwater(tsk);
group_dead = atomic_dec_and_test(>signal->live);
- if (group_dead)
+ if (group_dead) {
+ del_timer_sync(>signal->real_timer);
acct_process(code);
+ }
exit_mm(tsk);
exit_sem(tsk);
diff -puN kernel/posix-timers.c~revert-timer-exit-cleanup kernel/posix-timers.c
--- 25/kernel/posix-timers.c~revert-timer-exit-cleanup Thu Aug 4 15:00:55 2005
+++ 25-akpm/kernel/posix-timers.c Thu Aug 4 15:01:06 2005
@@ -1166,7 +1166,6 @@ void exit_itimers(struct signal_struct *
tmr = list_entry(sig->posix_timers.next, struct k_itimer, list);
itimer_delete(tmr);
}
- del_timer_sync(>real_timer);
}
/*
_
-
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: amd64-agp vs. swsusp
Hi! > > Does resuming from swsuspend work for anyone with amd64-agp loaded? > > It would seem not ;) > > > On my system when I suspend with amd64-agp loaded, I get a spontaneous > > reboot on resume. It reboots immediately after reading the saved image > > from disk. > > This is 100% reproducible. > > > > Athlon 64 FX-53, Asus A8V Deluxe, Linux 2.6.13-rc3-mm1. > > If this is reproducible in the soon-to-be-released 2.6.13-rc6 then could > you please raise an entry at bugzilla.kernel.org and we'll plug away at it > as the suspend stuff continues to get sorted out, thanks. I assume it is in -rc6, too; it is long-standing bug and I am not aware of any attempts at fixing it. Please file bug report, assign to me. OTOH it is not regression; AFAIK it never worked. Please do not let it block 2.6.13. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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/
Oops when rebooting 2.6.13-rc4-RT-V0.7.52-*
couldn't see the beginning of the oops but at the end was Init: no more processes left in this run level and have to power cycle to be able to boot. I tried vanilla -rc4, -rc5 and -rc4-mm1 which all worked just fine. But all 3 of the -RT versions I have on hand (08,10,13) showed the same symptom. This is my desktop system - Dell Optiplex GX-240 2GHz P4 1Gb SDRAM ATI Radeon VE/7000 QY SB Live! Value. Dell FP2000 RHEL 4.0 KDE 3.3 I don't have serial console debugging capability here at work, so what can I do to debug this? Thanks. -- Charles D. (Chuck) Harding <[EMAIL PROTECTED]> Voice: 925-423-8879 Senior Computer Associate ICCDFax: 925-423-6961 Lawrence Livermore National Laboratory Computation Directorate Livermore, CA USA http://www.llnl.gov GPG Public Key ID: B9EB6601 -- http://tinyurl.com/5w5ey --- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.13-rc4-RT-V0.7.52-13 # Thu Aug 4 09:01:47 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # 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_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT_DESKTOP is not set CONFIG_PREEMPT_RT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_SOFTIRQS=y CONFIG_PREEMPT_HARDIRQS=y CONFIG_PREEMPT_RCU=y CONFIG_PREEMPT_BKL=y CONFIG_RCU_STATS=y CONFIG_RCU_TORTURE_TEST=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ASM_SEMAPHORES=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_IOAPIC_FAST=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # # Firmware Drivers # CONFIG_EDD=y # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y CONFIG_REGPARM=y CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_PHYSICAL_START=0x10 CONFIG_KEXEC=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_DEBUG=y # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is
Re: amd64-agp vs. swsusp
On Thu, 4 Aug 2005, Andrew Morton wrote: > Michal Schmidt <[EMAIL PROTECTED]> wrote: > > > > Does resuming from swsuspend work for anyone with amd64-agp loaded? > > It would seem not ;) Must have missed the OP. Yes I can resume fine from swsusp with amd64-agp. System is an Averatec 3270 (Mobile Sempron(K8)). Not that this helps at all other than confirming it is possible ;) -cp -- "There are three kinds of lies: lies, damned lies, and statistics." -- Benjamin Disraeli - 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 0/23] reboot-fixes
Hi! > > > > > Good question. I'm not certain if Pavel intended to add > > > > > device_suspend(PMSG_FREEZE) to the reboot path. It was > > > > > there in only one instance. Pavel comments talk only about > > > > > the suspend path. > > > > > > > > Yes, I think we should do device_suspend(PMSG_FREEZE) in reboot path. > > > > > > Why? > > > > Many bioses are broken; if you leave hardware active during reboot, > > they'll hang during reboot. It is so common problem that I think that > > only sane solution is make hardware quiet before reboot. > > Sorry for my slow reply. > > If I remember correctly PMSG_FREEZE was intended solely for stopping > activity when suspend to disk implementations are about to do their Well, I think that PMSG_FREEZE can be handy when we want to stop activity for other reasons, too... > atomic copies. I thought that ide reacts to this message by putting a > hold on queues, but doesn't otherwise do anything to prepare a drive for > a restart. If that's true, using FREEZE here isn't going to stop drives > from doing their emergency shutdown actions. Don't we need PMSG_SUSPEND > instead? Spinning disk down is not neccessary for reboot. Users will be angry if we do it before reboot... Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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] i386 No-Idle-Hz aka Dynamic-Ticks 3
On Wed, Aug 03, 2005 at 03:59:24PM +1000, Con Kolivas wrote: >... > --- linux-2.6.13-rc5-ck2.orig/arch/i386/kernel/time.c 2005-08-03 > 11:29:08.0 +1000 > +++ linux-2.6.13-rc5-ck2/arch/i386/kernel/time.c 2005-08-03 > 11:29:29.0 +1000 >... > -static inline void do_timer_interrupt(int irq, void *dev_id, > +inline void do_timer_interrupt(int irq, void *dev_id, > struct pt_regs *regs) >... A global inline functions implies an increase of the size of the binary. Can you drop the "inline"? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: IDE disk and HPA
El Jueves, 4 de Agosto de 2005 07:11, Etienne Lorrain escribió: > > > > My question is now: why is an HPA disabled i.e. disprotected when > > > > detected? Why not let the HPA alone, because a certain set of disk > > > > sectors shall not be accessible by the OS? > > > > > > Because the HPA is most commonly used to hide all but a fraction of a > > > disk to work with older BIOSes. > > > > But as to my knowledge, the HPA was had been introduced to allow HW > > vendors to store things like diagnostic programs in a part of the > > disk protected from partitioning and filesystems. > > The point is, IF there is an HPA, there MIGHT be a partitioning > > scheme and some filesystems on the disk which rely on the size of > > disk being the native size MINUS the HPA. > > If those HW vendors want to store software in the HPA of the IDE > hard disk, and they employ people able to read the IDE specifications, > they know that this HPA can be protected by password and so Linux > just display a failure when trying to restore the capacity of the > Hard Disk - because it lacks the unlocking password. If I want to upgrade my IDE Hard drive by my self, how can I restore that kind of data on other diferent PC? HPA should not exist, there are a lot of other ways to store restore or diagnostics apps, Hibernation and Quick Restores should be handled in other way, I have once an omnibook (earth unplugged) and I can only reinstall Linux, because the host protected area does not allow me to install The Original OS, in other PC with the porper hardware and back it to the laptop. This HPA should be optional, but never by default, I once need to have them disabled (where is the specifications from the manufacturer to reproduce them in a new hard disk media). :| -- Gustavo Guillermo Pérez Compunauta uLinux www.compunauta.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] Fix a bit/byte counting error in the MMC/SD code
This fixes what looks like a bit/byte counting error in the MMC/SD code
which was causing data corruption (in the -mm tree).
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
Index: linux-2.6.12/drivers/mmc/mmc.c
===
--- linux-2.6.12.orig/drivers/mmc/mmc.c 2005-08-04 22:27:44.0 +0100
+++ linux-2.6.12/drivers/mmc/mmc.c 2005-08-04 22:30:02.0 +0100
@@ -923,7 +923,7 @@
mrq.cmd =
mrq.data =
- sg_init_one(, (u8*)card->raw_scr, 64);
+ sg_init_one(, (u8*)card->raw_scr, 8);
err = mmc_wait_for_req(host, );
if (err != MMC_ERR_NONE) {
-
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: NUMA policy interface
On Thu, Aug 04, 2005 at 02:21:09PM -0700, Christoph Lameter wrote: > Yes he mentioned that patch earlier in this thread. > > > > 5. No means to figure out where the memory was allocated although > > >mempoliy.c implements scans over ptes that would allow that > > >determination. > > > > You lost me here. > > There is this scan over the page table that verifies if all nodes are > allocated according to the policy. That scan could easily be used to > provide a map to the application (and to /proc//smap) of where the The application can already get it. But it's an ugly feature that I only used for debugging and I was actually considering to remove it. Doing it for external users is a completely different thing though. I still think those have business in messing with other people's virtual addresses. In addition I expect it will cause problems longer term (did you ever look why mmap on /proc/*/mem is not allowed - it used to be long ago, but it was impossible to make it work race free and before that was always a gapping security hole) > > > The long term impact of this missing functionality is already showing > > > in the numbers of workarounds that I have seen at a various sites, > > > > Examples? > > Two of the high profile ones are NASA and APA. One person from the APA > posted in one of our earlier discussions. Ok. I think for those the swapoff per process is the right because simplest and easiest solution. No complex patch sets needed, just some changes to an existing code path. If they cannot afford enough disk space it might be possible to do the page migration in swap cache like Hugh proposed. -Andi - 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: [openib-general] [RFC] Move InfiniBand .h files
On Thu, 4 Aug 2005, Roland Dreier wrote: I would like to get people's reactions to moving the InfiniBand .h files from their current location in drivers/infiniband/include/ to include/linux/rdma/. If we agree that this is a good idea then I'll push this change as soon as 2.6.14 starts. I think it is a good idea. The advantages of doing this are: - The headers become more easily accessible to other parts of the tree that might want to use IB support. For example, an NFS/RDMA client probably wants to live under fs/ net/sunrpc/ has also been proposed. - 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] Re: 2.6.12: itimer_real timers don't survive execve() any more
George Anzinger wrote:
>
> Source: MontaVista Software, Inc. George Anzinger
> Type: Defect Fix
> Description:
>
> The changes to itimer of late (after 2.6.11) cause itimers not
> to survive the exec* calls. Standard says they should.
>
> Signed-off-by: George Anzinger
>
> exit.c |1 +
> posix-timers.c |4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
>
> Index: linux-2.6.13-rc/kernel/exit.c
> ===
> --- linux-2.6.13-rc.orig/kernel/exit.c
> +++ linux-2.6.13-rc/kernel/exit.c
> @@ -794,6 +794,7 @@ fastcall NORET_TYPE void do_exit(long co
> }
>
> tsk->flags |= PF_EXITING;
> + del_timer_sync(>signal->real_timer);
>
> /*
>* Make sure we don't try to process any timer firings
> Index: linux-2.6.13-rc/kernel/posix-timers.c
> ===
> --- linux-2.6.13-rc.orig/kernel/posix-timers.c
> +++ linux-2.6.13-rc/kernel/posix-timers.c
> @@ -1183,10 +1183,10 @@ void exit_itimers(struct signal_struct *
> struct k_itimer *tmr;
>
> while (!list_empty(>posix_timers)) {
> - tmr = list_entry(sig->posix_timers.next, struct k_itimer, list);
> + tmr = list_entry(sig->posix_timers.next,
> + struct k_itimer, list);
> itimer_delete(tmr);
> }
> - del_timer_sync(>real_timer);
> }
Yup, that's the one, thanks George.
Obvious though it is, I'll hold off on forwarding this Linuswards until
Gerd has had a chance to test it. Or did you run Gerd's test app?
-
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: Linux v2.6.13-rc3
Sebastian Kaergel <[EMAIL PROTECTED]> wrote:
>
> On Tue, 12 Jul 2005 22:05:00 -0700 (PDT)
> Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > Dmitry Torokhov:
> > [ACPI] Enable EC Burst Mode
>
> After booting 2.6.13-rc3 on my acer travlemate 291LCI it starts
> complaining:
>
> acpi_ec-0217 [30] acpi_ec_leave_burst_mo: --->status fail
> acpi_ec-0217 [30] acpi_ec_leave_burst_mo: --->status fail
>
> 2.6.13-rc{1,2} did not have this problem.
We reverted the ec burst mode changes. I'll assume that 2.6.13-rc6 fixes
this up for you. If not, or if problems remain, please let us know.
Preferably via bugzilla.kernel.org, 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/
[PATCH] Re: 2.6.12: itimer_real timers don't survive execve() any more
Gerd Knorr wrote:
Hi,
Somewhere between 2.6.11 and 2.6.12 the regression in $subject
was added to the linux kernel. Testcase below.
Yep. The itimer changes got a bit carried away. Here is a fix.
--
George Anzinger george@mvista.com
HRT (High-res-timers): http://sourceforge.net/projects/high-res-timers/
Source: MontaVista Software, Inc. George Anzinger
Type: Defect Fix
Description:
The changes to itimer of late (after 2.6.11) cause itimers not
to survive the exec* calls. Standard says they should.
Signed-off-by: George Anzinger
exit.c |1 +
posix-timers.c |4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6.13-rc/kernel/exit.c
===
--- linux-2.6.13-rc.orig/kernel/exit.c
+++ linux-2.6.13-rc/kernel/exit.c
@@ -794,6 +794,7 @@ fastcall NORET_TYPE void do_exit(long co
}
tsk->flags |= PF_EXITING;
+ del_timer_sync(>signal->real_timer);
/*
* Make sure we don't try to process any timer firings
Index: linux-2.6.13-rc/kernel/posix-timers.c
===
--- linux-2.6.13-rc.orig/kernel/posix-timers.c
+++ linux-2.6.13-rc/kernel/posix-timers.c
@@ -1183,10 +1183,10 @@ void exit_itimers(struct signal_struct *
struct k_itimer *tmr;
while (!list_empty(>posix_timers)) {
- tmr = list_entry(sig->posix_timers.next, struct k_itimer, list);
+ tmr = list_entry(sig->posix_timers.next,
+struct k_itimer, list);
itimer_delete(tmr);
}
- del_timer_sync(>real_timer);
}
/*
Re: [PATCH] no-idle-hz aka dynamic ticks-2
On Thu, 4 Aug 2005 07:12, Pavel Machek wrote: > Hi! > > > > > As promised, here is an updated patch for the newly released > > > > 2.6.13-rc5. Boots and runs fine on P4HT (SMP+SMT kernel) built with > > > > gcc 4.0.1. > > > > > > Doesn't compile for me w/ gcc 3.4.4: > > > > Thanks for the report. Tiny change required. Here is a respun patch. > > Sorry, it breaks my machine in "interesting" way. Cursor no longer > blinks, sleep 1 takes more than five seconds, ... > > Pentium-M in compaq evo n620c notebok, cpufreq active: > > [EMAIL PROTECTED]:~$ dmesg | grep tick > dyn-tick: Found suitable timer: tsc > dyn-tick: Registering dynamic tick timer v050610-1 > dyn-tick: Maximum ticks to skip limited to 13 > dyn-tick: Timer not enabled during boot > [EMAIL PROTECTED]:~$ > > Ouch, even system time seems to go slower. I'll try setting > DYNTICK_USE_APIC next. > Pavel I assume you've confirmed this doesn't happen in vanilla rc5? Cheers, Con - 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] Remove suspend() calls from shutdown path
On Thursday, 4 of August 2005 22:58, you wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote: > > > > On Thursday, 4 of August 2005 17:20, Benjamin Herrenschmidt wrote: > > > On Thu, 2005-08-04 at 15:16 +0300, Zilvinas Valinskas wrote: > > > > Hello Ben, Andrew, > > > > > > > > This patch helps me if I disconnect all USB peripherals before shutting > > > > down notebook. With connected peripherals (USB mouse, PL2303 > > > > USB<->serial converter/port) - powering off process stops right after > > > > unmounting filesystems but before hda power off ... > > > > > > > > There is a bug report for this too: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=4992 > > > > > > This is unclear. > > > > > > I would expect the behaviour you report to happen _without_ this patch, > > > that is with current git tree, and I would expect this patch to fix it > > > by reverting to the previous 2.6.12 behaviour... > > > > I had this problem on a dual-core Athlon-based machine, but the patch > > apparently fixed it. > > > > So are all the (three?) bugs (regressions) which you were reporting now > fixed? Yes. As far as 2.6.13-rc5 (with the Ben's patch) is concerned, I have no visible problems whatever on any of my boxes. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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/
