Re: [PATCH] zero_user_page uses in fs/buffer.c and fs/libfs.c

[Satyam Sharma]

On 4/30/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:

There are a couple of places where kmap_atomic is surrounding two
memory operations. Usually only one of them is performed. So it is
possible to also use zero_user_page there.


I do like the patch, but would prefer if you'd give a better/correct
rationale here. "Usually only one of them is performed" is not exactly
correct to say, as it is perfectly (and frequently so) possible for
both of (block_end > to) and (block_start < from) to be true for the
same page for the prepare_write cases.

A simple "Replace open-coded kmap_atomic() and kunmap_atomic()
surrounding two memory clear operations with zero_user_page(), as both
memory operations act on the same page" would have been better.

Perhaps you were more worried with the additional overhead of two
successive kmap_atomic() and kunmap_atomic() calls for the same page
in the two resulting zero_user_page()'s (if both conditions evaluate
to true for the same page), but that would still be a price to pay to
replace the current open-coding.


--- linux-2.6.21-rc7-mm1.orig/fs/libfs.c2007-04-25 00:24:10.0 
-0700
+++ linux-2.6.21-rc7-mm1/fs/libfs.c 2007-04-25 00:25:56.0 -0700
@@ -337,12 +337,12 @@ int simple_prepare_write(struct file *fi
unsigned from, unsigned to)
 {
if (!PageUptodate(page)) {
-   if (to - from != PAGE_CACHE_SIZE) {
-   void *kaddr = kmap_atomic(page, KM_USER0);
-   memset(kaddr, 0, from);
-   memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
-   flush_dcache_page(page);
-   kunmap_atomic(kaddr, KM_USER0);
+   if (to - from != PAGE_CACHE_SIZE)
+   if (from)
+   zero_user_page(page, 0, from, KM_USER0);
+   if (to < PAGE_CACHE_SIZE)
+   zero_user_page(page, to,
+   PAGE_CACHE_SIZE - to, KM_USER0);


Why the two additional condition checks? The previous code didn't have
(or need) them, so this patch clearly does something more than simply
replacing open-coding with zero_user_page().

Either you've fixed an issue (in which case this should've been a
different patch with the accompanying explanation) or else I don't see
what we gain with the additional if's. Again, we still do incur the
overhead of two successive kmap_atomic() / kunmap_atomic() calls for
the same page in order to replace the open-coding.
-
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 linux-2.6-block.git] Fix blktrace trace ordering for plug branch

[Jens Axboe]

On Fri, Apr 27 2007, Alan D. Brunelle wrote:
> The attached patch will correct the ordering of trace output between 
> request queue insertions (I) and unplug calls (U). Right now the insert 
> precedes the unplug, which just isn't right:
> 
> 65,128  0167.699868965  7882  Q   R 0 + 1 [aiod]
> 65,128  0267.699876462  7882  G   R 0 + 1 [aiod]
> 65,128  0367.699878286  7882  P   W [aiod]
> 65,128  0467.699880491  7882  I   R 0 + 1 [aiod]
> 65,128  0567.699887589  7882  U   R [aiod] 1
> 65,128  0667.69989831754  D   R 0 + 1 [kblockd/0]
> 65,128  2  15367.700126590 0  C   R 0 + 1 [0]
> 
> With the patch provided the unplug comes first:
> 
> 65,128  31 0.0  7045  Q   R 0 + 1 [aiod]
> 65,128  32 0.02295  7045  G   R 0 + 1 [aiod]
> 65,128  33 0.02617  7045  P   W [aiod]
> 65,128  34 0.03685  7045  U   R [aiod] 1
> 65,128  35 0.04107  7045  I   R 0 + 1 [aiod]
> 65,128  36 0.0949157  D   R 0 + 1 [kblockd/3]
> 65,128  21 0.000232447 0  C   R 0 + 1 [0]
> 
> Jens: If you agree, the patch can be applied to your plug branch for 
> git://git.kernel.dk/data/git/linux-2.6-block.git

Thanks, with that applied the unplug ordering should be the same after
the plugging changes. Applied.

-- 
Jens Axboe

-
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: [DOC] Fix wrong identifier name in Documentation/driver-model/devres.txt

[Greg KH]

On Sun, Apr 29, 2007 at 04:50:29PM +0900, Tejun Heo wrote:
> Jeff Garzik wrote:
> > Now that devres is in the kernel, I don't think I am the best person to
> > merge these sort of patches.  Certainly I can, and I know the code from
> > my original review and subsequent usage, but I think the patch is more
> > appropriate for Greg, going through normal maintainership channels.
> > 
> > IOW, I think devres is too generic to be queued via libata-dev.git.
> > 
> > Tejun, comments?
> 
> I don't have problem either way.  If it's okay with Greg, I'll queue
> future devres updates through Greg.

It's fine with me, send them on :)

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/

Re: Linux 2.6.21

[Andrew Morton]

On Mon, 30 Apr 2007 00:09:06 +0200 "Rafael J. Wysocki" <[EMAIL PROTECTED]> 
wrote:

> On Sunday, 29 April 2007 22:52, Alexey Dobriyan wrote:
> > On Sun, Apr 29, 2007 at 10:18:10PM +0200, Rafael J. Wysocki wrote:
> > > [For example, you can create a bugzilla entry with a link to the lkml.org 
> > > copy
> > > of the relevant message, so why to require the reporter to file the 
> > > report with
> > > the bugzilla himself?]
> > 
> > Last time I did this, bugzilla at osdl.org won't let me add original
> > reporter to goddamn CC list. It would be el neat, because not everyone
> > followed instructions and forwarding emails between reporter and
> > bugzilla sucks.
> 
> That's related to what I said before.  The requirement that the addresses on
> the CC list must be 'known' to bugzilla is deadly wrong in every case I can
> imagine.

But unknown-to-bugzilla email addresses are accepted when they're sent to
[EMAIL PROTECTED]  This is why I'll very often switch a
bug report to email, copying individuals and mailing lists and
bugme-daemon.  Then bugzilla just sits silently in the background recording
everything.

But once a bug has switched to email, it needs to stay there - it would be
bad if someone were to update the bug via the web UI because none of the
emailed participants would know of the update.  So i'll often explicitly
ask "please follow up via emailed reply-to-all".

It's not great, but there's certainly enough material here for people to get
in and work on the bug, should they be so inclined.

My overall approach with this stuff is: short-term bugs are handled via email
and long-term ones are tracked in buzilla.

Hence someone (Hi, Mom) needs to track all the emailed-only bug reports and get
them filed in bugzilla once they go stale.
-
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/

man-pages-2.45 and man-pages-2.46 are released

[Michael Kerrisk]

Gidday,

I just released man-pages-2.45 and man-pages-2.46.

These releases are now available for download at:

ftp://ftp.kernel.org/pub/linux/docs/manpages
or mirrors: ftp://ftp.XX.kernel.org/pub/linux/docs/manpages

and soon at:

ftp://ftp.win.tue.nl/pub/linux-local/manpages

These releases consist mainly of formatting fixes (to a large
number of pages) to achieve greater consistency across pages.

Currently there are a large number of fixes required to various man-pages.
   There are probably different people on these lists who would be able to
fix most of these; any assistance would be most appreciated.  A list of
some of the more significant problems is given below.

Cheers,

Michael



==
man2/futex.2
 FIXME
 2.6.18 adds (Ingo Molnar) priority inheritance support:
 FUTEX_LOCK_PI, FUTEX_UNLOCK_PI, and FUTEX_TRYLOCK_PI.  These need
 to be documented in the manual page.  Probably there is sufficient
 material in the kernel source file Documentation/pi-futex.txt.

==
man2/get_mempolicy.2
 FIXME writeme -- no errors are listed on this page

==
man2/mount.2
 FIXME 2.6.15 added flags for "shared sub-tree" functionality:
 MS_UNBINDABLE, MS_PRIVATE, MS_SHARED, MS_SLAVE
 These need to be documented on this page.
 See Documentation/sharedsubtree.txt

==
man2/quotactl.2
 FIXME There is much that is missing and/or out of date in this page.
 As things stand the page more or less documents Linux 2.2 reality:

==
man2/set_mempolicy.2
 FIXME writeme -- no errors are listed on this page

==
man2/shmop.2
 FIXME A good explanation of the rationale for the existence
 of SHMLBA would be useful here

==
man4/initrd.4
 FIXME the manual page should describe the pivot_root mechanism.

==
man5/acct.5
 FIXME this page needs to say a lot more, including mentioning
Version 3 format process accounting on Linux.

==
man5/core.5
 FIXME Is the following speculation correct?  If it is, then
 it might be worth incorporating it into the text:
 Always including the PID in the name of the core file made
 sense for LinuxThreads, where each thread had a unique PID,
 but doesn't seem to server any purpose with NPTL, where all the
 threads in a process share the same PID (as POSIX.1 requires).
 Probably the behaviour is maintained so that applications using
 LinuxThreads continue appending the PID (the kernel has no easy
 way of telling which threading implementation the userspace
 application is using). -- mtk, April 2006

==
man5/locale.5
 FIXME glibc 2.2.2 added new non-standard locale categories:
 LC_ADDRESS, LC_IDENTIFICATION, LC_MEASUREMENT, LC_NAME,
 LC_PAPER, LC_TELEPHONE.  These need to be documented.

==
man5/proc.5
 FIXME 2.6.14 has /proc/PID/numa_maps (if CONFIG_NUMA is
 enabled); this needs to be documented.
 Info on numa_maps can be found in the patch-2.6.14
 Changelog, but this is possibly not up to date.

 FIXME 2.6.13 seems to have /proc/vmcore implemented
 in the source code, but there is no option available under
 'make xconfig'; eventually this should be fixed, and then info
 from the patch-2.6.13 and change log could be used to write an
 entry in this man page.

 FIXME Describe /proc/[number]/loginuid
   Added in 2.6.11; updating requires CAP_AUDIT_CONTROL

 FIXME Describe /proc/[number]/mountstats and
   /proc/PID/task/TID/mountstats
  Some information can be found in the 2.6.17-rc1 change log.
   Added in 2.6.17

 FIXME Describe /proc/[number]/oom_adj
   Added in 2.6.11; updating requires CAP_SYS_RESOURCE
   Mention OOM_DISABLE (-17)
 FIXME Describe /proc/[number]/oom_score
   Added in 2.6.11; read-only

 FIXME Describe /proc/[number]/seccomp
   Added in 2.6.12

 FIXME Document /proc/config.gz (new in kernel 2.6)

 FIXME Actually, the following info abut the /proc/stat 'cpu' field
   does not seem to be quite right (at least in 2.6.12)

 FIXME more should be said about /proc/zoneinfo

==
man7/capabilities.7
 FIXME CAP_KILL also has an effect for threads + setting child
   termination signal to other than SIGCHLD: without this
   capability, the termination signal reverts to SIGCHLD
   if the child does an exec().  What is the rationale
   for this?

 FIXME CAP_SETUID also an effect in exec(); document this.

 FIXME CAP_SYS_NICE also has the following effect for
 migrate_pages(2):
 do_migrate_pages(mm, &old, &new,
 capable(CAP_SYS_NICE) ? MPOL_MF_MOVE_ALL : MPOL_MF_MOVE);

==
man7/ip.7
 FIXME has someone verified that 2.1 is really 1812 compliant?

 FIXME Document IP_FREEBIND

 FIXME document ip_autoconfig

 FIXME Document the conf/*/* sysctls
 FIXME Documen

Re: [PATCH] usb/hid:The HID Simple Driver Patches 0.5.1

[Jiri Kosina]

On Mon, 30 Apr 2007, Li Yu wrote:

> This patch set include :
>   1. usb/hid: The HID Simple Driver Interface 0.5.0 (core)
>   2. usb/hid:Microsoft Natural Ergonomic Keyboard 4000 Driver 0.5.1
>   3. Some related kbuild changes.
> The changelog since 0.5.0:
>   1. The parameter ascii_keycode of usbnek4k.ko is on default. so 
>  the five custom keys can work without any care.
>   2. Add the parameter zoom_scroll of usbnek4k.ko, so we can use 
>  zoomin/zoomout handlers as mouse scrollwheel. this is on 
>  default too.

Hi Li,

is there any chance that you rather split up the hid bus patch you have 
been working on recently into independent reviewable patches instead, as 
we were discussing it previously?

Thanks,

-- 
Jiri Kosina
-
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 2.6.21

[Tomasz Chmielewski]

Adrian Bunk schrieb:

On Sun, Apr 29, 2007 at 11:04:10PM +0200, Tomasz Chmielewski wrote:

Linus Torvalds wrote:


On Sun, 29 Apr 2007, Adrian Bunk wrote:

The kernel Bugzilla currently contains 1600 open bugs.

Adrian, why do you keep harping on this, and ignoring reality?
Kernel bugzilla has 1600 open bugs BECAUSE IT SUCKS.
How many of those are interesting and valid? How many of them are 
relevant? How many of them are duplicates?
And - how many of these bug reports have kernel's bugzilla ever forwarded 
to lkml so that other people could see them?


Is that number zero (because kernel's bugzilla is configured this way)?


Andrew forwards incoming Bugzilla bugs to the responsible maintainers 
(if there are any).


If it is considered useful it shouldn't be a problem to automatically 
forward all incoming Bugzilla bugs to linux-kernel.


Why isn't it done yet? If the bugs were already forwarded to 
linux-kernel (and perhaps, to linux- when possible, too), we 
would save at least two days of this long "Linux 2.6.21" thread...


For I somehow feel that most people here dislike bugzilla because of 
misconceptions - which only arose as bugzilla.kernel.org is *really* 
misconfigured.



--
Tomasz Chmielewski
http://wpkg.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] usb/hid:The HID Simple Driver Patches 0.5.1

[Li Yu]

This patch set include :

1. usb/hid: The HID Simple Driver Interface 0.5.0 (core)
2. usb/hid:Microsoft Natural Ergonomic Keyboard 4000 Driver 0.5.1
3. Some related kbuild changes.

The changelog since 0.5.0:

1. The parameter ascii_keycode of usbnek4k.ko is on default. so the 
five custom keys can work without any care.
2. Add the parameter zoom_scroll of usbnek4k.ko, so we can use 
zoomin/zoomout handlers as mouse scrollwheel. this is on default too.

Signed-off-by: Liyu <[EMAIL PROTECTED]>

diff -Naurp linux-2.6.21.1.orig/drivers/hid/hid-core.c 
linux-2.6.21.1.new/drivers/hid/hid-core.c
--- linux-2.6.21.1.orig/drivers/hid/hid-core.c  2007-04-28 05:49:26.0 
+0800
+++ linux-2.6.21.1.new/drivers/hid/hid-core.c   2007-04-30 11:00:10.0 
+0800
@@ -27,8 +27,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -42,6 +44,19 @@
 #define DRIVER_LICENSE "GPL"
 
 /*
+ * The global data structure for simple device driver interface.
+ */
+DEFINE_MUTEX(matched_devices_lock);
+DEFINE_MUTEX(simple_drivers_lock);
+LIST_HEAD(matched_devices_list);
+LIST_HEAD(simple_drivers_list);
+
+EXPORT_SYMBOL(matched_devices_lock);
+EXPORT_SYMBOL(simple_drivers_lock);
+EXPORT_SYMBOL(matched_devices_list);
+EXPORT_SYMBOL(simple_drivers_list);
+
+/*
  * Register a new report for a device.
  */
 
@@ -803,8 +818,12 @@ static __inline__ int search(__s32 *arra
 static void hid_process_event(struct hid_device *hid, struct hid_field *field, 
struct hid_usage *usage, __s32 value, int interrupt)
 {
hid_dump_input(usage, value);
-   if (hid->claimed & HID_CLAIMED_INPUT)
+   if (hid->claimed & HID_CLAIMED_INPUT) {
+   if (!hidinput_simple_event_filter(hid, field, usage, value))
+   return;
hidinput_hid_event(hid, field, usage, value);
+   hidinput_simple_event_post(hid, field, usage, value);
+   }
if (hid->claimed & HID_CLAIMED_HIDDEV && interrupt && 
hid->hiddev_hid_event)
hid->hiddev_hid_event(hid, field, usage, value);
 }
@@ -829,7 +848,6 @@ void hid_input_field(struct hid_device *
return;
 
for (n = 0; n < count; n++) {
-
value[n] = min < 0 ? snto32(extract(data, offset + n * 
size, size), size) :
extract(data, offset + n * 
size, size);
 
@@ -985,5 +1003,136 @@ int hid_input_report(struct hid_device *
 }
 EXPORT_SYMBOL_GPL(hid_input_report);
 
+#ifdef CONFIG_HID_SIMPLE
+static int hidinput_simple_driver_bind_one(struct hidinput_simple_driver 
*simple,
+   struct hid_device *hid,
+   struct matched_device *matched,
+   int reload)
+{
+   int ret;
+
+   if (!try_module_get(simple->owner))
+   return -ENODEV;
+   /*
+* If the simple driver register itself after device insert,
+* we must send hotplug message to userspace again, elsewise,
+* we will break down some applications.
+*/
+   if (reload && hidinput_disconnect_core(hid)) {
+   module_put(simple->owner);
+   return -ENODEV;
+   }
+   ret = hidinput_simple_driver_connect(simple, matched);
+
+   if (reload)
+   hidinput_reconnect_core(hid); /* To activate this input_dev */
+   if (!ret)
+   printk(KERN_INFO "The simple driver \'%s\' attach"
+   " to the device \'%s\'\n", simple->name, hid->name);
+   else
+   module_put(simple->owner);
+   return 0;
+}
+
+void hidinput_simple_driver_bind_foreach_simple(
+   struct hid_device *hid,
+   struct matched_device *matched)
+{
+   struct hidinput_simple_driver *simple;
+   struct list_head *node;
+   
+   if (!hid || !matched || !matched->id || matched->hid)
+   return;
+   mutex_lock(&simple_drivers_lock);
+   list_for_each(node, &simple_drivers_list) {
+   simple = list_entry(node, struct hidinput_simple_driver, node);
+   if (simple->match_device(simple, matched)) {
+   if (!hidinput_simple_driver_bind_one(simple, hid,
+   matched, 0))
+   break;
+   }
+   }
+   mutex_unlock(&simple_drivers_lock);
+}
+EXPORT_SYMBOL(hidinput_simple_driver_bind_foreach_simple);
+
+void hidinput_simple_driver_bind_foreach_matched(
+   struct hidinput_simple_driver *simple)
+{
+   struct list_head *node=NULL;
+   struct matched_device *matched;
+   struct hid_device *hid=NULL;
+
+   if (!simple)
+   return;
+
+   mutex_l

[PATCH] zero_user_page uses in fs/buffer.c and fs/libfs.c

[Christoph Lameter]

There are a couple of places where kmap_atomic is surrounding two
memory operations. Usually only one of them is performed. So it is
possible to also use zero_user_page there.

Cc: Nate Diller <[EMAIL PROTECTED]>
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

---
 fs/buffer.c |   29 ++---
 fs/libfs.c  |   12 ++--
 2 files changed, 16 insertions(+), 25 deletions(-)

Index: linux-2.6.21-rc7-mm1/fs/buffer.c
===
--- linux-2.6.21-rc7-mm1.orig/fs/buffer.c   2007-04-25 00:20:35.0 
-0700
+++ linux-2.6.21-rc7-mm1/fs/buffer.c2007-04-25 00:24:05.0 -0700
@@ -1796,19 +1796,12 @@ static int __block_prepare_write(struct 
set_buffer_uptodate(bh);
continue;
}
-   if (block_end > to || block_start < from) {
-   void *kaddr;
-
-   kaddr = kmap_atomic(page, KM_USER0);
-   if (block_end > to)
-   memset(kaddr+to, 0,
-   block_end-to);
-   if (block_start < from)
-   memset(kaddr+block_start,
-   0, from-block_start);
-   flush_dcache_page(page);
-   kunmap_atomic(kaddr, KM_USER0);
-   }
+   if (block_end > to)
+   zero_user_page(page, to,
+   block_end - to, KM_USER0);
+   if (block_start < from)
+   zero_user_page(page, block_start,
+   from - block_start, KM_USER0);
continue;
}
}
@@ -2224,7 +2217,6 @@ int nobh_prepare_write(struct page *page
unsigned block_in_page;
unsigned block_start;
sector_t block_in_file;
-   char *kaddr;
int nr_reads = 0;
int i;
int ret = 0;
@@ -2264,13 +2256,12 @@ int nobh_prepare_write(struct page *page
if (PageUptodate(page))
continue;
if (buffer_new(&map_bh) || !buffer_mapped(&map_bh)) {
-   kaddr = kmap_atomic(page, KM_USER0);
if (block_start < from)
-   memset(kaddr+block_start, 0, from-block_start);
+   zero_user_page(page, block_start,
+   from - block_start, KM_USER0);
if (block_end > to)
-   memset(kaddr + to, 0, block_end - to);
-   flush_dcache_page(page);
-   kunmap_atomic(kaddr, KM_USER0);
+   zero_user_page(page, to,
+   block_end - to, KM_USER0);
continue;
}
if (buffer_uptodate(&map_bh))
Index: linux-2.6.21-rc7-mm1/fs/libfs.c
===
--- linux-2.6.21-rc7-mm1.orig/fs/libfs.c2007-04-25 00:24:10.0 
-0700
+++ linux-2.6.21-rc7-mm1/fs/libfs.c 2007-04-25 00:25:56.0 -0700
@@ -337,12 +337,12 @@ int simple_prepare_write(struct file *fi
unsigned from, unsigned to)
 {
if (!PageUptodate(page)) {
-   if (to - from != PAGE_CACHE_SIZE) {
-   void *kaddr = kmap_atomic(page, KM_USER0);
-   memset(kaddr, 0, from);
-   memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
-   flush_dcache_page(page);
-   kunmap_atomic(kaddr, KM_USER0);
+   if (to - from != PAGE_CACHE_SIZE)
+   if (from)
+   zero_user_page(page, 0, from, KM_USER0);
+   if (to < PAGE_CACHE_SIZE)
+   zero_user_page(page, to,
+   PAGE_CACHE_SIZE - to, KM_USER0);
}
}
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21

[Tomasz Chmielewski]

David Miller wrote:


> I reported a bug that eats people's hard disks due to a bug
> in the X.ORG PCI support code on sparc, NOBODY has fixed
> the bug in 2 years even though a full bugzilla entry with
> even a full patch fix is in there.

Well but at least they could find it again if they wanted.
If you sent it by email and it had gotten lost for some reason
(nobody interested, which seems to be the real issue here) then
it would be lost forever.


WRONG!  If I have sent it to the main developer list the damn patch
would be applied by now.


Why didn't you do it then? Why didn't you send your patch to the main 
developer?

Wouldn't be your problem fixed if you did it?



WHY?

BECAUSE EMAIL ENGAGES PEOPLE AND BUGZILLA DOES NOT!


--
Tomasz Chmielewski
http://wpkg.org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] fallocate system call

[Chris Wedgwood]

On Mon, Apr 30, 2007 at 03:56:32PM +1000, David Chinner wrote:
> On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote:

> IIRC, the argument for FA_ALLOCATE changing file size is that
> posix_fallocate() is supposed to change the file size.

But it's not posix_fallocate; it's something more generic. glibc can
do posix_fallocate using truncate + fallocate.

> Note that the way XFS implements growing the file size after the
> allocation is via a truncate

What's wrong with that?  That seems very reasonable.

> That's would what I did because otherwise you'd use ftruncate64().
> Without documented behaviour or an ext4 implementation, I have to
> ask what it's supposed to do, though ;)

How many *real* users are there for ext4?  Why does 'what ext4 does'
define 'the semantics'?

Surely semantics should be decided either by precedent (if there is an
existing relevant userbase) or sensible thought and some debate?
-
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: can a kmalloc be both GFP_ATOMIC and GFP_KERNEL at the same time?

[Christoph Lameter]

On Sat, 28 Apr 2007, Alan Cox wrote:

> > > drivers/scsi/aic7xxx_old.c:  aic_dev = kmalloc(sizeof(struct 
> > > aic_dev_data), GFP_ATOMIC | GFP_KERNEL);
> > > drivers/message/i2o/device.c:   resblk = kmalloc(buflen + 8, GFP_KERNEL | 
> > > GFP_ATOMIC);
> > >
> > >   clarification?
> > 
> > oh, i'm *aware* of the definitions of those flags, but every single
> > source i've ever read has *strongly* suggested that you don't use
> 
> I don't believe either of those is doing what the author intended 8).

Well sortof. First of all kmalloc may not even allocate a page to 
satisfy the request. If it does then we do essentially GFP_KERNEL | 
__GFP_HIGH meaning a allocation where we can sleep etc but are allowed to 
dip into the reserves.

-
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/5] fallocate system call

[David Chinner]

On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote:
> On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote:
> 
> > For FA_ALLOCATE, it's supposed to change the file size if we
> > allocate past EOF, right?
> 
> I would argue no.  Use truncate for that.

I'm going from the ext4 implementation because the semantics
have not been documented yet.

IIRC, the argument for FA_ALLOCATE changing file size is that
posix_fallocate() is supposed to change the file size. I think
that having a mode for real preallocation and another for
posix_fallocate is a valid thing to do...

Note that the way XFS implements growing the file size after the
allocation is via a truncate

> > For FA_DEALLOCATE, does it change the filesize at all?
> 
> Same as above.
> 
> > Or does
> > it just punch a hole in the file?
> 
> Yes.

That's would what I did because otherwise you'd use ftruncate64().
Without documented behaviour or an ext4 implementation, I have to
ask what it's supposed to do, though ;)

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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] [9/26] x86_64: Fix vmalloc_32 to really allocate <4GB on 64bit platforms

[Borislav Petkov]

Sorry, I meant this one:


Index: 2.6.21/mm/vmalloc.c
===
--- 2.6.21.orig/mm/vmalloc.c
+++ 2.6.21/mm/vmalloc.c
@@ -577,6 +577,16 @@ void *vmalloc_exec(unsigned long size)
return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL_EXEC);
 }
 
+#if defined(CONFIG_64BIT)
+  #if defined(CONFIG_ZONE_DMA32)
+  #define GFP_VMALLOC32 GFP_DMA32
+  #elif defined(CONFIG_ZONE_DMA)
+  #define GFP_VMALLOC32 GFP_DMA
+  #endif
+#else
+  #define GFP_VMALLOC32 GFP_KERNEL
+#endif
+
 /**
  * vmalloc_32  -  allocate virtually contiguous memory (32bit addressable)
  * @size:  allocation size
-- 
Regards/Gruß,
Boris.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Incorrect order of last two arguments of ptrace for requests PPC_PTRACE_GETREGS, SETREGS, GETFPREGS, SETFPREGS

[Paul Mackerras]

Anton Blanchard writes:

> I looked at this a while ago and my decision at the time was to keep the
> old implementation around for a while and create two new ones that match
> the x86 numbering:
> 
> #define PTRACE_GETREGS12
> #define PTRACE_SETREGS13
> #define PTRACE_GETFPREGS  14
> #define PTRACE_SETFPREGS  15
> 
> I hate gratuitous differences, each ptrace app ends up with a sea of
> ifdefs.
> 
> Also I think it would be worth changing getregs/setregs to grab the
> entire pt_regs structure. Otherwise most ops (gdb, strace etc) will just
> have to make multiple ptrace calls to get the nia etc.

Did you do a patch to do that?

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: Linux 2.6.21

[Willy Tarreau]

On Sun, Apr 29, 2007 at 07:37:25PM +0200, Andi Kleen wrote:
> > My personal experience with bugzilla is that it's very unfriendly to
> > reporters.  IMHO it's suitable for tracking unresolved problems along with
> > debug patches, system information etc., but not for _reporting_ new ones.
> 
> What did you find unfriendly? 

It is too much complicated for new reporters.

I remember I sent a patch by mail for NTP to people at ISC, and they asked
me to pass through bugzilla because it was important for them to track it.
What initially was a 5 minutes email turned to a 30 minutes nightmare with
doubts at every click, and it was even difficult for me to attach the patch.

Later they replied to me by mail, which I consulted from another address, I
replied and was rejected because it was not the same address... I had to be
very very motivated to use such a crap.

Definitely the tool we need if we want to reduce the number of bug reports!

Just my experience as a bug reporter...

Willy

-
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] Propagate errors from find in scripts/gen_initramfs_list.sh

[Michael Ellerman]

If the find(1) in scripts/gen_initramfs_list.sh generates any errors, it
will cause gen_initramfs_list.sh to fail (because of "set -e"), however
the errors from find are not printed to the user. This is rather confusing:

~/src/powerpc$ make O=~/build/powerpc-cell32/
make[2]: *** [usr/initramfs_data.cpio.gz] Error 1
make[1]: *** [usr] Error 2
make[1]: *** Waiting for unfinished jobs
make[1]: *** wait: No child processes.  Stop.
make: *** [_all] Error 2


It is much easier to work out what the problem is if we let the errors
from find hit the console, eg:

~/src/powerpc$ make O=~/build/powerpc-cell32/
find: /home/michael/initramfs-source/home: Permission denied
find: /home/michael/initramfs-source/lost+found: Permission denied
find: /home/michael/initramfs-source/opt: Permission denied
find: /home/michael/initramfs-source/root: Permission denied
make[2]: *** [usr/initramfs_data.cpio.gz] Error 1
make[1]: *** [usr] Error 2
make[1]: *** Waiting for unfinished jobs
make[1]: *** wait: No child processes.  Stop.
make: *** [_all] Error 2

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---

 scripts/gen_initramfs_list.sh |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: powerpc/scripts/gen_initramfs_list.sh
===
--- powerpc.orig/scripts/gen_initramfs_list.sh
+++ powerpc/scripts/gen_initramfs_list.sh
@@ -171,7 +171,7 @@ dir_filelist() {
${dep_list}header "$1"
 
srcdir=$(echo "$1" | sed -e 's://*:/:g')
-   dirlist=$(find "${srcdir}" -printf "%p %m %U %G\n" 2>/dev/null)
+   dirlist=$(find "${srcdir}" -printf "%p %m %U %G\n")
 
# If $dirlist is only one line, then the directory is empty
if [  "$(echo "${dirlist}" | wc -l)" -gt 1 ]; then
-
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: [00/17] Large Blocksize Support V3

[Christoph Lameter]

On Fri, 27 Apr 2007, Andrew Morton wrote:

> By misunderstanding any suggestions, misrepresenting them, making incorrect
> statements about them, by not suggesting any alternatives yourself, all of
> it buttressed by a stolid refusal to recognise that this patch has any
> costs.

That was even mentioned in the initial post Definitely it would 
require significant changes but getting there is fairly straightforward 
with the use of compound pages.
 
> This effectively leaves it up to others to find time to think about and to
> implement possible alternative solutions to the problems which you're
> observing.

They are working on other problems like radix tree scalability it seems. 

> The altenative which is on the table (and there may be others) is
> populating pagecache with physically contiguous pages.  This will fix the
> HBA problem and is much less costly in terms of maintenance and will
> improve all workloads on all machines and doesn't have the additional
> runtime costs of pagecache wastage and more memset() overhead with small
> files and it doesn't require administrator intervention.
> 
> OTOH (yes!  there are tradeoffs!) it will consume an unknown amount more
> CPU and it doesn't address the large-fs-blocksize requirement, but I don't
> know how important the latter is and given the unrelenting advocacy storm
> coming from the SGI direction I don't know how to find that out, frankly.

This is certainly a nice approach if it works and may address one 
issue that motivated this patchset but it does not address all.

-
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: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

[Eric W. Biederman]

Rusty Russell <[EMAIL PROTECTED]> writes:

> On Sun, 2007-04-29 at 21:38 -0700, H. Peter Anvin wrote:
>> Rusty Russell wrote:
>> > 
>> > Dammit, Eric, you spend a lot of time using words like "insane" where
>> > you mean we didn't do everything all at once.
>> > 
>> > It's *not* clear that using %esi is sane, but nothing in the current
>> > code prevents that.
>> 
>> Why not?
>
> (I assume you mean why isn't it clear?)
>
> Because VMI uses the presence of a ROM to indicate it's not native.  KVM
> uses a magic MSR IIRC.

Reasonable, if you don't mid a little hardware emulation.

> I think it makes sense for lguest to change over, tho.  Patches welcome
> 8)

Sure.

Peter do we want to use the bootloader byte and assign lguest it's own
bootloader type or do we want to add another field specific to 
paravirtualized environments?

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: [PATCH 0/5] fallocate system call

[Chris Wedgwood]

On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote:

> For FA_ALLOCATE, it's supposed to change the file size if we
> allocate past EOF, right?

I would argue no.  Use truncate for that.

> For FA_DEALLOCATE, does it change the filesize at all?

Same as above.

> Or does
> it just punch a hole in the file?

Yes.

> FWIW, we definitely need a FA_PREALLOCATE mode (FA_ALLOCATE but does
> not change file size) so we can preallocate beyond EOF for apps
> which use O_APPEND (i.e. changing file size would cause problems for
> them).

FA_ALLOCATE should be able to allocate past-EOF I would argue.
-
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.21-rc7-mm2 hangs in boot

[Andrew Morton]

On Sun, 29 Apr 2007 22:01:32 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote:

> On Wed, 25 Apr 2007 22:57:16 -0700 Andrew Morton wrote:
> 
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/
> 
> I'm getting a hang near the end of booting on x86_64 UP.
> The last initcall_debug function varies.  E.g.:
> 
> 1/
> [0.140257] Calling initcall 0x806f2fa8: 
> init_misc_binfmt+0x0/0x3f()
> [0.140266] initcall 0x806f2fa8: init_misc_binfmt+0x0/0x3f() 
> returned 0.
> [0.140275] initcall 0x806f2fa8 ran for 0 msecs: 
> init_misc_binfmt+0x0/0x3f()
> [0.140284] Calling initcall 0x806f2fe7: 
> init_script_binfmt+0x0/0x12()
> [0.140293] initcall 0x806f2fe7: init_script_binfmt+0x0/0x12() 
> returned 0.
> [0.140302] initcall 0x806f2fe7 ran for 0 msecs: 
> init_script_binfmt+0x0/0x12()
> [0.140310] Calling initcall 0x806f2ff9: init_elf_binfmt+0x0/0x12()
> [0.140317] initcall 0x806f2ff9: init_elf_binfmt+0x0/0x12() 
> returned 0.
> [0.140326] initcall 0x806f2ff9 ran for 0 msecs: 
> init_elf_binfmt+0x0/0x12()
> [0.140335] Calling initcall 0x806f3de9: debugfs_init+0x0/0x4a()
> [0.140344] initcall 0x806f3de9: debugfs_init+0x0/0x4a() returned 
> 0.
> [0.140351] initcall 0x806f3de9 ran for 0 msecs: 
> debugfs_init+0x0/0x4a()
> 
> 2/
> [0.140206] Calling initcall 0x806efeb1: ksysfs_init+0x0/0x29()
> [0.140215] initcall 0x806efeb1: ksysfs_init+0x0/0x29() returned 0.
> [0.140222] initcall 0x806efeb1 ran for 0 msecs: 
> ksysfs_init+0x0/0x29()
> [0.140230] Calling initcall 0x806f25be: filelock_init+0x0/0x31()
> [0.140242] initcall 0x806f25be: filelock_init+0x0/0x31() returned 
> 0.
> [0.140249] initcall 0x806f25be ran for 0 msecs: 
> filelock_init+0x0/0x31()
> [0.140258] Calling initcall 0x806f2fa8: 
> init_misc_binfmt+0x0/0x3f()
> [0.140266] initcall 0x806f2fa8: init_misc_binfmt+0x0/0x3f() 
> returned 0.
> [0.140276] initcall 0x806f2fa8 ran for 0 msecs: 
> init_misc_binfmt+0x0/0x3f()
> [0.140284] Calling initcall 0x806f2fe7: 
> init_script_binfmt+0x0/0x12()
> [0.140293] initcall 0x806f2fe7: init_script_binfmt+0x0/0x12() 
> returned 0.
> 

So perhaps it locks during a timer interrupt.

> .config is attached.
> 
> Any ideas/suggestions?

Just the usual: nothing from sysrq or NMI watchdog?
-
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: [00/17] Large Blocksize Support V3

[Christoph Lameter]

On Sat, 28 Apr 2007, Maxim Levitsky wrote:

> 1) Is it possible for block device to assume that it will alway get big 
> requests (and aligned by big blocksize) ?

That is one of the key problems. We hope that Mel Gorman's antifrag work 
will get us there.
 
> 2) Does metadata reading/writing occuress also using same big blocksize ?

It can if the filesystem decides to and sets up the order the mapping.
 
> 3 If so, How __bread/__getblk are affrected? Does returned buffer_head point 
> to whole block ?

Correct.

-
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] CFS scheduler, -v7

[Al Boldi]

Ingo Molnar wrote:
>
> i'm pleased to announce release -v7 of the CFS scheduler patchset. (The
> main goal of CFS is to implement "desktop scheduling" with as high
> quality as technically possible.)
:
:
> As usual, any sort of feedback, bugreport, fix and suggestion is more
> than welcome,

This one seems on par with SD, but there are still some nice issues.

Try running 3 chew.c's, then renicing one to -10, starves others for some 
seconds while switching prio-level.  Now renice it back to 10, it starves 
for up to 45sec.

Also, nice levels are only effective on every other step; ie:
 ... -3/-2 , -1/0 , 1/2 ... yields only 20 instead of 40 prio-levels.


Thanks!

--
Al

-
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/

gdb-6.4: is not handling input 'q' properly

[Dharmosoth Seetharam]

Hi, 

The following result was the effect of "info threads"
command

Architecture: x86_64 , Linux kernel : 2.6.7 and 2.6.20



34 process 541  0xa017544e in ?? ()
  33 process 540  schedule_timeout
(timeout=1101144554856)
at kernel/timer.c:1164
  32 process 493  md_thread (arg=0x8068c800)
at drivers/md/md.c:4526
  31 process 384  schedule_timeout
(timeout=9223372036854775807)
---Type  to continue, or q  to
quit---q
 at kernel/timerQuit
  30 process 383  schedule_timeout
(timeout=1100444515608)
at kernel/timer.c:1164
  29 process 382  0x801656b7 in worker_thread
(__cwq=0x100fb134650)
at include/linux/sched.h:1163
  28 process 381  0x801656b7 in worker_thread
(__cwq=0x100fb134190)
at include/linux/sched.h:1163



It displays the --- continue Or quit --- 
I have entered the 'q' (want to stop scrolling).

But, it shows the "Quit" and continues to scroll down.

We can observe that - the last line (24th line) on
cosole has a wrapped text (ie "at kernel/").

Please update me with the change.

Thanks
RAM


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21

[Gene Heskett]

On Monday 30 April 2007, Bernd Eckenfels wrote:
>In article <[EMAIL PROTECTED]> you wrote:
>> You can't have it even do a search to see if it already has something
>> similar without creating an account and logging in.  Since I'm out of wall
>> space, and the missus is bugging me to paint over all that, I left.
>
>Well, thats not a bugzilla problem. upstream bugzilla allows anonymous
>search.
>
>Infact bugme.osdl.org allows search right on the frontpage. And if you want
>to dig deeper, use the query function.
>
>This is the quicksearch on "USB":
>
>_status=OPEN&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type
>0-0-0=substring&value0-0-0=usb&field0-0-1=component&type0-0-1=substring&valu
>e0-0-1=usb&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=usb&field0-0
>-3=status_whiteboard&type0-0-3=substring&value0-0-3=usb>
>
And that output I'll have to admit, is much more usefull.  However, in your 
wildest dreams I couldn't recompose that link line if I was stuck in a pool 
drain 10 feet down and that turned on the air hose I had in my hands.

>> I repeat:  Usefull?  For what?
>
>Try again.
>
>Gruss
>Bernd



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
He who is content with his lot probably has a lot.
-
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: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

[Rusty Russell]

On Sun, 2007-04-29 at 21:38 -0700, H. Peter Anvin wrote:
> Rusty Russell wrote:
> > 
> > Dammit, Eric, you spend a lot of time using words like "insane" where
> > you mean we didn't do everything all at once.
> > 
> > It's *not* clear that using %esi is sane, but nothing in the current
> > code prevents that.
> 
> Why not?

(I assume you mean why isn't it clear?)

Because VMI uses the presence of a ROM to indicate it's not native.  KVM
uses a magic MSR IIRC.

I think it makes sense for lguest to change over, tho.  Patches welcome
8)

Rusty.


-
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 2.6.21

[Kyle Moffett]

It might not be bad to write up an email-based BTS-alike bug-tracking  
system just for the Linux kernel.  It should probably even be  
implemented 100% via email at first, with a web-based status viewer  
as a later add-on.  Here's a possible email format:


[kbugger: action1 arg1 arg2 ..., action2 arg1 arg2 ...]

Make it almost totally message-id and thread based, and make it an  
implicit part of LKML (IE: subscribe the kbugger program to LKML).   
People who are flagged "admin" may ban/unban users and make certain  
large-scale changes.  Supported actions:


create, create-parent, create-thread:
  Create a new bug associated with this message.
  The arguments specify the title.
  This would automatically happen for new threads with titles like  
"[BUG] foo: It's broken"


merge:
  Merges the current bug and/or email thread into an existing bug.
  The arguments are a list of bug numbers and/or message-IDs to  
merge together with this one.


prune, prune-parent, prune-thread:
  Prunes a given thread from the current bug.
  Optional argument specifies a referential message-ID

settitle:
  Change the title of the current bug

fixed, broken:
  Mark the bug as fixed or broken in a particular version/configuration
  Arguments are used as opaque strings representing configurations  
where it is known to be fixed or broken.  For example [kbugger: fixed  
2.6.16 2.6.20-x86, broken 2.6.20-ppc] would just store the list of  
strings and statuses.  If the bug was auto-created with a title like  
"[BUG ppc] foo: It's broken" or "[BUG 2.6.20] bar: I dunno", then the  
argument to the [BUG] title portion will be auto-passed to [kbugger:  
broken].


status:
  Get a brief status report on the current bug.

info:
  Get a detailed status report on the current bug.

history:
  Get detailed information about the history of the current bug.   
This only sends the reply to the author.


stop:
  Stop parsing the rest of this email.  Useful when teaching  
somebody about kbugger commands via an email sent to kbugger itself.


The results of the kbugger statements in an email will be sent as a  
reply to the original message and "To:" the original sender, "CC:"- 
ing the targets of the message, so if the original [kbugger: create]  
post went to LKML then the reply will go there as well for people to  
read and for it to be archived by kbugger as part of the status  
history of that bug.  All emails it receives will be autoparsed for  
commands, however it should be coded to ignore all text in emailed  
patches, and it should support the [kbugger: stop] command to halt  
parsing for cases where you need to send plain kbugger commands via  
email.


If somebody was feeling unusually brave they might add some  
keyword<=>author bayesian tracking so that it could automatically  
discover the keywords in emails that particular authors reply to and  
helpfully forward a kbugger info email to that person with a link to  
the archives for the original thread.  If somebody didn't want to  
receive such info messages they could click a link or send a  
[kbugger: no-auto-forward] command to blacklist themselves from  
receiving automatic forwards ([kbugger: auto-forward] to re-enable).   
Maybe even [kbugger: not-for-me ...] and [kbugger: for-me] commands  
which take bug numbers and message-IDs to tune the keyword lists.


I may try working on something like that this week if I get the time.

Cheers,
Kyle Moffett

-
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] [9/26] x86_64: Fix vmalloc_32 to really allocate <4GB on 64bit platforms

[Borislav Petkov]

On Mon, Apr 30, 2007 at 01:46:18AM +0200, Andi Kleen wrote:
> 
> Ugly ifdef, but should handle all 64bit platforms that have suitable
> zones. On some like Altix it's probably impossible without IOMMU
> use to get memory <4GB this way,  but they have to live with that.
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
> 
> ---
>  mm/vmalloc.c |   12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> Index: linux/mm/vmalloc.c
> ===
> --- linux.orig/mm/vmalloc.c
> +++ linux/mm/vmalloc.c
> @@ -577,6 +577,14 @@ void *vmalloc_exec(unsigned long size)
>   return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL_EXEC);
>  }
>  
> +#if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
> +#define GFP_VMALLOC32 GFP_DMA32
> +#elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
> +#define GFP_VMALLOC32 GFP_DMA
> +#else
> +#define GFP_VMALLOC32 GFP_KERNEL
> +#endif
> +

Isn't the following shorter:


Index: 2.6.21/mm/vmalloc.c
===
--- 2.6.21.orig/mm/vmalloc.c
+++ 2.6.21/mm/vmalloc.c
@@ -577,6 +577,15 @@ void *vmalloc_exec(unsigned long size)
return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL_EXEC);
 }

+#if defined(CONFIG_64BIT)
+  #if defined(CONFIG_ZONE_DMA32)
+  #define GFP_VMALLOC32 GFP_DMA32
+  #elif defined(CONFIG_ZONE_DMA)
+  #define GFP_VMALLOC32 GFP_DMA
+#else
+  #define GFP_VMALLOC32 GFP_KERNEL
+#endif
+
 /**
  * vmalloc_32  -  allocate virtually contiguous memory (32bit addressable)
  * @size:  allocation size
-- 
Regards/Gruß,
Boris.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> You can't have it even do a search to see if it already has something similar 
> without creating an account and logging in.  Since I'm out of wall space, and 
> the missus is bugging me to paint over all that, I left.

Well, thats not a bugzilla problem. upstream bugzilla allows anonymous
search.

Infact bugme.osdl.org allows search right on the frontpage. And if you want
to dig deeper, use the query function.

This is the quicksearch on "USB":



> I repeat:  Usefull?  For what?

Try again.

Gruss
Bernd
-
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 03/32] xen: Add nosegneg capability to the vsyscall page notes

[Jeremy Fitzhardinge]

Roland McGrath wrote:
> I wouldn't add that macro to asm/elf.h.  There is nothing magical or
> standard about that number.
>   

It was just there for a later patch to set/clear the mask dynamically
depending on whether we're running under Xen.  But I haven't implemented
that yet.

J
-
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 2.6.21

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> If it is considered useful it shouldn't be a problem to automatically 
> forward all incoming Bugzilla bugs to linux-kernel.

Yes, most of it to linux-kernel, some components (netdev@, architecture) to
a more specific list.

Gruss
Bernd
-
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/

Slab allocators: Remove useless __GFP_NO_GROW flag (fwd)

[Christoph Lameter]

Forgot to CC lkml.

-- Forwarded message --
Date: Sun, 29 Apr 2007 21:52:32 -0700 (PDT)
From: Christoph Lameter <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Slab allocators: Remove useless __GFP_NO_GROW flag

There is no user remaining and I have never seen any use of that flag.

Sorry, I overlooked it when reviewing slab flags. It was hidden in the
GFP flags and I only spotted it when looking at the antifrag patches. The
"Slab internal use" comment got my attention because there is no such 
internal use. It is never set. I could also find no outside user.

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

---
 include/linux/gfp.h |3 +--
 mm/slab.c   |6 ++
 mm/slub.c   |3 ---
 3 files changed, 3 insertions(+), 9 deletions(-)

Index: slub/include/linux/gfp.h
===
--- slub.orig/include/linux/gfp.h   2007-04-29 21:33:53.0 -0700
+++ slub/include/linux/gfp.h2007-04-29 21:41:05.0 -0700
@@ -43,7 +43,6 @@ struct vm_area_struct;
 #define __GFP_REPEAT   ((__force gfp_t)0x400u) /* Retry the allocation.  Might 
fail */
 #define __GFP_NOFAIL   ((__force gfp_t)0x800u) /* Retry for ever.  Cannot fail 
*/
 #define __GFP_NORETRY  ((__force gfp_t)0x1000u)/* Do not retry.  Might fail */
-#define __GFP_NO_GROW  ((__force gfp_t)0x2000u)/* Slab internal usage */
 #define __GFP_COMP ((__force gfp_t)0x4000u)/* Add compound page metadata */
 #define __GFP_ZERO ((__force gfp_t)0x8000u)/* Return zeroed page on 
success */
 #define __GFP_NOMEMALLOC ((__force gfp_t)0x1u) /* Don't use emergency 
reserves */
@@ -58,7 +57,7 @@ struct vm_area_struct;
 /* if you forget to add the bitmask here kernel will crash, period */
 #define GFP_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS| \
__GFP_COLD|__GFP_NOWARN|__GFP_REPEAT| \
-   __GFP_NOFAIL|__GFP_NORETRY|__GFP_NO_GROW|__GFP_COMP| \
+   __GFP_NOFAIL|__GFP_NORETRY|__GFP_COMP| \
__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE| \
__GFP_RECLAIMABLE|__GFP_MOVABLE)
 
Index: slub/mm/slab.c
===
--- slub.orig/mm/slab.c 2007-04-29 21:34:24.0 -0700
+++ slub/mm/slab.c  2007-04-29 21:34:49.0 -0700
@@ -2722,9 +2722,7 @@ static int cache_grow(struct kmem_cache 
 * Be lazy and only check for valid flags here,  keeping it out of the
 * critical path in kmem_cache_alloc().
 */
-   BUG_ON(flags & ~(GFP_DMA | GFP_LEVEL_MASK | __GFP_NO_GROW));
-   if (flags & __GFP_NO_GROW)
-   return 0;
+   BUG_ON(flags & ~(GFP_DMA | GFP_LEVEL_MASK));
 
ctor_flags = SLAB_CTOR_CONSTRUCTOR;
local_flags = (flags & GFP_LEVEL_MASK);
@@ -3228,7 +3226,7 @@ retry:
flags | GFP_THISNODE, nid);
}
 
-   if (!obj && !(flags & __GFP_NO_GROW)) {
+   if (!obj) {
/*
 * This allocation will be performed within the constraints
 * of the current cpuset / memory policy requirements.
Index: slub/mm/slub.c
===
--- slub.orig/mm/slub.c 2007-04-29 21:34:13.0 -0700
+++ slub/mm/slub.c  2007-04-29 21:34:20.0 -0700
@@ -822,9 +822,6 @@ static struct page *new_slab(struct kmem
void *last;
void *p;
 
-   if (flags & __GFP_NO_GROW)
-   return NULL;
-
BUG_ON(flags & ~(GFP_DMA | GFP_LEVEL_MASK));
 
if (flags & __GFP_WAIT)
-
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: vmstat: use our own timer events

[Christoph Lameter]

On Sun, 29 Apr 2007, Andrew Morton wrote:

> > on each node at the second and then each of the other processor on a
> > node on a subsequent tick. That may be useful to keep a large amount
> > of the second free of timer activity. Maybe the timer folks will have
> > some feedback on this one?
> 
> The one-per-second timer interrupt will upset the people who are really
> aggressive about power consumption (eg, OLPC).  Perhaps there isn't (yet)
> an intersection between those people and SMP.

Well the cache_reaper of SLAB hits hard todays anyways. This will help
if they switch to slub because the counter consolidation is much lighter 
weight.

> However a knob to set the frequency would be nice, if it's not too
> expensive to implement.  Presumably anyone who cares enough will come along
> and add one, but then they have to wait for a long period for that change
> to propagate out to their users, which is a bit sad for something which we
> already knew about.

Ok will do.
 
> Having each CPU touch every zone looks a bit expensive - I'd have thought
> that it would be showing up a little on your monster NUMA machines?

Vmstat updates only touch cachelines that are node local. Data from
remote zones may be updated but pcps of those remote zones are for
this processor and have been placed local to the processor accessing them.

Thus no problem for monster NUMA.

> Oh dear.  Some of these new notifier types are added by a patch which is a
> few hundred patches later than slub.  I can park this patch after that one,
> but that introduces a risk that later slub patches will also get
> disconnected.

I am fine with delaying this. I just wanted the timer guys to have a 
chance to shape this a bit. Not sure what they want. What they did to the 
cache_reaper in 2.6.20/21 is bad.

-
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: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

[Rusty Russell]

On Sun, 2007-04-29 at 00:24 -0700, Jeremy Fitzhardinge wrote:
> Is it possible to decompress and extract the kernel image from the
> bzImage without executing it?  Ie, is there enough information to find
> the compressed data part of the bzImage by inspection?
> 
> At some point we'll need to change the Xen domain builder to handle
> bzImage files, and it would be best if we didn't need to run them.

Almost.  See lguest's launcher code: load_bzimage().  You'll hate it 8)

Rusty.


-
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: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

[H. Peter Anvin]

Rusty Russell wrote:
> 
> Dammit, Eric, you spend a lot of time using words like "insane" where
> you mean we didn't do everything all at once.
> 
> It's *not* clear that using %esi is sane, but nothing in the current
> code prevents that.
> 

Why not?

-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: utrace comments

[Roland McGrath]

I'm sorry I've taken so long to reply to your review comments.
I won't dwell on that, and just dive into the discussion.

> --- linux-2.6/include/asm-i386/thread_info.h.utrace-ptrace-compat
> +++ linux-2.6/include/asm-i386/thread_info.h
> @@ -135,13 +135,13 @@ static inline struct thread_info *curren
>  #define TIF_NEED_RESCHED 3   /* rescheduling necessary */
>  #define TIF_SINGLESTEP   4   /* restore singlestep on return 
> to user mode */
>  #define TIF_IRET 5   /* return with iret */
> -#define TIF_SYSCALL_EMU  6   /* syscall emulation active */
>  #define TIF_SYSCALL_AUDIT7   /* syscall auditing active */
>  #define TIF_SECCOMP  8   /* secure computing */
>  #define TIF_RESTORE_SIGMASK  9   /* restore signal mask in do_signal() */
>  #define TIF_MEMDIE   16
>  #define TIF_DEBUG17  /* uses debug registers */
>  #define TIF_IO_BITMAP18  /* uses I/O bitmap */
> +#define TIF_FORCED_TF19  /* true if TF in eflags 
> artificially */
> 
>   I think it would make a lot of sense if you simply reused the
>   existing flag number instead of leaving a hole.

You mean renumber 7,8,9 down to 6,7,8?  I guess there's no reason not to
do that, I was just not changing values I didn't need to.  AFAIK the
only thing that matters about these value is the bits < 16 that there
and the bits >= 16 likewise, for _TIF_ALLWORK_MASK to work right.

> +#define utrace_lock(utrace)  spin_lock(&(utrace)->lock)
> +#define utrace_unlock(utrace)spin_unlock(&(utrace)->lock)
> 
>   Please don't introduce such obsfucation macros.

I removed them.

> +/***
> + *** These are the exported entry points for tracing engines to use.
> + ***/
> 
>   This is not a standard comment format.  It should be:

Ok.  The intention was to clearly set off those declarations from others.
It appears the thing other linux/*.h files do for this is:

/**
 * These are the exported entry points for tracing engines to use.
 **/

>   Please don't put such long comments in headerfiles.  They should be
>   part of the kerneldoc comments near the actual function body so
>   we can extract them and autogenerate real documentation for it.
>   A big thanks for the huge amount of comments, btw - they're just
>   in the wrong place ;-)

Ok.  The kerneldoc stuff is new and strange to me, and I've never
personally experienced its benefical features.  But I've read
Documentation/kernel-doc-nano-HOWTO.txt now and I will try to convert all
my documentary comments to that style.

>   Please try consolidate all the compat code in a single #ifdef block,
>   preferably at the end of the file.

I did it this way to put each compat_foo near foo so it makes sense in
context, and it's easy to remember to update it in parallel if you change
foo.  Is it really better to move them all to an undifferentiated cluster
at the end?

>   Please don't do this kind of conditional mess.  It leads to really
>   ugly code like this (later in the patch):
> 
> #ifdef ARCH_HAS_SINGLE_STEP
>   if (! ARCH_HAS_SINGLE_STEP)
> #endif
>   WARN_ON(flags & UTRACE_ACTION_SINGLESTEP);
> #ifdef ARCH_HAS_BLOCK_STEP
>   if (! ARCH_HAS_BLOCK_STEP)
> #endif
>   WARN_ON(flags & UTRACE_ACTION_BLOCKSTEP);
> 
>   Instead make it a
> 
>   arch_has_single_step()
> 
>   which must be defined by every architecture as a boolean value, with
>   fixes like that the code above will become a lot more readable:
> 
>   WARN_ON(!arch_has_single_step() && (flags & UTRACE_ACTION_SINGLESTEP));
>   WARN_ON(!arch_has_block_step() && (flags & UTRACE_ACTION_BLOCKSTEP));

I agree it's come out ugly.  The reason I complicated it was an attempt
to make the answer testable in #if when it's constant at compile time.
My thinking is there will be situations where you want to avoid building
in some useless dead code and just "if (0)" is not sufficient.  But
primarily I was thinking of avoiding building extra fancy code in lieu
of single-step on machines/configurations where single-step is always
available, and the current #if's don't help with that.  How about if an
asm-arch/tracehook.h either declares arch_has_single_step or else it
#define's one of two things and in a single place I'll add:

#ifdef ARCH_ALWAYS_HAS_SINGLE_STEP
#define arch_has_single_step()  1
#elif defined ARCH_NEVER_HAS_SINGLE_STEP
#define arch_has_single_step()  0
#endif

>   The coding style here is wrong.  The else should be on the line
>   of the closing brace.  

I can ordinarily ignore syntax, but this is an abomination in the sight
of the Lord and always will be.  Fortunately, it's far from being 100%
consistently used in 

Re: [PATCH] utrace: remove indirections

[Roland McGrath]

I am not in favor of this change.

Previously you said:

>   This shows very nicely why the tracehooks vs utrace abstraction
>   is utter madness.  Every tracehook 'abstraction' just conatains
>   an ifdef block.  Just kill CONFIG_UTRACE as there is no point
>   in making this functionality conditional an opencode the
>   utrace functionality at the callers (or add a utrace_ helper
>   for the few cases where it makes sense)

Since then I have gotten rid of the #ifdef's there so it is easier on the
eyes.  But that is not the crux of the issue.

> Currently generic code calls into tracehook_* which then alls into
> utrace_* to do the actual work.  With utrace as the new singing dancing
> framework there's little point in that, and readability would be greatly
> improved by getting rid of this.  The few places where tracehook_*
> was more than a one-liner and used in multiple places in arch code
> I renamed the call to utrace_*.

I've never meant to claim that tracehook is, or should be, an abstraction
layer in the sense of multiplexing across different implementations
simultaneously.  It's always been intended to compile away completely.
The purpose of the tracehook layer is to be "abstract" in the sense that
it is all that any other kernel code should need to know about the
tracing infrastructure.  I believe it helps readability, not of
tracehook.h, but of the rest of the kernel, and maintainability too.

The first phase of my work, and an arduous one, was to untangle and
document all the interwinings of the old ptrace implementation with core
code and the implicit assumptions between them.  utrace-tracehook.patch
is the product of this work.  Noone should ever have to deal with that
again.  Now, when someone is modifying kernel code and stumbles across a
tracehook_* call, there is a single obvious place to go looking for what
that's about.  Each call's documentation in tracehook.h gives explicit
details about the expectations of the call, including locking conditions
and so forth.  Someone modifying those documented expectations, e.g. by
changing the locking calls in the surrounding core code, knows that this
tracehook call has to be updated to resolve the conflict, and will ask
around for the right people to update the tracing infrastructure to match
the new core code.  All the while, this poor kernel hacker was never
required to think about utrace and what its implementation might need.
(People who don't care what utrace is, shouldn't have to find out.
People who didn't care what ptrace was, knew they were supposed to be afraid.)

Certainly the benefits of simple entry points from core code whose
expectations of their callers are thoroughly documented can be retained
with everything named utrace_* and tracehook.h removed.  In either event,
keeping all the entry points clean and their documentation complete and
correct requires continuous diligent maintenance effort.  Nonetheless, I
do believe the separation helps.  Those only interested in what they must
avoid breaking incidentally have something simple to contend with in
tracehook.h, rather than feeling obliged to digest utrace.txt and
utrace.h to get up to speed.  It may turn out that utrace is no good, or
winds up being drastically different (at the least, maybe I'll think of a
decent name for something, for a change).  In any event, the set of
tracehook entry points is unlikely to change very much, and new work
won't need to touch core code all over the kernel to change the tracing
infrastructure completely.

> Also kill the CONFIG_UTRACE config option, there's very little reason
> in not having a core debugging mechanisms, and this allows to get rid
> of another layer of wrapping again.

I spend most of my time debugging, so a configuration with fewer
debugging facilities rather than more is somewhat hypothetical to me
personally too.  But I don't buy the rationale for not making this
configurable.  CONFIG_PROC_FS can be turned off, and I dare say /proc is
used by more people more often, for what they would broadly term
debugging, than is ptrace.  If someone builds a special-purpose
configuration for a fixed installation that has no way to attach any kind
of debugger, then why should they have to compile in more dead code?
Moreover, it's a good test that the interfaces between core code and the
tracing infrastructure remain simple and clean that you can build a
working kernel without it.


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] utrace: remove exports

[Roland McGrath]

> All the exports in utrace are totally unused, and not really something
> I'd want modules to use anyway :)

Previously you said:

> EXPORT_SYMBOL_GPL(utrace_attach);
> 
>   There is not modular user of this, so this and the other utrace_
>   functions should not be exported.  Nor do I think that exporting
>   such a low-level process control is nessecary a good idea, but
>   we'll have to evaluate that if patches to add users show up.

If you remove the exports, just throw the whole thing away.
The reason utrace exists is to be used by modules.

It's true that the only users around are some simple test and demo
modules I've done, and some unfinished and experimental work such as
uprobes.  When useful things built on utrace get hashed out and in a
functional state ready for general consumption, then it may be time to
put them in the kernel tree.  (All the work I'm aware of is pretty well
public already, just not in any condition to be submitted.)

There is something of a chicken and egg problem here.  In the current
kernel, most people consider adding or enhancing a user debugging
facility to be intractable.  The intent of utrace is to make
experimenting and developing in this area feasible.  If it's not there,
people can't play with it.  If someone has to have a serious use before
it can be there, it's never going to be easy for anyone to get their
feet wet so they might wind up producing something serious.  

I hope there settles to be one main, nice, new thing at a higher level
with a sane user-level interface, that most everyone wants to use.
Manifestly, I have been taking my sweet time coming up with something
worth talking about so far.  Even when I do produce something like that,
I don't expect everyone to like everything about it that I like.
Someone else might produce something better or sooner or both--but noone
else seems to want to do something else new at the lowest layer.  The
basic utrace interface is about as straightforward in the core kernel
implementation context as it can be while allowing multiple unrelated
higher-level agents to coexist, and cleaning up the interfaces into
machine-dependent code.  The complexities it does have stem from efforts
to make it easier not to write bugs in the higher layers and to make it
harder to write bugs that badly derail user processes or the system
overall.  The hope is to give people a chance to write interesting
things and mitigate some of the most onerous debugging of such things.
Perhaps one day everything anyone wants to do will be based around a
higher-level thing by me or someone else, and the need for the low-level
utrace platform will fall away.  But I tend to think there will always
be some specialized uses for which people want a lower-level base to
work on.  I think of utrace like the block device layer: most people
don't care about that layer, they just want to use a filesystem and
other things above that; but there are always people who want to do some
special thing directly on the lower level, or want to start over
building an entirely different style of filesystem.


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/

[PATCH] Move sig_kernel_* et al macros to linux/signal.h

[Roland McGrath]

This patch moves the sig_kernel_* and related macros from kernel/signal.c
to linux/signal.h, and cleans them up slightly.  I need the sig_kernel_*
macros for default signal behavior in the utrace code, and want to avoid
duplication or overhead to share the knowledge.

Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
 include/linux/signal.h |  125 
 kernel/signal.c|  119 -
 2 files changed, 125 insertions(+), 119 deletions(-)

diff --git a/include/linux/signal.h b/include/linux/signal.h
index 1474905..9850667 100644  
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -243,6 +243,131 @@ extern int get_signal_to_deliver(siginfo
 
 extern struct kmem_cache *sighand_cachep;
 
+/*
+ * In POSIX a signal is sent either to a specific thread (Linux task)
+ * or to the process as a whole (Linux thread group).  How the signal
+ * is sent determines whether it's to one thread or the whole group,
+ * which determines which signal mask(s) are involved in blocking it
+ * from being delivered until later.  When the signal is delivered,
+ * either it's caught or ignored by a user handler or it has a default
+ * effect that applies to the whole thread group (POSIX process).
+ *
+ * The possible effects an unblocked signal set to SIG_DFL can have are:
+ *   ignore- Nothing Happens
+ *   terminate - kill the process, i.e. all threads in the group,
+ *   similar to exit_group.  The group leader (only) reports
+ *   WIFSIGNALED status to its parent.
+ *   coredump  - write a core dump file describing all threads using
+ *   the same mm and then kill all those threads
+ *   stop  - stop all the threads in the group, i.e. TASK_STOPPED state
+ *
+ * SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.
+ * Other signals when not blocked and set to SIG_DFL behaves as follows.
+ * The job control signals also have other special effects.
+ *
+ * ++--+
+ * |  POSIX signal  |  default action  |
+ * ++--+
+ * |  SIGHUP|  terminate   |
+ * |  SIGINT|  terminate   |
+ * |  SIGQUIT   |  coredump|
+ * |  SIGILL|  coredump|
+ * |  SIGTRAP   |  coredump|
+ * |  SIGABRT/SIGIOT|  coredump|
+ * |  SIGBUS|  coredump|
+ * |  SIGFPE|  coredump|
+ * |  SIGKILL   |  terminate(+)|
+ * |  SIGUSR1   |  terminate   |
+ * |  SIGSEGV   |  coredump|
+ * |  SIGUSR2   |  terminate   |
+ * |  SIGPIPE   |  terminate   |
+ * |  SIGALRM   |  terminate   |
+ * |  SIGTERM   |  terminate   |
+ * |  SIGCHLD   |  ignore  |
+ * |  SIGCONT   |  ignore(*)   |
+ * |  SIGSTOP   |  stop(*)(+)  |
+ * |  SIGTSTP   |  stop(*) |
+ * |  SIGTTIN   |  stop(*) |
+ * |  SIGTTOU   |  stop(*) |
+ * |  SIGURG|  ignore  |
+ * |  SIGXCPU   |  coredump|
+ * |  SIGXFSZ   |  coredump|
+ * |  SIGVTALRM |  terminate   |
+ * |  SIGPROF   |  terminate   |
+ * |  SIGPOLL/SIGIO |  terminate   |
+ * |  SIGSYS/SIGUNUSED  |  coredump|
+ * |  SIGSTKFLT |  terminate   |
+ * |  SIGWINCH  |  ignore  |
+ * |  SIGPWR|  terminate   |
+ * |  SIGRTMIN-SIGRTMAX |  terminate   |
+ * ++--+
+ * |  non-POSIX signal  |  default action  |
+ * ++--+
+ * |  SIGEMT|  coredump|
+ * ++--+
+ *
+ * (+) For SIGKILL and SIGSTOP the action is "always", not just "default".
+ * (*) Special job control effects:
+ * When SIGCONT is sent, it resumes the process (all threads in the group)
+ * from TASK_STOPPED state and also clears any pending/queued stop signals
+ * (any of those marked with "stop(*)").  This happens regardless of blocking,
+ * catching, or ignoring SIGCONT.  When any stop signal is sent, it clears
+ * any pending/queued SIGCONT signals; this happens regardless of blocking,
+ * catching, or ignored the stop signal, though (except for SIGSTOP) the
+ * default action of stopping the process may happen later or never.
+ */
+
+#ifdef SIGEMT
+#define SIGEMT_MASKrt_sigmask(SIGEMT)
+#else
+#define SIGEMT_MASK0
+#endif
+
+#if SIGRTMIN > BITS_PER_LONG
+#define rt_sigmask(sig)(1ULL << ((sig)-1))
+#else
+#define rt_sigmask(sig)sigmask(sig)
+#endif
+#define siginmask(sig, mask) (rt_sigmask(sig) & (mask))
+
+#define SIG_KERNEL_ONLY_MASK (\
+

Re: [-mm patch] i386: enable 4k stacks by default

[David Chinner]

On Sat, Apr 28, 2007 at 03:18:38PM -0600, Zan Lynx wrote:
> On Sat, 2007-04-28 at 21:19 +0200, Adrian Bunk wrote:
> > 4k stacks have become a well-tested feature used fore a long time in
> > Fedora and even in RHEL 4.
> 
> So has anyone fixed the bugs involving ext3 and LVM snapshots on top of
> DM mirror?

I doubt it.  Every time this comes up the problem of stacked I/O
configuration being able to reliably blow the 4k stack limit comes
up. Usually it's XFS that is blamed, but it seems ext3 and reiser
can both suffer from the same problem.  And now we can add things
like unionfs/ecryptfs into the stack as well

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86_64: support poll() on /dev/mcelog

[Tim Hockin]

Crap - I have just got soft lockup detected.  Back to debug.

Call Trace:
  [] wake_up_process+0x10/0x20
 [] softlockup_tick+0xea/0x110
 [] run_local_timers+0x13/0x20
 [] update_process_times+0x57/0x90
 [] mcheck_check_cpu+0x0/0x40
 [] smp_local_timer_interrupt+0x34/0x60
 [] smp_apic_timer_interrupt+0x4e/0x70
 [] apic_timer_interrupt+0x66/0x70


On 4/29/07, Tim Hockin <[EMAIL PROTECTED]> wrote:

From: Tim Hockin <[EMAIL PROTECTED]>

Background:
 /dev/mcelog is typically polled manually.  This is less than optimal for
 some situations.  Calling poll() on /dev/mcelog does not work.

Description:
 This patch adds support for poll() to /dev/mcelog.  This results in
 immediate wakeup of user apps whenever the poller finds MCEs.  Because
 the exception handler can not take any locks, it can not call the wakeup
 itself.  Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
 caught at the next return from interrupt, calling the mce_user_notify()
 routine.

 This patch also does some small cleanup for essentially unused variables,
 and moves the user notification into the body of the poller, so it is
 only called once, rather than once per CPU.

Result:
 Applications can now poll() on /dev/mcelog.  When an error is logged
 (whether through the poller or through an exception) the applications are
 woken up promptly.  This should not affect any previous behaviors.  If no
 MCEs are being logged, there is no overhead.

Alternatives:
 I considered simply supporting poll() through the poller and not using
 TIF_MCE_NOTIFY at all.  However, the time between an uncorrectable error
 happening and the user application being notified is *the*most* critical
 window for us.  Many uncorrectable errors can be logged to the network if
 given a chance.

Testing:
 I used an error-injecting DIMM to create lots of correctable DRAM errors
 and verified that my user app is woken up in sync with the polling interval.
 I also used the northbridge to inject uncorrectable ECC errors, and
 verified (printk() to the rescue) that the notify routine is called and the
 user app does wake up.

Patch:
 This patch is against 2.6.21-rc7.

Signed-Off-By: Tim Hockin <[EMAIL PROTECTED]>

---

This is the first public version version of this patch.  The TIF_*
approach was suggested by Mike Waychison and Andi did not yell at me when
I suggested it. :)


diff -pruN linux-2.6.20+th/arch/x86_64/kernel/entry.S 
linux-2.6.20+th2v2/arch/x86_64/kernel/entry.S
--- linux-2.6.20+th/arch/x86_64/kernel/entry.S  2007-04-24 22:46:19.0 
-0700
+++ linux-2.6.20+th2v2/arch/x86_64/kernel/entry.S   2007-04-29 
18:10:40.0 -0700
@@ -585,7 +585,7 @@ bad_iret:
 retint_careful:
CFI_RESTORE_STATE
bt$TIF_NEED_RESCHED,%edx
-   jnc   retint_signal
+   jnc   retint_mce
TRACE_IRQS_ON
sti
pushq %rdi
@@ -597,7 +597,23 @@ retint_careful:
cli
TRACE_IRQS_OFF
jmp retint_check
-
+
+   /* handle a waiting machine check */
+retint_mce:
+   bt $TIF_MCE_NOTIFY,%edx
+   jnc retint_signal
+   TRACE_IRQS_ON
+   sti
+   pushq %rdi
+   CFI_ADJUST_CFA_OFFSET   8
+   call mce_notify_user
+   popq %rdi
+   CFI_ADJUST_CFA_OFFSET   -8
+   GET_THREAD_INFO(%rcx)
+   cli
+   TRACE_IRQS_OFF
+   jmp retint_check
+
 retint_signal:
testl $(_TIF_SIGPENDING|_TIF_NOTIFY_RESUME|_TIF_SINGLESTEP),%edx
jzretint_swapgs
diff -pruN linux-2.6.20+th/arch/x86_64/kernel/mce.c 
linux-2.6.20+th2v2/arch/x86_64/kernel/mce.c
--- linux-2.6.20+th/arch/x86_64/kernel/mce.c2007-04-27 14:19:08.0 
-0700
+++ linux-2.6.20+th2v2/arch/x86_64/kernel/mce.c 2007-04-29 18:27:22.0 
-0700
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -39,8 +41,7 @@ static int mce_dont_init;
 static int tolerant = 1;
 static int banks;
 static unsigned long bank[NR_BANKS] = { [0 ... NR_BANKS-1] = ~0UL };
-static unsigned long console_logged;
-static int notify_user;
+static unsigned long notify_user;
 static int rip_msr;
 static int mce_bootlog = 1;
 static atomic_t mce_events;
@@ -48,6 +49,8 @@ static atomic_t mce_events;
 static char trigger[128];
 static char *trigger_argv[2] = { trigger, NULL };

+static DECLARE_WAIT_QUEUE_HEAD(mce_wait);
+
 /*
  * Lockless MCE logging infrastructure.
  * This avoids deadlocks on printk locks without having to break locks. Also
@@ -94,8 +97,7 @@ void mce_log(struct mce *mce)
mcelog.entry[entry].finished = 1;
wmb();

-   if (!test_and_set_bit(0, &console_logged))
-   notify_user = 1;
+   set_bit(0, ¬ify_user);
 }

 static void print_mce(struct mce *m)
@@ -167,15 +169,19 @@ static inline void mce_get_rip(struct mc
}
 }

-static void do_mce_trigger(void)
+/*
+ * This is only called in normal interrupt context.  This is where we do
+ * anything we need to alert userspace.  This is called directly from the
+ * poller and also from

[PATCH 1/1] fs: add 4th case to do_path_lookup

[Josef Sipek]

Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>

diff --git a/fs/namei.c b/fs/namei.c
index 2995fba..1516a9b 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1125,6 +1125,10 @@ static int fastcall do_path_lookup(int dfd, const char 
*name,
nd->mnt = mntget(fs->rootmnt);
nd->dentry = dget(fs->root);
read_unlock(&fs->lock);
+   } else if (flags & LOOKUP_ONE) {
+   /* nd->mnt and nd->dentry already set, just grab references */
+   mntget(nd->mnt);
+   dget(nd->dentry);
} else if (dfd == AT_FDCWD) {
read_lock(&fs->lock);
nd->mnt = mntget(fs->pwdmnt);
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 92b422b..aa89d97 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -48,6 +48,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
  *  - internal "there are more path compnents" flag
  *  - locked when lookup done with dcache_lock held
  *  - dentry cache is untrusted; force a real lookup
+ *  - lookup path from given dentry/vfsmount pair
  */
 #define LOOKUP_FOLLOW   1
 #define LOOKUP_DIRECTORY2
@@ -55,6 +56,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT, LAST_BIND};
 #define LOOKUP_PARENT  16
 #define LOOKUP_NOALT   32
 #define LOOKUP_REVAL   64
+#define LOOKUP_ONE128
 /*
  * Intent data
  */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/1] [RFC] New mode for path_lookup (V1)

[Josef Sipek]

Stackable file systems frequently need to lookup paths or path components
starting from an arbitrary point in the namespace (identified by a dentry
and a vfsmount).  Currently, such file systems use lookup_one_len, which is
frowned upon [1] as it does not pass the lookup intent along; not passing a
lookup intent, for example, can trigger BUG_ON's when stacking on top of
NFSv4.

The following patch introduces a new mode to path_lookup to allow lookup to
start from an arbitrary point in the namespace.  This approach has been
suggested by Christoph Hellwig at the Linux Storage & Filesystem workshop in
February of this year.

One indicates that the lookup should be relative to a dentry-vfsmnt pair by
using the LOOKUP_ONE flag.  For example, the following snippet of code,
looks up "pathcomponent" in a directory pointed to by
parent_{dentry,vfsmnt}:

nd.dentry = parent_dentry;
nd.mnt = parent_vfsmnt;

err = path_lookup("pathcomponent", LOOKUP_ONE, &nd);
if (!err) {
/* exits */

...

/* once done, release the references */
path_release(&nd);
} else if (err == -ENOENT) {
/* doesn't exits */
} else {
/* other error */
}

VFS functions such as lookup_create can be used on the nameidata structure
to pass the create intent to the file system.

Currently, there is no easy way to pass the LOOKUP_OPEN intent.  The proper
way would be to call open_namei.

We'd like to get comments about what's necessary to make stackable file
systems do lookups right - this includes potential changes to open_namei. 

Josef 'Jeff' Sipek.

[1] http://marc.info/?l=linux-kernel&m=117343337823760&w=2
-
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 preallocation beyond EOF to fallocate

[David Chinner]

Add new mode to ->fallocate() to allow allocation to occur
beyond the current EOF without changing the file size. Implement
in XFS ->fallocate() vector.

Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]>

---
 fs/xfs/linux-2.6/xfs_iops.c |8 +---
 include/linux/fs.h  |1 +
 2 files changed, 6 insertions(+), 3 deletions(-)

Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c
===
--- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_iops.c  2007-04-30 
11:02:16.0 +1000
+++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c   2007-04-30 11:09:48.233375382 
+1000
@@ -833,11 +833,13 @@ xfs_vn_fallocate(
VNODE_POSITION_XFS);
 
switch (mode) {
-   case FA_ALLOCATE: /* changes file size */
-   error = xfs_change_file_space(bdp, XFS_IOC_RESVSP,
-   &bf, 0, NULL, 0);
+   case FA_ALLOCATE:/* changes file size */
if (offset + len > i_size_read(inode))
do_setattr = offset + len;
+   /* FALL THROUGH */
+   case FA_PREALLOCATE:/* no filesize change */
+   error = xfs_change_file_space(bdp, XFS_IOC_RESVSP,
+   &bf, 0, NULL, 0);
break;
case FA_DEALLOCATE:
/* XXX: changes file size?  this just punches a hole */
Index: 2.6.x-xfs-new/include/linux/fs.h
===
--- 2.6.x-xfs-new.orig/include/linux/fs.h   2007-04-27 18:48:01.0 
+1000
+++ 2.6.x-xfs-new/include/linux/fs.h2007-04-30 11:08:05.790903661 +1000
@@ -269,6 +269,7 @@ extern int dir_notify_enable;
  */
 #define FA_ALLOCATE0x1
 #define FA_DEALLOCATE  0x2
+#define FA_PREALLOCATE 0x3
 
 #ifdef __KERNEL__
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] atl1: use dev_printk macros

[Jay Cliburn]

Use dev_printk macros for PCI related errors, warnings, debug and info
console messages.

Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
 drivers/net/atl1/atl1_ethtool.c |   19 +++--
 drivers/net/atl1/atl1_hw.c  |   22 +--
 drivers/net/atl1/atl1_main.c|   83 +-
 drivers/net/atl1/atl1_param.c   |   31 +++
 4 files changed, 68 insertions(+), 87 deletions(-)

diff --git a/drivers/net/atl1/atl1_ethtool.c b/drivers/net/atl1/atl1_ethtool.c
index c11c277..1f616c5 100644
--- a/drivers/net/atl1/atl1_ethtool.c
+++ b/drivers/net/atl1/atl1_ethtool.c
@@ -156,8 +156,7 @@ static int atl1_set_settings(struct net_device *netdev,
u16 old_media_type = hw->media_type;
 
if (netif_running(adapter->netdev)) {
-   printk(KERN_DEBUG "%s: ethtool shutting down adapter\n",
-   atl1_driver_name);
+   dev_dbg(&adapter->pdev->dev, "ethtool shutting down adapter\n");
atl1_down(adapter);
}
 
@@ -166,9 +165,8 @@ static int atl1_set_settings(struct net_device *netdev,
else {
if (ecmd->speed == SPEED_1000) {
if (ecmd->duplex != DUPLEX_FULL) {
-   printk(KERN_WARNING
-  "%s: can't force to 1000M half duplex\n",
-   atl1_driver_name);
+   dev_warn(&adapter->pdev->dev,
+   "can't force to 1000M half duplex\n");
ret_val = -EINVAL;
goto exit_sset;
}
@@ -206,9 +204,8 @@ static int atl1_set_settings(struct net_device *netdev,
}
if (atl1_phy_setup_autoneg_adv(hw)) {
ret_val = -EINVAL;
-   printk(KERN_WARNING
-   "%s: invalid ethtool speed/duplex setting\n",
-   atl1_driver_name);
+   dev_warn(&adapter->pdev->dev,
+   "invalid ethtool speed/duplex setting\n");
goto exit_sset;
}
if (hw->media_type == MEDIA_TYPE_AUTO_SENSOR ||
@@ -239,12 +236,10 @@ exit_sset:
hw->media_type = old_media_type;
 
if (netif_running(adapter->netdev)) {
-   printk(KERN_DEBUG "%s: ethtool starting adapter\n",
-   atl1_driver_name);
+   dev_dbg(&adapter->pdev->dev, "ethtool starting adapter\n");
atl1_up(adapter);
} else if (!ret_val) {
-   printk(KERN_DEBUG "%s: ethtool resetting adapter\n",
-   atl1_driver_name);
+   dev_dbg(&adapter->pdev->dev, "ethtool resetting adapter\n");
atl1_reset(adapter);
}
return ret_val;
diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c
index 69482e0..5b9dd3c 100644
--- a/drivers/net/atl1/atl1_hw.c
+++ b/drivers/net/atl1/atl1_hw.c
@@ -38,6 +38,7 @@
  */
 s32 atl1_reset_hw(struct atl1_hw *hw)
 {
+   struct pci_dev *pdev = hw->back->pdev;
u32 icr;
int i;
 
@@ -74,7 +75,7 @@ s32 atl1_reset_hw(struct atl1_hw *hw)
}
 
if (icr) {
-   printk (KERN_DEBUG "icr = %x\n", icr); 
+   dev_dbg(&pdev->dev, "ICR = 0x%x\n", icr);
return icr;
}
 
@@ -437,6 +438,7 @@ s32 atl1_phy_enter_power_saving(struct atl1_hw *hw)
  */
 static s32 atl1_phy_reset(struct atl1_hw *hw)
 {
+   struct pci_dev *pdev = hw->back->pdev;
s32 ret_val;
u16 phy_data;
 
@@ -468,8 +470,7 @@ static s32 atl1_phy_reset(struct atl1_hw *hw)
u32 val;
int i;
/* pcie serdes link may be down! */
-   printk(KERN_DEBUG "%s: autoneg caused pcie phy link down\n", 
-   atl1_driver_name);
+   dev_dbg(&pdev->dev, "pcie phy link down\n");
 
for (i = 0; i < 25; i++) {
msleep(1);
@@ -479,9 +480,7 @@ static s32 atl1_phy_reset(struct atl1_hw *hw)
}
 
if ((val & (MDIO_START | MDIO_BUSY)) != 0) {
-   printk(KERN_WARNING 
-   "%s: pcie link down at least for 25ms\n", 
-   atl1_driver_name);
+   dev_warn(&pdev->dev, "pcie link down at least 25ms\n");
return ret_val;
}
}
@@ -571,6 +570,7 @@ s32 atl1_phy_setup_autoneg_adv(struct atl1_hw *hw)
  */
 static s32 atl1_setup_link(struct atl1_hw *hw)
 {
+   struct pci_dev *pdev = hw->back->pdev;
s32 ret_val;
 
/*
@@ -581,15 +581,13 @@ static s32 atl1_setup_link(struct atl1_hw *hw)
 */
ret_val = atl1_phy_setup_autoneg_adv(hw);
if (ret_val) {
-   printk(KERN_DEBUG "%s: error setting up autonegotiation\n", 
-   atl1_driver_nam

[PATCH 0/2] atl1: minor cleanup

[Jay Cliburn]

Please accept the following trivial patches to the atl1 driver.

- use dev_printk macros
- fix whitespace damage

 drivers/net/atl1/atl1_ethtool.c |   19 +++--
 drivers/net/atl1/atl1_hw.c  |   44 ++---
 drivers/net/atl1/atl1_main.c|   83 +-
 drivers/net/atl1/atl1_param.c   |   31 +++
 4 files changed, 79 insertions(+), 98 deletions(-)
-
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/2] atl1: fix whitespace damage

[Jay Cliburn]

Remove trailing whitespace and spaces preceding tabs.

Signed-off-by: Jay Cliburn <[EMAIL PROTECTED]>
---
 drivers/net/atl1/atl1_hw.c |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c
index 5b9dd3c..ef886bd 100644
--- a/drivers/net/atl1/atl1_hw.c
+++ b/drivers/net/atl1/atl1_hw.c
@@ -2,20 +2,20 @@
  * Copyright(c) 2005 - 2006 Attansic Corporation. All rights reserved.
  * Copyright(c) 2006 Chris Snook <[EMAIL PROTECTED]>
  * Copyright(c) 2006 Jay Cliburn <[EMAIL PROTECTED]>
- * 
+ *
  * Derived from Intel e1000 driver
  * Copyright(c) 1999 - 2005 Intel Corporation. All rights reserved.
- * 
+ *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License as published by the Free
  * Software Foundation; either version 2 of the License, or (at your option)
  * any later version.
- * 
+ *
  * This program is distributed in the hope that it will be useful, but WITHOUT
  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
  * more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License along with
  * this program; if not, write to the Free Software Foundation, Inc., 59
  * Temple Place - Suite 330, Boston, MA  02111-1307, USA.
@@ -42,9 +42,9 @@ s32 atl1_reset_hw(struct atl1_hw *hw)
u32 icr;
int i;
 
-   /* 
+   /*
 * Clear Interrupt mask to stop board from generating
-* interrupts & Clear any pending interrupt events 
+* interrupts & Clear any pending interrupt events
 */
/*
 * iowrite32(0, hw->hw_addr + REG_IMR);
@@ -137,8 +137,8 @@ s32 atl1_read_phy_reg(struct atl1_hw *hw, u16 reg_addr, u16 
*phy_data)
int i;
 
val = ((u32) (reg_addr & MDIO_REG_ADDR_MASK)) << MDIO_REG_ADDR_SHIFT |
-   MDIO_START | MDIO_SUP_PREAMBLE | MDIO_RW | MDIO_CLK_25_4 <<
-   MDIO_CLK_SEL_SHIFT;
+   MDIO_START | MDIO_SUP_PREAMBLE | MDIO_RW | MDIO_CLK_25_4 <<
+   MDIO_CLK_SEL_SHIFT;
iowrite32(val, hw->hw_addr + REG_MDIO_CTRL);
ioread32(hw->hw_addr + REG_MDIO_CTRL);
 
@@ -205,7 +205,7 @@ static bool atl1_spi_read(struct atl1_hw *hw, u32 addr, u32 
*buf)
 
 /*
  * get_permanent_address
- * return 0 if get valid mac address, 
+ * return 0 if get valid mac address,
  */
 static int atl1_get_permanent_address(struct atl1_hw *hw)
 {
@@ -302,7 +302,7 @@ static int atl1_get_permanent_address(struct atl1_hw *hw)
 }
 
 /*
- * Reads the adapter's MAC address from the EEPROM 
+ * Reads the adapter's MAC address from the EEPROM
  * hw - Struct containing variables accessed by shared code
  */
 s32 atl1_read_mac_addr(struct atl1_hw *hw)
@@ -629,7 +629,7 @@ static void atl1_init_flash_opcode(struct atl1_hw *hw)
  * Performs basic configuration of the adapter.
  * hw - Struct containing variables accessed by shared code
  * Assumes that the controller has previously been reset and is in a
- * post-reset uninitialized state. Initializes multicast table, 
+ * post-reset uninitialized state. Initializes multicast table,
  * and  Calls routines to setup link
  * Leaves the transmit and receive units disabled and uninitialized.
  */
-- 
1.5.0.6

-
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] XFS ->fallocate() support

[David Chinner]

Add XFS support for ->fallocate() vector.

Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]>

---
 fs/xfs/linux-2.6/xfs_iops.c |   48 
 1 file changed, 48 insertions(+)

Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c
===
--- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_iops.c  2007-02-07 
13:24:32.0 +1100
+++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c   2007-04-30 11:02:16.225095992 
+1000
@@ -812,6 +812,53 @@ xfs_vn_removexattr(
return namesp->attr_remove(vp, attr, xflags);
 }
 
+STATIC long
+xfs_vn_fallocate(
+   struct inode*inode,
+   int mode,
+   loff_t  offset,
+   loff_t  len)
+{
+   longerror = -EOPNOTSUPP;
+   bhv_vnode_t *vp = vn_from_inode(inode);
+   bhv_desc_t  *bdp;
+   int do_setattr = 0;
+   xfs_flock64_t   bf;
+
+   bf.l_whence = 0;
+   bf.l_start = offset;
+   bf.l_len = len;
+
+   bdp = bhv_lookup_range(VN_BHV_HEAD(vp), VNODE_POSITION_XFS,
+   VNODE_POSITION_XFS);
+
+   switch (mode) {
+   case FA_ALLOCATE: /* changes file size */
+   error = xfs_change_file_space(bdp, XFS_IOC_RESVSP,
+   &bf, 0, NULL, 0);
+   if (offset + len > i_size_read(inode))
+   do_setattr = offset + len;
+   break;
+   case FA_DEALLOCATE:
+   /* XXX: changes file size?  this just punches a hole */
+   error = xfs_change_file_space(bdp, XFS_IOC_UNRESVSP,
+   &bf, 0, NULL, 0);
+   break;
+   default:
+   break;
+   }
+
+   /* Change file size if needed */
+   if (!error && do_setattr) {
+   bhv_vattr_t va;
+
+   va.va_mask = XFS_AT_SIZE;
+   va.va_size = do_setattr;
+   error = bhv_vop_setattr(vp, &va, 0, NULL);
+   }
+
+   return error;
+}
 
 struct inode_operations xfs_inode_operations = {
.permission = xfs_vn_permission,
@@ -822,6 +869,7 @@ struct inode_operations xfs_inode_operat
.getxattr   = xfs_vn_getxattr,
.listxattr  = xfs_vn_listxattr,
.removexattr= xfs_vn_removexattr,
+   .fallocate  = xfs_vn_fallocate,
 };
 
 struct inode_operations xfs_dir_inode_operations = {
-
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] ia64 fallocate syscall

[David Chinner]

ia64 fallocate syscall support.

Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]>

---
 arch/ia64/kernel/entry.S  |1 +
 include/asm-ia64/unistd.h |3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

Index: 2.6.x-xfs-new/arch/ia64/kernel/entry.S
===
--- 2.6.x-xfs-new.orig/arch/ia64/kernel/entry.S 2007-03-29 19:01:41.0 
+1000
+++ 2.6.x-xfs-new/arch/ia64/kernel/entry.S  2007-04-27 19:12:56.829396661 
+1000
@@ -1612,5 +1612,6 @@ sys_call_table:
data8 sys_vmsplice
data8 sys_ni_syscall// reserved for move_pages
data8 sys_getcpu
+   data8 sys_fallocate
 
.org sys_call_table + 8*NR_syscalls // guard against failures to 
increase NR_syscalls
Index: 2.6.x-xfs-new/include/asm-ia64/unistd.h
===
--- 2.6.x-xfs-new.orig/include/asm-ia64/unistd.h2007-03-29 
19:03:37.0 +1000
+++ 2.6.x-xfs-new/include/asm-ia64/unistd.h 2007-04-27 19:18:18.215568425 
+1000
@@ -293,11 +293,12 @@
 #define __NR_vmsplice  1302
 /* 1303 reserved for move_pages */
 #define __NR_getcpu1304
+#define __NR_fallocate 1305
 
 #ifdef __KERNEL__
 
 
-#define NR_syscalls281 /* length of syscall table */
+#define NR_syscalls282 /* length of syscall table */
 
 #define __ARCH_WANT_SYS_RT_SIGACTION
 
-
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 the ATI SB700 SATA controller device id to AHCI pci table

[Henry Su]

From: [EMAIL PROTECTED]
Adding the device ID to AHCI pci table for ATI SB700 SATA controller,
the subsequent chipset of SB600.
Signed-off-by:henry su<[EMAIL PROTECTED]>

diff -Nur linux-2.6.21.orig/drivers/ata/ahci.c
linux-2.6.21/drivers/ata/ahci.c
--- linux-2.6.21.orig/drivers/ata/ahci.c 2007-04-29 07:00:15.0
+0800
+++ linux-2.6.21/drivers/ata/ahci.c 2007-04-29 07:06:04.0 +0800
@@ -415,6 +415,7 @@
/* ATI */
{ PCI_VDEVICE(ATI, 0x4380), board_ahci_sb600 }, /* ATI SB600 non-raid */
{ PCI_VDEVICE(ATI, 0x4381), board_ahci }, /* ATI SB600 raid */
+ { PCI_VDEVICE(ATI, 0x4390), board_ahci_sb600 }, /* ATI SB700 */

/* VIA */
{ PCI_VDEVICE(VIA, 0x3349), board_ahci_vt8251 }, /* VIA VT8251 */

-
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: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage

[Rusty Russell]

On Sun, 2007-04-29 at 09:11 -0600, Eric W. Biederman wrote:
>   Right now I'm a little frustrated that insanity below slipped into
>   head.S right after the 32bit entry point after the review said
>   use the normal linux parameters for parameter passing.
>   
>   > #ifdef CONFIG_PARAVIRT
>   > movl %cs, %eax
>   > testl $0x3, %eax
>   > jnz startup_paravirt
>   > #endif
>   
>   The whole thing should be based on a value in the linux parameter block
>   pointed to by %esi, instead of the insane preserve all registers and
>   attempt to be super compatible with everyone.

Dammit, Eric, you spend a lot of time using words like "insane" where
you mean we didn't do everything all at once.

It's *not* clear that using %esi is sane, but nothing in the current
code prevents that.

I was trying to get Xen to use this entry point rather than their own: I
failed, and only lguest now uses it.

Fortunately, this also means it's trivial to change.
Rusty.

-
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 2.6.21

[Adrian Bunk]

On Sun, Apr 29, 2007 at 11:04:10PM +0200, Tomasz Chmielewski wrote:
> Linus Torvalds wrote:
>
>> On Sun, 29 Apr 2007, Adrian Bunk wrote:
>>> The kernel Bugzilla currently contains 1600 open bugs.
>> Adrian, why do you keep harping on this, and ignoring reality?
>> Kernel bugzilla has 1600 open bugs BECAUSE IT SUCKS.
>> How many of those are interesting and valid? How many of them are 
>> relevant? How many of them are duplicates?
>
> And - how many of these bug reports have kernel's bugzilla ever forwarded 
> to lkml so that other people could see them?
>
> Is that number zero (because kernel's bugzilla is configured this way)?

Andrew forwards incoming Bugzilla bugs to the responsible maintainers 
(if there are any).

If it is considered useful it shouldn't be a problem to automatically 
forward all incoming Bugzilla bugs to linux-kernel.

> Tomasz Chmielewski

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.21-rc7-mm1 BUG at kernel/sched-clock.c:175 init_sched_clock()

[Tejun Heo]

Hello.

Berck E. Nash wrote:
> Okay, while this patch allows my system to boot, it eventually crashed.
>  Unfortunately, I don't know enough to know if this crash is at all
> related, but it seems like it might be?
> 
> [ 1314.960784] irq 316: nobody cared (try booting with the "irqpoll" option)
> [ 1314.967602]
> [ 1314.967602] Call Trace:
> [ 1314.971566]  [] dump_trace+0xb6/0x3d6
> [ 1314.976809]  [] show_trace+0x3c/0x52
> [ 1314.981963]  [] dump_stack+0x15/0x17
> [ 1314.987118]  [] __report_bad_irq+0x38/0x7c
> [ 1314.992790]  [] note_interrupt+0x1cf/0x215
> [ 1314.998463]  [] handle_edge_irq+0x104/0x133
> [ 1315.004231]  [] do_IRQ+0x6d/0xd5
> [ 1315.009039]  [] ret_from_intr+0x0/0xa
> [ 1315.014281]  [] mwait_idle+0x46/0x4b
> [ 1315.019433]  [] cpu_idle+0x87/0xaa
> [ 1315.024414]  [] rest_init+0x49/0x4b
> [ 1315.029489]  [] start_kernel+0x291/0x29c
> [ 1315.034989]  [] _sinittext+0x13a/0x141
> [ 1315.040323]
> [ 1315.041813] handlers:
> [ 1315.044090] [] (ahci_interrupt+0x0/0x47a)
> [ 1315.049722] Disabling IRQ #316
> [ 1345.037254] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
> frozen
> [ 1345.044333] ata1.00: cmd c8/00:08:ff:53:00/00:00:00:00:00/e2 tag 0
> cdb 0x0 data 4096 in
> [ 1345.044334]  res 40/00:00:76:5a:00/00:00:00:00:00/e0 Emask
> 0x4 (timeout)
> [ 1345.059832] ata3.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x2
> frozen
> [ 1345.066919] ata3.00: cmd 60/08:00:bb:26:0a/00:00:09:00:00/40 tag 0
> cdb 0x0 data 4096 in
> [ 1345.066920]  res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask
> 0x4 (timeout)
> [ 1345.389731] ata1: soft resetting port
> [ 1345.396451] ata3: soft resetting port

Hmmm... Once properly initialized, ahci is highly unlikely to cause
runaway IRQs which results in nobody cared.  It has proper IRQ mask and
pending bits allowing the driver to reliably detect when and why the
controller is raising interrupt and disable it if necessary.  Can you
try without the NVIDIA module?

-- 
tejun

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources

[Randy Dunlap]

On Sun, 29 Apr 2007 20:14:37 -0600 Robert Hancock wrote:

> diff -up linux-2.6.21.1/arch/i386/pci/mmconfig-shared.c 
> linux-2.6.21.1edit/arch/i386/pci/mmconfig-shared.c
> --- linux-2.6.21.1/arch/i386/pci/mmconfig-shared.c2007-04-27 
> 15:49:26.0 -0600
> +++ linux-2.6.21.1edit/arch/i386/pci/mmconfig-shared.c2007-04-29 
> 19:47:57.0 -0600
> @@ -191,9 +191,77 @@ static void __init pci_mmcfg_insert_reso
>   }
>  }
>  
> +
> +static int __init is_acpi_reserved(unsigned long start, unsigned long end)
> +{
> + struct resource mcfg_res;
> + 
> + mcfg_res.start = start;
> + mcfg_res.end = end;
> + mcfg_res.flags = 0;
> +
> + acpi_get_devices("PNP0C01", find_mboard_resource, &mcfg_res, NULL);
> + 
> + if( !mcfg_res.flags )

if (!mcfg_res.flags)

> + acpi_get_devices("PNP0C02", find_mboard_resource, &mcfg_res, 
> NULL);
> +
> + return mcfg_res.flags;
> +}
> +
> +static void __init pci_mmcfg_reject_broken(void)
>  {
>   typeof(pci_mmcfg_config[0]) *cfg;
> + int i;
>  
>   if ((pci_mmcfg_config_num == 0) ||
>   (pci_mmcfg_config == NULL) ||
> @@ -213,18 +281,36 @@ static void __init pci_mmcfg_reject_brok
>  "Rejected as broken MCFG.\n");
>   goto reject;
>   }
> -
> - /*
> -  * Only do this check when type 1 works. If it doesn't work
> -  * assume we run on a Mac and always use MCFG
> -  */
> - if (type == 1 && !e820_all_mapped(cfg->address,
> -   cfg->address + MMCONFIG_APER_MIN,
> -   E820_RESERVED)) {
> - printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %Lx is not"
> -" E820-reserved\n", cfg->address);
> - goto reject;
> + 
> + for(i=0; i < pci_mmcfg_config_num; i++) {

for (i = 0; i < pci_mmcfg_config_num; i++) {

> + u32 size = (cfg->end_bus_number + 1) << 20;
> + cfg = &pci_mmcfg_config[i];
> + printk(KERN_NOTICE "PCI: MCFG configuration %d: base %p segment 
> %hu buses %u - %u\n",

line too long.

> + i, (void*)cfg->address, cfg->pci_segment, 
> + (unsigned int)cfg->start_bus_number,
> + (unsigned int)cfg->end_bus_number);
> + if(is_acpi_reserved(cfg->address,

if (
> + cfg->address + size - 1))
> + printk(KERN_NOTICE "PCI: MCFG area at %Lx reserved "
> + "in ACPI motherboard resources\n",
> + cfg->address);
> + else {
> + printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %Lx is not 
> "
> + "reserved in ACPI motherboard resources\n",
> + cfg->address);
> + /* Don't try to do this check unless configuration type 
> 1 is
> +available. */
> + if((pci_probe & PCI_PROBE_CONF1) && 

if ((
and that line ends with a space :(

> +e820_all_mapped(cfg->address,
> +cfg->address + size - 1,
> +E820_RESERVED))
> + printk(KERN_NOTICE "PCI: MCFG area at %Lx 
> reserved in E820\n",
> + cfg->address);
> + else
> + goto reject;
> + }
>   }
> +
>   return;
>  
>  reject:
> @@ -234,20 +320,46 @@ reject:
>   pci_mmcfg_config_num = 0;
>  }
>  
> -void __init pci_mmcfg_init(int type)
> +void __init pci_mmcfg_early_init(int type)
> +{
> + if ((pci_probe & PCI_PROBE_MMCONF) == 0)
> + return;
> + 
> + /* If type 1 access is available, no need to enable MMCONFIG yet, we can
> +defer until later when the ACPI interpreter is available to better
> +validate things. */
> + if( type == 1 )

if (type == 1)

> + return;
> +
> + acpi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg);
> +
> + if ((pci_mmcfg_config_num == 0) ||
> + (pci_mmcfg_config == NULL) ||
> + (pci_mmcfg_config[0].address == 0))
> + return;
> +
> + if (pci_mmcfg_arch_init())
> + pci_probe = (pci_probe & ~PCI_PROBE_MASK) | PCI_PROBE_MMCONF;
> +}

> diff -ruw linux-2.6.21.1/drivers/acpi/bus.c 
> linux-2.6.21.1edit/drivers/acpi/bus.c
> --- linux-2.6.21.1/drivers/acpi/bus.c 2007-04-27 15:49:26.0 -0600
> +++ linux-2.6.21.1edit/drivers/acpi/bus.c 2007-04-29 19:22:07.0 
> -0600
> @@ -42,6 +42,7 @@
>  ACPI_MODULE_NAME("bus");
>  #ifdef   CONFIG_X86
>  extern void __init acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger);
> +extern void __init pci_mmcfg_late_init(void);

externs should go in header files.  (not that

[patch] Add the combined mode for ATI SB700

[Henry Su]

From: [EMAIL PROTECTED]
Besides those modes in ATI SB600 SATA controller, ATI SB700 supports one
more mode:the combined mode. \
The combined mode is a Legacy IDE mode used for compatibility with some
old OS without AHCI driver, \
but now it is not necessary for Linux since the kernel has supported
AHCI. 
Signed-off-by: Luugi Marsan <[EMAIL PROTECTED]>

diff -Nur linux-2.6.21.orig/include/linux/pci_ids.h
linux-2.6.21/include/linux/pci_ids.h
--- linux-2.6.21.orig/include/linux/pci_ids.h 2007-04-29
07:00:04.0 +0800
+++ linux-2.6.21/include/linux/pci_ids.h 2007-04-29 07:49:00.0 
+++ +0800
@@ -371,6 +371,7 @@
#define PCI_DEVICE_ID_ATI_IXP600_SRAID 0x4381 
#define PCI_DEVICE_ID_ATI_IXP600_SMBUS 0x4385 
#define PCI_DEVICE_ID_ATI_IXP600_IDE 0x438c
+#define PCI_DEVICE_ID_ATI_IXP700_SATA 0x4390

#define PCI_VENDOR_ID_VLSI 0x1004
#define PCI_DEVICE_ID_VLSI_82C592 0x0005

diff -Nur linux-2.6.21.orig/drivers/pci/quirks.c
linux-2.6.21/drivers/pci/quirks.c
--- linux-2.6.21.orig/drivers/pci/quirks.c 2007-04-29 07:00:15.0
+0800
+++ linux-2.6.21/drivers/pci/quirks.c 2007-04-29 07:35:53.0 
+++ +0800
@@ -875,6 +875,7 @@
}
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI,
PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, 
+PCI_DEVICE_ID_ATI_IXP700_SATA, quirk_sb600_sata);

/*
* Serverworks CSB5 IDE does not fully support native mode




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] x86_64: support poll() on /dev/mcelog

[Tim Hockin]

From: Tim Hockin <[EMAIL PROTECTED]>

Background:
 /dev/mcelog is typically polled manually.  This is less than optimal for
 some situations.  Calling poll() on /dev/mcelog does not work.

Description:
 This patch adds support for poll() to /dev/mcelog.  This results in
 immediate wakeup of user apps whenever the poller finds MCEs.  Because
 the exception handler can not take any locks, it can not call the wakeup
 itself.  Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
 caught at the next return from interrupt, calling the mce_user_notify()
 routine.

 This patch also does some small cleanup for essentially unused variables,
 and moves the user notification into the body of the poller, so it is
 only called once, rather than once per CPU.

Result:
 Applications can now poll() on /dev/mcelog.  When an error is logged
 (whether through the poller or through an exception) the applications are
 woken up promptly.  This should not affect any previous behaviors.  If no
 MCEs are being logged, there is no overhead.

Alternatives:
 I considered simply supporting poll() through the poller and not using
 TIF_MCE_NOTIFY at all.  However, the time between an uncorrectable error
 happening and the user application being notified is *the*most* critical
 window for us.  Many uncorrectable errors can be logged to the network if
 given a chance.

Testing:
 I used an error-injecting DIMM to create lots of correctable DRAM errors
 and verified that my user app is woken up in sync with the polling interval.
 I also used the northbridge to inject uncorrectable ECC errors, and
 verified (printk() to the rescue) that the notify routine is called and the
 user app does wake up.

Patch:
 This patch is against 2.6.21-rc7.

Signed-Off-By: Tim Hockin <[EMAIL PROTECTED]>

---

This is the first public version version of this patch.  The TIF_*
approach was suggested by Mike Waychison and Andi did not yell at me when
I suggested it. :)


diff -pruN linux-2.6.20+th/arch/x86_64/kernel/entry.S 
linux-2.6.20+th2v2/arch/x86_64/kernel/entry.S
--- linux-2.6.20+th/arch/x86_64/kernel/entry.S  2007-04-24 22:46:19.0 
-0700
+++ linux-2.6.20+th2v2/arch/x86_64/kernel/entry.S   2007-04-29 
18:10:40.0 -0700
@@ -585,7 +585,7 @@ bad_iret:
 retint_careful:
CFI_RESTORE_STATE
bt$TIF_NEED_RESCHED,%edx
-   jnc   retint_signal
+   jnc   retint_mce
TRACE_IRQS_ON
sti
pushq %rdi
@@ -597,7 +597,23 @@ retint_careful:
cli
TRACE_IRQS_OFF
jmp retint_check
-   
+
+   /* handle a waiting machine check */
+retint_mce:
+   bt $TIF_MCE_NOTIFY,%edx
+   jnc retint_signal
+   TRACE_IRQS_ON
+   sti
+   pushq %rdi
+   CFI_ADJUST_CFA_OFFSET   8
+   call mce_notify_user
+   popq %rdi   
+   CFI_ADJUST_CFA_OFFSET   -8
+   GET_THREAD_INFO(%rcx)
+   cli
+   TRACE_IRQS_OFF
+   jmp retint_check
+
 retint_signal:
testl $(_TIF_SIGPENDING|_TIF_NOTIFY_RESUME|_TIF_SINGLESTEP),%edx
jzretint_swapgs
diff -pruN linux-2.6.20+th/arch/x86_64/kernel/mce.c 
linux-2.6.20+th2v2/arch/x86_64/kernel/mce.c
--- linux-2.6.20+th/arch/x86_64/kernel/mce.c2007-04-27 14:19:08.0 
-0700
+++ linux-2.6.20+th2v2/arch/x86_64/kernel/mce.c 2007-04-29 18:27:22.0 
-0700
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include  
 #include 
 #include 
@@ -39,8 +41,7 @@ static int mce_dont_init;
 static int tolerant = 1;
 static int banks;
 static unsigned long bank[NR_BANKS] = { [0 ... NR_BANKS-1] = ~0UL };
-static unsigned long console_logged;
-static int notify_user;
+static unsigned long notify_user;
 static int rip_msr;
 static int mce_bootlog = 1;
 static atomic_t mce_events;
@@ -48,6 +49,8 @@ static atomic_t mce_events;
 static char trigger[128];
 static char *trigger_argv[2] = { trigger, NULL };
 
+static DECLARE_WAIT_QUEUE_HEAD(mce_wait);
+
 /*
  * Lockless MCE logging infrastructure.
  * This avoids deadlocks on printk locks without having to break locks. Also
@@ -94,8 +97,7 @@ void mce_log(struct mce *mce)
mcelog.entry[entry].finished = 1;
wmb();
 
-   if (!test_and_set_bit(0, &console_logged))
-   notify_user = 1;
+   set_bit(0, ¬ify_user);
 }
 
 static void print_mce(struct mce *m)
@@ -167,15 +169,19 @@ static inline void mce_get_rip(struct mc
}
 }
 
-static void do_mce_trigger(void)
+/*
+ * This is only called in normal interrupt context.  This is where we do
+ * anything we need to alert userspace.  This is called directly from the
+ * poller and also from entry.S thanks to TIF_MCE_NOTIFY.
+ */
+void mce_notify_user(void)
 {
-   static atomic_t mce_logged;
-   int events = atomic_read(&mce_events);
-   if (events != atomic_read(&mce_logged) && trigger[0]) {
-   /* Small race window, but should be harmless.  */
-   atomic_set(&mce_logged, events);
+   clear_thread_flag(TIF_MCE_NOTIFY

[RFC PATCH] PCI MMCONFIG: add validation against ACPI motherboard resources

[Robert Hancock]

This path adds validation of the MMCONFIG table against the ACPI reserved
motherboard resources. If the MMCONFIG table is found to be reserved in
ACPI, we don't bother checking the E820 table. The PCI Express firmware spec
apparently tells BIOS developers that reservation in ACPI is required and
E820 reservation is optional, so checking against ACPI first makes sense.
Many BIOSes don't reserve the MMCONFIG region in E820 even though it is
perfectly functional, the existing check needlessly disables MMCONFIG in
these cases.

In order to do this, MMCONFIG setup has been split into two phases. If PCI
configuration type 1 is not available (like on EFI Macs) then MMCONFIG is
enabled early as before. Otherwise, it is enabled later after the ACPI
interpreter is enabled, since we need to be able to execute control methods
in order to check the ACPI reserved resources. Presently this is just triggered
off the end of ACPI interpreter initialization.

There are a few other behavioral changes here:

-Validate all MMCONFIG configurations provided, not just the first one.

-Validate the entire required length of each configuration according to the
provided ending bus number is reserved, not just the minimum required 
allocation.

-Validate that the area is reserved even if we read it from the chipset directly
and not from the MCFG table. This catches the case where the BIOS didn't set the
location properly in the chipset and has mapped it over other things it 
shouldn't have.
This might be overly pessimistic - we might be able to instead verify that no 
other
reserved resources (like chipset registers) are inside this memory range.

Some testing is needed to see if this rejects MMCONFIG on all systems where it
is problematic. There were some patches floating around to read the table
location out of the chipset for Intel 915 and 965, I think the author found the
latter to be problematic since the chipset had the table mapped over top of
motherboard resources. The extra checking here may catch that case if we add
that chipset-specific support.

Applies to 2.6.21.1.

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>

diff -up linux-2.6.21.1/arch/i386/pci/init.c 
linux-2.6.21.1edit/arch/i386/pci/init.c
--- linux-2.6.21.1/arch/i386/pci/init.c 2007-04-27 15:49:26.0 -0600
+++ linux-2.6.21.1edit/arch/i386/pci/init.c 2007-04-29 18:36:32.0 
-0600
@@ -12,7 +12,7 @@ static __init int pci_access_init(void)
type = pci_direct_probe();
#endif
#ifdef CONFIG_PCI_MMCONFIG
-   pci_mmcfg_init(type);
+   pci_mmcfg_early_init(type);
#endif
if (raw_pci_ops)
return 0;
diff -up linux-2.6.21.1/arch/i386/pci/mmconfig-shared.c 
linux-2.6.21.1edit/arch/i386/pci/mmconfig-shared.c
--- linux-2.6.21.1/arch/i386/pci/mmconfig-shared.c  2007-04-27 
15:49:26.0 -0600
+++ linux-2.6.21.1edit/arch/i386/pci/mmconfig-shared.c  2007-04-29 
19:47:57.0 -0600
@@ -191,9 +191,77 @@ static void __init pci_mmcfg_insert_reso
}
}

-static void __init pci_mmcfg_reject_broken(int type)
+static acpi_status __init check_mcfg_resource(struct acpi_resource *res,
+   void *data)
+{
+   struct resource *mcfg_res = data;
+   struct acpi_resource_address64 address;
+   acpi_status status;
+
+   if (res->type == ACPI_RESOURCE_TYPE_FIXED_MEMORY32) {
+   struct acpi_resource_fixed_memory32 *fixmem32 =
+   &res->data.fixed_memory32;
+   if (!fixmem32)
+   return AE_OK;
+   if ((mcfg_res->start >= fixmem32->address) &&
+   (mcfg_res->end <= (fixmem32->address +
+  fixmem32->address_length))) {
+   mcfg_res->flags = 1;
+   return AE_CTRL_TERMINATE;
+   }
+   }
+   if ((res->type != ACPI_RESOURCE_TYPE_ADDRESS32) &&
+   (res->type != ACPI_RESOURCE_TYPE_ADDRESS64))
+   return AE_OK;
+
+   status = acpi_resource_to_address64(res, &address);
+   if (ACPI_FAILURE(status) || (address.address_length <= 0) ||
+   (address.resource_type != ACPI_MEMORY_RANGE))
+   return AE_OK;
+
+   if ((mcfg_res->start >= address.minimum) &&
+   (mcfg_res->end <=
+(address.minimum +address.address_length))) {
+   mcfg_res->flags = 1;
+   return AE_CTRL_TERMINATE;
+   }
+   return AE_OK;
+}
+
+static acpi_status __init find_mboard_resource(acpi_handle handle, u32 lvl,
+   void *context, void **rv)
+{
+   struct resource *mcfg_res = context;
+
+   acpi_walk_resources(handle, METHOD_NAME__CRS,
+   check_mcfg_resource, context);
+
+   if (mcfg_res->flags)
+   return AE_CTRL_TERMINATE;
+
+   return AE_OK;
+}
+
+static int __init is_acpi_reserved(unsigned long start, unsigned long end)
+{
+   stru

Re: [PATCH] support PCI MCFG space on Intel i915 bridges

[Robert Hancock]

Jesse Barnes wrote:

Add support for Intel 915 bridge chips to the new PCI MMConfig detection
code.  Tested and works on my sole 915 based platform (a Toshiba laptop).  I
added register masking per Oliver's suggestion, and moved the __init
qualifier to after the 'static const char' to match Ogawa-san's recent
cleanup patches.

Signed-off-by:  Jesse Barnes <[EMAIL PROTECTED]>

diff --git a/arch/i386/pci/mmconfig-shared.c b/arch/i386/pci/mmconfig-shared.c
index 747d8c6..1339d31 100644
--- a/arch/i386/pci/mmconfig-shared.c
+++ b/arch/i386/pci/mmconfig-shared.c
@@ -72,6 +72,26 @@ static const char __init *pci_mmcfg_e7520(void)
return "Intel Corporation E7520 Memory Controller Hub";
 }
 
+static const char __init *pci_mmcfg_intel_915(void)

+{
+   u32 pciexbar, len = 0;
+
+   pci_conf1_read(0, 0, PCI_DEVFN(0,0), 0x48, 4, &pciexbar);
+
+   /* No enable bit or size field, so assume 256M range is enabled. */
+   len = 0x1000U;


Check the 915 spec more carefully, there is an enable bit, it's in the 
DEVEN register offset 54h, the bit is called PCIEXBAREN (bit 31). If 
that is not set you should be setting pci_mmcfg_config_num to 0 and 
bailing out.


The size is indeed always 256MB though.


+   pci_mmcfg_config_num = 1;
+   pciexbar &= 0xe000; /* mask out potentially bogus bits */
+
+   pci_mmcfg_config = kzalloc(sizeof(pci_mmcfg_config[0]), GFP_KERNEL);
+   pci_mmcfg_config[0].address = pciexbar;
+   pci_mmcfg_config[0].pci_segment = 0;
+   pci_mmcfg_config[0].start_bus_number = 0;
+   pci_mmcfg_config[0].end_bus_number = (len >> 20) - 1;
+
+   return "Intel Corporation 915PM/GM/GMS Express Memory Controller Hub";
+}
+
 static const char __init *pci_mmcfg_intel_945(void)
 {
u32 pciexbar, mask = 0, len = 0;
@@ -129,6 +149,7 @@ struct pci_mmcfg_hostbridge_probe {
 
 static struct pci_mmcfg_hostbridge_probe pci_mmcfg_probes[] __initdata = {

{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_E7520_MCH, pci_mmcfg_e7520 },
+   { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82915GM_HB, 
pci_mmcfg_intel_915 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82945G_HB, 
pci_mmcfg_intel_945 },
 };


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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: checkpatch, a patch checking script.

[Matt Mackall]

On Sun, Apr 29, 2007 at 05:18:00PM -0700, Randy Dunlap wrote:
> Matt Mackall wrote:
> >On Sun, Apr 29, 2007 at 04:37:01PM -0700, Randy Dunlap wrote:
> >>On Sat, 28 Apr 2007 12:21:54 -0500 Matt Mackall wrote:
> >>
> >>>On Sat, Apr 28, 2007 at 01:11:01PM -0400, Dave Jones wrote:
> On Sat, Apr 28, 2007 at 11:11:36AM -0500, Matt Mackall wrote:
>  > > I'm all ears for additional regexps, bug reports or other 
>  suggestions.
>  > 
>  > Neat.
>  > 
>  > Does it check for:
>  > 
>  > functions marked extern?
> >>data marked extern?
> >
> >It's perfectly reasonable to have a data extern declaration in a header 
> >file.
> 
> but it's not perfectly acceptable to have
> 
> extern unsigned long volatile jiffies;
> 
> in a .c file.
> 
> The biggest problem I'm seeing ATM is that this script is a bit too
> simplistic.  It doesn't know what it's looking at.  We'll have to
> address that, I think.

If you can make it run a regexp over the whole file at once rather
than a line at a time, you can deal with this with multi-line regexps.
Roughly, match:

 a +++ patch header followed by
 any number of lines not starting with +++ followed by
 the actual target expression

So, approximately:

 /+++ [\w\/]+.c(.*)\\n((([^+])|(\+[^+]))\n)*extern.*/

Or you could just make search remember what file it's in as it walks
the list of lines. But as I mentioned, multiline regexps are useful
for things other than just remembering what file we're in.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NR_UNSTABLE_FS vs. NR_FILE_DIRTY: double counting pages?

[Trond Myklebust]

On Sun, 2007-04-29 at 17:26 -0700, Ethan Solomita wrote:
> Trond Myklebust wrote:
> > On Fri, 2007-04-27 at 18:21 -0700, Ethan Solomita wrote:
> >> There are several places where we add together NR_UNSTABLE_FS and
> >> NF_FILE_DIRTY:
> >>
> >> sync_inodes_sb()
> >> balance_dirty_pages()
> >> wakeup_pdflush()
> >> wb_kupdate()
> >> prefetch_suitable()
> >>
> >> I can trace a standard codepath where it seems both of these are set
> >> on the same page:
> >>
> >> nfs_file_aops.commit_write ->
> >> nfs_commit_write
> >> nfs_updatepages
> >> nfs_writepage_setup
> >> nfs_wb_page
> >> nfs_wb_page_priority
> >> nfs_writepage_locked
> >> nfs_flush_mapping
> >> nfs_flush_list
> >> nfs_flush_multi
> >> nfs_write_partial_ops.rpc_call_done
> >> nfs_writeback_done_partial
> >> nfs_writepage_release
> >> nfs_reschedule_unstable_write
> >> nfs_mark_request_commit
> >> incr NR_UNSTABLE_NFS
> >>
> >> nfs_file_aops.commit_write ->
> >> nfs_commit_write
> >> nfs_updatepage
> >> __set_page_dirty_nobuffers
> >> incr NF_FILE_DIRTY
> >>
> >>
> >> This is the standard code path that derives from sys_write(). Can
> >> someone either show how this code sequence can't happen, or confirm for
> >> me that there's a bug?
> >> -- Ethan
> > 
> > It should not happen. If the page is on the unstable list, then it will
> > be committed before nfs_updatepage is allowed to redirty it. See the
> > recent fixes in 2.6.21-rc7.
> 
>   Above I present a codepath called straight from sys_write() which seems 
> to do what I say. I could be wrong, but can you address the code paths I 
> show above which seem to set both?
>   -- Ethan

Look carefully at nfs_update_request(): if !nfs_dirty_request(), then it
returns -EBUSY, and so nfs_writepage_setup() will loop on nfs_wb_page().
IOW: if PG_NEED_COMMIT is set (which it should be if on the commit list)
then nfs_writepage_setup() will loop...

Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21

[Gene Heskett]

On Sunday 29 April 2007, Michal Piotrowski wrote:
>Hi Diego,
>
>On 29/04/07, Diego Calleja <[EMAIL PROTECTED]> wrote:
>[..]
>
>> So unless someone is willing to write such tool (which I doubt, since it
>> doesn't looks easy), all this discussion seems pointless, and we should
>> stick with this http://kernelnewbies.org/known_regressions page
>> which is showing to be quite useful :)

Usefull?  For what?  Having seen the link at the time I was fighting with yet 
another rearranged USB setup, and I swear the boot process uses Schrodingers 
Cat to determine which device found in the usb scan gets the first ttyUSB, 
and which gets the second, so I went to this site to see if it could be more 
productive than bugzilla (I'd like to toss about 10 pounds of C4 into the 
only code repository on the planet that thing is built from), but no, sorry, 
no bisquit.

Why?  First, its yet another password I have to scribble on the wall along 
with enough surrounding data so I might be able to find it the next time.

You can't have it even do a search to see if it already has something similar 
without creating an account and logging in.  Since I'm out of wall space, and 
the missus is bugging me to paint over all that, I left.

I repeat:  Usefull?  For what?

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Simon: (to Jayne) "Enemies?  You?  No, how can it be?"
--Episode #7, "Jaynestown"
-
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: Critical points about kernel 2.6.21 and pseudo-authorities

[Trent Piepho]

On Sun, 29 Apr 2007, Linus Torvalds wrote:
> On Sun, 29 Apr 2007, Uwe Bugla wrote:
>
> > BUT: This 2.6.21-git2 is unusable in so far as it contains regressive code
> > in the dvb-section, authored by Trent Piepho, acked by Michael Krufky, and 
> > signed-off-by Mauro Carvalho Chehab:
>
> You never explained what the problem even was, apart from compiling in
> some code that you didn't need to before. Didn't it work in the end?
>
> If it worked, I don't see what the big issue was. You are getting a _lot_
> of other code in the kernel that you probably never use, you may not even
> have realized.

I'd like to explain this a bit, for people seeing these messages who haven't
been following this part of dvb development.

dvb-pll is a simple driver for a number of I2C tuners, which are used in
many many TV cards.

These are simple devices, and drivers for host controllers (which usually
support quite a few different models of tv card based on the same core chip)
often didn't use dvb-pll.  They would just re-implement an I2C tuner driver,
sometimes more than once in the same file!

The dvb tree ended up with over a dozen different re-implementations of the
same basic tuner driver.  Of course each implementation would have different
bugs, quirks, and missing features.

So we've been removing this code and using dvb-pll.  If you look at some of
my patches to do this:

 14 files changed, 14 insertions(+), 199 deletions(-)
 1 files changed, 4 insertions(+), 34 deletions(-)
 4 files changed, 17 insertions(+), 204 deletions(-)

These patches fixed bugs and added features, yet are very much net negative
when if comes to lines of code in the kernel.

> any chance to deselect the compilation of the dvb-pll.c-module, as its
> deselection only works for VIDEO_V4L1_COMPAT, NOT for VIDEO_V4L1.

dvb-pll has nothing to do with VIDEO_V4L1_COMPAT or VIDEO_V4L1.  Uwe is just
confused about what is causing what.

> All the almost excellent work that Michael Krufky has offered for that
> issue at the transition from 2.6.18 to 2.6.19 or 2.6.20 (do not remeber
> exactly) is being wiped out and rolled back with his acknowledgement!

Uwe is probably talking about the dvb_attach() system, written mainly by
Andrew de Quincey and myself, which went into 2.6.18.  The basic concept is
that a core driver uses symbol_request() to avoid any strong references to
its helper drivers.  This way only the helper drivers that are actually
needed must be loaded.  We want to make dvb-pll use this system too, but it
doesn't fully work yet.  I have several ideas about how to solve the
problem, but it's not a high priority.
-
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: NR_UNSTABLE_FS vs. NR_FILE_DIRTY: double counting pages?

[Ethan Solomita]

Ethan Solomita wrote:

Trond Myklebust wrote:


It should not happen. If the page is on the unstable list, then it will
be committed before nfs_updatepage is allowed to redirty it. See the
recent fixes in 2.6.21-rc7.


Above I present a codepath called straight from sys_write() which 
seems to do what I say. I could be wrong, but can you address the code 
paths I show above which seem to set both?


	Sorry about my quick reply, I'd misunderstood what you were saying. 
I'll take a look at what you say.


Thanks,
-- Ethan
-
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 2.6.21

[Björn Steinbrink]

[Oops, the first try of this mail got out from my local address, sorry]

On 2007.04.29 19:55:35 -0400, Theodore Tso wrote:
> On Sun, Apr 29, 2007 at 03:15:42PM +0200, Andi Kleen wrote:
> > This means we need people who figure out who to assign bugs too.
> > Aka bugmasters.
> > 
> > BTW one big problem in our current bugzilla is that a lot of people
> > cannot reassign bugs they don't own. I sometimes see bugs that I don't
> > own bug I know who is responsible, but bugzilla doesn't allow me to do it.
> > 
> > So I think what would help:
> > 
> > - Ask more people to just categorize and reassign bugs (anybody interested?)
> > - Give more people in bugzilla the power to reassign arbitary bugs
> > (bugzilla maintainers would need to do that)
> 
> Folks might want to take a look at the Debian Bug Tracking System
> (BTS).  It has a web interface which you can use to query history, but
> *everything* is e-mail driven, and the way you submit, close, update,
> tag/classfy bugs --- everything --- is via e-mail.
> 
> More importantly, anyone is allowed to recategorize and reassign bugs.
> If someone does so maliciously or incorrectly, you can always revert
> it, and if someone is being truly malicious, you can always blacklist
> that one person.  It this respect, it is far more wiki-like than
> bugzilla, which has always been too much like a straightjacket.
> 
> It's not perfect, but it's better than bugzilla --- but then again,
> just about *anything* would be better than bugzilla.  (Hmm, except
> maybe SourceForge's very tragic bug tracking system... :-)
> 
> Of course, as Linus has said, it's not a complete solution --- you
> still need humans to be smart about things --- but if the goal is to
> make it easier to archive and track information about a bug, at
> *least* with the Debian BTS, when you reply to an e-mail message, the
> reply is automatically appended to the bug log!

I've started hacking on some bash scripts to do the e-mail part, based
on the requirements I've gathered from reading this thread. So far, I
got one script that can be plugged into procmail and processes mails to
do the following (right now):

 - Create a bug
 - Set the bug type to "regression"
 - Update the timestamp of the last action for that bug
 - Assign the bug to a subsystem
 - Track the submitter and whoever grabs the bug

More (hopefully) to come...

Those commands are just added to any email in the thread discussing a
bug like this:
@bugthing
mine# Mark myself as owner
regression  # Mark this bug as a regression (used for reports)
subsystem mm# Assign the bug to mm
needinfo# Tell the tracker to bug the reporter if nothing happens
Thanks

That block can appear anywhere in the email, so if you're discussing
some problem on lkml and want to track that bug, you can just add such a
block to your email and turn an untracked email conversion into a
tracked bug.

Tracking does _not_ mean that all emails are stored, those can be looked
up on lkml.org or MARC, where the created reports will probably contain
URLs to the latter, because it supports lookups based on message ids.

Tracking does just mean that the state of the bug is stored somewhere.
That means (currently, suggestions welcome):

 - What's its name? (E-Mail subject)
 - Who reported it?
 - Who (if any) stepped up to own that bug?
 - What type of bug is it?
 - Which subsystem does it belong to?
 - What's its current state? (new, owned, fixed, ...)
 - When did the last action on this bug happen?

Based on that information, I've started writing some scripts that create
"reports" (all of them currently being pretty incomplete):

 - Bugs that belong to a specific subsystem (on request, currently
   through a procmail triggered script; this is meant to satisfy
   Adrian's request of asking for example for all SATA bugs.)

 - Bugs that are not owned and didn't see any action for one week
   (cronjob; to lkml, the submitter, the recipients of the bug mail and
   maybe folks who subscribed to such mails)

 - All bugs marked as regressions (complete list to lkml, personalised
   lists to each owner of any regressions, probably sent on request)

 - Annoy the bug submitter if someone tagged the bug with "moreinfo" and
   there wasn't any reply from the submitter within one week

 - Annoy the bug owner if he didn't do anything about his bug within
   one week

Those "reports" should push the relevant parties into looking at those
bugs again while being terse, like Adrian's regression list and not
annoying anyone but those who are most likely to be interested.

Bugs in which noone shows interest (i.e. nothing happens at all), should
probably be removed after 2-3 weeks, with a notice going to the
submitter and recipients of the bug's emails as well as those subscribed
to receiving reports of non-owned inactive bugs. Well, unless those bugs
are regressions, we should probably bug about them until they get
closed.


That's my plan so far. It's probably going to be ugl

Re: [patch 20/38] Minor fault path optimization.

[Paul Mackerras]

Christoph Hellwig writes:

> Well, here's my powerpc patch to do the direct call that I sent out
> a few weeks ago.  It not just speed up the pagefault path a lot, 
> but also is a major code cleanup.  Andi and Anton didn't like it
> because they have ambition for murky debugger code to possibly
> use it one day..

Looks good.  Could you resend it to me with a proper description and a
sign-off?

Thanks,
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: checkpatch, a patch checking script.

[Randy Dunlap]

On Fri, 27 Apr 2007 22:18:03 -0700 Andrew Morton wrote:

> On Fri, 27 Apr 2007 23:08:05 -0400 Dave Jones <[EMAIL PROTECTED]> wrote:
> 
> > You can find the script at http://www.codemonkey.org.uk/projects/checkpatch/
> 
> hm.
> 
...

> box:/usr/src/25> ~/checkpatch.pl patches/git-powerpc.patch
> Checking patches/git-powerpc.patch:  signoffs = 427   
> kmalloc return shouldn't be cast.
> 10969:+ char *out = (char*)kmalloc(count + 1, GFP_KERNEL);
> 
> Use 'inline' instead of '__inline__'26644:+static __inline__ void 
> atomic_scrub(void *va, u32 size)

Fixed missing \n.

...

> A good start, thanks.  The BUG_ON() thing might be unpopular, but I think it's
> for the best.  It should skip BUILD_BUG_ON though.

BUILD_BUG_ON is now skipped (in my script, not sent to DaveJ yet).

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities

[hermann pitton]

Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla:
>  Original-Nachricht 
> Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT)
> Von: Linus Torvalds <[EMAIL PROTECTED]>
> An: Uwe Bugla <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], 
> linux-kernel@vger.kernel.org, [EMAIL PROTECTED]
> Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities
> 
> > 
> > 
> > On Sun, 29 Apr 2007, Uwe Bugla wrote:
> > > 
> > > I have been trying diff and other tools in various variants (except 
> > > git-bisect that I cannot handle because I do not understand the practice
> > > of it).
> > 
> > git bisect is _really_ simple if you already have a git tree anyway. And 
> > even if you don't, getting one isn't really hard either. Just do
> > 
> > git clone
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 
> > linux-2.6
> > 
> > and you have a tree (it will take a little while - it's going to dowload 
> > about 170MB or so of stuff, so the initial clone is going to be a bit 
> > painful unless you have a fast internet connection).
> > 
> > Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's 
> > really as easy as just saying
> > 
> > git bisect start
> > git bisect good v2.6.21-rc7
> > git bisect bad v2.6.21
> > 
> > and git will think for a short while (most of the time is going to be 
> > checking out the new tree) and give you a tree to test.
> > 
> > Just build, boot, and test that tree.
> > 
> > If it was fine, do
> > 
> > git bisect good
> > 
> > and git will pick a new tree to test. And if it wasn't, instead just do 
> > "git bisect bad", and git will pick _another_ version to test. Do this a 
> > few times, and git will tell you which commit introduced them.
> > 
> > There were just 125 commits in between 2.6.21-rc7 and the final one, so it
> > should be quite quick - bisection basically does a binary search, so doing
> > seven reboots should have you with the result.
> > 
> > The fact that it already works in 2.6.21-git2 obviously means that _I_ end
> > up being less interested, but the -stable tree people would love to hear 
> > what broke!
> 
> Hi again Linus,
> my deep thanks for your excellent explication of git-bisect.
> But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB 
> git tree will need the time amount of one entire night (11.5 kb /s if I am 
> lucky - no more).
> Just to take up a different approach:
> 
> The difference between 2.6.21-rc7 and 2.6.21 official does not play any role 
> at all.
> 
> On the other hand I found out that:
> 2.6.21-rc7 made my AMD K7 router work fine
> 2.6.21 official hung my AMD K7 router up
> 2.6.21-git1 hung my AMD K7 router up
> 2.6.21-git2 made my AMD K7 router work.
> 
> In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the 
> problem.
> Or am I saying something wrong as far as logical terms are concerned?
> 
> > 
> > > I like small and effective kernels instead of blown up RAM waste.
> > > This is no Windoze, man, this is Linux!
> > 
> > Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere 
> > at all.
> > 
> > This is Linux, not Windows. But that also means that those developers that
> > you denigrate aren't getting paid by you, and if you don't show them 
> > respect, they'll totally ignore you.
> > 
> > Linus
> 
> Now this is the old problem about it all: the hypocricy factor, the utmost 
> small, if not to say pre-pubertarian character plus some other obviously 
> counter-productive character traits in those so-called "maintainers" who 
> behave like kids, but not like grown-ups at all!
> Not only you, but also Andrew perfectly and willingly step into the 
> hypocritic trap and do not even feel that they are trapped!
> 
> For the majority of all cases of the so-called "maintainer personnel" at 
> linuxtv.org the statement of some missing "politeness" or some missing 
> "respect" is nothing but an utmost dumb, kiddish, human mediocre and utmost 
> stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, 
> wrong solidarity, kiddishness and technical incompetence.
> 
> They are building up pseudo-authorities to hide their lack of competence, no 
> matter if their lack of competence funds on technical or human lacks.
> And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap 
> in Andrew Morton's face with this enourmous threat of incompetence, 
> kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, 
> lack of experience, pre-pubertarian behaviour, fascistoid opinion 
> dictatorship as part of a deep immature anti-democratic and reactionary 
> personality structure.
> 
> Would you call Mauro Carvalho Chehab a maintainer!
> I can certify you that I cannot, even if I try. And I want him to be 
> substituted as quick as possible as he is the biggest mismatch of gatekeeper 
> one can ever imagine.
> 
> And 

Re: [PATCH 0/5] fallocate system call

[David Chinner]

On Thu, Apr 26, 2007 at 11:20:56PM +0530, Amit K. Arora wrote:
> Based on the discussion, this new patchset uses following as the
> interface for fallocate() system call:
> 
>  asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len)

Ok, so now for the hard questions - what are the semantics of
FA_ALLOCATE and FA_DEALLOCATE?

For FA_ALLOCATE, it's supposed to change the file size if we
allocate past EOF, right? What's the return value supposed to
be? Zero for success, error otherwise? Does this update a/m/ctime
at all? How persistent is this preallocation? Should it be
there "forever" or for the lifetime of the currently open fd
that it was preallocated on?

For FA_DEALLOCATE, does it change the filesize at all? Or does
it just punch a hole in the file? If it does change file size,
what happens when you punch out preallocation beyond EOF?
What's the return value supposed to be?

> Currently we have two modes FA_ALLOCATE and FA_DEALLOCATE, for
> preallocation and deallocation of preallocated blocks respectively. More
> modes can be added, when required.

FWIW, we definitely need a FA_PREALLOCATE mode (FA_ALLOCATE but does
not change file size) so we can preallocate beyond EOF for apps which
use O_APPEND (i.e. changing file size would cause problems for them).

> ToDos:
> =
> 1>   Implementation on other architectures (other than i386, x86_64, 
> ppc64 and s390(x)) 

I'll have ia64 soon.

> 2>   A generic file system operation to handle fallocate
> (generic_fallocate), for filesystems that do _not_ have the fallocate
> inode operation implemented.
> 3>   Changes to glibc,
>   a) to support fallocate() system call
>   b) so that posix_fallocate() and posix_fallocate64() call
>  fallocate() system call
> 4>   Changes to XFS to implement the fallocate inode operation

And that's what I'm doing now, hence all the questions ;)

BTW, do you have a test program for this, or will I need to write
one myself?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
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 interpreter errors (aer_init)

[Dave Jones]

On Sat, Apr 28, 2007 at 02:31:52AM -0400, Len Brown wrote:

 > On a quick glance, it appears that these messages have been in the aer driver
 > since it was born.
 > Did you run with CONFIG_PCIEAER in 2.6.19 or 2.6.20 and not have them there?
 > 
 > I agree with Bob, as status 5 is AE_NOT_FOUND,
 > it appears that the driver is being overly verbose,
 > even though these appear to all be KERN_DEBUG messages.

See this thread.. 

From: "Zhang, Yanmin" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [PATCH] reduce AER init error information

for a patch resolving this.

Dave

-- 
http://www.codemonkey.org.uk
-
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: checkpatch, a patch checking script.

[Randy Dunlap]

On Fri, 27 Apr 2007 20:36:17 -0700 Roland Dreier wrote:

>  > http://www.codemonkey.org.uk/projects/checkpatch/example.log shows
>  > what fell out of running it on my mbox of lkml from the past month.
>  > Some of them are kinda noisy, and perhaps should be moved under --pedantic
>  > 
>  > I'm all ears for additional regexps, bug reports or other suggestions.
> 
> Looks great... however I notice a few obvious false positives in the
> example log:
> 
>  > Don't init statics to 0/NULL:
>  > 94312:+static const struct in6_addr in6addr_v4mapped = { { { [10] = 0xff, 
> [11] = 0xff } } };
> 
> ummm?

fixed

>  > 137054:+static uint32_t drvr_ver  = 0x02200207;
> 
> that ain't zero...

not?  fixed.

>  > 230079:+path->static_rate = 0;
> 
> and that ain't a static variable.

ack, fixed.

> I guess trying to parse C in a regexp is a little tricky.
> 
> Also, it would be nice to be able to do something like
> 
> git diff v2.6.20..|perl ~/checkpatch.pl -

I'll check into how to treat "-" as STDIN.

> rather than having to create a temp file -- as it stands that command
> produces
> 
> unknown option: -
> usage: findbugs.pl [-options] file(s)
>   -allsource : check entire source file, not just '+' patch lines
>   -pedantic : TBD
>   -style : TBD
>   -v, --verbose : verbose
>   -h, --help : this help text
> Version: 002
> 
> And even worse
> 
> git diff v2.6.20..|perl ~/checkpatch.pl
> 
> just silently does nothing (maybe a "no input files" warning would be
> a good clue for people).

or print usage info?


Thanks.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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 2.6.21

[Andi Kleen]

Theodore Tso <[EMAIL PROTECTED]> writes:
> 
> Folks might want to take a look at the Debian Bug Tracking System
> (BTS).  It has a web interface which you can use to query history, but
> *everything* is e-mail driven, and the way you submit, close, update,
> tag/classfy bugs --- everything --- is via e-mail.

Bugzilla can do that too. But I'm not convinced this is a good idea.
We had this some years ago with the jitterbug experiment and usually
it tended to faithfully keep track of very long off topic threads
that had drifted long from the original bug. The resulting collections
of emails usually not very useful.

While other interfaces might be a culture shock for some people
at least they force them to concentrate on the particular issue --
contribute to a specific bug.

-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: Why ask Sun for ZFS while we have ReiserFS4 !?

[Chris Adams]

Once upon a time, Theodore Tso  <[EMAIL PROTECTED]> said:
>The people who want ZFS have in mind certain features, such as the
>ability to scale to very large sizes, and ease of use when
>administering filesystems that span multiple disks (ZFS subsumes the
>device-mapper/RAID layer in Solaris, so they get certain performance
>benefits and they are able to make it simpler to set up a filesystem
>that spans multiple disks with a single command --- the flip side is
>that they are violating an relatively well understood abstraction
>boundary, for better or for worse).   

I haven't used ZFS, but I do manage servers with Tru64 Unix AdvFS
filesystems.  Having some of the logical volume functionality merged in
the filesystem layer does seem to be a good thing.  For example,
snapshotting a filesystem can use free space in the filesystem (without
having to set aside unused logical volume space for snapshotting).
Expanding the filesystem is simple: "addvol  " and
go (no adding to the volume group, extending the logical volume, and
resizing the filesystem).  Shrinking the filesystem is just as easy
(currently you can't even do that live with ext3).

I know this violates the Linux layering.  However, AdvFS has done this
for years (in a single-system-image cluster environment even), and now I
guess ZFS does it as well.  Maybe the Linux layering needs a revision to
handle something like this?

I'm just speaking as a system admin that prefers Linux everywhere, but
does like (and will miss) a few things about Tru64/TruCluster.
-
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: NR_UNSTABLE_FS vs. NR_FILE_DIRTY: double counting pages?

[Ethan Solomita]

Trond Myklebust wrote:

On Fri, 2007-04-27 at 18:21 -0700, Ethan Solomita wrote:

There are several places where we add together NR_UNSTABLE_FS and
NF_FILE_DIRTY:

sync_inodes_sb()
balance_dirty_pages()
wakeup_pdflush()
wb_kupdate()
prefetch_suitable()

I can trace a standard codepath where it seems both of these are set
on the same page:

nfs_file_aops.commit_write ->
nfs_commit_write
nfs_updatepages
nfs_writepage_setup
nfs_wb_page
nfs_wb_page_priority
nfs_writepage_locked
nfs_flush_mapping
nfs_flush_list
nfs_flush_multi
nfs_write_partial_ops.rpc_call_done
nfs_writeback_done_partial
nfs_writepage_release
nfs_reschedule_unstable_write
nfs_mark_request_commit
incr NR_UNSTABLE_NFS

nfs_file_aops.commit_write ->
nfs_commit_write
nfs_updatepage
__set_page_dirty_nobuffers
incr NF_FILE_DIRTY


This is the standard code path that derives from sys_write(). Can
someone either show how this code sequence can't happen, or confirm for
me that there's a bug?
-- Ethan


It should not happen. If the page is on the unstable list, then it will
be committed before nfs_updatepage is allowed to redirty it. See the
recent fixes in 2.6.21-rc7.


	Above I present a codepath called straight from sys_write() which seems 
to do what I say. I could be wrong, but can you address the code paths I 
show above which seem to set both?

-- Ethan
-
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-dvb] Re: [PATCH] Re: More than 2Gb problem (dvb related) ?

[Oliver Endriss]

Jon Burgess wrote:
> On Sat, 2007-04-28 at 18:17 +0100, Jon Burgess wrote:
> > On Fri, 2007-04-27 at 18:06 -0400, Lee Revell wrote:
> > > On 4/27/07, Jon Burgess <[EMAIL PROTECTED]> wrote:
> > > > Interesting - I see similar symptoms after upgrading my PC:
> > > > * old PC was AMD Athlon 64 3000 w/ 2GB of RAM which had no issues
> > > > * new PC is a Intel Core 2 Duo w/ 4GB of RAM and fails in the way you
> > > > describe.
> > > 
> > > Driver using an incorrect DMA mask?
> > > 
> > > Lee
> > 
> > It appears the problem is that the driver is using streamed PCI and
> > needs to explicitly sync the data otherwise it breaks when the SWIOTLB
> > is in use. A call to pci_unmap_sg() was missing too.
> > 
> > This patch is against the current v4l-dvb HG tree.
> > 
> > I've only tested the change with a budget-ci card.
> > 
> > Jon
> > 
> > Signed-off-by: Jon Burgess <[EMAIL PROTECTED]>
> 
> While the above patch works, it seems the underlying causes is that
> vmalloc_32() is providing memory above 4Gb on x86-64 which is not what
> the driver expects. This same issue came up a few weeks ago with regards
> to DRM on radeon http://lkml.org/lkml/2007/4/1/257
> 
> Andi Kleen included a patch to ensure vmalloc_32() returns memory <4Gb
> in a patch which is currently in -mm
>  
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc7/2.6.21-rc7-mm2/broken-out/x86_64-mm-vmalloc-32.patch
> 
> With this patch applied the current driver appears to work OK. 
> 
> Attached is a smaller patch against v4l-dvb which just adds the missing
> pci_unmap_sg() call.

Imo your patch is correct and should be applied.
Any objections?

After digging through the code, kernel DMA docs and the saa7146
datasheet, I think that we should remove the scatter-gatter voodoo
from the budget and av7110 driver. ;-)

What about the attached patch?
- easy to understand and maintain
- saves 1 page of memory (page table of the SAA7146 MMU)
- saves PCI bandwidth (SAA7146 does not read page table anymore)

Comments?

CU
Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/
---
diff -r e9e1b86b7892 linux/drivers/media/dvb/ttpci/budget-core.c
--- a/linux/drivers/media/dvb/ttpci/budget-core.c	Mon Apr 23 07:41:13 2007 +0200
+++ b/linux/drivers/media/dvb/ttpci/budget-core.c	Mon Apr 30 01:29:42 2007 +0200
@@ -74,6 +74,7 @@ static int start_ts_capture(struct budge
 static int start_ts_capture(struct budget *budget)
 {
 	struct saa7146_dev *dev = budget->dev;
+	u32 dma_base = (u32) budget->dma;
 
 	dprintk(2, "budget: %p\n", budget);
 
@@ -137,16 +138,16 @@ static int start_ts_capture(struct budge
 	saa7146_write(dev, MC2, (MASK_08 | MASK_24));
 	mdelay(10);
 
-	saa7146_write(dev, BASE_ODD3, 0);
+	saa7146_write(dev, BASE_ODD3, dma_base);
 	if (budget->buffer_size > budget->buffer_height * budget->buffer_width) {
 		// using odd/even buffers
-		saa7146_write(dev, BASE_EVEN3, budget->buffer_height * budget->buffer_width);
+		saa7146_write(dev, BASE_EVEN3, dma_base + budget->buffer_height * budget->buffer_width);
 	} else {
 		// using a single buffer
-		saa7146_write(dev, BASE_EVEN3, 0);
-	}
-	saa7146_write(dev, PROT_ADDR3, budget->buffer_size);
-	saa7146_write(dev, BASE_PAGE3, budget->pt.dma | ME1 | 0x90);
+		saa7146_write(dev, BASE_EVEN3, dma_base);
+	}
+	saa7146_write(dev, PROT_ADDR3, dma_base + budget->buffer_size);
+	saa7146_write(dev, BASE_PAGE3, 0x90);
 
 	saa7146_write(dev, PITCH3, budget->buffer_width);
 	saa7146_write(dev, NUM_LINE_BYTE3,
@@ -190,9 +191,9 @@ static void vpeirq(unsigned long data)
 static void vpeirq(unsigned long data)
 {
 	struct budget *budget = (struct budget *) data;
-	u8 *mem = (u8 *) (budget->grabbing);
+	u8 *mem = budget->grabbing;
 	u32 olddma = budget->ttbp;
-	u32 newdma = saa7146_read(budget->dev, PCI_VDP3);
+	u32 newdma = saa7146_read(budget->dev, PCI_VDP3) - (u32) budget->dma;
 	u32 count;
 
 	/* nearest lower position divisible by 188 */
@@ -510,8 +511,9 @@ int ttpci_budget_init(struct budget *bud
 
 	ttpci_eeprom_parse_mac(&budget->i2c_adap, budget->dvb_adapter.proposed_mac);
 
-	if (NULL ==
-	(budget->grabbing = saa7146_vmalloc_build_pgtable(dev->pci, budget->buffer_size, &budget->pt))) {
+	budget->grabbing = pci_alloc_consistent(dev->pci, budget->buffer_size,
+		&budget->dma);
+	if (NULL == budget->grabbing) {
 		ret = -ENOMEM;
 		goto err;
 	}
@@ -526,13 +528,15 @@ int ttpci_budget_init(struct budget *bud
 	if (bi->type != BUDGET_FS_ACTIVY)
 		saa7146_setgpio(dev, 2, SAA7146_GPIO_OUTHI);
 
-	if (budget_register(budget) == 0) {
+	if (budget_register(budget) == 0)
 		return 0;
-	}
+
 err:
 	i2c_del_adapter(&budget->i2c_adap);
 
-	vfree(budget->grabbing);
+	if (budget->grabbing)	
+		pci_free_consistent(dev->pci, budget->buffer_size,
+budget->grabbing, budget->dma);
 
 	dvb_unregister_adapter(&budget->dvb_adapter);
 
@@ -561,9 +565,8 @@ int ttpci_budget_d

Re: "REPORT: sd-0.46 vs cfs-v6 vs mainline 2.6.21-rc7 Beryl + Video + Audio"

[hechacker1]

Another update:

This is the same testing but for cfs-v7.

Summary:
1. context switch rate is much higher than for cfs-v6 for the same
sched_granularity_ns 20
2. Video playback suffered. FPS is much lower.
3. Trying different values of sched-granularity_ns didn't help
(neither did the default).
4. Firefox is actually much more responsive when the system isn't
under stress, better than any other scheduler so far.
5. Generally the system completes operations faster with cfs-v7, but
beryl FPS suffers.
6. I've monitored idle context switch rates at ~2000, and some spikes
at ~35000 (emerge -s firefox) for example.

--
cfs-v7
700m kernel # cat sched_granularity_ns
200

procs ---memory-- ---swap-- -io -system-- cpu
r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa
2  0  0 28536 88267200   100 0 3793 13889 67  6 27  0
5  0  0 888708536 8827680096 0 3435 13969 69  7 24  0
1  0  0 888468536 8829920096 0 3704 13645 64  8 28  0
0  0  0 888284536 8830640072 0 4378 13557 53  7 40  0
6  0  0 888224536 8831320068 0 3909 13700 60  9 31  0
0  0  0 888164536 8832160084 0 3726 13670 65  6 29  0

top - 16:53:54 up 10 min,  5 users,  load average: 3.33, 2.78, 1.43
Tasks: 102 total,   2 running, 100 sleeping,   0 stopped,   0 zombie
Cpu(s): 57.9%us,  5.7%sy,  0.0%ni, 35.4%id,  0.0%wa,  0.7%hi,  0.3%si,  0.0%st
Mem:   2057700k total,  1172136k used,   885564k free,  536k buffers
Swap:   987988k total,0k used,   987988k free,   885976k cached

 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
11701 hechacke  20   0 51268  30m  18m R 18.9  1.5   1:46.30 gmplayer
11620 hechacke  20   0  127m  35m  18m S 15.3  1.7   0:40.64 mono
11695 hechacke  20   0  180m  67m  20m S 14.3  3.4   1:51.19 totem
9421 root  20   0  272m  49m  15m S 11.3  2.4   0:59.29 Xorg
11442 hechacke  20   0 63304 6232 4316 S  3.7  0.3   0:11.86 beryl

Observation:
Music plays perfectly.
Audio of video's play perfectly.
New Processes start in about the same amount of time as cfs-v6
Already open applications are responsive.
Behavior of video:
video's both moving forward. totem is doing ~0.9fps.
mplayer is doing ~1 fps.
Video's are slideshows in cfs-v7 vs cfs-v6 which was had more fps.

Going back to sd-0.46 since so far it provides the most constant FPS
under load (and thus the most responsiveness/smoothness).
-
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 2.6.21

[Dave Jones]

On Sun, Apr 29, 2007 at 07:55:35PM -0400, Theodore Tso wrote:

 > but if the goal is to
 > make it easier to archive and track information about a bug, at
 > *least* with the Debian BTS, when you reply to an e-mail message, the
 > reply is automatically appended to the bug log!

bugzilla does that too.

Dave

-- 
http://www.codemonkey.org.uk
-
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: checkpatch, a patch checking script.

[Randy Dunlap]

Matt Mackall wrote:

On Sun, Apr 29, 2007 at 04:37:01PM -0700, Randy Dunlap wrote:

On Sat, 28 Apr 2007 12:21:54 -0500 Matt Mackall wrote:


On Sat, Apr 28, 2007 at 01:11:01PM -0400, Dave Jones wrote:

On Sat, Apr 28, 2007 at 11:11:36AM -0500, Matt Mackall wrote:
 > > I'm all ears for additional regexps, bug reports or other suggestions.
 > 
 > Neat.
 > 
 > Does it check for:
 > 
 > functions marked extern?

data marked extern?


It's perfectly reasonable to have a data extern declaration in a header file.


but it's not perfectly acceptable to have

extern unsigned long volatile jiffies;

in a .c file.

The biggest problem I'm seeing ATM is that this script is a bit too
simplistic.  It doesn't know what it's looking at.  We'll have to
address that, I think.


--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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: checkpatch, a patch checking script.

[Matt Mackall]

On Sun, Apr 29, 2007 at 04:37:01PM -0700, Randy Dunlap wrote:
> On Sat, 28 Apr 2007 12:21:54 -0500 Matt Mackall wrote:
> 
> > On Sat, Apr 28, 2007 at 01:11:01PM -0400, Dave Jones wrote:
> > > On Sat, Apr 28, 2007 at 11:11:36AM -0500, Matt Mackall wrote:
> > >  > > I'm all ears for additional regexps, bug reports or other 
> > > suggestions.
> > >  > 
> > >  > Neat.
> > >  > 
> > >  > Does it check for:
> > >  > 
> > >  > functions marked extern?
> 
>   data marked extern?

It's perfectly reasonable to have a data extern declaration in a header file.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [19/26] i386: Enable bank 0 on non K7 Athlon

[Dave Jones]

On Mon, Apr 30, 2007 at 01:46:28AM +0200, Andi Kleen wrote:
 > 
 > As a bug workaround bank 0 on K7s is normally disabled, but no need
 > to do that on other AMD CPUs.
 > 
 > Cc: [EMAIL PROTECTED]
 > 
 > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
 
ACK, looks good to me.

thanks,

Dave

-- 
http://www.codemonkey.org.uk
-
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.21] BUG: clocksource_watchdog isn't reset after resume

[Indan Zupancic]

On Sun, April 29, 2007 21:25, Thomas Gleixner wrote:
> --- linux-2.6.orig/kernel/time/tick-common.c
> +++ linux-2.6/kernel/time/tick-common.c
> @@ -308,16 +308,20 @@ static void tick_suspend(void)
>   spin_unlock_irqrestore(&tick_device_lock, flags);
>  }
>
> -static void tick_resume(void)
> +static void tick_resume(int broadcast)
>  {
>   struct tick_device *td = &__get_cpu_var(tick_cpu_device);
>   unsigned long flags;
>
>   spin_lock_irqsave(&tick_device_lock, flags);
> - if (td->mode == TICKDEV_MODE_PERIODIC)
> - tick_setup_periodic(td->evtdev, 0);
> - else
> - tick_resume_oneshot();
> + clockevents_set_mode(td->evtdev, CLOCK_EVT_MODE_RESUME);
> +
> + if (!broadcast) {
> + if (td->mode == TICKDEV_MODE_PERIODIC)
> + tick_setup_periodic(td->evtdev, 0);
> + else
> + tick_resume_oneshot();
> + }
>   spin_unlock_irqrestore(&tick_device_lock, flags);
>  }
>
> @@ -327,6 +331,8 @@ static void tick_resume(void)
>  static int tick_notify(struct notifier_block *nb, unsigned long reason,
>  void *dev)
>  {
> + int res;
> +
>   switch (reason) {
>
>   case CLOCK_EVT_NOTIFY_ADD:
> @@ -354,8 +360,8 @@ static int tick_notify(struct notifier_b
>   break;
>
>   case CLOCK_EVT_NOTIFY_RESUME:
> - if (!tick_resume_broadcast())
> - tick_resume();
> + res = tick_resume_broadcast();
> + tick_resume(res);
>   break;

What about moving the tick_resume_broadcast() check into tick_resume() and
removing the parameter again? Something like the below:


--- tick-common.c   2007-04-30 01:45:19.0 +0200
+++ tick-common.c.iz2007-04-30 01:45:14.0 +0200
@@ -308,7 +308,7 @@ static void tick_suspend(void)
spin_unlock_irqrestore(&tick_device_lock, flags);
 }

-static void tick_resume(int broadcast)
+static void tick_resume(void)
 {
struct tick_device *td = &__get_cpu_var(tick_cpu_device);
unsigned long flags;
@@ -316,7 +316,7 @@ static void tick_resume(int broadcast)
spin_lock_irqsave(&tick_device_lock, flags);
clockevents_set_mode(td->evtdev, CLOCK_EVT_MODE_RESUME);

-   if (!broadcast) {
+   if (!tick_resume_broadcast()) {
if (td->mode == TICKDEV_MODE_PERIODIC)
tick_setup_periodic(td->evtdev, 0);
else
@@ -360,8 +360,7 @@ static int tick_notify(struct notifier_b
break;

case CLOCK_EVT_NOTIFY_RESUME:
-   res = tick_resume_broadcast();
-   tick_resume(res);
+   tick_resume();
break;

default:


-
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 2.6.21

[Indan Zupancic]

On Mon, April 30, 2007 01:41, Johannes Stezenbach wrote:
> Developers are just humans and if they have no incentive to
> act on a bug report they will ignore it. I think this is a
> fact that you have to deal with.

Reporters are just humans too and if they have no incentive to
post bugs they won't. So it's a lose/lose situation, really.
With a group of people working together they should try to
motivate each other, not demoralize everyone.

(I know, each bug report is a pain, voicing someone's failure.
So ignoring it might make people feel better, but it doesn't
fix anything.)


> It's also not necessarily the fault of the reporter if
> a bug report gets ignored, but for every report a developer
> has to make a decision to handle it or not, and there are
> lots of reasons why he may decide to not handle it, or
> at least not now (and then forget about it).

True. There's also a difference between a bad bug report and
one that a specific developer won't handle. In the former case
anyone could recognize it and tell the reporter about it. The
latter is a bit trickier, but if the developer thinks about
looking at it later, he better can tell the reporter just that.
A short "I'll take a look at it, later, when I've more time."
is so much better than plain silence.


> But I'm quite sure that an important bug would be reported
> again until fixed.

I wouldn't be so sure about that. What's worse, why would the
reporter bother telling that the bug is fixed in version N+1?
No one cared about it anyway, so there's no one to tell it to.
That would explain a lot open bugs too.

Greetings,

Indan


-
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] [19/26] i386: Enable bank 0 on non K7 Athlon

[Andi Kleen]

As a bug workaround bank 0 on K7s is normally disabled, but no need
to do that on other AMD CPUs.

Cc: [EMAIL PROTECTED]

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 arch/i386/kernel/cpu/mcheck/k7.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Index: linux/arch/i386/kernel/cpu/mcheck/k7.c
===
--- linux.orig/arch/i386/kernel/cpu/mcheck/k7.c
+++ linux/arch/i386/kernel/cpu/mcheck/k7.c
@@ -82,9 +82,13 @@ void amd_mcheck_init(struct cpuinfo_x86 
nr_mce_banks = l & 0xff;
 
/* Clear status for MC index 0 separately, we don't touch CTL,
-* as some Athlons cause spurious MCEs when its enabled. */
-   wrmsr (MSR_IA32_MC0_STATUS, 0x0, 0x0);
-   for (i=1; ihttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21

[Theodore Tso]

On Sun, Apr 29, 2007 at 03:15:42PM +0200, Andi Kleen wrote:
> This means we need people who figure out who to assign bugs too.
> Aka bugmasters.
> 
> BTW one big problem in our current bugzilla is that a lot of people
> cannot reassign bugs they don't own. I sometimes see bugs that I don't
> own bug I know who is responsible, but bugzilla doesn't allow me to do it.
> 
> So I think what would help:
> 
> - Ask more people to just categorize and reassign bugs (anybody interested?)
> - Give more people in bugzilla the power to reassign arbitary bugs
> (bugzilla maintainers would need to do that)

Folks might want to take a look at the Debian Bug Tracking System
(BTS).  It has a web interface which you can use to query history, but
*everything* is e-mail driven, and the way you submit, close, update,
tag/classfy bugs --- everything --- is via e-mail.

More importantly, anyone is allowed to recategorize and reassign bugs.
If someone does so maliciously or incorrectly, you can always revert
it, and if someone is being truly malicious, you can always blacklist
that one person.  It this respect, it is far more wiki-like than
bugzilla, which has always been too much like a straightjacket.

It's not perfect, but it's better than bugzilla --- but then again,
just about *anything* would be better than bugzilla.  (Hmm, except
maybe SourceForge's very tragic bug tracking system... :-)

Of course, as Linus has said, it's not a complete solution --- you
still need humans to be smart about things --- but if the goal is to
make it easier to archive and track information about a bug, at
*least* with the Debian BTS, when you reply to an e-mail message, the
reply is automatically appended to the bug log!

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [26/26] i386: i386 separate hardware-defined TSS from Linux additions

[Andi Kleen]

From: Rusty Russell <[EMAIL PROTECTED]>
On Thu, 2007-03-29 at 13:16 +0200, Andi Kleen wrote:
> Please clean it up properly with two structs.

Not sure about this, now I've done it.  Running it here.

If you like it, I can do x86-64 as well.

==
lguest defines its own TSS struct because the "struct tss_struct"
contains linux-specific additions.  Andi asked me to split the struct
in processor.h.

Unfortunately it makes usage a little awkward.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 arch/i386/kernel/asm-offsets.c |2 +-
 arch/i386/kernel/doublefault.c |   31 +--
 arch/i386/kernel/ioport.c  |2 +-
 arch/i386/kernel/process.c |8 
 arch/i386/kernel/sysenter.c|6 +++---
 arch/i386/kernel/traps.c   |4 ++--
 arch/i386/kernel/vmi.c |8 
 include/asm-i386/processor.h   |   24 
 8 files changed, 48 insertions(+), 37 deletions(-)

Index: linux/include/asm-i386/processor.h
===
--- linux.orig/include/asm-i386/processor.h
+++ linux/include/asm-i386/processor.h
@@ -291,7 +291,8 @@ typedef struct {
 
 struct thread_struct;
 
-struct tss_struct {
+/* This is the TSS defined by the hardware. */
+struct i386_hw_tss {
unsigned short  back_link,__blh;
unsigned long   esp0;
unsigned short  ss0,__ss0h;
@@ -315,6 +316,11 @@ struct tss_struct {
unsigned short  gs, __gsh;
unsigned short  ldt, __ldth;
unsigned short  trace, io_bitmap_base;
+} __attribute__((packed));
+
+struct tss_struct {
+   struct i386_hw_tss x86_tss;
+
/*
 * The extra 1 is there because the CPU will access an
 * additional byte beyond the end of the IO permission
@@ -381,10 +387,12 @@ struct thread_struct {
  * be within the limit.
  */
 #define INIT_TSS  {\
-   .esp0   = sizeof(init_stack) + (long)&init_stack,   \
-   .ss0= __KERNEL_DS,  \
-   .ss1= __KERNEL_CS,  \
-   .io_bitmap_base = INVALID_IO_BITMAP_OFFSET, \
+   .x86_tss = {\
+   .esp0   = sizeof(init_stack) + (long)&init_stack, \
+   .ss0= __KERNEL_DS,  \
+   .ss1= __KERNEL_CS,  \
+   .io_bitmap_base = INVALID_IO_BITMAP_OFFSET, \
+}, \
.io_bitmap  = { [ 0 ... IO_BITMAP_LONGS] = ~0 },\
 }
 
@@ -493,10 +501,10 @@ static inline void rep_nop(void)
 
 static inline void native_load_esp0(struct tss_struct *tss, struct 
thread_struct *thread)
 {
-   tss->esp0 = thread->esp0;
+   tss->x86_tss.esp0 = thread->esp0;
/* This can only happen when SEP is enabled, no need to test 
"SEP"arately */
-   if (unlikely(tss->ss1 != thread->sysenter_cs)) {
-   tss->ss1 = thread->sysenter_cs;
+   if (unlikely(tss->x86_tss.ss1 != thread->sysenter_cs)) {
+   tss->x86_tss.ss1 = thread->sysenter_cs;
wrmsr(MSR_IA32_SYSENTER_CS, thread->sysenter_cs, 0);
}
 }
Index: linux/arch/i386/kernel/asm-offsets.c
===
--- linux.orig/arch/i386/kernel/asm-offsets.c
+++ linux/arch/i386/kernel/asm-offsets.c
@@ -93,7 +93,7 @@ void foo(void)
OFFSET(pbe_next, pbe, next);
 
/* Offset from the sysenter stack to tss.esp0 */
-   DEFINE(TSS_sysenter_esp0, offsetof(struct tss_struct, esp0) -
+   DEFINE(TSS_sysenter_esp0, offsetof(struct tss_struct, x86_tss.esp0) -
 sizeof(struct tss_struct));
 
DEFINE(PAGE_SIZE_asm, PAGE_SIZE);
Index: linux/arch/i386/kernel/doublefault.c
===
--- linux.orig/arch/i386/kernel/doublefault.c
+++ linux/arch/i386/kernel/doublefault.c
@@ -33,7 +33,7 @@ static void doublefault_fn(void)
printk("double fault, tss at %08lx\n", tss);
 
if (ptr_ok(tss)) {
-   struct tss_struct *t = (struct tss_struct *)tss;
+   struct i386_hw_tss *t = (struct i386_hw_tss *)tss;
 
printk("eip = %08lx, esp = %08lx\n", t->eip, t->esp);
 
@@ -49,18 +49,21 @@ static void doublefault_fn(void)
 }
 
 struct tss_struct doublefault_tss __cacheline_aligned = {
-   .esp0   = STACK_START,
-   .ss0= __KERNEL_DS,
-   .ldt= 0,
-   .io_bitmap_base = INVALID_IO_BITMAP_OFFSET,
-
-   .eip= (unsigned long) doublefault_fn,
-   .eflags = X86_EFLAGS_SF | 0x2,  /* 0x2 bit is always set */
- 

[PATCH] [20/26] x86: Allow percpu variables to be page-aligned

[Andi Kleen]

From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Let's allow page-alignment in general for per-cpu data (wanted by Xen, and
Ingo suggested KVM as well).

Because larger alignments can use more room, we increase the max per-cpu
memory to 64k rather than 32k: it's getting a little tight.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
 arch/alpha/kernel/vmlinux.lds.S   |2 +-
 arch/arm/kernel/vmlinux.lds.S |2 +-
 arch/cris/arch-v32/vmlinux.lds.S  |1 +
 arch/frv/kernel/vmlinux.lds.S |1 +
 arch/i386/kernel/vmlinux.lds.S|2 +-
 arch/m32r/kernel/vmlinux.lds.S|2 +-
 arch/mips/kernel/vmlinux.lds.S|2 +-
 arch/parisc/kernel/vmlinux.lds.S  |2 +-
 arch/powerpc/kernel/setup_64.c|4 ++--
 arch/powerpc/kernel/vmlinux.lds.S |6 +-
 arch/ppc/kernel/vmlinux.lds.S |2 +-
 arch/s390/kernel/vmlinux.lds.S|2 +-
 arch/sh/kernel/vmlinux.lds.S  |2 +-
 arch/sh64/kernel/vmlinux.lds.S|2 +-
 arch/sparc/kernel/vmlinux.lds.S   |2 +-
 arch/sparc64/kernel/smp.c |6 +++---
 arch/x86_64/kernel/setup64.c  |4 ++--
 arch/x86_64/kernel/vmlinux.lds.S  |2 +-
 arch/xtensa/kernel/vmlinux.lds.S  |2 +-
 init/main.c   |8 ++--
 kernel/module.c   |8 
 21 files changed, 29 insertions(+), 35 deletions(-)

===
Index: linux/arch/alpha/kernel/vmlinux.lds.S
===
--- linux.orig/arch/alpha/kernel/vmlinux.lds.S
+++ linux/arch/alpha/kernel/vmlinux.lds.S
@@ -69,7 +69,7 @@ SECTIONS
   . = ALIGN(8);
   SECURITY_INIT
 
-  . = ALIGN(64);
+  . = ALIGN(8192);
   __per_cpu_start = .;
   .data.percpu : { *(.data.percpu) }
   __per_cpu_end = .;
Index: linux/arch/arm/kernel/vmlinux.lds.S
===
--- linux.orig/arch/arm/kernel/vmlinux.lds.S
+++ linux/arch/arm/kernel/vmlinux.lds.S
@@ -59,7 +59,7 @@ SECTIONS
usr/built-in.o(.init.ramfs)
__initramfs_end = .;
 #endif
-   . = ALIGN(64);
+   . = ALIGN(4096);
__per_cpu_start = .;
*(.data.percpu)
__per_cpu_end = .;
Index: linux/arch/cris/arch-v32/vmlinux.lds.S
===
--- linux.orig/arch/cris/arch-v32/vmlinux.lds.S
+++ linux/arch/cris/arch-v32/vmlinux.lds.S
@@ -91,6 +91,7 @@ SECTIONS
}
SECURITY_INIT
 
+   . =  ALIGN (8192);
__per_cpu_start = .;
.data.percpu  : { *(.data.percpu) }
__per_cpu_end = .;
Index: linux/arch/frv/kernel/vmlinux.lds.S
===
--- linux.orig/arch/frv/kernel/vmlinux.lds.S
+++ linux/arch/frv/kernel/vmlinux.lds.S
@@ -57,6 +57,7 @@ SECTIONS
   __alt_instructions_end = .;
  .altinstr_replacement : { *(.altinstr_replacement) }
 
+  . = ALIGN(4096);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }
   __per_cpu_end = .;
Index: linux/arch/i386/kernel/vmlinux.lds.S
===
--- linux.orig/arch/i386/kernel/vmlinux.lds.S
+++ linux/arch/i386/kernel/vmlinux.lds.S
@@ -194,7 +194,7 @@ SECTIONS
__initramfs_end = .;
   }
 #endif
-  . = ALIGN(L1_CACHE_BYTES);
+  . = ALIGN(4096);
   .data.percpu  : AT(ADDR(.data.percpu) - LOAD_OFFSET) {
__per_cpu_start = .;
*(.data.percpu)
Index: linux/arch/m32r/kernel/vmlinux.lds.S
===
--- linux.orig/arch/m32r/kernel/vmlinux.lds.S
+++ linux/arch/m32r/kernel/vmlinux.lds.S
@@ -110,7 +110,7 @@ SECTIONS
   __initramfs_end = .;
 #endif
 
-  . = ALIGN(32);
+  . = ALIGN(4096);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }
   __per_cpu_end = .;
Index: linux/arch/mips/kernel/vmlinux.lds.S
===
--- linux.orig/arch/mips/kernel/vmlinux.lds.S
+++ linux/arch/mips/kernel/vmlinux.lds.S
@@ -119,7 +119,7 @@ SECTIONS
   .init.ramfs : { *(.init.ramfs) }
   __initramfs_end = .;
 #endif
-  . = ALIGN(32);
+  . = ALIGN(_PAGE_SIZE);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }
   __per_cpu_end = .;
Index: linux/arch/parisc/kernel/vmlinux.lds.S
===
--- linux.orig/arch/parisc/kernel/vmlinux.lds.S
+++ linux/arch/parisc/kernel/vmlinux.lds.S
@@ -181,7 +181,7 @@ SECTIONS
   .init.ramfs : { *(.init.ramfs) }
   __initramfs_end = .;
 #endif
-  . = ALIGN(32);
+  . = ALIGN(ASM_PAGE_SIZE);
   __per_cpu_start = .;
   .data.percpu  : { *(.data.percpu) }

[PATCH] [23/26] i386: Allow boot-time disable of SMP altinstructions

[Andi Kleen]

From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Add "noreplace-smp" to disable SMP instruction replacement.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
 
---
 Documentation/kernel-parameters.txt |6 ++
 arch/i386/kernel/alternative.c  |   23 +++
 2 files changed, 25 insertions(+), 4 deletions(-)

===
Index: linux/Documentation/kernel-parameters.txt
===
--- linux.orig/Documentation/kernel-parameters.txt
+++ linux/Documentation/kernel-parameters.txt
@@ -1142,6 +1142,9 @@ and is between 256 and 4096 characters. 
 
nomce   [IA-32] Machine Check Exception
 
+   noreplace-smp   [IA-32,SMP] Don't replace SMP instructions
+   with UP alternatives
+
noresidual  [PPC] Don't use residual data on PReP machines.
 
noresume[SWSUSP] Disables resume and restores original swap
@@ -1547,6 +1550,9 @@ and is between 256 and 4096 characters. 
smart2= [HW]
Format: [,[,...,]]
 
+   smp-alt-once[IA-32,SMP] On a hotplug CPU system, only
+   attempt to substitute SMP alternatives once at boot.
+
snd-ad1816a=[HW,ALSA]
 
snd-ad1848= [HW,ALSA]
Index: linux/arch/i386/kernel/alternative.c
===
--- linux.orig/arch/i386/kernel/alternative.c
+++ linux/arch/i386/kernel/alternative.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 
+static int noreplace_smp = 0;
 static int smp_alt_once  = 0;
 static int debug_alternative = 0;
 
@@ -13,15 +14,23 @@ static int __init bootonly(char *str)
smp_alt_once = 1;
return 1;
 }
+__setup("smp-alt-boot", bootonly);
+
 static int __init debug_alt(char *str)
 {
debug_alternative = 1;
return 1;
 }
-
-__setup("smp-alt-boot", bootonly);
 __setup("debug-alternative", debug_alt);
 
+static int __init setup_noreplace_smp(char *str)
+{
+   noreplace_smp = 1;
+   return 1;
+}
+__setup("noreplace-smp", setup_noreplace_smp);
+
+
 #define DPRINTK(fmt, args...) if (debug_alternative) \
printk(KERN_DEBUG fmt, args)
 
@@ -185,6 +194,9 @@ static void alternatives_smp_unlock(u8 *
 {
u8 **ptr;
 
+   if (noreplace_smp)
+   return;
+
for (ptr = start; ptr < end; ptr++) {
if (*ptr < text)
continue;
@@ -219,6 +231,9 @@ void alternatives_smp_module_add(struct 
struct smp_alt_module *smp;
unsigned long flags;
 
+   if (noreplace_smp)
+   return;
+
if (smp_alt_once) {
if (boot_cpu_has(X86_FEATURE_UP))
alternatives_smp_unlock(locks, locks_end,
@@ -253,7 +268,7 @@ void alternatives_smp_module_del(struct 
struct smp_alt_module *item;
unsigned long flags;
 
-   if (smp_alt_once)
+   if (smp_alt_once || noreplace_smp)
return;
 
spin_lock_irqsave(&smp_alt, flags);
@@ -284,7 +299,7 @@ void alternatives_smp_switch(int smp)
return;
 #endif
 
-   if (smp_alt_once)
+   if (noreplace_smp || smp_alt_once)
return;
BUG_ON(!smp && (num_online_cpus() > 1));
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [6/26] x86: fix amd64-agp aperture validation

[Andi Kleen]

From: "Jan Beulich" <[EMAIL PROTECTED]>
Under CONFIG_DISCONTIGMEM, assuming that a !pfn_valid() implies all
subsequent pfn-s are also invalid is wrong. Thus replace this by
explicitly checking against the E820 map.

AK: make e820 on x86-64 not initdata

Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Acked-by: Mark Langsdorf <[EMAIL PROTECTED]>

---
 arch/i386/kernel/e820.c  |   20 
 arch/x86_64/kernel/e820.c|5 +++--
 drivers/char/agp/amd64-agp.c |   13 -
 include/asm-i386/e820.h  |1 +
 4 files changed, 28 insertions(+), 11 deletions(-)

Index: linux/arch/i386/kernel/e820.c
===
--- linux.orig/arch/i386/kernel/e820.c
+++ linux/arch/i386/kernel/e820.c
@@ -825,6 +825,26 @@ void __init limit_regions(unsigned long 
print_memory_map("limit_regions endfunc");
 }
 
+/*
+ * This function checks if any part of the range  is mapped
+ * with type.
+ */
+int
+e820_any_mapped(u64 start, u64 end, unsigned type)
+{
+   int i;
+   for (i = 0; i < e820.nr_map; i++) {
+   const struct e820entry *ei = &e820.map[i];
+   if (type && ei->type != type)
+   continue;
+   if (ei->addr >= end || ei->addr + ei->size <= start)
+   continue;
+   return 1;
+   }
+   return 0;
+}
+EXPORT_SYMBOL_GPL(e820_any_mapped);
+
  /*
   * This function checks if the entire range  is mapped with type.
   *
Index: linux/arch/x86_64/kernel/e820.c
===
--- linux.orig/arch/x86_64/kernel/e820.c
+++ linux/arch/x86_64/kernel/e820.c
@@ -25,7 +25,7 @@
 #include 
 #include 
 
-struct e820map e820 __initdata;
+struct e820map e820;
 
 /* 
  * PFN of last memory page.
@@ -98,7 +98,7 @@ static inline int bad_addr(unsigned long
  * This function checks if any part of the range  is mapped
  * with type.
  */
-int __meminit
+int
 e820_any_mapped(unsigned long start, unsigned long end, unsigned type)
 { 
int i;
@@ -112,6 +112,7 @@ e820_any_mapped(unsigned long start, uns
} 
return 0;
 }
+EXPORT_SYMBOL_GPL(e820_any_mapped);
 
 /*
  * This function checks if the entire range  is mapped with type.
Index: linux/drivers/char/agp/amd64-agp.c
===
--- linux.orig/drivers/char/agp/amd64-agp.c
+++ linux/drivers/char/agp/amd64-agp.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include   /* PAGE_SIZE */
+#include 
 #include 
 #include "agp.h"
 
@@ -259,7 +260,6 @@ static const struct agp_bridge_driver am
 /* Some basic sanity checks for the aperture. */
 static int __devinit aperture_valid(u64 aper, u32 size)
 {
-   u32 pfn, c;
if (aper == 0) {
printk(KERN_ERR PFX "No aperture\n");
return 0;
@@ -272,14 +272,9 @@ static int __devinit aperture_valid(u64 
printk(KERN_ERR PFX "Aperture out of bounds\n");
return 0;
}
-   pfn = aper >> PAGE_SHIFT;
-   for (c = 0; c < size/PAGE_SIZE; c++) {
-   if (!pfn_valid(pfn + c))
-   break;
-   if (!PageReserved(pfn_to_page(pfn + c))) {
-   printk(KERN_ERR PFX "Aperture pointing to RAM\n");
-   return 0;
-   }
+   if (e820_any_mapped(aper, aper + size, E820_RAM)) {
+   printk(KERN_ERR PFX "Aperture pointing to RAM\n");
+   return 0;
}
 
/* Request the Aperture. This catches cases when someone else
Index: linux/include/asm-i386/e820.h
===
--- linux.orig/include/asm-i386/e820.h
+++ linux/include/asm-i386/e820.h
@@ -38,6 +38,7 @@ extern struct e820map e820;
 
 extern int e820_all_mapped(unsigned long start, unsigned long end,
   unsigned type);
+extern int e820_any_mapped(u64 start, u64 end, unsigned type);
 extern void find_max_pfn(void);
 extern void register_bootmem_low_pages(unsigned long max_low_pfn);
 extern void e820_register_memory(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/

[PATCH] [18/26] i386: Update smp_call_function* comments

[Andi Kleen]

From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Update documentation for i386 smp_call_function* functions.

As reported by Randy Dunlap <[EMAIL PROTECTED]>

[ I've posted this before but it seems to have been lost along the way. ]

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Cc: Randy Dunlap <[EMAIL PROTECTED]>

---
 arch/i386/kernel/smp.c |   25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

===
Index: linux/arch/i386/kernel/smp.c
===
--- linux.orig/arch/i386/kernel/smp.c
+++ linux/arch/i386/kernel/smp.c
@@ -554,8 +554,10 @@ static void __smp_call_function(void (*f
  * @info: An arbitrary pointer to pass to the function.
  * @wait: If true, wait (atomically) until function has completed on other 
CPUs.
  *
- * Returns 0 on success, else a negative status code. Does not return until
- * remote CPUs are nearly ready to execute <> or are or have finished.
+  * Returns 0 on success, else a negative status code.
+ *
+ * If @wait is true, then returns once @func has returned; otherwise
+ * it returns just before the target cpu calls @func.
  *
  * You must not call this function with disabled interrupts or from a
  * hardware interrupt handler or from a bottom half handler.
@@ -617,11 +619,13 @@ int native_smp_call_function_mask(cpumas
  * smp_call_function(): Run a function on all other CPUs.
  * @func: The function to run. This must be fast and non-blocking.
  * @info: An arbitrary pointer to pass to the function.
- * @nonatomic: currently unused.
+ * @nonatomic: Unused.
  * @wait: If true, wait (atomically) until function has completed on other 
CPUs.
  *
- * Returns 0 on success, else a negative status code. Does not return until
- * remote CPUs are nearly ready to execute <> or are or have executed.
+ * Returns 0 on success, else a negative status code.
+ *
+ * If @wait is true, then returns once @func has returned; otherwise
+ * it returns just before the target cpu calls @func.
  *
  * You must not call this function with disabled interrupts or from a
  * hardware interrupt handler or from a bottom half handler.
@@ -633,17 +637,18 @@ int smp_call_function(void (*func) (void
 }
 EXPORT_SYMBOL(smp_call_function);
 
-/*
+/**
  * smp_call_function_single - Run a function on another CPU
+ * @cpu: The target CPU.  Cannot be the calling CPU.
  * @func: The function to run. This must be fast and non-blocking.
  * @info: An arbitrary pointer to pass to the function.
- * @nonatomic: Currently unused.
+ * @nonatomic: Unused.
  * @wait: If true, wait until function has completed on other CPUs.
  *
- * Retrurns 0 on success, else a negative status code.
+ * Returns 0 on success, else a negative status code.
  *
- * Does not return until the remote CPU is nearly ready to execute 
- * or is or has executed.
+ * If @wait is true, then returns once @func has returned; otherwise
+ * it returns just before the target cpu calls @func.
  */
 int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
 int nonatomic, int wait)
-
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] [17/26] i386: Use menuconfig objects - APM

[Andi Kleen]

From: Jan Engelhardt <[EMAIL PROTECTED]>

(I hope Andi is the right one to Cc, otherwise please add, thanks!)


Use menuconfigs instead of menus, so the whole menu can be disabled at
once instead of going through all options.

Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 arch/i386/Kconfig |   17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

Index: linux/arch/i386/Kconfig
===
--- linux.orig/arch/i386/Kconfig
+++ linux/arch/i386/Kconfig
@@ -915,12 +915,9 @@ source kernel/power/Kconfig
 
 source "drivers/acpi/Kconfig"
 
-menu "APM (Advanced Power Management) BIOS Support"
-depends on PM && !X86_VISWS
-
-config APM
+menuconfig APM
tristate "APM (Advanced Power Management) BIOS support"
-   depends on PM
+   depends on PM && !X86_VISWS
---help---
  APM is a BIOS specification for saving power using several different
  techniques. This is mostly useful for battery powered laptops with
@@ -977,9 +974,10 @@ config APM
  To compile this driver as a module, choose M here: the
  module will be called apm.
 
+if APM
+
 config APM_IGNORE_USER_SUSPEND
bool "Ignore USER SUSPEND"
-   depends on APM
help
  This option will ignore USER SUSPEND requests. On machines with a
  compliant APM BIOS, you want to say N. However, on the NEC Versa M
@@ -987,7 +985,6 @@ config APM_IGNORE_USER_SUSPEND
 
 config APM_DO_ENABLE
bool "Enable PM at boot time"
-   depends on APM
---help---
  Enable APM features at boot time. From page 36 of the APM BIOS
  specification: "When disabled, the APM BIOS does not automatically
@@ -1005,7 +1002,6 @@ config APM_DO_ENABLE
 
 config APM_CPU_IDLE
bool "Make CPU Idle calls when idle"
-   depends on APM
help
  Enable calls to APM CPU Idle/CPU Busy inside the kernel's idle loop.
  On some machines, this can activate improved power savings, such as
@@ -1017,7 +1013,6 @@ config APM_CPU_IDLE
 
 config APM_DISPLAY_BLANK
bool "Enable console blanking using APM"
-   depends on APM
help
  Enable console blanking using the APM. Some laptops can use this to
  turn off the LCD backlight when the screen blanker of the Linux
@@ -1031,7 +1026,6 @@ config APM_DISPLAY_BLANK
 
 config APM_ALLOW_INTS
bool "Allow interrupts during APM BIOS calls"
-   depends on APM
help
  Normally we disable external interrupts while we are making calls to
  the APM BIOS as a measure to lessen the effects of a badly behaving
@@ -1042,13 +1036,12 @@ config APM_ALLOW_INTS
 
 config APM_REAL_MODE_POWER_OFF
bool "Use real mode APM BIOS call to power off"
-   depends on APM
help
  Use real mode APM BIOS calls to switch off the computer. This is
  a work-around for a number of buggy BIOSes. Switch this option on if
  your computer crashes instead of powering off properly.
 
-endmenu
+endif # APM
 
 source "arch/i386/kernel/cpu/cpufreq/Kconfig"
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] [1/26] i386: Add smp_ops interface

[Andi Kleen]

From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Subject: Add smp_ops interface

Add a smp_ops interface.  This abstracts the API defined by
 for use within arch/i386.  The primary intent is that it
be used by a paravirtualizing hypervisor to implement SMP, but it
could also be used by non-APIC-using sub-architectures.

This is related to CONFIG_PARAVIRT, but is implemented unconditionally
since it is simpler that way and not a highly performance-sensitive
interface.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>

---
 arch/i386/kernel/smp.c |   21 +
 arch/i386/kernel/smpboot.c |8 +++---
 include/asm-i386/smp.h |   53 +
 3 files changed, 73 insertions(+), 9 deletions(-)

===
Index: linux/arch/i386/kernel/smp.c
===
--- linux.orig/arch/i386/kernel/smp.c
+++ linux/arch/i386/kernel/smp.c
@@ -483,7 +483,7 @@ void flush_tlb_all(void)
  * it goes straight through and wastes no time serializing
  * anything. Worst case is that we lose a reschedule ...
  */
-void smp_send_reschedule(int cpu)
+void native_smp_send_reschedule(int cpu)
 {
WARN_ON(cpu_is_offline(cpu));
send_IPI_mask(cpumask_of_cpu(cpu), RESCHEDULE_VECTOR);
@@ -560,9 +560,9 @@ static void __smp_call_function(void (*f
  * You must not call this function with disabled interrupts or from a
  * hardware interrupt handler or from a bottom half handler.
  */
-int smp_call_function_mask(cpumask_t mask,
-  void (*func)(void *), void *info,
-  int wait)
+int native_smp_call_function_mask(cpumask_t mask,
+ void (*func)(void *), void *info,
+ int wait)
 {
struct call_data_struct data;
cpumask_t allbutself;
@@ -681,7 +681,7 @@ static void stop_this_cpu (void * dummy)
  * this function calls the 'stop' function on all other CPUs in the system.
  */
 
-void smp_send_stop(void)
+void native_smp_send_stop(void)
 {
/* Don't deadlock on the call lock in panic */
int nolock = !spin_trylock(&call_lock);
@@ -757,3 +757,14 @@ int safe_smp_processor_id(void)
 
return cpuid >= 0 ? cpuid : 0;
 }
+
+struct smp_ops smp_ops = {
+   .smp_prepare_boot_cpu = native_smp_prepare_boot_cpu,
+   .smp_prepare_cpus = native_smp_prepare_cpus,
+   .cpu_up = native_cpu_up,
+   .smp_cpus_done = native_smp_cpus_done,
+
+   .smp_send_stop = native_smp_send_stop,
+   .smp_send_reschedule = native_smp_send_reschedule,
+   .smp_call_function_mask = native_smp_call_function_mask,
+};
Index: linux/arch/i386/kernel/smpboot.c
===
--- linux.orig/arch/i386/kernel/smpboot.c
+++ linux/arch/i386/kernel/smpboot.c
@@ -1171,7 +1171,7 @@ static void __init smp_boot_cpus(unsigne
 
 /* These are wrappers to interface to the new boot process.  Someone
who understands all this stuff should rewrite it properly. --RR 15/Jul/02 */
-void __init smp_prepare_cpus(unsigned int max_cpus)
+void __init native_smp_prepare_cpus(unsigned int max_cpus)
 {
smp_commenced_mask = cpumask_of_cpu(0);
cpu_callin_map = cpumask_of_cpu(0);
@@ -1191,7 +1191,7 @@ static inline void switch_to_new_gdt(voi
asm volatile ("mov %0, %%fs" : : "r" (__KERNEL_PDA) : "memory");
 }
 
-void __init smp_prepare_boot_cpu(void)
+void __init native_smp_prepare_boot_cpu(void)
 {
unsigned int cpu = smp_processor_id();
 
@@ -1292,7 +1292,7 @@ void __cpu_die(unsigned int cpu)
 }
 #endif /* CONFIG_HOTPLUG_CPU */
 
-int __cpuinit __cpu_up(unsigned int cpu)
+int __cpuinit native_cpu_up(unsigned int cpu)
 {
unsigned long flags;
 #ifdef CONFIG_HOTPLUG_CPU
@@ -1337,7 +1337,7 @@ int __cpuinit __cpu_up(unsigned int cpu)
return 0;
 }
 
-void __init smp_cpus_done(unsigned int max_cpus)
+void __init native_smp_cpus_done(unsigned int max_cpus)
 {
 #ifdef CONFIG_X86_IO_APIC
setup_ioapic_dest();
Index: linux/include/asm-i386/smp.h
===
--- linux.orig/include/asm-i386/smp.h
+++ linux/include/asm-i386/smp.h
@@ -49,6 +49,59 @@ extern void cpu_exit_clear(void);
 extern void cpu_uninit(void);
 #endif
 
+struct smp_ops
+{
+   void (*smp_prepare_boot_cpu)(void);
+   void (*smp_prepare_cpus)(unsigned max_cpus);
+   int (*cpu_up)(unsigned cpu);
+   void (*smp_cpus_done)(unsigned max_cpus);
+
+   void (*smp_send_stop)(void);
+   void (*smp_send_reschedule)(int cpu);
+   int (*smp_call_function_mask)(cpumask_t mask,
+ void (*func)(void *info), void *info,
+

[PATCH] [24/26] x86_64: Fix x86_64 compilation with DEBUG_SIG on

[Andi Kleen]

From: Glauber de Oliveira Costa <[EMAIL PROTECTED]>

Setting the DEBUG_SIG flag breaks compilation due to a wrong
struct access. Aditionally, it raises two warnings. This is one
patch to fix them all.

Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

-- 
Glauber de Oliveira Costa
Red Hat Inc.
"Free as in Freedom"


commit ff9d841995b6055b74017306f30485c2b4a9ea70
Author: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Date:   Fri Mar 23 07:13:38 2007 -0300

[PATCH] Fix x86_64 compilation with DEBUG_SIG on

Setting the DEBUG_SIG flag breaks compilation due to a wrong
struct access. Aditionally, it raises two warnings. This is one
patch to fix them all.

Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>

---
 arch/x86_64/kernel/signal.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: linux/arch/x86_64/kernel/signal.c
===
--- linux.orig/arch/x86_64/kernel/signal.c
+++ linux/arch/x86_64/kernel/signal.c
@@ -141,7 +141,7 @@ asmlinkage long sys_rt_sigreturn(struct 
goto badframe;
 
 #ifdef DEBUG_SIG
-   printk("%d sigreturn rip:%lx rsp:%lx frame:%p 
rax:%lx\n",current->pid,regs.rip,regs.rsp,frame,eax);
+   printk("%d sigreturn rip:%lx rsp:%lx frame:%p 
rax:%lx\n",current->pid,regs->rip,regs->rsp,frame,eax);
 #endif
 
if (do_sigaltstack(&frame->uc.uc_stack, NULL, regs->rsp) == -EFAULT)
@@ -301,7 +301,7 @@ static int setup_rt_frame(int sig, struc
if (test_thread_flag(TIF_SINGLESTEP))
ptrace_notify(SIGTRAP);
 #ifdef DEBUG_SIG
-   printk("SIG deliver (%s:%d): sp=%p pc=%p ra=%p\n",
+   printk("SIG deliver (%s:%d): sp=%p pc=%lx ra=%p\n",
current->comm, current->pid, frame, regs->rip, frame->pretcode);
 #endif
 
@@ -463,7 +463,7 @@ void
 do_notify_resume(struct pt_regs *regs, void *unused, __u32 thread_info_flags)
 {
 #ifdef DEBUG_SIG
-   printk("do_notify_resume flags:%x rip:%lx rsp:%lx caller:%lx 
pending:%lx\n",
+   printk("do_notify_resume flags:%x rip:%lx rsp:%lx caller:%p 
pending:%x\n",
   thread_info_flags, regs->rip, regs->rsp, 
__builtin_return_address(0),signal_pending(current)); 
 #endif
   
-
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] [16/26] i386: Enable machine check for AMD Family 10

[Andi Kleen]

From: Joachim Deguara <[EMAIL PROTECTED]>

We don't check for any specific family because the code is generic
to all systems supporting the Intel machine check architecture.
Just check the CPUID bit instead

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 arch/i386/kernel/cpu/mcheck/mce.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/arch/i386/kernel/cpu/mcheck/mce.c
===
--- linux.orig/arch/i386/kernel/cpu/mcheck/mce.c
+++ linux/arch/i386/kernel/cpu/mcheck/mce.c
@@ -38,7 +38,7 @@ void mcheck_init(struct cpuinfo_x86 *c)
 
switch (c->x86_vendor) {
case X86_VENDOR_AMD:
-   if (c->x86==6 || c->x86==15)
+   if (boot_cpu_has(X86_FEATURE_MCA))
amd_mcheck_init(c);
break;
 
-
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] [15/26] x86: Don't use MWAIT on AMD Family 10

[Andi Kleen]

It doesn't put the CPU into deeper sleep states, so it's better to use the 
standard
idle loop to save power. But allow to reenable it anyways for benchmarking.

I also removed the obsolete idle=halt on i386

Cc: [EMAIL PROTECTED]

Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 Documentation/kernel-parameters.txt |   11 +--
 arch/i386/kernel/cpu/amd.c  |5 +
 arch/i386/kernel/process.c  |   17 -
 arch/x86_64/kernel/process.c|   12 +++-
 arch/x86_64/kernel/setup.c  |6 ++
 include/asm-i386/processor.h|2 ++
 include/asm-x86_64/proto.h  |2 ++
 7 files changed, 39 insertions(+), 16 deletions(-)

Index: linux/Documentation/kernel-parameters.txt
===
--- linux.orig/Documentation/kernel-parameters.txt
+++ linux/Documentation/kernel-parameters.txt
@@ -673,8 +673,15 @@ and is between 256 and 4096 characters. 
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
See Documentation/ide.txt.
 
-   idle=   [HW]
-   Format: idle=poll or idle=halt
+   idle=   [X86]
+   Format: idle=poll or idle=mwait
+   Poll forces a polling idle loop that can slightly 
improves the performance
+   of waking up a idle CPU, but will use a lot of power 
and make the system
+   run hot. Not recommended.
+   idle=mwait. On systems which support MONITOR/MWAIT but 
the kernel chose
+   to not use it because it doesn't save as much power as 
a normal idle
+   loop use the MONITOR/MWAIT idle loop anyways. 
Performance should be the same
+   as idle=poll.
 
ignore_loglevel [KNL]
Ignore loglevel setting - this will print /all/
Index: linux/arch/i386/kernel/cpu/amd.c
===
--- linux.orig/arch/i386/kernel/cpu/amd.c
+++ linux/arch/i386/kernel/cpu/amd.c
@@ -53,6 +53,8 @@ static __cpuinit int amd_apic_timer_brok
return 0;
 }
 
+int force_mwait __cpuinitdata;
+
 static void __cpuinit init_amd(struct cpuinfo_x86 *c)
 {
u32 l, h;
@@ -275,6 +277,9 @@ static void __cpuinit init_amd(struct cp
 
if (amd_apic_timer_broken())
set_bit(X86_FEATURE_LAPIC_TIMER_BROKEN, c->x86_capability);
+
+   if (c->x86 == 0x10 && !force_mwait)
+   clear_bit(X86_FEATURE_MWAIT, c->x86_capability);
 }
 
 static unsigned int __cpuinit amd_size_cache(struct cpuinfo_x86 * c, unsigned 
int size)
Index: linux/arch/i386/kernel/process.c
===
--- linux.orig/arch/i386/kernel/process.c
+++ linux/arch/i386/kernel/process.c
@@ -272,25 +272,24 @@ void __devinit select_idle_routine(const
}
 }
 
-static int __init idle_setup (char *str)
+static int __init idle_setup(char *str)
 {
-   if (!strncmp(str, "poll", 4)) {
+   if (!strcmp(str, "poll")) {
printk("using polling idle threads.\n");
pm_idle = poll_idle;
 #ifdef CONFIG_X86_SMP
if (smp_num_siblings > 1)
printk("WARNING: polling idle and HT enabled, 
performance may degrade.\n");
 #endif
-   } else if (!strncmp(str, "halt", 4)) {
-   printk("using halt in idle threads.\n");
-   pm_idle = default_idle;
-   }
+   } else if (!strcmp(str, "mwait"))
+   force_mwait = 1;
+   else
+   return -1;
 
boot_option_idle_override = 1;
-   return 1;
+   return 0;
 }
-
-__setup("idle=", idle_setup);
+early_param("idle", idle_setup);
 
 void show_regs(struct pt_regs * regs)
 {
Index: linux/arch/x86_64/kernel/process.c
===
--- linux.orig/arch/x86_64/kernel/process.c
+++ linux/arch/x86_64/kernel/process.c
@@ -288,16 +288,18 @@ void __cpuinit select_idle_routine(const
 
 static int __init idle_setup (char *str)
 {
-   if (!strncmp(str, "poll", 4)) {
+   if (!strcmp(str, "poll")) {
printk("using polling idle threads.\n");
pm_idle = poll_idle;
-   }
+   } else if (!strcmp(str, "mwait"))
+   force_mwait = 1;
+   else
+   return -1;
 
boot_option_idle_override = 1;
-   return 1;
+   return 0;
 }
-
-__setup("idle=", idle_setup);
+early_param("idle", idle_setup);
 
 /* Prints also some state that isn't saved in the pt_regs */ 
 void __show_regs(struct pt_regs * regs)
Index: linux/arch/x86_64/kernel/setup.c
===
--- linux.orig/arch/x86_64/kernel/setup.c
+++ linux/arch/x86_64/kernel/setup.c
@@ -79,6 +79,8 @@ int bootloader_type;
 
 unsigned long saved_video_mode;
 
+int force_mwa

[PATCH] [22/26] i386: Remove smp_alt_instructions

[Andi Kleen]

From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
The .smp_altinstructions section and its corresponding symbols are
completely unused, so remove them.

Also, remove stray #ifdef __KENREL__ in asm-i386/alternative.h

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>

---
 arch/i386/kernel/alternative.c |   38 ++
 arch/i386/kernel/vmlinux.lds.S |   11 ---
 include/asm-i386/alternative.h |6 +-
 3 files changed, 3 insertions(+), 52 deletions(-)

===
Index: linux/arch/i386/kernel/alternative.c
===
--- linux.orig/arch/i386/kernel/alternative.c
+++ linux/arch/i386/kernel/alternative.c
@@ -132,11 +132,8 @@ static void nop_out(void *insns, unsigne
 }
 
 extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
-extern struct alt_instr __smp_alt_instructions[], __smp_alt_instructions_end[];
 extern u8 *__smp_locks[], *__smp_locks_end[];
 
-extern u8 __smp_alt_begin[], __smp_alt_end[];
-
 /* Replace instructions with better alternatives for this CPU type.
This runs before SMP is initialized to avoid SMP problems with
self modifying code. This implies that assymetric systems where
@@ -171,29 +168,6 @@ void apply_alternatives(struct alt_instr
 
 #ifdef CONFIG_SMP
 
-static void alternatives_smp_save(struct alt_instr *start, struct alt_instr 
*end)
-{
-   struct alt_instr *a;
-
-   DPRINTK("%s: alt table %p-%p\n", __FUNCTION__, start, end);
-   for (a = start; a < end; a++) {
-   memcpy(a->replacement + a->replacementlen,
-  a->instr,
-  a->instrlen);
-   }
-}
-
-static void alternatives_smp_apply(struct alt_instr *start, struct alt_instr 
*end)
-{
-   struct alt_instr *a;
-
-   for (a = start; a < end; a++) {
-   memcpy(a->instr,
-  a->replacement + a->replacementlen,
-  a->instrlen);
-   }
-}
-
 static void alternatives_smp_lock(u8 **start, u8 **end, u8 *text, u8 *text_end)
 {
u8 **ptr;
@@ -319,8 +293,6 @@ void alternatives_smp_switch(int smp)
printk(KERN_INFO "SMP alternatives: switching to SMP code\n");
clear_bit(X86_FEATURE_UP, boot_cpu_data.x86_capability);
clear_bit(X86_FEATURE_UP, cpu_data[0].x86_capability);
-   alternatives_smp_apply(__smp_alt_instructions,
-  __smp_alt_instructions_end);
list_for_each_entry(mod, &smp_alt_modules, next)
alternatives_smp_lock(mod->locks, mod->locks_end,
  mod->text, mod->text_end);
@@ -328,8 +300,6 @@ void alternatives_smp_switch(int smp)
printk(KERN_INFO "SMP alternatives: switching to UP code\n");
set_bit(X86_FEATURE_UP, boot_cpu_data.x86_capability);
set_bit(X86_FEATURE_UP, cpu_data[0].x86_capability);
-   apply_alternatives(__smp_alt_instructions,
-  __smp_alt_instructions_end);
list_for_each_entry(mod, &smp_alt_modules, next)
alternatives_smp_unlock(mod->locks, mod->locks_end,
mod->text, mod->text_end);
@@ -396,17 +366,13 @@ void __init alternative_instructions(voi
printk(KERN_INFO "SMP alternatives: switching to UP 
code\n");
set_bit(X86_FEATURE_UP, boot_cpu_data.x86_capability);
set_bit(X86_FEATURE_UP, cpu_data[0].x86_capability);
-   apply_alternatives(__smp_alt_instructions,
-  __smp_alt_instructions_end);
alternatives_smp_unlock(__smp_locks, __smp_locks_end,
_text, _etext);
}
free_init_pages("SMP alternatives",
-   __pa_symbol(&__smp_alt_begin),
-   __pa_symbol(&__smp_alt_end));
+   __pa_symbol(&__smp_locks),
+   __pa_symbol(&__smp_locks_end));
} else {
-   alternatives_smp_save(__smp_alt_instructions,
- __smp_alt_instructions_end);
alternatives_smp_module_add(NULL, "core kernel",
__smp_locks, __smp_locks_end,
_text, _etext);
Index: linux/arch/i386/kernel/vmlinux.lds.S
===
--- linux.orig/arch/i386/kernel/vmlinux.lds.S
+++ linux/arch/i386/kernel/vmlinux.lds.S
@@ -117,22 +117,11 @@ SECTIONS
 
   /* might get freed after init */
   . = ALI

[PATCH] [8/26] x86_64: fix arithmetic in comment

[Andi Kleen]

From: Avi Kivity <[EMAIL PROTECTED]>
The xmm space on x86_64 is 256 bytes.

Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 include/asm-x86_64/processor.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux/include/asm-x86_64/processor.h
===
--- linux.orig/include/asm-x86_64/processor.h
+++ linux/include/asm-x86_64/processor.h
@@ -181,7 +181,7 @@ struct i387_fxsave_struct {
u32 mxcsr;
u32 mxcsr_mask;
u32 st_space[32];   /* 8*16 bytes for each FP-reg = 128 bytes */
-   u32 xmm_space[64];  /* 16*16 bytes for each XMM-reg = 128 bytes */
+   u32 xmm_space[64];  /* 16*16 bytes for each XMM-reg = 256 bytes */
u32 padding[24];
 } __attribute__ ((aligned (16)));
 
-
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/26] i386: Add machine_ops interface to abstract halting and rebooting

[Andi Kleen]

From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
machine_ops is an interface for the machine_* functions defined in
.  This is intended to allow hypervisors to intercept
the reboot process, but it could be used to implement other x86
subarchtecture reboots.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 arch/i386/kernel/apm.c|3 +--
 arch/i386/kernel/reboot.c |   43 ++-
 include/asm-i386/reboot.h |   20 
 3 files changed, 59 insertions(+), 7 deletions(-)

===
Index: linux/arch/i386/kernel/apm.c
===
--- linux.orig/arch/i386/kernel/apm.c
+++ linux/arch/i386/kernel/apm.c
@@ -233,11 +233,10 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "io_ports.h"
 
-extern void machine_real_restart(unsigned char *, int);
-
 #if defined(CONFIG_APM_DISPLAY_BLANK) && defined(CONFIG_VT)
 extern int (*console_blank_hook)(int);
 #endif
Index: linux/arch/i386/kernel/reboot.c
===
--- linux.orig/arch/i386/kernel/reboot.c
+++ linux/arch/i386/kernel/reboot.c
@@ -18,6 +18,7 @@
 #include 
 #include "mach_reboot.h"
 #include 
+#include 
 
 /*
  * Power off function, if any
@@ -280,7 +281,7 @@ void machine_real_restart(unsigned char 
 EXPORT_SYMBOL(machine_real_restart);
 #endif
 
-void machine_shutdown(void)
+static void native_machine_shutdown(void)
 {
 #ifdef CONFIG_SMP
int reboot_cpu_id;
@@ -320,7 +321,7 @@ void __attribute__((weak)) mach_reboot_f
 {
 }
 
-void machine_emergency_restart(void)
+static void native_machine_emergency_restart(void)
 {
if (!reboot_thru_bios) {
if (efi_enabled) {
@@ -344,17 +345,17 @@ void machine_emergency_restart(void)
machine_real_restart(jump_to_bios, sizeof(jump_to_bios));
 }
 
-void machine_restart(char * __unused)
+static void native_machine_restart(char * __unused)
 {
machine_shutdown();
machine_emergency_restart();
 }
 
-void machine_halt(void)
+static void native_machine_halt(void)
 {
 }
 
-void machine_power_off(void)
+static void native_machine_power_off(void)
 {
if (pm_power_off) {
machine_shutdown();
@@ -363,3 +364,35 @@ void machine_power_off(void)
 }
 
 
+struct machine_ops machine_ops = {
+   .power_off = native_machine_power_off,
+   .shutdown = native_machine_shutdown,
+   .emergency_restart = native_machine_emergency_restart,
+   .restart = native_machine_restart,
+   .halt = native_machine_halt,
+};
+
+void machine_power_off(void)
+{
+   machine_ops.power_off();
+}
+
+void machine_shutdown(void)
+{
+   machine_ops.shutdown();
+}
+
+void machine_emergency_restart(void)
+{
+   machine_ops.emergency_restart();
+}
+
+void machine_restart(char *cmd)
+{
+   machine_ops.restart(cmd);
+}
+
+void machine_halt(void)
+{
+   machine_ops.halt();
+}
Index: linux/include/asm-i386/reboot.h
===
--- /dev/null
+++ linux/include/asm-i386/reboot.h
@@ -0,0 +1,20 @@
+#ifndef _ASM_REBOOT_H
+#define _ASM_REBOOT_H
+
+struct pt_regs;
+
+struct machine_ops
+{
+   void (*restart)(char *cmd);
+   void (*halt)(void);
+   void (*power_off)(void);
+   void (*shutdown)(void);
+   void (*crash_shutdown)(struct pt_regs *);
+   void (*emergency_restart)(void);
+};
+
+extern struct machine_ops machine_ops;
+
+void machine_real_restart(unsigned char *code, int length);
+
+#endif /* _ASM_REBOOT_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/

[PATCH] [11/26] i386: clean up identify_cpu

[Andi Kleen]

From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
identify_cpu() is used to identify both the boot CPU and secondary
CPUs, but it performs some actions which only apply to the boot CPU.
Those functions are therefore really __init functions, but because
they're called by identify_cpu(), they must be marked __cpuinit.

This patch splits identify_cpu() into identify_boot_cpu() and
identify_secondary_cpu(), and calls the appropriate init functions
from each.  Also, identify_boot_cpu() and all the functions it
dominates are marked __init.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 arch/i386/kernel/cpu/common.c |   21 ++---
 arch/i386/kernel/smpboot.c|2 +-
 arch/i386/kernel/sysenter.c   |2 +-
 include/asm-i386/processor.h  |3 ++-
 4 files changed, 18 insertions(+), 10 deletions(-)

===
Index: linux/arch/i386/kernel/cpu/common.c
===
--- linux.orig/arch/i386/kernel/cpu/common.c
+++ linux/arch/i386/kernel/cpu/common.c
@@ -394,7 +394,7 @@ __setup("serialnumber", x86_serial_nr_se
 /*
  * This does the hard work of actually picking apart the CPU stuff...
  */
-void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
+static void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
 {
int i;
 
@@ -505,15 +505,22 @@ void __cpuinit identify_cpu(struct cpuin
 
/* Init Machine Check Exception if available. */
mcheck_init(c);
+}
 
-   if (c == &boot_cpu_data)
-   sysenter_setup();
+void __init identify_boot_cpu(void)
+{
+   identify_cpu(&boot_cpu_data);
+   sysenter_setup();
enable_sep_cpu();
+   mtrr_bp_init();
+}
 
-   if (c == &boot_cpu_data)
-   mtrr_bp_init();
-   else
-   mtrr_ap_init();
+void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c)
+{
+   BUG_ON(c == &boot_cpu_data);
+   identify_cpu(c);
+   enable_sep_cpu();
+   mtrr_ap_init();
 }
 
 #ifdef CONFIG_X86_HT
Index: linux/arch/i386/kernel/smpboot.c
===
--- linux.orig/arch/i386/kernel/smpboot.c
+++ linux/arch/i386/kernel/smpboot.c
@@ -155,7 +155,7 @@ static void __cpuinit smp_store_cpu_info
 
*c = boot_cpu_data;
if (id!=0)
-   identify_cpu(c);
+   identify_secondary_cpu(c);
/*
 * Mask B, Pentium, but not Pentium MMX
 */
Index: linux/arch/i386/kernel/sysenter.c
===
--- linux.orig/arch/i386/kernel/sysenter.c
+++ linux/arch/i386/kernel/sysenter.c
@@ -72,7 +72,7 @@ extern const char vsyscall_int80_start, 
 extern const char vsyscall_sysenter_start, vsyscall_sysenter_end;
 static struct page *syscall_pages[1];
 
-int __cpuinit sysenter_setup(void)
+int __init sysenter_setup(void)
 {
void *syscall_page = (void *)get_zeroed_page(GFP_ATOMIC);
syscall_pages[0] = virt_to_page(syscall_page);
Index: linux/include/asm-i386/processor.h
===
--- linux.orig/include/asm-i386/processor.h
+++ linux/include/asm-i386/processor.h
@@ -116,7 +116,8 @@ extern char ignore_fpu_irq;
 
 void __init cpu_detect(struct cpuinfo_x86 *c);
 
-extern void identify_cpu(struct cpuinfo_x86 *);
+extern void identify_boot_cpu(void);
+extern void identify_secondary_cpu(struct cpuinfo_x86 *);
 extern void print_cpu_info(struct cpuinfo_x86 *);
 extern unsigned int init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern unsigned short num_cache_leaves;
-
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] [14/26] x86_64: Clean up asm-x86_64/bugs.h

[Andi Kleen]

From: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Most of asm-x86_64/bugs.h is code which should be in a C file, so put it there.

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Linus Torvalds <[EMAIL PROTECTED]>

---
 arch/x86_64/kernel/Makefile  |3 ++-
 arch/x86_64/kernel/bugs.c|   28 
 include/asm-x86_64/alternative.h |1 +
 include/asm-x86_64/bugs.h|   30 --
 4 files changed, 35 insertions(+), 27 deletions(-)

===
Index: linux/arch/x86_64/kernel/Makefile
===
--- linux.orig/arch/x86_64/kernel/Makefile
+++ linux/arch/x86_64/kernel/Makefile
@@ -8,7 +8,8 @@ obj-y   := process.o signal.o entry.o trap
ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_x86_64.o \
x8664_ksyms.o i387.o syscall.o vsyscall.o \
setup64.o bootflag.o e820.o reboot.o quirks.o i8237.o \
-   pci-dma.o pci-nommu.o alternative.o hpet.o tsc.o sched-clock.o
+   pci-dma.o pci-nommu.o alternative.o hpet.o tsc.o sched-clock.o \
+   bugs.o
 
 obj-$(CONFIG_STACKTRACE)   += stacktrace.o
 obj-$(CONFIG_X86_MCE)  += mce.o therm_throt.o
Index: linux/arch/x86_64/kernel/bugs.c
===
--- /dev/null
+++ linux/arch/x86_64/kernel/bugs.c
@@ -0,0 +1,28 @@
+/*
+ *  arch/x86_64/kernel/bugs.c
+ *
+ *  Copyright (C) 1994  Linus Torvalds
+ *  Copyright (C) 2000  SuSE
+ *
+ * This is included by init/main.c to check for architecture-dependent bugs.
+ *
+ * Needs:
+ * void check_bugs(void);
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void __init check_bugs(void)
+{
+   identify_cpu(&boot_cpu_data);
+#if !defined(CONFIG_SMP)
+   printk("CPU: ");
+   print_cpu_info(&boot_cpu_data);
+#endif
+   alternative_instructions();
+}
Index: linux/include/asm-x86_64/alternative.h
===
--- linux.orig/include/asm-x86_64/alternative.h
+++ linux/include/asm-x86_64/alternative.h
@@ -16,6 +16,7 @@ struct alt_instr {
u8  pad[5];
 };
 
+extern void alternative_instructions(void);
 extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
 
 struct module;
Index: linux/include/asm-x86_64/bugs.h
===
--- linux.orig/include/asm-x86_64/bugs.h
+++ linux/include/asm-x86_64/bugs.h
@@ -1,28 +1,6 @@
-/*
- *  include/asm-x86_64/bugs.h
- *
- *  Copyright (C) 1994  Linus Torvalds
- *  Copyright (C) 2000  SuSE
- *
- * This is included by init/main.c to check for architecture-dependent bugs.
- *
- * Needs:
- * void check_bugs(void);
- */
+#ifndef _ASM_X86_64_BUGS_H
+#define _ASM_X86_64_BUGS_H
 
-#include 
-#include 
-#include 
-#include 
+void check_bugs(void);
 
-extern void alternative_instructions(void);
-
-static void __init check_bugs(void)
-{
-   identify_cpu(&boot_cpu_data);
-#if !defined(CONFIG_SMP)
-   printk("CPU: ");
-   print_cpu_info(&boot_cpu_data);
-#endif
-   alternative_instructions(); 
-}
+#endif /* _ASM_X86_64_BUGS_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/

[PATCH] [21/26] x86: Clean up x86 control register and MSR macros (corrected)

[Andi Kleen]

From: "H. Peter Anvin" <[EMAIL PROTECTED]>
This patch is based on Rusty's recent cleanup of the EFLAGS-related
macros; it extends the same kind of cleanup to control registers and
MSRs.

It also unifies these between i386 and x86-64; at least with regards
to MSRs, the two had definitely gotten out of sync.

Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 include/asm-i386/Kbuild  |2 
 include/asm-i386/msr-index.h |  273 ++
 include/asm-i386/msr.h   |  237 --
 include/asm-i386/processor-flags.h   |   65 
 include/asm-i386/processor.h |   35 
 include/asm-x86_64/Kbuild|3 
 include/asm-x86_64/msr-index.h   |1 
 include/asm-x86_64/msr.h |  274 ---
 include/asm-x86_64/processor-flags.h |   27 ---
 include/asm-x86_64/processor.h   |   31 ---
 10 files changed, 356 insertions(+), 592 deletions(-)

Index: linux/include/asm-i386/Kbuild
===
--- linux.orig/include/asm-i386/Kbuild
+++ linux/include/asm-i386/Kbuild
@@ -3,8 +3,10 @@ include include/asm-generic/Kbuild.asm
 header-y += boot.h
 header-y += debugreg.h
 header-y += ldt.h
+header-y += msr-index.h
 header-y += ptrace-abi.h
 header-y += ucontext.h
 
+unifdef-y += msr.h
 unifdef-y += mtrr.h
 unifdef-y += vm86.h
Index: linux/include/asm-i386/msr-index.h
===
--- /dev/null
+++ linux/include/asm-i386/msr-index.h
@@ -0,0 +1,273 @@
+#ifndef __ASM_MSR_INDEX_H
+#define __ASM_MSR_INDEX_H
+
+/* CPU model specific register (MSR) numbers */
+
+/* x86-64 specific MSRs */
+#define MSR_EFER   0xc080 /* extended feature register */
+#define MSR_STAR   0xc081 /* legacy mode SYSCALL target */
+#define MSR_LSTAR  0xc082 /* long mode SYSCALL target */
+#define MSR_CSTAR  0xc083 /* compat mode SYSCALL target */
+#define MSR_SYSCALL_MASK   0xc084 /* EFLAGS mask for syscall */
+#define MSR_FS_BASE0xc100 /* 64bit FS base */
+#define MSR_GS_BASE0xc101 /* 64bit GS base */
+#define MSR_KERNEL_GS_BASE 0xc102 /* SwapGS GS shadow */
+
+/* EFER bits: */
+#define _EFER_SCE  0  /* SYSCALL/SYSRET */
+#define _EFER_LME  8  /* Long mode enable */
+#define _EFER_LMA  10 /* Long mode active (read-only) */
+#define _EFER_NX   11 /* No execute enable */
+
+#define EFER_SCE   (1<<_EFER_SCE)
+#define EFER_LME   (1<<_EFER_LME)
+#define EFER_LMA   (1<<_EFER_LMA)
+#define EFER_NX(1<<_EFER_NX)
+
+/* Intel MSRs. Some also available on other CPUs */
+#define MSR_IA32_PERFCTR0  0x00c1
+#define MSR_IA32_PERFCTR1  0x00c2
+#define MSR_FSB_FREQ   0x00cd
+
+#define MSR_MTRRcap0x00fe
+#define MSR_IA32_BBL_CR_CTL0x0119
+
+#define MSR_IA32_SYSENTER_CS   0x0174
+#define MSR_IA32_SYSENTER_ESP  0x0175
+#define MSR_IA32_SYSENTER_EIP  0x0176
+
+#define MSR_IA32_MCG_CAP   0x0179
+#define MSR_IA32_MCG_STATUS0x017a
+#define MSR_IA32_MCG_CTL   0x017b
+
+#define MSR_IA32_PEBS_ENABLE   0x03f1
+#define MSR_IA32_DS_AREA   0x0600
+#define MSR_IA32_PERF_CAPABILITIES 0x0345
+
+#define MSR_MTRRfix64K_0   0x0250
+#define MSR_MTRRfix16K_8   0x0258
+#define MSR_MTRRfix16K_A   0x0259
+#define MSR_MTRRfix4K_C0x0268
+#define MSR_MTRRfix4K_C80000x0269
+#define MSR_MTRRfix4K_D0x026a
+#define MSR_MTRRfix4K_D80000x026b
+#define MSR_MTRRfix4K_E0x026c
+#define MSR_MTRRfix4K_E80000x026d
+#define MSR_MTRRfix4K_F0x026e
+#define MSR_MTRRfix4K_F80000x026f
+#define MSR_MTRRdefType0x02ff
+
+#define MSR_IA32_DEBUGCTLMSR   0x01d9
+#define MSR_IA32_LASTBRANCHFROMIP  0x01db
+#define MSR_IA32_LASTBRANCHTOIP0x01dc
+#define MSR_IA32_LASTINTFROMIP 0x01dd
+#define MSR_IA32_LASTINTTOIP   0x01de
+
+#define MSR_IA32_MC0_CTL   0x0400
+#define MSR_IA32_MC0_STATUS0x0401
+#define MSR_IA32_MC0_ADDR  0x0402
+#define MSR_IA32_MC0_MISC  0x0403
+
+#define MSR_P6_PERFCTR00x00c1
+#define MSR_P6_PERFCTR10x00c2
+#define MSR_P6_EVNTSEL00x0186
+#define MSR_P6_EVNTSEL10x0187
+
+/* K7/K8 MSRs. Not complete. See the architecture manual for a mor

[PATCH] [9/26] x86_64: Fix vmalloc_32 to really allocate <4GB on 64bit platforms

[Andi Kleen]

Ugly ifdef, but should handle all 64bit platforms that have suitable
zones. On some like Altix it's probably impossible without IOMMU
use to get memory <4GB this way,  but they have to live with that.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>

---
 mm/vmalloc.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

Index: linux/mm/vmalloc.c
===
--- linux.orig/mm/vmalloc.c
+++ linux/mm/vmalloc.c
@@ -577,6 +577,14 @@ void *vmalloc_exec(unsigned long size)
return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL_EXEC);
 }
 
+#if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
+#define GFP_VMALLOC32 GFP_DMA32
+#elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
+#define GFP_VMALLOC32 GFP_DMA
+#else
+#define GFP_VMALLOC32 GFP_KERNEL
+#endif
+
 /**
  * vmalloc_32  -  allocate virtually contiguous memory (32bit addressable)
  * @size:  allocation size
@@ -586,7 +594,7 @@ void *vmalloc_exec(unsigned long size)
  */
 void *vmalloc_32(unsigned long size)
 {
-   return __vmalloc(size, GFP_KERNEL, PAGE_KERNEL);
+   return __vmalloc(size, GFP_VMALLOC32, PAGE_KERNEL);
 }
 EXPORT_SYMBOL(vmalloc_32);
 
@@ -602,7 +610,7 @@ void *vmalloc_32_user(unsigned long size
struct vm_struct *area;
void *ret;
 
-   ret = __vmalloc(size, GFP_KERNEL | __GFP_ZERO, PAGE_KERNEL);
+   ret = __vmalloc(size, GFP_VMALLOC32 | __GFP_ZERO, PAGE_KERNEL);
if (ret) {
write_lock(&vmlist_lock);
area = __find_vm_area(ret);
-
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/