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
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
Hi,
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
Hi,
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
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
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
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
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
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
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
>>
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
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
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
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
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
> >> >> 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
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
> >> 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
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
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,
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
>>
>>
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
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
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
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 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
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
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
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
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
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
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
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,
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
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
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
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
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.
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
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
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
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
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 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
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
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
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
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
Hi all,
On Mon, 4 Mar 2013 15:22:22 +1100 Stephen Rothwell
wrote:
>
> So commits in -rc1 that were "in" next-20130220: 930090.6%
> (down from 90.0% last time)
That should read "down from 90.9% last time".
At least I know that one person
On Sun, 3 Mar 2013 16:28:25 -0800 Linus Torvalds
wrote:
>
> It's been two weeks (ok, thirteen days, but close enough), and the
> merge window is closed, and I've cut the 3.9-rc1 release.
>
> I don't know if it's just me, but this merge window had more "Uhhuh"
> moments than I'm used to. I
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
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
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
It's been two weeks (ok, thirteen days, but close enough), and the
merge window is closed, and I've cut the 3.9-rc1 release.
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
It's been two weeks (ok, thirteen days, but close enough), and the
merge window is closed, and I've cut the 3.9-rc1 release.
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
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
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
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
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
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
On Sun, 3 Mar 2013 16:28:25 -0800 Linus Torvalds
torva...@linux-foundation.org wrote:
It's been two weeks (ok, thirteen days, but close enough), and the
merge window is closed, and I've cut the 3.9-rc1 release.
I don't know if it's just me, but this merge window had more Uhhuh
moments than
Hi all,
On Mon, 4 Mar 2013 15:22:22 +1100 Stephen Rothwell s...@canb.auug.org.au
wrote:
So commits in -rc1 that were in next-20130220: 930090.6%
(down from 90.0% last time)
That should read down from 90.9% last time.
At least I know
68 matches
Mail list logo
