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 com
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 unsubscrib
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-ke
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 r
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-kerne
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
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
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
>> pre
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
descr
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 ro
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.
> >
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 att
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
De
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
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 a
> >> >> 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 l
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 n
> >> 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
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
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 comma
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, straigh
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
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
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 t
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
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
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 y
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
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 t
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 ca
30 matches
Mail list logo
