Re: linux 3.9-rc1: nouveau crash on PPC
Hi,
On Sat, Mar 09, 2013 at 08:44:31PM +0200, Aaro Koskinen wrote:
> There's nouveau crash during boot with 3.9-rc1 on iMac G5 (nVidia GeForce
> FX 5200 Ultra). This happens also with current mainline kernel HEAD
> (0aefda3e8188ad71168bd32152d41b3d72f04087).
>
> git bisect tells the first bad commit is
> 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b (drm/nouveau/disp: port vblank
> handling to event interface).
>
> The crash is (manually copied from screen):
>
> [...]
>
> Unable to handle kernel paging request for data at address 0x1
>
> call trace:
> nouveau_event_trigger
The cause is event handling linked lists getting corrupted.
I'm not sure how that code is intented to work, but with the below HACK
I can at least boot the iMac without crashing, and get a working display:
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 6d01e0f..ab8d6c7 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -29,7 +29,7 @@ nouveau_event_put_locked(struct nouveau_event *event, int
index,
{
if (!--event->index[index].refs)
event->disable(event, index);
- list_del(>head);
+ list_del(>heads[index]);
}
void
@@ -39,7 +39,7 @@ nouveau_event_put(struct nouveau_event *event, int index,
unsigned long flags;
spin_lock_irqsave(>lock, flags);
- if (index < event->index_nr)
+ if (index < ARRAY_SIZE(handler->heads) && index < event->index_nr)
nouveau_event_put_locked(event, index, handler);
spin_unlock_irqrestore(>lock, flags);
}
@@ -51,8 +51,8 @@ nouveau_event_get(struct nouveau_event *event, int index,
unsigned long flags;
spin_lock_irqsave(>lock, flags);
- if (index < event->index_nr) {
- list_add(>head, >index[index].list);
+ if (index < ARRAY_SIZE(handler->heads) && index < event->index_nr) {
+ list_add(>heads[index], >index[index].list);
if (!event->index[index].refs++)
event->enable(event, index);
}
@@ -69,7 +69,7 @@ nouveau_event_trigger(struct nouveau_event *event, int index)
return;
spin_lock_irqsave(>lock, flags);
- list_for_each_entry_safe(handler, temp, >index[index].list,
head) {
+ list_for_each_entry_safe(handler, temp, >index[index].list,
heads[index]) {
if (handler->func(handler, index) == NVKM_EVENT_DROP) {
nouveau_event_put_locked(event, index, handler);
}
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index 9e09440..ba52172 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -6,7 +6,7 @@
#define NVKM_EVENT_KEEP 1
struct nouveau_eventh {
- struct list_head head;
+ struct list_head heads[2];
int (*func)(struct nouveau_eventh *, int index);
};
A.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux 3.9-rc1: nouveau crash on PPC
Hi,
On Sat, Mar 09, 2013 at 08:44:31PM +0200, Aaro Koskinen wrote:
There's nouveau crash during boot with 3.9-rc1 on iMac G5 (nVidia GeForce
FX 5200 Ultra). This happens also with current mainline kernel HEAD
(0aefda3e8188ad71168bd32152d41b3d72f04087).
git bisect tells the first bad commit is
1d7c71a3e2f77336df536855b0efd2dc5bdeb41b (drm/nouveau/disp: port vblank
handling to event interface).
The crash is (manually copied from screen):
[...]
Unable to handle kernel paging request for data at address 0x1
call trace:
nouveau_event_trigger
The cause is event handling linked lists getting corrupted.
I'm not sure how that code is intented to work, but with the below HACK
I can at least boot the iMac without crashing, and get a working display:
diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
b/drivers/gpu/drm/nouveau/core/core/event.c
index 6d01e0f..ab8d6c7 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -29,7 +29,7 @@ nouveau_event_put_locked(struct nouveau_event *event, int
index,
{
if (!--event-index[index].refs)
event-disable(event, index);
- list_del(handler-head);
+ list_del(handler-heads[index]);
}
void
@@ -39,7 +39,7 @@ nouveau_event_put(struct nouveau_event *event, int index,
unsigned long flags;
spin_lock_irqsave(event-lock, flags);
- if (index event-index_nr)
+ if (index ARRAY_SIZE(handler-heads) index event-index_nr)
nouveau_event_put_locked(event, index, handler);
spin_unlock_irqrestore(event-lock, flags);
}
@@ -51,8 +51,8 @@ nouveau_event_get(struct nouveau_event *event, int index,
unsigned long flags;
spin_lock_irqsave(event-lock, flags);
- if (index event-index_nr) {
- list_add(handler-head, event-index[index].list);
+ if (index ARRAY_SIZE(handler-heads) index event-index_nr) {
+ list_add(handler-heads[index], event-index[index].list);
if (!event-index[index].refs++)
event-enable(event, index);
}
@@ -69,7 +69,7 @@ nouveau_event_trigger(struct nouveau_event *event, int index)
return;
spin_lock_irqsave(event-lock, flags);
- list_for_each_entry_safe(handler, temp, event-index[index].list,
head) {
+ list_for_each_entry_safe(handler, temp, event-index[index].list,
heads[index]) {
if (handler-func(handler, index) == NVKM_EVENT_DROP) {
nouveau_event_put_locked(event, index, handler);
}
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index 9e09440..ba52172 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -6,7 +6,7 @@
#define NVKM_EVENT_KEEP 1
struct nouveau_eventh {
- struct list_head head;
+ struct list_head heads[2];
int (*func)(struct nouveau_eventh *, int index);
};
A.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 2:48 PM, H. Peter Anvin wrote: > On 03/06/2013 02:44 PM, Yinghai Lu wrote: >> >> ok, let's stay with 2M. >> > > I still want an explanation of the logic here. What is the purpose of > this? Keeping the kernel page tables in large page mappable space? yes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 02:44 PM, Yinghai Lu wrote: > > ok, let's stay with 2M. > I still want an explanation of the logic here. What is the purpose of this? Keeping the kernel page tables in large page mappable space? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 02:46 PM, Yinghai Lu wrote: > On Wed, Mar 6, 2013 at 2:28 PM, H. Peter Anvin wrote: >> >>> Current what is minimum ram is required for boot x86 32bit kernel? 8M? >> >> I have heard of a 6M boot, I believe. > > good. > > How about 64bit kernel? 64M? > Same ballpark. There isn't really an inherent reason a 64-bit kernel needs more space. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 2:28 PM, H. Peter Anvin wrote: > >> Current what is minimum ram is required for boot x86 32bit kernel? 8M? > > I have heard of a 6M boot, I believe. good. How about 64bit kernel? 64M? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 2:27 PM, H. Peter Anvin wrote: > On 03/06/2013 02:04 PM, Henrik Rydberg wrote: >>> >>> Sigh. This is why "keep the page tables together" is fundamentally the >>> wrong strategy. >>> >>> 8M means that we won't even be able to boot on machines with less than >>> 16M or so of RAM... I'm not sure if anyone still cares, but that is a >>> pretty aggressive heuristic. >> >> Maybe this should be a config option, given the ad-hoc nature of the >> chosen value? Anyway, the patch works. >> > > Can we make a sensible argument for what the value *needs* to be? 2M at > least makes a modicum of sense. Either way, it's clear we still have > plenty of cleaning up to do... ok, let's stay with 2M. Please check attached v1 with updated commit log. Thanks Yinghai fix_real_end_v1.patch Description: Binary data
Re: Linux 3.9-rc1
On 03/06/2013 02:14 PM, Yinghai Lu wrote: > > Henrik's system has 5M holes, so i picked 8M. > Wait... this number is related to the amount of holes? That really doesn't make any sense. Seriously... what is the logic behind this parameter? > Current what is minimum ram is required for boot x86 32bit kernel? 8M? I have heard of a 6M boot, I believe. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 02:04 PM, Henrik Rydberg wrote: >> >> Sigh. This is why "keep the page tables together" is fundamentally the >> wrong strategy. >> >> 8M means that we won't even be able to boot on machines with less than >> 16M or so of RAM... I'm not sure if anyone still cares, but that is a >> pretty aggressive heuristic. > > Maybe this should be a config option, given the ad-hoc nature of the > chosen value? Anyway, the patch works. > Can we make a sensible argument for what the value *needs* to be? 2M at least makes a modicum of sense. Either way, it's clear we still have plenty of cleaning up to do... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 2:14 PM, Yinghai Lu wrote: > On Wed, Mar 6, 2013 at 1:49 PM, H. Peter Anvin wrote: >> On 03/06/2013 01:33 PM, Yinghai Lu wrote: >>> On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin >>> wrote: >>> Excellent. Yinghai, can you write up the patch with a proper description and I'll put it into x86/urgent. >>> >>> I made it more robust: make sure real_end have 8M below it. >>> Please check attached one. >>> >> >> Sigh. This is why "keep the page tables together" is fundamentally the >> wrong strategy. >> >> 8M means that we won't even be able to boot on machines with less than >> 16M or so of RAM... I'm not sure if anyone still cares, but that is a >> pretty aggressive heuristic. > > Henrik's system has 5M holes, so i picked 8M. > > Current what is minimum ram is required for boot x86 32bit kernel? 8M? just check the code again, it should be ok. we can not find the 8M, real_end will set to 8M anyway. as the memblock_find_in_range will return 0. then will map [0, 8M] at first, then will map [8M, whatever). Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 1:49 PM, H. Peter Anvin wrote: > On 03/06/2013 01:33 PM, Yinghai Lu wrote: >> On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin wrote: >> >>> Excellent. Yinghai, can you write up the patch with a proper >>> description and I'll put it into x86/urgent. >> >> I made it more robust: make sure real_end have 8M below it. >> Please check attached one. >> > > Sigh. This is why "keep the page tables together" is fundamentally the > wrong strategy. > > 8M means that we won't even be able to boot on machines with less than > 16M or so of RAM... I'm not sure if anyone still cares, but that is a > pretty aggressive heuristic. Henrik's system has 5M holes, so i picked 8M. Current what is minimum ram is required for boot x86 32bit kernel? 8M? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 06, 2013 at 01:49:15PM -0800, H. Peter Anvin wrote: > On 03/06/2013 01:33 PM, Yinghai Lu wrote: > > On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin > > wrote: > > > >> Excellent. Yinghai, can you write up the patch with a proper > >> description and I'll put it into x86/urgent. > > > > I made it more robust: make sure real_end have 8M below it. > > Please check attached one. > > > > Sigh. This is why "keep the page tables together" is fundamentally the > wrong strategy. > > 8M means that we won't even be able to boot on machines with less than > 16M or so of RAM... I'm not sure if anyone still cares, but that is a > pretty aggressive heuristic. Maybe this should be a config option, given the ad-hoc nature of the chosen value? Anyway, the patch works. Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 01:33 PM, Yinghai Lu wrote: > On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin wrote: > >> Excellent. Yinghai, can you write up the patch with a proper >> description and I'll put it into x86/urgent. > > I made it more robust: make sure real_end have 8M below it. > Please check attached one. > Sigh. This is why "keep the page tables together" is fundamentally the wrong strategy. 8M means that we won't even be able to boot on machines with less than 16M or so of RAM... I'm not sure if anyone still cares, but that is a pretty aggressive heuristic. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin wrote: > Excellent. Yinghai, can you write up the patch with a proper > description and I'll put it into x86/urgent. I made it more robust: make sure real_end have 8M below it. Please check attached one. Thanks Yinghai fix_real_end_v2.patch Description: Binary data
Re: Linux 3.9-rc1
On Wed, Mar 06, 2013 at 08:08:34AM -0800, Linus Torvalds wrote: > On Wed, Mar 6, 2013 at 12:06 AM, Henrik Rydberg wrote: > > > > Or not. ;-) This commit breaks boot on my MacBookAir3,1: > > > > commit 8d57470d8f859635deffe3919d7d4867b488b85a > > Author: Yinghai Lu > > Date: Fri Nov 16 19:38:58 2012 -0800 > > > > x86, mm: setup page table in top-down > > Argh. The whole page table setup crud is scarily fragile. > > > Being a 64-bit apple-EFI machine, it probably runs through an obscure > > path in this patch. I wish I had more vital information, but I get the > > white screen of death, so not much to go on so far. > > I actually test on my MBA (also EFI boot), but it's a slightly newer > 4,1 version, and the memory map looks very different (I've got 251 > memory regions reported by efi, ugh). > > So Apple EFI does work at least in some cases, just not yours. Let's > hope Yinghai can figure this one out.. And so he did, thanks! FWIW, I also hit the ACPI problem. I have not seen it often enough to register anything. Cheers, Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 12:45 PM, Henrik Rydberg wrote: > > Bingo. Excellent, thank you Yinghai. I verified that it also boots on > top of Linus' tree, so you may add > > Tested-by: Henrik Rydberg > > to the final result. > Excellent. Yinghai, can you write up the patch with a proper description and I'll put it into x86/urgent. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
> >> >> Can you check bootloader like grub.efi ? > >> > > >> > I checked, same story. I tried without EFI_STUB, no joy. I ran with > >> > and without nouveau, just in case. Without the patch, everything > >> > works. With the patch, nothing works, and no output at all. > >> > > >> > With a bit of luck, I could maybe get the first lines of output using > >> > grub.efi, but frankly I cannot remember if that ever worked on this > >> > machine. > > Found one bug about real_end calculating, it should be PMD_SIZE align. > Otherwise in extreme case we could have less then 2M for the first step. > In your case is about only (1M - 32k) for first step. > > Please try attached patch. Bingo. Excellent, thank you Yinghai. I verified that it also boots on top of Linus' tree, so you may add Tested-by: Henrik Rydberg to the final result. Cheers, Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 11:54 AM, Henrik Rydberg wrote: >> >> Can you check bootloader like grub.efi ? >> > >> > I checked, same story. I tried without EFI_STUB, no joy. I ran with >> > and without nouveau, just in case. Without the patch, everything >> > works. With the patch, nothing works, and no output at all. >> > >> > With a bit of luck, I could maybe get the first lines of output using >> > grub.efi, but frankly I cannot remember if that ever worked on this >> > machine. Found one bug about real_end calculating, it should be PMD_SIZE align. Otherwise in extreme case we could have less then 2M for the first step. In your case is about only (1M - 32k) for first step. Please try attached patch. Thanks Yinghai fix_real_end.patch Description: Binary data
Re: Linux 3.9-rc1
> >> Can you check bootloader like grub.efi ? > > > > I checked, same story. I tried without EFI_STUB, no joy. I ran with > > and without nouveau, just in case. Without the patch, everything > > works. With the patch, nothing works, and no output at all. > > > > With a bit of luck, I could maybe get the first lines of output using > > grub.efi, but frankly I cannot remember if that ever worked on this > > machine. > > > > A simpler one is efilinux: > > https://github.com/mfleming/efilinux Sadly, that one does not seem to boot at all on this machine (picked it up in arch linux, so obvisouly it works for someone). I have started applying portions of the patch to see what happens. Adding early_alloc_pgt_buf() in setup_arch() seems to work, which limits the problem to the actual init function. Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 11:36 AM, Henrik Rydberg wrote: > Hi Yinghai, > Can you get a boot log with "debug memblock=debug" from the last successful commit point? Are you booting EFI or BootCamp? >>> >>> Attached the dmesg log, booting from f763ad1 which is on top of >>> 3.7-rc6. I am booting with EFI_STUB, straight into the kernel. >>> The command line and modules are built in. >> >> will check that EFI_STUB path. >> >> Can you check bootloader like grub.efi ? > > I checked, same story. I tried without EFI_STUB, no joy. I ran with > and without nouveau, just in case. Without the patch, everything > works. With the patch, nothing works, and no output at all. > > With a bit of luck, I could maybe get the first lines of output using > grub.efi, but frankly I cannot remember if that ever worked on this > machine. > A simpler one is efilinux: https://github.com/mfleming/efilinux -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
Hi Yinghai, > >> Can you get a boot log with "debug memblock=debug" from the last > >> successful commit point? Are you booting EFI or BootCamp? > > > > Attached the dmesg log, booting from f763ad1 which is on top of > > 3.7-rc6. I am booting with EFI_STUB, straight into the kernel. > > The command line and modules are built in. > > will check that EFI_STUB path. > > Can you check bootloader like grub.efi ? I checked, same story. I tried without EFI_STUB, no joy. I ran with and without nouveau, just in case. Without the patch, everything works. With the patch, nothing works, and no output at all. With a bit of luck, I could maybe get the first lines of output using grub.efi, but frankly I cannot remember if that ever worked on this machine. Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 2:07 AM, Henrik Rydberg wrote: >> Can you get a boot log with "debug memblock=debug" from the last >> successful commit point? Are you booting EFI or BootCamp? > > Attached the dmesg log, booting from f763ad1 which is on top of > 3.7-rc6. I am booting with EFI_STUB, straight into the kernel. > The command line and modules are built in. will check that EFI_STUB path. Can you check bootloader like grub.efi ? > [0.00] Initializing cgroup subsys cpu > [0.00] Linux version 3.7.0-rc6+ (rydberg@polaris) (gcc version 4.7.2 > (GCC) ) #1 SMP PREEMPT Wed Mar 6 10:52:49 CET 2013 > [0.00] Command line: > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0008efff] usable > [0.00] BIOS-e820: [mem 0x0008f000-0x0008] ACPI NVS > [0.00] BIOS-e820: [mem 0x0009-0x0009] usable > [0.00] BIOS-e820: [mem 0x0010-0x6eff] usable > [0.00] BIOS-e820: [mem 0x6f00-0x7eff] reserved > [0.00] BIOS-e820: [mem 0x7f00-0x7f718fff] usable > [0.00] BIOS-e820: [mem 0x7f719000-0x7f938fff] ACPI NVS > [0.00] BIOS-e820: [mem 0x7f939000-0x7f953fff] usable > [0.00] BIOS-e820: [mem 0x7f954000-0x7f96afff] ACPI > data > [0.00] BIOS-e820: [mem 0x7f96b000-0x7f96efff] usable > [0.00] BIOS-e820: [mem 0x7f96f000-0x7f99afff] reserved > [0.00] BIOS-e820: [mem 0x7f99b000-0x7f9b1fff] usable > [0.00] BIOS-e820: [mem 0x7f9b2000-0x7f9dafff] reserved > [0.00] BIOS-e820: [mem 0x7f9db000-0x7fef8fff] usable > [0.00] BIOS-e820: [mem 0x7fef9000-0x7fef] reserved > [0.00] BIOS-e820: [mem 0x9320-0x93200fff] reserved > [0.00] BIOS-e820: [mem 0xffc0-0x] reserved > [0.00] NX (Execute Disable) protection: active > [0.00] efi: EFI v1.10 by Apple > [0.00] efi: ACPI=0x7f96a000 ACPI 2.0=0x7f96a014 SMBIOS=0x7f71a000 > [0.00] efi: mem00: type=7, attr=0xf, > range=[0x-0x0008f000) (0MB) > [0.00] efi: mem01: type=10, attr=0xf, > range=[0x0008f000-0x0009) (0MB) > [0.00] efi: mem02: type=2, attr=0xf, > range=[0x0009-0x00096000) (0MB) > [0.00] efi: mem03: type=7, attr=0xf, > range=[0x00096000-0x000a) (0MB) > [0.00] efi: mem04: type=7, attr=0xf, > range=[0x0010-0x0100) (15MB) > [0.00] efi: mem05: type=2, attr=0xf, > range=[0x0100-0x01db) (13MB) > [0.00] efi: mem06: type=7, attr=0xf, > range=[0x01db-0x6d0d6000) (1715MB) > [0.00] efi: mem07: type=1, attr=0xf, > range=[0x6d0d6000-0x6d546000) (4MB) > [0.00] efi: mem08: type=7, attr=0xf, > range=[0x6d546000-0x6d9b6000) (4MB) > [0.00] efi: mem09: type=4, attr=0xf, > range=[0x6d9b6000-0x6e615000) (12MB) > [0.00] efi: mem10: type=7, attr=0xf, > range=[0x6e615000-0x6e616000) (0MB) > [0.00] efi: mem11: type=4, attr=0xf, > range=[0x6e616000-0x6e7ac000) (1MB) > [0.00] efi: mem12: type=7, attr=0xf, > range=[0x6e7ac000-0x6ea6e000) (2MB) > [0.00] efi: mem13: type=2, attr=0xf, > range=[0x6ea6e000-0x6ea6f000) (0MB) > [0.00] efi: mem14: type=4, attr=0xf, > range=[0x6ea6f000-0x6f00) (5MB) > [0.00] efi: mem15: type=4, attr=0xf, > range=[0x7f00-0x7f6af000) (6MB) > [0.00] efi: mem16: type=7, attr=0xf, > range=[0x7f6af000-0x7f719000) (0MB) > [0.00] efi: mem17: type=10, attr=0xf, > range=[0x7f719000-0x7f939000) (2MB) > [0.00] efi: mem18: type=7, attr=0xf, > range=[0x7f939000-0x7f954000) (0MB) > [0.00] efi: mem19: type=9, attr=0xf, > range=[0x7f954000-0x7f96b000) (0MB) > [0.00] efi: mem20: type=7, attr=0xf, > range=[0x7f96b000-0x7f96f000) (0MB) > [0.00] efi: mem21: type=6, attr=0x800f, > range=[0x7f96f000-0x7f99b000) (0MB) > [0.00] efi: mem22: type=7, attr=0xf, > range=[0x7f99b000-0x7f9b2000) (0MB) > [0.00] efi: mem23: type=5, attr=0x800f, > range=[0x7f9b2000-0x7f9db000) (0MB) > [0.00] efi: mem24: type=7, attr=0xf, > range=[0x7f9db000-0x7fc2c000) (2MB) > [0.00] efi: mem25: type=3, attr=0xf, > range=[0x7fc2c000-0x7fd5f000) (1MB) > [0.00] efi: mem26: type=7, attr=0xf, >
Re: Linux 3.9-rc1
On 03/06/2013 08:08 AM, Linus Torvalds wrote: > On Wed, Mar 6, 2013 at 12:06 AM, Henrik Rydberg wrote: >> >> Or not. ;-) This commit breaks boot on my MacBookAir3,1: >> >> commit 8d57470d8f859635deffe3919d7d4867b488b85a >> Author: Yinghai Lu >> Date: Fri Nov 16 19:38:58 2012 -0800 >> >> x86, mm: setup page table in top-down > > Argh. The whole page table setup crud is scarily fragile. > Yes. The design of the new code should be much more robust by design, but of course all the corner cases got shifted around... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 12:06 AM, Henrik Rydberg wrote: > > Or not. ;-) This commit breaks boot on my MacBookAir3,1: > > commit 8d57470d8f859635deffe3919d7d4867b488b85a > Author: Yinghai Lu > Date: Fri Nov 16 19:38:58 2012 -0800 > > x86, mm: setup page table in top-down Argh. The whole page table setup crud is scarily fragile. > Being a 64-bit apple-EFI machine, it probably runs through an obscure > path in this patch. I wish I had more vital information, but I get the > white screen of death, so not much to go on so far. I actually test on my MBA (also EFI boot), but it's a slightly newer 4,1 version, and the memory map looks very different (I've got 251 memory regions reported by efi, ugh). So Apple EFI does work at least in some cases, just not yours. Let's hope Yinghai can figure this one out.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 12:06 AM, Henrik Rydberg wrote: > Hi Linus, Peter, > >> I don't know if it's just me, but this merge window had more "Uhhuh" >> moments than I'm used to. I stopped merging a couple of times, because >> we had bugs that looked really scary, but thankfully each time people >> were on them like paparazzi on Justin Bieber. Special thanks to Peter, >> Ted and Rafael (and the people who reported the bugs too!) for being >> so responsive. It could have been so much worse. > > Or not. ;-) This commit breaks boot on my MacBookAir3,1: > > commit 8d57470d8f859635deffe3919d7d4867b488b85a > Author: Yinghai Lu > Date: Fri Nov 16 19:38:58 2012 -0800 > > x86, mm: setup page table in top-down > > Get pgt_buf early from BRK, and use it to map PMD_SIZE from top at first. > Then use mapped pages to map more ranges below, and keep looping until > all pages get mapped. > > Being a 64-bit apple-EFI machine, it probably runs through an obscure > path in this patch. I wish I had more vital information, but I get the > white screen of death, so not much to go on so far. > Adding Yinghai. Can you get a boot log with "debug memblock=debug" from the last successful commit point? Are you booting EFI or BootCamp? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
Hi Linus, Peter, > I don't know if it's just me, but this merge window had more "Uhhuh" > moments than I'm used to. I stopped merging a couple of times, because > we had bugs that looked really scary, but thankfully each time people > were on them like paparazzi on Justin Bieber. Special thanks to Peter, > Ted and Rafael (and the people who reported the bugs too!) for being > so responsive. It could have been so much worse. Or not. ;-) This commit breaks boot on my MacBookAir3,1: commit 8d57470d8f859635deffe3919d7d4867b488b85a Author: Yinghai Lu Date: Fri Nov 16 19:38:58 2012 -0800 x86, mm: setup page table in top-down Get pgt_buf early from BRK, and use it to map PMD_SIZE from top at first. Then use mapped pages to map more ranges below, and keep looping until all pages get mapped. Being a 64-bit apple-EFI machine, it probably runs through an obscure path in this patch. I wish I had more vital information, but I get the white screen of death, so not much to go on so far. Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
Hi Linus, Peter, I don't know if it's just me, but this merge window had more Uhhuh moments than I'm used to. I stopped merging a couple of times, because we had bugs that looked really scary, but thankfully each time people were on them like paparazzi on Justin Bieber. Special thanks to Peter, Ted and Rafael (and the people who reported the bugs too!) for being so responsive. It could have been so much worse. Or not. ;-) This commit breaks boot on my MacBookAir3,1: commit 8d57470d8f859635deffe3919d7d4867b488b85a Author: Yinghai Lu ying...@kernel.org Date: Fri Nov 16 19:38:58 2012 -0800 x86, mm: setup page table in top-down Get pgt_buf early from BRK, and use it to map PMD_SIZE from top at first. Then use mapped pages to map more ranges below, and keep looping until all pages get mapped. Being a 64-bit apple-EFI machine, it probably runs through an obscure path in this patch. I wish I had more vital information, but I get the white screen of death, so not much to go on so far. Henrik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 12:06 AM, Henrik Rydberg wrote: Hi Linus, Peter, I don't know if it's just me, but this merge window had more Uhhuh moments than I'm used to. I stopped merging a couple of times, because we had bugs that looked really scary, but thankfully each time people were on them like paparazzi on Justin Bieber. Special thanks to Peter, Ted and Rafael (and the people who reported the bugs too!) for being so responsive. It could have been so much worse. Or not. ;-) This commit breaks boot on my MacBookAir3,1: commit 8d57470d8f859635deffe3919d7d4867b488b85a Author: Yinghai Lu ying...@kernel.org Date: Fri Nov 16 19:38:58 2012 -0800 x86, mm: setup page table in top-down Get pgt_buf early from BRK, and use it to map PMD_SIZE from top at first. Then use mapped pages to map more ranges below, and keep looping until all pages get mapped. Being a 64-bit apple-EFI machine, it probably runs through an obscure path in this patch. I wish I had more vital information, but I get the white screen of death, so not much to go on so far. Adding Yinghai. Can you get a boot log with debug memblock=debug from the last successful commit point? Are you booting EFI or BootCamp? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 12:06 AM, Henrik Rydberg rydb...@euromail.se wrote: Or not. ;-) This commit breaks boot on my MacBookAir3,1: commit 8d57470d8f859635deffe3919d7d4867b488b85a Author: Yinghai Lu ying...@kernel.org Date: Fri Nov 16 19:38:58 2012 -0800 x86, mm: setup page table in top-down Argh. The whole page table setup crud is scarily fragile. Being a 64-bit apple-EFI machine, it probably runs through an obscure path in this patch. I wish I had more vital information, but I get the white screen of death, so not much to go on so far. I actually test on my MBA (also EFI boot), but it's a slightly newer 4,1 version, and the memory map looks very different (I've got 251 memory regions reported by efi, ugh). So Apple EFI does work at least in some cases, just not yours. Let's hope Yinghai can figure this one out.. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 08:08 AM, Linus Torvalds wrote: On Wed, Mar 6, 2013 at 12:06 AM, Henrik Rydberg rydb...@euromail.se wrote: Or not. ;-) This commit breaks boot on my MacBookAir3,1: commit 8d57470d8f859635deffe3919d7d4867b488b85a Author: Yinghai Lu ying...@kernel.org Date: Fri Nov 16 19:38:58 2012 -0800 x86, mm: setup page table in top-down Argh. The whole page table setup crud is scarily fragile. Yes. The design of the new code should be much more robust by design, but of course all the corner cases got shifted around... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 2:07 AM, Henrik Rydberg rydb...@euromail.se wrote: Can you get a boot log with debug memblock=debug from the last successful commit point? Are you booting EFI or BootCamp? Attached the dmesg log, booting from f763ad1 which is on top of 3.7-rc6. I am booting with EFI_STUB, straight into the kernel. The command line and modules are built in. will check that EFI_STUB path. Can you check bootloader like grub.efi ? [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.7.0-rc6+ (rydberg@polaris) (gcc version 4.7.2 (GCC) ) #1 SMP PREEMPT Wed Mar 6 10:52:49 CET 2013 [0.00] Command line: [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0008efff] usable [0.00] BIOS-e820: [mem 0x0008f000-0x0008] ACPI NVS [0.00] BIOS-e820: [mem 0x0009-0x0009] usable [0.00] BIOS-e820: [mem 0x0010-0x6eff] usable [0.00] BIOS-e820: [mem 0x6f00-0x7eff] reserved [0.00] BIOS-e820: [mem 0x7f00-0x7f718fff] usable [0.00] BIOS-e820: [mem 0x7f719000-0x7f938fff] ACPI NVS [0.00] BIOS-e820: [mem 0x7f939000-0x7f953fff] usable [0.00] BIOS-e820: [mem 0x7f954000-0x7f96afff] ACPI data [0.00] BIOS-e820: [mem 0x7f96b000-0x7f96efff] usable [0.00] BIOS-e820: [mem 0x7f96f000-0x7f99afff] reserved [0.00] BIOS-e820: [mem 0x7f99b000-0x7f9b1fff] usable [0.00] BIOS-e820: [mem 0x7f9b2000-0x7f9dafff] reserved [0.00] BIOS-e820: [mem 0x7f9db000-0x7fef8fff] usable [0.00] BIOS-e820: [mem 0x7fef9000-0x7fef] reserved [0.00] BIOS-e820: [mem 0x9320-0x93200fff] reserved [0.00] BIOS-e820: [mem 0xffc0-0x] reserved [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v1.10 by Apple [0.00] efi: ACPI=0x7f96a000 ACPI 2.0=0x7f96a014 SMBIOS=0x7f71a000 [0.00] efi: mem00: type=7, attr=0xf, range=[0x-0x0008f000) (0MB) [0.00] efi: mem01: type=10, attr=0xf, range=[0x0008f000-0x0009) (0MB) [0.00] efi: mem02: type=2, attr=0xf, range=[0x0009-0x00096000) (0MB) [0.00] efi: mem03: type=7, attr=0xf, range=[0x00096000-0x000a) (0MB) [0.00] efi: mem04: type=7, attr=0xf, range=[0x0010-0x0100) (15MB) [0.00] efi: mem05: type=2, attr=0xf, range=[0x0100-0x01db) (13MB) [0.00] efi: mem06: type=7, attr=0xf, range=[0x01db-0x6d0d6000) (1715MB) [0.00] efi: mem07: type=1, attr=0xf, range=[0x6d0d6000-0x6d546000) (4MB) [0.00] efi: mem08: type=7, attr=0xf, range=[0x6d546000-0x6d9b6000) (4MB) [0.00] efi: mem09: type=4, attr=0xf, range=[0x6d9b6000-0x6e615000) (12MB) [0.00] efi: mem10: type=7, attr=0xf, range=[0x6e615000-0x6e616000) (0MB) [0.00] efi: mem11: type=4, attr=0xf, range=[0x6e616000-0x6e7ac000) (1MB) [0.00] efi: mem12: type=7, attr=0xf, range=[0x6e7ac000-0x6ea6e000) (2MB) [0.00] efi: mem13: type=2, attr=0xf, range=[0x6ea6e000-0x6ea6f000) (0MB) [0.00] efi: mem14: type=4, attr=0xf, range=[0x6ea6f000-0x6f00) (5MB) [0.00] efi: mem15: type=4, attr=0xf, range=[0x7f00-0x7f6af000) (6MB) [0.00] efi: mem16: type=7, attr=0xf, range=[0x7f6af000-0x7f719000) (0MB) [0.00] efi: mem17: type=10, attr=0xf, range=[0x7f719000-0x7f939000) (2MB) [0.00] efi: mem18: type=7, attr=0xf, range=[0x7f939000-0x7f954000) (0MB) [0.00] efi: mem19: type=9, attr=0xf, range=[0x7f954000-0x7f96b000) (0MB) [0.00] efi: mem20: type=7, attr=0xf, range=[0x7f96b000-0x7f96f000) (0MB) [0.00] efi: mem21: type=6, attr=0x800f, range=[0x7f96f000-0x7f99b000) (0MB) [0.00] efi: mem22: type=7, attr=0xf, range=[0x7f99b000-0x7f9b2000) (0MB) [0.00] efi: mem23: type=5, attr=0x800f, range=[0x7f9b2000-0x7f9db000) (0MB) [0.00] efi: mem24: type=7, attr=0xf, range=[0x7f9db000-0x7fc2c000) (2MB) [0.00] efi: mem25: type=3, attr=0xf, range=[0x7fc2c000-0x7fd5f000) (1MB) [0.00] efi: mem26: type=7, attr=0xf, range=[0x7fd5f000-0x7fef9000) (1MB) [0.00] efi: mem27:
Re: Linux 3.9-rc1
Hi Yinghai, Can you get a boot log with debug memblock=debug from the last successful commit point? Are you booting EFI or BootCamp? Attached the dmesg log, booting from f763ad1 which is on top of 3.7-rc6. I am booting with EFI_STUB, straight into the kernel. The command line and modules are built in. will check that EFI_STUB path. Can you check bootloader like grub.efi ? I checked, same story. I tried without EFI_STUB, no joy. I ran with and without nouveau, just in case. Without the patch, everything works. With the patch, nothing works, and no output at all. With a bit of luck, I could maybe get the first lines of output using grub.efi, but frankly I cannot remember if that ever worked on this machine. Henrik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 11:36 AM, Henrik Rydberg wrote: Hi Yinghai, Can you get a boot log with debug memblock=debug from the last successful commit point? Are you booting EFI or BootCamp? Attached the dmesg log, booting from f763ad1 which is on top of 3.7-rc6. I am booting with EFI_STUB, straight into the kernel. The command line and modules are built in. will check that EFI_STUB path. Can you check bootloader like grub.efi ? I checked, same story. I tried without EFI_STUB, no joy. I ran with and without nouveau, just in case. Without the patch, everything works. With the patch, nothing works, and no output at all. With a bit of luck, I could maybe get the first lines of output using grub.efi, but frankly I cannot remember if that ever worked on this machine. A simpler one is efilinux: https://github.com/mfleming/efilinux -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
Can you check bootloader like grub.efi ? I checked, same story. I tried without EFI_STUB, no joy. I ran with and without nouveau, just in case. Without the patch, everything works. With the patch, nothing works, and no output at all. With a bit of luck, I could maybe get the first lines of output using grub.efi, but frankly I cannot remember if that ever worked on this machine. A simpler one is efilinux: https://github.com/mfleming/efilinux Sadly, that one does not seem to boot at all on this machine (picked it up in arch linux, so obvisouly it works for someone). I have started applying portions of the patch to see what happens. Adding early_alloc_pgt_buf() in setup_arch() seems to work, which limits the problem to the actual init function. Henrik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 11:54 AM, Henrik Rydberg rydb...@euromail.se wrote: Can you check bootloader like grub.efi ? I checked, same story. I tried without EFI_STUB, no joy. I ran with and without nouveau, just in case. Without the patch, everything works. With the patch, nothing works, and no output at all. With a bit of luck, I could maybe get the first lines of output using grub.efi, but frankly I cannot remember if that ever worked on this machine. Found one bug about real_end calculating, it should be PMD_SIZE align. Otherwise in extreme case we could have less then 2M for the first step. In your case is about only (1M - 32k) for first step. Please try attached patch. Thanks Yinghai fix_real_end.patch Description: Binary data
Re: Linux 3.9-rc1
Can you check bootloader like grub.efi ? I checked, same story. I tried without EFI_STUB, no joy. I ran with and without nouveau, just in case. Without the patch, everything works. With the patch, nothing works, and no output at all. With a bit of luck, I could maybe get the first lines of output using grub.efi, but frankly I cannot remember if that ever worked on this machine. Found one bug about real_end calculating, it should be PMD_SIZE align. Otherwise in extreme case we could have less then 2M for the first step. In your case is about only (1M - 32k) for first step. Please try attached patch. Bingo. Excellent, thank you Yinghai. I verified that it also boots on top of Linus' tree, so you may add Tested-by: Henrik Rydberg rydb...@euromail.se to the final result. Cheers, Henrik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 12:45 PM, Henrik Rydberg wrote: Bingo. Excellent, thank you Yinghai. I verified that it also boots on top of Linus' tree, so you may add Tested-by: Henrik Rydberg rydb...@euromail.se to the final result. Excellent. Yinghai, can you write up the patch with a proper description and I'll put it into x86/urgent. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 06, 2013 at 08:08:34AM -0800, Linus Torvalds wrote: On Wed, Mar 6, 2013 at 12:06 AM, Henrik Rydberg rydb...@euromail.se wrote: Or not. ;-) This commit breaks boot on my MacBookAir3,1: commit 8d57470d8f859635deffe3919d7d4867b488b85a Author: Yinghai Lu ying...@kernel.org Date: Fri Nov 16 19:38:58 2012 -0800 x86, mm: setup page table in top-down Argh. The whole page table setup crud is scarily fragile. Being a 64-bit apple-EFI machine, it probably runs through an obscure path in this patch. I wish I had more vital information, but I get the white screen of death, so not much to go on so far. I actually test on my MBA (also EFI boot), but it's a slightly newer 4,1 version, and the memory map looks very different (I've got 251 memory regions reported by efi, ugh). So Apple EFI does work at least in some cases, just not yours. Let's hope Yinghai can figure this one out.. And so he did, thanks! FWIW, I also hit the ACPI problem. I have not seen it often enough to register anything. Cheers, Henrik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin h...@linux.intel.com wrote: Excellent. Yinghai, can you write up the patch with a proper description and I'll put it into x86/urgent. I made it more robust: make sure real_end have 8M below it. Please check attached one. Thanks Yinghai fix_real_end_v2.patch Description: Binary data
Re: Linux 3.9-rc1
On 03/06/2013 01:33 PM, Yinghai Lu wrote: On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin h...@linux.intel.com wrote: Excellent. Yinghai, can you write up the patch with a proper description and I'll put it into x86/urgent. I made it more robust: make sure real_end have 8M below it. Please check attached one. Sigh. This is why keep the page tables together is fundamentally the wrong strategy. 8M means that we won't even be able to boot on machines with less than 16M or so of RAM... I'm not sure if anyone still cares, but that is a pretty aggressive heuristic. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 06, 2013 at 01:49:15PM -0800, H. Peter Anvin wrote: On 03/06/2013 01:33 PM, Yinghai Lu wrote: On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin h...@linux.intel.com wrote: Excellent. Yinghai, can you write up the patch with a proper description and I'll put it into x86/urgent. I made it more robust: make sure real_end have 8M below it. Please check attached one. Sigh. This is why keep the page tables together is fundamentally the wrong strategy. 8M means that we won't even be able to boot on machines with less than 16M or so of RAM... I'm not sure if anyone still cares, but that is a pretty aggressive heuristic. Maybe this should be a config option, given the ad-hoc nature of the chosen value? Anyway, the patch works. Henrik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 1:49 PM, H. Peter Anvin h...@linux.intel.com wrote: On 03/06/2013 01:33 PM, Yinghai Lu wrote: On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin h...@linux.intel.com wrote: Excellent. Yinghai, can you write up the patch with a proper description and I'll put it into x86/urgent. I made it more robust: make sure real_end have 8M below it. Please check attached one. Sigh. This is why keep the page tables together is fundamentally the wrong strategy. 8M means that we won't even be able to boot on machines with less than 16M or so of RAM... I'm not sure if anyone still cares, but that is a pretty aggressive heuristic. Henrik's system has 5M holes, so i picked 8M. Current what is minimum ram is required for boot x86 32bit kernel? 8M? Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 2:14 PM, Yinghai Lu ying...@kernel.org wrote: On Wed, Mar 6, 2013 at 1:49 PM, H. Peter Anvin h...@linux.intel.com wrote: On 03/06/2013 01:33 PM, Yinghai Lu wrote: On Wed, Mar 6, 2013 at 12:58 PM, H. Peter Anvin h...@linux.intel.com wrote: Excellent. Yinghai, can you write up the patch with a proper description and I'll put it into x86/urgent. I made it more robust: make sure real_end have 8M below it. Please check attached one. Sigh. This is why keep the page tables together is fundamentally the wrong strategy. 8M means that we won't even be able to boot on machines with less than 16M or so of RAM... I'm not sure if anyone still cares, but that is a pretty aggressive heuristic. Henrik's system has 5M holes, so i picked 8M. Current what is minimum ram is required for boot x86 32bit kernel? 8M? just check the code again, it should be ok. we can not find the 8M, real_end will set to 8M anyway. as the memblock_find_in_range will return 0. then will map [0, 8M] at first, then will map [8M, whatever). Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 02:04 PM, Henrik Rydberg wrote: Sigh. This is why keep the page tables together is fundamentally the wrong strategy. 8M means that we won't even be able to boot on machines with less than 16M or so of RAM... I'm not sure if anyone still cares, but that is a pretty aggressive heuristic. Maybe this should be a config option, given the ad-hoc nature of the chosen value? Anyway, the patch works. Can we make a sensible argument for what the value *needs* to be? 2M at least makes a modicum of sense. Either way, it's clear we still have plenty of cleaning up to do... -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 02:14 PM, Yinghai Lu wrote: Henrik's system has 5M holes, so i picked 8M. Wait... this number is related to the amount of holes? That really doesn't make any sense. Seriously... what is the logic behind this parameter? Current what is minimum ram is required for boot x86 32bit kernel? 8M? I have heard of a 6M boot, I believe. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 2:27 PM, H. Peter Anvin h...@linux.intel.com wrote: On 03/06/2013 02:04 PM, Henrik Rydberg wrote: Sigh. This is why keep the page tables together is fundamentally the wrong strategy. 8M means that we won't even be able to boot on machines with less than 16M or so of RAM... I'm not sure if anyone still cares, but that is a pretty aggressive heuristic. Maybe this should be a config option, given the ad-hoc nature of the chosen value? Anyway, the patch works. Can we make a sensible argument for what the value *needs* to be? 2M at least makes a modicum of sense. Either way, it's clear we still have plenty of cleaning up to do... ok, let's stay with 2M. Please check attached v1 with updated commit log. Thanks Yinghai fix_real_end_v1.patch Description: Binary data
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 2:28 PM, H. Peter Anvin h...@linux.intel.com wrote: Current what is minimum ram is required for boot x86 32bit kernel? 8M? I have heard of a 6M boot, I believe. good. How about 64bit kernel? 64M? Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 02:46 PM, Yinghai Lu wrote: On Wed, Mar 6, 2013 at 2:28 PM, H. Peter Anvin h...@linux.intel.com wrote: Current what is minimum ram is required for boot x86 32bit kernel? 8M? I have heard of a 6M boot, I believe. good. How about 64bit kernel? 64M? Same ballpark. There isn't really an inherent reason a 64-bit kernel needs more space. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/06/2013 02:44 PM, Yinghai Lu wrote: ok, let's stay with 2M. I still want an explanation of the logic here. What is the purpose of this? Keeping the kernel page tables in large page mappable space? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Wed, Mar 6, 2013 at 2:48 PM, H. Peter Anvin h...@linux.intel.com wrote: On 03/06/2013 02:44 PM, Yinghai Lu wrote: ok, let's stay with 2M. I still want an explanation of the logic here. What is the purpose of this? Keeping the kernel page tables in large page mappable space? yes. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Sun, Mar 3, 2013 at 5:42 PM, Linus Torvalds
wrote:
>
> git log v3.8.. --author=Torvalds --merges |
> egrep '^((Merge)|(Pull)) .* from '
>
> and then some nasty sed+sort crud, followed by some manual fixup. It's
> the kind of thing perl is perfect for, but I'm not much of a perl
> person, so I have never written a *good* script to just do this right.
Ok, this is still not good, but this at least makes my manual editing
minimal. There's a few extra lines that match the pattern that need
manual fixup, and some people with two different names (Ted vs
Theodore) but other than that it looks ok.
So do the above git long + egrep pipeline, and then pipe it to the
perl script below. I feel a git alias coming up in my future..
Real perl people may want to avert their eyes..
Linus
---
#!/usr/bin/perl -w
use strict;
my (%map);
sub add_entry($$) {
my ($key,$desc) = @_;
if (exists $map{$key}) {
my $obj = $map{$key};
push(@$obj, $desc);
} else {
my @arr = ($desc);
$map{$key} = \@arr;
}
}
sub input {
while (<>) {
my ($type,$desc,$key) = (/^ *(\S*) *(.*) from *(.*)/);
chomp($key = $3);
chomp($desc = $2);
chop $key if ($key =~ /(:|\.)$/);
add_entry($key, $desc);
}
}
sub by_name($$) {
my ($a, $b) = @_;
uc($a) cmp uc($b);
}
sub output {
my ($key);
foreach $key (sort by_name keys %map) {
my ($obj, $desc);
$obj = $map{$key};
printf "%s: (%d)\n", $key, scalar(@$obj);
print "\t$_\n" foreach @$obj;
print "\n";
}
}
input;
output;
exit(0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Sun, Mar 3, 2013 at 6:32 PM, Randy Dunlap wrote: > > I suppose that this omits individual contributor patches by design? > I had 3 patches merged, but they are hidden by this method. Absolutely. We had over ten thousand commits in between 3.8 and 3.9-rc1 (10942 if you count merges, 10265 if you don't). So the whole shortlog format (that gives authorship for individual commits) is simply not very useful. It's over half a megabyte of data. You show up in the shortlog: Randy Dunlap (5): lguest: select CONFIG_TTY to build properly. i2c: fix i2c-ismt.c printk format warning [SCSI] scsi: fix lpfc build when wmb() is defined as mb() watchdog: da9055_wdt needs to select WATCHDOG_CORE hsi: fix kernel-doc warnings but it's *so* much data that it's not worth posting in lkml. Nobody would read it, and more importantly, it's so much that there's no feel for any kind of overview. The *mergelog* I post is literally just a list of merges I do, and the names that get credited are neither the authors nor the committers, but literally just the people who send me the pull request. Now, *often* that has high correlation with committers, but not always. For example, David Miller is who asks me to pull the networking tree, but in reality, that hides not just all the authors, but also all the submaintainers who he in turn pulls from. Similarly, most of the x86 tree pull requests come from Ingo, even though there are other people involved as maintainers. So the mergelog really only gives you an idea of which *subsystems* got merged, and generally the top-level maintainer for that subsystem. And even then, the "top-level maintainer" can be just "one of several top-level maintainers", so even that particular data point is not really completely unambiguous. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On 03/03/13 17:42, Linus Torvalds wrote: > On Sun, Mar 3, 2013 at 5:17 PM, Jiri Kosina wrote: >> >> I actually quite liked your merge shortlog, which of course I can generate >> easily myself, but it was nice to have for free :) > > No, you're right, I should do it. In fact, I should automate it better > so that I do it by default and don't have to do so much hand-editing > of the result of a (really) stupid shell script. > > It's all based on just > > git log v3.8.. --author=Torvalds --merges | > egrep '^((Merge)|(Pull)) .* from ' > > and then some nasty sed+sort crud, followed by some manual fixup. It's > the kind of thing perl is perfect for, but I'm not much of a perl > person, so I have never written a *good* script to just do this right. > > Anyway, here it is, the merge-log of stuff that happened in the merge > window for 3.9. > >Linus > > --- I suppose that this omits individual contributor patches by design? I had 3 patches merged, but they are hidden by this method. > James Bottomley: > first round of SCSI updates > SCSI updates 1 here > Wim Van Sebroeck: > watchdog updates 1 here and 1 merged by Linus Torvalds. thanks, -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Sun, Mar 3, 2013 at 5:17 PM, Jiri Kosina wrote: > > I actually quite liked your merge shortlog, which of course I can generate > easily myself, but it was nice to have for free :) No, you're right, I should do it. In fact, I should automate it better so that I do it by default and don't have to do so much hand-editing of the result of a (really) stupid shell script. It's all based on just git log v3.8.. --author=Torvalds --merges | egrep '^((Merge)|(Pull)) .* from ' and then some nasty sed+sort crud, followed by some manual fixup. It's the kind of thing perl is perfect for, but I'm not much of a perl person, so I have never written a *good* script to just do this right. Anyway, here it is, the merge-log of stuff that happened in the merge window for 3.9. Linus --- Alasdair G Kergon: device-mapper update Alex Williamson: VFIO updates Al Viro: vfs pile (part one) vfs fix more VFS bits signal/compat fixes signal handling cleanups sigprocmask compat fix Andrew Morton: misc patches second patch-bomb third patch-bumb Anton Vorontsov: battery updates Arnd Bergmann: ARM SoC board specific changes ARM SoC cleanups ARM SoC device tree conversions ARM SoC driver specific changes ARM SoC multiplatform support ARM SoC-specific updates non-critical ARM SoC bug fixes sh-mobile pinctrl conversion Artem Bityutskiy: ubifs updates Benjamin Herrenschmidt: powerpc updates Ben Myers: xfs update Bjorn Helgaas: PCI changes Bob Liu: small blackfin update Borislav Petkov: EDAC updates Bryan Wu: LED subsystem update Catalin Marinas: arm64 patches Chris Ball: MMC update Chris Mason: btrfs fixup btrfs update Chris Zankel: xtensa update Dave Airlie: drm merge David Howells: fbdev UAPI disintegration David Miller: networking update networking fixes sparc updates David Teigland: dlm update David Woodhouse: MTD update Dmitry Torokhov: input updates Eric Van Hensbergen: v9fs updates Eric W Biederman: user namespace and namespace infrastructure changes Geert Uytterhoeven: m68k update Gleb Natapov: KVM ARM compile fixes one kvm bugfix Grant Likely: device tree changes GPIO changes SPI changes Greg Kroah-Hartman: char/misc driver patches char/misc patch driver core patches staging tree update tty/serial patches USB patches USB patch revert Guenter Roeck: hwmon updates Helge Deller: parisc updates second round of PARISC updates Herbert Xu: crypto update Ingo Molnar: core locking changes irq core changes perf changes perf fixes preparatory smp/hotplug patches RCU changes scheduler changes scheduler fixes timer changes timer fixes two x86 kernel build changes x86/apic changes x86/asm changes x86 bootup changes x86 cleanup patches x86/debug changes x86 fixes x86/hyperv changes x86 platform changes x86 UV3 support update Jaegeuk Kim: f2fs update James Bottomley: first round of SCSI updates SCSI updates James Hogan: new ImgTec Meta architecture James Morris: security subsystem fixes security subsystem updates Jan Kara: ext2, ext3, udf updates Jason Wessel: KGDB/KDB fixes and cleanups J Bruce Fields: nfsd changes Jeff Garzik: libata updates Jens Axboe: block driver bits block IO core bits Jiri Kosina: HID subsystem updates trivial tree Joerg Roedel: IOMMU Updates Jonas Bonn: OpenRISC updates Konrad Rzeszutek Wilk: Xen bug-fixes Xen update Linus Walleij: pinctrl changes Marcelo Tosatti: KVM updates Marek Szyprowski: DMA-mapping updates Mark Brown: regmap updates regulator updates Markus Oberhumer: LZO compression update Martin Schwidefsky: s390 update second set of s390 patches Matthew Garrett: x86 platform driver updates Mauro Carvalho Chehab: EDAC fixes and ghes-edac media updates Michael Turquette: clock framework update Michal Marek: kbuild changes kconfig changes misc non-critical kbuild changes Michal Simek: microblaze update Miklos Szeredi: fuse updates Nicholas Bellinger: scsi target updates SCSI target patches Olof Johansson: ARM SoC i.MX DT changes ARM SoC late OMAP changes ARM SoC mvebu platform
Re: Linux 3.9-rc1
On Sun, 3 Mar 2013, Linus Torvalds wrote: > There is a lot of stuff there, and as usual even the shortlog is really > too big to pst or read through. I'd suggest using git to check whatever > particular area you're interested in.. I actually quite liked your merge shortlog, which of course I can generate easily myself, but it was nice to have for free :) Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Sun, 3 Mar 2013, Linus Torvalds wrote: There is a lot of stuff there, and as usual even the shortlog is really too big to pst or read through. I'd suggest using git to check whatever particular area you're interested in.. I actually quite liked your merge shortlog, which of course I can generate easily myself, but it was nice to have for free :) Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Sun, Mar 3, 2013 at 5:17 PM, Jiri Kosina jkos...@suse.cz wrote: I actually quite liked your merge shortlog, which of course I can generate easily myself, but it was nice to have for free :) No, you're right, I should do it. In fact, I should automate it better so that I do it by default and don't have to do so much hand-editing of the result of a (really) stupid shell script. It's all based on just git log v3.8.. --author=Torvalds --merges | egrep '^((Merge)|(Pull)) .* from ' and then some nasty sed+sort crud, followed by some manual fixup. It's the kind of thing perl is perfect for, but I'm not much of a perl person, so I have never written a *good* script to just do this right. Anyway, here it is, the merge-log of stuff that happened in the merge window for 3.9. Linus --- Alasdair G Kergon: device-mapper update Alex Williamson: VFIO updates Al Viro: vfs pile (part one) vfs fix more VFS bits signal/compat fixes signal handling cleanups sigprocmask compat fix Andrew Morton: misc patches second patch-bomb third patch-bumb Anton Vorontsov: battery updates Arnd Bergmann: ARM SoC board specific changes ARM SoC cleanups ARM SoC device tree conversions ARM SoC driver specific changes ARM SoC multiplatform support ARM SoC-specific updates non-critical ARM SoC bug fixes sh-mobile pinctrl conversion Artem Bityutskiy: ubifs updates Benjamin Herrenschmidt: powerpc updates Ben Myers: xfs update Bjorn Helgaas: PCI changes Bob Liu: small blackfin update Borislav Petkov: EDAC updates Bryan Wu: LED subsystem update Catalin Marinas: arm64 patches Chris Ball: MMC update Chris Mason: btrfs fixup btrfs update Chris Zankel: xtensa update Dave Airlie: drm merge David Howells: fbdev UAPI disintegration David Miller: networking update networking fixes sparc updates David Teigland: dlm update David Woodhouse: MTD update Dmitry Torokhov: input updates Eric Van Hensbergen: v9fs updates Eric W Biederman: user namespace and namespace infrastructure changes Geert Uytterhoeven: m68k update Gleb Natapov: KVM ARM compile fixes one kvm bugfix Grant Likely: device tree changes GPIO changes SPI changes Greg Kroah-Hartman: char/misc driver patches char/misc patch driver core patches staging tree update tty/serial patches USB patches USB patch revert Guenter Roeck: hwmon updates Helge Deller: parisc updates second round of PARISC updates Herbert Xu: crypto update Ingo Molnar: core locking changes irq core changes perf changes perf fixes preparatory smp/hotplug patches RCU changes scheduler changes scheduler fixes timer changes timer fixes two x86 kernel build changes x86/apic changes x86/asm changes x86 bootup changes x86 cleanup patches x86/debug changes x86 fixes x86/hyperv changes x86 platform changes x86 UV3 support update Jaegeuk Kim: f2fs update James Bottomley: first round of SCSI updates SCSI updates James Hogan: new ImgTec Meta architecture James Morris: security subsystem fixes security subsystem updates Jan Kara: ext2, ext3, udf updates Jason Wessel: KGDB/KDB fixes and cleanups J Bruce Fields: nfsd changes Jeff Garzik: libata updates Jens Axboe: block driver bits block IO core bits Jiri Kosina: HID subsystem updates trivial tree Joerg Roedel: IOMMU Updates Jonas Bonn: OpenRISC updates Konrad Rzeszutek Wilk: Xen bug-fixes Xen update Linus Walleij: pinctrl changes Marcelo Tosatti: KVM updates Marek Szyprowski: DMA-mapping updates Mark Brown: regmap updates regulator updates Markus Oberhumer: LZO compression update Martin Schwidefsky: s390 update second set of s390 patches Matthew Garrett: x86 platform driver updates Mauro Carvalho Chehab: EDAC fixes and ghes-edac media updates Michael Turquette: clock framework update Michal Marek: kbuild changes kconfig changes misc non-critical kbuild changes Michal Simek: microblaze update Miklos Szeredi: fuse updates Nicholas Bellinger: scsi target updates SCSI target patches Olof Johansson: ARM SoC i.MX DT changes ARM SoC late OMAP changes ARM SoC mvebu
Re: Linux 3.9-rc1
On 03/03/13 17:42, Linus Torvalds wrote: On Sun, Mar 3, 2013 at 5:17 PM, Jiri Kosina jkos...@suse.cz wrote: I actually quite liked your merge shortlog, which of course I can generate easily myself, but it was nice to have for free :) No, you're right, I should do it. In fact, I should automate it better so that I do it by default and don't have to do so much hand-editing of the result of a (really) stupid shell script. It's all based on just git log v3.8.. --author=Torvalds --merges | egrep '^((Merge)|(Pull)) .* from ' and then some nasty sed+sort crud, followed by some manual fixup. It's the kind of thing perl is perfect for, but I'm not much of a perl person, so I have never written a *good* script to just do this right. Anyway, here it is, the merge-log of stuff that happened in the merge window for 3.9. Linus --- I suppose that this omits individual contributor patches by design? I had 3 patches merged, but they are hidden by this method. James Bottomley: first round of SCSI updates SCSI updates 1 here Wim Van Sebroeck: watchdog updates 1 here and 1 merged by Linus Torvalds. thanks, -- ~Randy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Sun, Mar 3, 2013 at 6:32 PM, Randy Dunlap rdun...@infradead.org wrote: I suppose that this omits individual contributor patches by design? I had 3 patches merged, but they are hidden by this method. Absolutely. We had over ten thousand commits in between 3.8 and 3.9-rc1 (10942 if you count merges, 10265 if you don't). So the whole shortlog format (that gives authorship for individual commits) is simply not very useful. It's over half a megabyte of data. You show up in the shortlog: Randy Dunlap (5): lguest: select CONFIG_TTY to build properly. i2c: fix i2c-ismt.c printk format warning [SCSI] scsi: fix lpfc build when wmb() is defined as mb() watchdog: da9055_wdt needs to select WATCHDOG_CORE hsi: fix kernel-doc warnings but it's *so* much data that it's not worth posting in lkml. Nobody would read it, and more importantly, it's so much that there's no feel for any kind of overview. The *mergelog* I post is literally just a list of merges I do, and the names that get credited are neither the authors nor the committers, but literally just the people who send me the pull request. Now, *often* that has high correlation with committers, but not always. For example, David Miller is who asks me to pull the networking tree, but in reality, that hides not just all the authors, but also all the submaintainers who he in turn pulls from. Similarly, most of the x86 tree pull requests come from Ingo, even though there are other people involved as maintainers. So the mergelog really only gives you an idea of which *subsystems* got merged, and generally the top-level maintainer for that subsystem. And even then, the top-level maintainer can be just one of several top-level maintainers, so even that particular data point is not really completely unambiguous. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.9-rc1
On Sun, Mar 3, 2013 at 5:42 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
git log v3.8.. --author=Torvalds --merges |
egrep '^((Merge)|(Pull)) .* from '
and then some nasty sed+sort crud, followed by some manual fixup. It's
the kind of thing perl is perfect for, but I'm not much of a perl
person, so I have never written a *good* script to just do this right.
Ok, this is still not good, but this at least makes my manual editing
minimal. There's a few extra lines that match the pattern that need
manual fixup, and some people with two different names (Ted vs
Theodore) but other than that it looks ok.
So do the above git long + egrep pipeline, and then pipe it to the
perl script below. I feel a git alias coming up in my future..
Real perl people may want to avert their eyes..
Linus
---
#!/usr/bin/perl -w
use strict;
my (%map);
sub add_entry($$) {
my ($key,$desc) = @_;
if (exists $map{$key}) {
my $obj = $map{$key};
push(@$obj, $desc);
} else {
my @arr = ($desc);
$map{$key} = \@arr;
}
}
sub input {
while () {
my ($type,$desc,$key) = (/^ *(\S*) *(.*) from *(.*)/);
chomp($key = $3);
chomp($desc = $2);
chop $key if ($key =~ /(:|\.)$/);
add_entry($key, $desc);
}
}
sub by_name($$) {
my ($a, $b) = @_;
uc($a) cmp uc($b);
}
sub output {
my ($key);
foreach $key (sort by_name keys %map) {
my ($obj, $desc);
$obj = $map{$key};
printf %s: (%d)\n, $key, scalar(@$obj);
print \t$_\n foreach @$obj;
print \n;
}
}
input;
output;
exit(0)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
