Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Geert Uytterhoeven]

On Sat, May 21, 2011 at 15:28, Thorsten Glaser <tg@mirbsd.de> wrote:
>>main archive in a few days, then. Just saw there was a new upload.
>
> Hm, well. It doesn’t include the “Reserve ST-RAM early” patch ☹
> but we know how to work around the problem, for now, I think.
> Let’s just hope it’ll end up in 2.6.40 upstream.

I'm sorry, it won't make 2.6.40, unless someone does the rewrite before Sunday
(Linus flying to Japan, end-of-merge-window).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Michael Schmitz]

Geert,

remind me - what rewrite will be required?

I've seen your work on the chip RAM driver, will take a close look at
adapting this for ST-RAM when I return from overseas.

Cheers,

  Michael


On Tue, May 24, 2011 at 2:22 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Sat, May 21, 2011 at 15:28, Thorsten Glaser <tg@mirbsd.de> wrote:
>>>main archive in a few days, then. Just saw there was a new upload.
>>
>> Hm, well. It doesn’t include the “Reserve ST-RAM early” patch ☹
>> but we know how to work around the problem, for now, I think.
>> Let’s just hope it’ll end up in 2.6.40 upstream.
>
> I'm sorry, it won't make 2.6.40, unless someone does the rewrite before Sunday
> (Linus flying to Japan, end-of-merge-window).
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Geert Uytterhoeven]

On Mon, May 30, 2011 at 19:14, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
> remind me - what rewrite will be required?

Remove your own memory allocator.
Probably the simplest is to always reserve some ST-RAM on bootup, and let
stram_alloc()/stram_free() use that reserved pool.

> I've seen your work on the chip RAM driver, will take a close look at
> adapting this for ST-RAM when I return from overseas.

When will you return, just in case I come to it before that (woow, I
feel overly optimistic now)?

> On Tue, May 24, 2011 at 2:22 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Sat, May 21, 2011 at 15:28, Thorsten Glaser <tg@mirbsd.de> wrote:
>>>>main archive in a few days, then. Just saw there was a new upload.
>>>
>>> Hm, well. It doesn’t include the “Reserve ST-RAM early” patch ☹
>>> but we know how to work around the problem, for now, I think.
>>> Let’s just hope it’ll end up in 2.6.40 upstream.
>>
>> I'm sorry, it won't make 2.6.40, unless someone does the rewrite before Sunday
>> (Linus flying to Japan, end-of-merge-window).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Geert Uytterhoeven]

On Mon, May 30, 2011 at 19:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, May 30, 2011 at 19:14, Michael Schmitz
> <schmitzmic@googlemail.com> wrote:
>> remind me - what rewrite will be required?
>
> Remove your own memory allocator.
> Probably the simplest is to always reserve some ST-RAM on bootup, and let
> stram_alloc()/stram_free() use that reserved pool.
>
>> I've seen your work on the chip RAM driver, will take a close look at
>> adapting this for ST-RAM when I return from overseas.
>
> When will you return, just in case I come to it before that (woow, I
> feel overly optimistic now)?

Has anyone besides me tried http://lkml.org/lkml/2011/6/5/46 on top of
https://lkml.org/lkml/2011/5/21/142?

>> On Tue, May 24, 2011 at 2:22 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> On Sat, May 21, 2011 at 15:28, Thorsten Glaser <tg@mirbsd.de> wrote:
>>>>>main archive in a few days, then. Just saw there was a new upload.
>>>>
>>>> Hm, well. It doesn’t include the “Reserve ST-RAM early” patch ☹
>>>> but we know how to work around the problem, for now, I think.
>>>> Let’s just hope it’ll end up in 2.6.40 upstream.
>>>
>>> I'm sorry, it won't make 2.6.40, unless someone does the rewrite before Sunday
>>> (Linus flying to Japan, end-of-merge-window).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Michael Schmitz]

Hi Geert,

On Tue, Jun 14, 2011 at 6:49 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, May 30, 2011 at 19:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Mon, May 30, 2011 at 19:14, Michael Schmitz
>> <schmitzmic@googlemail.com> wrote:
>>> remind me - what rewrite will be required?
>>
>> Remove your own memory allocator.
>> Probably the simplest is to always reserve some ST-RAM on bootup, and let
>> stram_alloc()/stram_free() use that reserved pool.
>>
>>> I've seen your work on the chip RAM driver, will take a close look at
>>> adapting this for ST-RAM when I return from overseas.
>>
>> When will you return, just in case I come to it before that (woow, I
>> feel overly optimistic now)?
>
> Has anyone besides me tried http://lkml.org/lkml/2011/6/5/46 on top of
> https://lkml.org/lkml/2011/5/21/142?

Sorry, I haven't had much time to do any coherent work on this yet. I
seem to have fried my EtherNAT PHY, two of my SCSI disks didn't come
back up after I returned from overseas, and I have been just too
jetlagged to risk blowing up anything else.

I do very much appreciate your effort in getting rid of the old ST-RAM
allocator, and I will try to test a new kernel later this week.

Cheers,

  Michael

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Michael Schmitz]

Geert,

http://lkml.org/lkml/2011/6/5/46 appears malformed (patch ending in
the middle of the line), can you send a fresh patch file per PM
please?

3.0.0-rc4 seems fine otherwise.

Cheers,

  Michael


On Tue, Jun 14, 2011 at 8:35 AM, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
> Hi Geert,
>
> On Tue, Jun 14, 2011 at 6:49 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Mon, May 30, 2011 at 19:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> On Mon, May 30, 2011 at 19:14, Michael Schmitz
>>> <schmitzmic@googlemail.com> wrote:
>>>> remind me - what rewrite will be required?
>>>
>>> Remove your own memory allocator.
>>> Probably the simplest is to always reserve some ST-RAM on bootup, and let
>>> stram_alloc()/stram_free() use that reserved pool.
>>>
>>>> I've seen your work on the chip RAM driver, will take a close look at
>>>> adapting this for ST-RAM when I return from overseas.
>>>
>>> When will you return, just in case I come to it before that (woow, I
>>> feel overly optimistic now)?
>>
>> Has anyone besides me tried http://lkml.org/lkml/2011/6/5/46 on top of
>> https://lkml.org/lkml/2011/5/21/142?
>
> Sorry, I haven't had much time to do any coherent work on this yet. I
> seem to have fried my EtherNAT PHY, two of my SCSI disks didn't come
> back up after I returned from overseas, and I have been just too
> jetlagged to risk blowing up anything else.
>
> I do very much appreciate your effort in getting rid of the old ST-RAM
> allocator, and I will try to test a new kernel later this week.
>
> Cheers,
>
>  Michael
>

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Andreas Schwab]

Michael Schmitz <schmitzmic@googlemail.com> writes:

> http://lkml.org/lkml/2011/6/5/46 appears malformed (patch ending in
> the middle of the line),

Your browser appears to be broken.  Try wget or
<http://marc.info/?l=linux-kernel&m=130726658112067&q=raw> instead.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Michael Schmitz]

Andreas,

On Sun, Jun 19, 2011 at 7:37 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Michael Schmitz <schmitzmic@googlemail.com> writes:
>
>> http://lkml.org/lkml/2011/6/5/46 appears malformed (patch ending in
>> the middle of the line),
>
> Your browser appears to be broken.  Try wget or
> <http://marc.info/?l=linux-kernel&m=130726658112067&q=raw> instead.

Silly me - for not thinking of wget. Haven't had trouble with that
browser (whatever Ubuntu 10.04 uses) before though.

Thanks, will retry that!

Cheers,

  Michael

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Michael Schmitz]

Hi All,

after making sure I had a good patch file, the patch applied sort of
cleanly (I had used DEBUG in the stram pool code) and the resulting
kernel runs fine on my Falcon. Geert's resource allocator appears to
do the right thing and provides ST-RAM where needed so the old ST-RAM
allcocator can go.

Thanks a lot, Geert!

Cheers,

  Michael


On Mon, Jun 20, 2011 at 8:08 AM, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
> Andreas,
>
> On Sun, Jun 19, 2011 at 7:37 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Michael Schmitz <schmitzmic@googlemail.com> writes:
>>
>>> http://lkml.org/lkml/2011/6/5/46 appears malformed (patch ending in
>>> the middle of the line),
>>
>> Your browser appears to be broken.  Try wget or
>> <http://marc.info/?l=linux-kernel&m=130726658112067&q=raw> instead.
>
> Silly me - for not thinking of wget. Haven't had trouble with that
> browser (whatever Ubuntu 10.04 uses) before though.
>
> Thanks, will retry that!
>
> Cheers,
>
>  Michael
>

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Geert Uytterhoeven]

On Mon, Jun 27, 2011 at 01:49, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
> after making sure I had a good patch file, the patch applied sort of
> cleanly (I had used DEBUG in the stram pool code) and the resulting
> kernel runs fine on my Falcon. Geert's resource allocator appears to
> do the right thing and provides ST-RAM where needed so the old ST-RAM
> allcocator can go.

Good. Will queue for 3.1.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Geert Uytterhoeven]

On Mon, Jun 27, 2011 at 08:56, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Mon, Jun 27, 2011 at 01:49, Michael Schmitz
> <schmitzmic@googlemail.com> wrote:
>> after making sure I had a good patch file, the patch applied sort of
>> cleanly (I had used DEBUG in the stram pool code) and the resulting
>> kernel runs fine on my Falcon. Geert's resource allocator appears to
>> do the right thing and provides ST-RAM where needed so the old ST-RAM
>> allcocator can go.
>
> Good. Will queue for 3.1.

I folded it into your previous patch and pushed it out for 3.1.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>I folded it into your previous patch and pushed it out for 3.1.

Can you make a patch (series) on top of 3.0 and mail that to
debian-kernel asking for inclusion in the next 3.0 upload, on
the ground it’s been accepted upstream and fixes UI problems?

Thanks,
//mirabilos (still ill ☹)
-- 
08:05⎜<XTaran:#grml> mika: Does grml have an tool to read Apple
     ⎜    System Log (asl) files? :)
08:08⎜<ft:#grml> yeah. /bin/rm. ;)       08:09⎜<mrud:#grml> hexdump -C
08:31⎜<XTaran:#grml> ft, mrud: *g*

Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable

[Geert Uytterhoeven]

On Wed, Jun 29, 2011 at 19:38, Thorsten Glaser <tg@mirbsd.de> wrote:
> Geert Uytterhoeven dixit:
>
>>I folded it into your previous patch and pushed it out for 3.1.
>
> Can you make a patch (series) on top of 3.0 and mail that to
> debian-kernel asking for inclusion in the next 3.0 upload, on
> the ground it’s been accepted upstream and fixes UI problems?

The two patches you need are

http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commitdiff;h=1789c38726c2805563e9049dbc5d5253251761a7
http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commitdiff;h=10b2495b79eb8c2b6ec92b3ce1e5577f892f7821

which are both on my for-3.1/for-next branch:

http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/for-3.1

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[m68k] Patches for 3.0 (was Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable)

[Thorsten Glaser]

Hi Debian Kernel team,

can we please have these for 3.0? They will be in 3.1, and replace
0008-m68k-atari-Reserve-some-ST-RAM-early-on-for-device-b.patch
from 2.6.38-2, addressing the same problem (garbled video output
when the machine has too much FastRAM).

Thanks!



Geert Uytterhoeven dixit:

>On Wed, Jun 29, 2011 at 19:38, Thorsten Glaser <tg@mirbsd.de> wrote:
>> Geert Uytterhoeven dixit:
>>
>>>I folded it into your previous patch and pushed it out for 3.1.
>>
>> Can you make a patch (series) on top of 3.0 and mail that to
>> debian-kernel asking for inclusion in the next 3.0 upload, on
>> the ground it’s been accepted upstream and fixes UI problems?
>
>The two patches you need are
>
>http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commitdiff;h=1789c38726c2805563e9049dbc5d5253251761a7
>http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commitdiff;h=10b2495b79eb8c2b6ec92b3ce1e5577f892f7821
>
>which are both on my for-3.1/for-next branch:
>
>http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/for-3.1
>
>Gr{oetje,eeting}s,
>
>                        Geert

Re: [m68k] Patches for 3.0 (was Re: linux-2.6_2.6.39-1_amd64.changes ACCEPTED into unstable)

[maximilian attems]

hello,

On Wed, Jun 29, 2011 at 08:05:11PM +0000, Thorsten Glaser wrote:
> Hi Debian Kernel team,
> 
> can we please have these for 3.0? They will be in 3.1, and replace
> 0008-m68k-atari-Reserve-some-ST-RAM-early-on-for-device-b.patch
> from 2.6.38-2, addressing the same problem (garbled video output
> when the machine has too much FastRAM).

aboves confuses me, I don't see any m68k patches in the trunk branch
heading for the next 3.0-rcX upload?

which are needed?
 
> Thanks!
> 
> 
> 
> Geert Uytterhoeven dixit:
> 
> >On Wed, Jun 29, 2011 at 19:38, Thorsten Glaser <tg@mirbsd.de> wrote:
> >> Geert Uytterhoeven dixit:
> >>
> >>>I folded it into your previous patch and pushed it out for 3.1.
> >>
> >> Can you make a patch (series) on top of 3.0 and mail that to
> >> debian-kernel asking for inclusion in the next 3.0 upload, on
> >> the ground it’s been accepted upstream and fixes UI problems?
> >
> >The two patches you need are
> >
> >http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commitdiff;h=1789c38726c2805563e9049dbc5d5253251761a7
> >http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commitdiff;h=10b2495b79eb8c2b6ec92b3ce1e5577f892f7821
> >
> >which are both on my for-3.1/for-next branch:
> >
> >http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/for-3.1
> >
> >Gr{oetje,eeting}s,
> >
> >                        Geert

ah ok I see, will wait till these 2 materialise in linux-next and
then add them.

thanks.

-- 
maks

Re: [m68k] Patches for 3.0

[Thorsten Glaser]

maximilian attems dixit:

>aboves confuses me, I don't see any m68k patches in the trunk branch
>heading for the next 3.0-rcX upload?

Yes, they were in 2.6.38 but someone removed them before 2.6.39 in Debian.
All but this one patch, replaced by (see below), were included in 2.6.39
upstream though, so only this issue popped up again.

>which are needed?

These:

>> >The two patches you need are
>> >
>> >http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commitdiff;h=1789c38726c2805563e9049dbc5d5253251761a7
>> >http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=commitdiff;h=10b2495b79eb8c2b6ec92b3ce1e5577f892f7821

>ah ok I see, will wait till these 2 materialise in linux-next and
>then add them.

OK, thanks!

bye,
//mirabilos
-- 
08:05⎜<XTaran:#grml> mika: Does grml have an tool to read Apple
     ⎜    System Log (asl) files? :)
08:08⎜<ft:#grml> yeah. /bin/rm. ;)       08:09⎜<mrud:#grml> hexdump -C
08:31⎜<XTaran:#grml> ft, mrud: *g*

Re: [m68k] Patches for 3.0

[maximilian attems]

On Wed, 29 Jun 2011, Thorsten Glaser wrote:

> >ah ok I see, will wait till these 2 materialise in linux-next and
> >then add them.
> 
> OK, thanks!

done.