Debian kernel v2.6.38 (was: Re: Fix for SLUB?)

Debian kernel v2.6.38 (was: Re: Fix for SLUB?)

[Geert Uytterhoeven]

On Sat, Apr 23, 2011 at 17:39, Thorsten Glaser <tg@mirbsd.de> wrote:
> But I was just told by a member of the Debian Kernel Team on
> IRC that the patches from m68k-v2.6.38 will (probably) not be
> accepted, unless they go in via Linus’ tree. How are chances
> of that happening? (He says they had told that years ago al-
> ready.) I’ll need at least the ARAnyM/NatFeat support and some
> of the bugfixes. Otherwise I fear this keeps getting obsolete
> very fast. ☹

  1. The critical bugfixes will go in via v2.6.38-stable anyway,
  2. The ARAnyM/NatFeat support will be in v2.6.39, which may be a
sufficiently convincing argument for the Debian Kernel Team to accept
it in Debian's v2.6.38,
  3. If there's anything left that you really need, please tell us, so
"we" can get it in a good shape for v2.6.40.

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: Debian kernel v2.6.38

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>  1. The critical bugfixes will go in via v2.6.38-stable anyway,

OK.

>  2. The ARAnyM/NatFeat support will be in v2.6.39, which may be a
>sufficiently convincing argument for the Debian Kernel Team to accept
>it in Debian's v2.6.38,

Thanks, that’s great! (Having no ethernet is a bit limitating…)
Please don’t forget to update the defconfigs (there are two commits
to that effect in the queue, but that must of course be split matching
the features actually submitted…).

>  3. If there's anything left that you really need, please tell us, so
>"we" can get it in a good shape for v2.6.40.

OK. While I don’t strictly need it, I can think of these:
• Reclaim chip RAM on Amiga
• Reserve ST RAM early

No idea about the required status of the other patches, e.g. Mac. Finn?


I’m Bcc’ing the Debian Kernel person I was talking to, so we may
get an agreement. I’ll revisit your gitweb later then, to see
which patches you actually schedule for Linus, and try to get
them into Debian.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.		-- Coywolf Qi Hunt

Re: Debian kernel v2.6.38

[Geert Uytterhoeven]

On Sat, Apr 23, 2011 at 20:13, Thorsten Glaser <tg@mirbsd.de> wrote:
> Geert Uytterhoeven dixit:
>>  3. If there's anything left that you really need, please tell us, so
>>"we" can get it in a good shape for v2.6.40.
>
> OK. While I don’t strictly need it, I can think of these:
> • Reclaim chip RAM on Amiga

Nobody cares about 4 KiB of Chip RAM, especially not if you have to piss off the
Debian Kernel Team to have it now instead of in a few months :-)

> • Reserve ST RAM early

Yeah, that's a valid one,
My (and probably lkml's) main issue there is that it introduces yet
another custom
allocator. Can we avoid that?

> I’m Bcc’ing the Debian Kernel person I was talking to, so we may
> get an agreement. I’ll revisit your gitweb later then, to see
> which patches you actually schedule for Linus, and try to get
> them into Debian.

As for-2.6.39 got rebased in the mean time, you have to compare
m68k-v2.6.38 with m68k-queue to see what's (not yet) upstream.

And to back up Christian: keep up the good work!

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: Debian kernel v2.6.38

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>As for-2.6.39 got rebased in the mean time, you have to compare
>m68k-v2.6.38 with m68k-queue to see what's (not yet) upstream.

Actually, I think looking at your sent out pull requests will
be easier. Anyway, I’ve got the (cross-built) kernel running:

Linux ara4.mirbsd.org 2.6.38-1+m68k.1-atari #1 Sat Apr 23 16:18:16 UTC 2011 m68k GNU/Linux

Now it’s a matter of
• reducing patches
• getting patches accepted
• Debian Kernel Team creates an ABI file (?)
• build entire _official_ package natively (takes a week)

But we can play with it already, until then.

bye,
//mirabilos
-- 
13:47⎜<tobiasu> if i were omnipotent, i would divide by zero
                all day long ;)
(thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)

Re: Debian kernel v2.6.38

[Michael Schmitz]

Hi Geert,
> On Sat, Apr 23, 2011 at 20:13, Thorsten Glaser <tg@mirbsd.de> wrote:
>   
>> • Reserve ST RAM early
>>     
>
> Yeah, that's a valid one,
> My (and probably lkml's) main issue there is that it introduces yet
> another custom
> allocator. Can we avoid that?
>   
Ideally it would not be an issue if we could properly flag ST-RAM only 
as DMA memory. I've tried in the past but setting the max. DMA address 
to the 0x00ffffff did have unintended side effects elsewhere in the m68k 
mm code.

If there is a generic lowmem allocator, we might be able to use that 
instead. It does not need to be available early on, but we need to be 
able to reserve some lowmem early.

Another possible hack would be to allocate lowmem early on for each 
compiled-in user and store that in a platform device struct for use by 
the driver once it initializes. Is there such a thing like early 
initcalls for this specific purpose (do a minimum early setup such as 
allocate resources, silence IRQs and the like)?.

If all that is not an option (and for the sake of modules needing 
ST-RAM), I don't see another way to do it. Some parts of the hardware 
just need memory below 0x00ffffff.

Cheers,

  Michael

>   
>> I’m Bcc’ing the Debian Kernel person I was talking to, so we may
>> get an agreement. I’ll revisit your gitweb later then, to see
>> which patches you actually schedule for Linus, and try to get
>> them into Debian.
>>     
>
> As for-2.6.39 got rebased in the mean time, you have to compare
> m68k-v2.6.38 with m68k-queue to see what's (not yet) upstream.
>
> And to back up Christian: keep up the good work!
>
> 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: Debian kernel v2.6.38

[Geert Uytterhoeven]

Hi Michael,

On Sun, Apr 24, 2011 at 00:12, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
>> On Sat, Apr 23, 2011 at 20:13, Thorsten Glaser <tg@mirbsd.de> wrote:
>>> • Reserve ST RAM early
>>
>> Yeah, that's a valid one,
>> My (and probably lkml's) main issue there is that it introduces yet
>> another custom
>> allocator. Can we avoid that?
>
> Ideally it would not be an issue if we could properly flag ST-RAM only as
> DMA memory. I've tried in the past but setting the max. DMA address to the
> 0x00ffffff did have unintended side effects elsewhere in the m68k mm code.
>
> If there is a generic lowmem allocator, we might be able to use that
> instead. It does not need to be available early on, but we need to be able
> to reserve some lowmem early.

Reserving the pool using alloc_bootmem_low() is fine.
But the allocator for memory inside the pool could be changed to use e.g.
allocate_resource(), cfr. arch/m68k/amiga/chipram.c.
If I'm not mistaken, the main difference between Chip RAM on Amiga and ST-RAM
on Atari is that ST-RAM can be used as system memory, while Chip RAM cannot
(due to the lack of RMW bus support)?

> Another possible hack would be to allocate lowmem early on for each
> compiled-in user and store that in a platform device struct for use by the
> driver once it initializes. Is there such a thing like early initcalls for
> this specific purpose (do a minimum early setup such as allocate resources,
> silence IRQs and the like)?.

That's a bit like we do on the ps3, cfr. arch/powerpc/platforms/ps3/setup.c.
The main disadvantage is that it's less flexible, esp. for modules.

> If all that is not an option (and for the sake of modules needing ST-RAM), I
> don't see another way to do it. Some parts of the hardware just need memory
> below 0x00ffffff.

If you would just reserve 1 MiB (or a better tuned amount) of ST-RAM pool and
always use allocate_resource() to allocate ST-RAM, most of stram.c (e.g.
manageing the list of free blocks) can go?
As a bonus, you get freeing of memory from the pool.

I had a quick look into the ST-RAM users:
  - ataflop, atari_scsi, and atafb allocate ST-RAM only at driver
initialization,
  - dmasound_atari allocates/deallocates ST-RAM on sq_open()/close(),
so this will
    definitely break after a while if the ST-RAM pool doesn't support
freeing ST-RAM.

What do you think?

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: Debian kernel v2.6.38

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>On Sun, Apr 24, 2011 at 00:12, Michael Schmitz
><schmitzmic@googlemail.com> wrote:

>> If there is a generic lowmem allocator

There’s bound to be one. For example, on i386 you have two kinds
of lowmem to take care of: ISA DMA (first 16 MiB), and DMA and/or
BIOS call space within the first 640 KiB (both preferably not
crossing a 64 KiB boundary). But then, I’m not a kernel programmer
(either BSD or Linux), so I don’t know how things are handled these
days.

>  - ataflop, atari_scsi, and atafb allocate ST-RAM only at driver
>initialization,

Speaking of atafb, with the trimmed-down patch I get garbled video
with BootColorDepth 1, 4 or 8, and no option or video=atafb:vga2
both; using video=atafb:vga4 (with BCD=4) has no output at all.

This is no biggie for me, since the boxen work, but e.g. when
there’s an “mounted n times” fsck, the machine takes ages longer
to get up, and people will think it has frozen, so I’d very much
like to get _some_ kind of fix into at least the second version
of the Debian kernel, once we get past the initial hurdle…

bye,
//mirabilos
-- 
13:47⎜<tobiasu> if i were omnipotent, i would divide by zero
                all day long ;)
(thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)

Re: Debian kernel v2.6.38

[Finn Thain]

On Sat, 23 Apr 2011, Thorsten Glaser wrote:

> 
> No idea about the required status of the other patches, e.g. Mac. Finn?

Most of the relevant mac patches were merged into the mainline prior to 
the 2.6.34 release and by 2.6.37 all of them were merged.

I do have some unfinished patches based on 2.6.37 but I'm pretty sure they 
don't relate to the mac hardware used by the Debian/68k developers.

Finn

Re: Debian kernel v2.6.38

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>> • Reserve ST RAM early
>
>Yeah, that's a valid one,

It got accepted in the current form, but I said I’ll prod you
to have it pushed into 2.6.40 or so.

http://svn.debian.org/viewsvn/kernel?view=rev&revision=17252

Looks like we’ll get our kernels from stock unstable/sid in
two weeks or something.

Keep up *your* good work, too!

bye,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
	-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: Debian kernel v2.6.38

[Michael Schmitz]

Hi Thorsten,
>>  - ataflop, atari_scsi, and atafb allocate ST-RAM only at driver
>> initialization,
>>     
>
> Speaking of atafb, with the trimmed-down patch I get garbled video
> with BootColorDepth 1, 4 or 8, and no option or video=atafb:vga2
> both; using video=atafb:vga4 (with BCD=4) has no output at all.
>   
Patch trimmed down in what respect? No ST-RAM pool allocation at all, or 
atafb trimmed down?
> This is no biggie for me, since the boxen work, but e.g. when
> there’s an “mounted n times” fsck, the machine takes ages longer
> to get up, and people will think it has frozen, so I’d very much
> like to get _some_ kind of fix into at least the second version
> of the Debian kernel, once we get past the initial hurdle…
>   
Geert has given me something to think about with the allocate_resource 
suggestion. If that works at module load time (both ataflop and 
atari_scsi ought to work as modules) it definitely would be the 
preferred way.

Cheers,

  Michael

Re: Debian kernel v2.6.38

[Michael Schmitz]

Finn Thain wrote:
> On Sat, 23 Apr 2011, Thorsten Glaser wrote:
>
>   
>> No idea about the required status of the other patches, e.g. Mac. Finn?
>>     
>
> Most of the relevant mac patches were merged into the mainline prior to 
> the 2.6.34 release and by 2.6.37 all of them were merged.
>
> I do have some unfinished patches based on 2.6.37 but I'm pretty sure they 
> don't relate to the mac hardware used by the Debian/68k developers.
>   
Incidentially - did you work on the Mac 5380 SCSI code recently? Does it 
work with full error handling capability in its current state?

I begin to feel the only way to make the Falcon SCSI code work again is 
a clean restart ...

Cheers,

  Michael

Re: Debian kernel v2.6.38

[Finn Thain]

On Mon, 25 Apr 2011, Michael Schmitz wrote:

> Finn Thain wrote:
> > On Sat, 23 Apr 2011, Thorsten Glaser wrote:
> > 
> >   
> > > No idea about the required status of the other patches, e.g. Mac. 
> > > Finn?
> > >     
> > 
> > Most of the relevant mac patches were merged into the mainline prior 
> > to the 2.6.34 release and by 2.6.37 all of them were merged.
> > 
> > I do have some unfinished patches based on 2.6.37 but I'm pretty sure 
> > they don't relate to the mac hardware used by the Debian/68k 
> > developers.
> >   
> Incidentially - did you work on the Mac 5380 SCSI code recently? Does it 
> work with full error handling capability in its current state?

I got as far as confirming the reports of working mac_scsi on the IIfx. It 
fails on every other model. I didn't really investigate error handling.

The explanation was that PDMA isn't relevant to the IIfx so the driver 
runs in PIO mode (should be DMA but that has not yet been implemented 
successfully).

> 
> I begin to feel the only way to make the Falcon SCSI code work again is 
> a clean restart ...

That was also my feeling when we discussed this some years ago*.

I'm told that mac_scsi PDMA worked for either mac68k or mainline 2.2 
kernels and so I tend to think that a rewrite would likely suffer from the 
same PDMA bug. I really need to investigate that bug.

There are still good reasons for a rewrite but I don't have the necessary 
understanding of the SCSI subsystem nor the time to tackle those issues.

But if someone else were to rewrite the core 5380 driver as was done with 
esp_scsi.c then I would be willing to tackle the mac portion (the 
equivalent of mac_esp.c)...

Finn

* http://thread.gmane.org/gmane.linux.scsi/44873


> 
> Cheers,
> 
>  Michael
> 
> --
> 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: Debian kernel v2.6.38

[Thorsten Glaser]

Michael Schmitz dixit:

> Patch trimmed down in what respect? No ST-RAM pool allocation at all

Yes, that’s why I had it included in the second preview, which is
what’s now accepted.

> Geert has given me something to think about with the allocate_resource
> suggestion. If that works at module load time (both ataflop and atari_scsi
> ought to work as modules) it definitely would be the preferred way.

OK. I’m not (really) a kernel programmer, so looking forward to
input from you. Currently I’m mostly putting pieces together.

bye,
//mirabilos
-- 
13:47⎜<tobiasu> if i were omnipotent, i would divide by zero
                all day long ;)
(thinking about http://lobacevski.tumblr.com/post/3260866481 by waga)

Re: Debian kernel v2.6.38

[Michael Schmitz]

Hi Finn,
>> Incidentially - did you work on the Mac 5380 SCSI code recently? Does it 
>> work with full error handling capability in its current state?
>>     
>
> I got as far as confirming the reports of working mac_scsi on the IIfx. It 
> fails on every other model. I didn't really investigate error handling.
>   
OK so it works in principle but error handling may still be in need of 
updating.
> The explanation was that PDMA isn't relevant to the IIfx so the driver 
> runs in PIO mode (should be DMA but that has not yet been implemented 
> successfully).
>   
Gives me something to fall back to, at least...
>> I begin to feel the only way to make the Falcon SCSI code work again is 
>> a clean restart ...
>>     
>
> That was also my feeling when we discussed this some years ago*.
>   
I do well remember we talked about that - since mac_scsi uses mainline 
NCR5380.c I think you are in better shape already. No other driver uses 
anything close to PDMA but I cannot see what should be wrong there.
> I'm told that mac_scsi PDMA worked for either mac68k or mainline 2.2 
> kernels and so I tend to think that a rewrite would likely suffer from the 
> same PDMA bug. I really need to investigate that bug.
>   
> There are still good reasons for a rewrite but I don't have the necessary 
> understanding of the SCSI subsystem nor the time to tackle those issues.
>   
The Falcon driver worked in 2.2 and 2.4 and even as recent as 2.6.18 but 
broke in later 2.6 releases. Error handling changes, running the 
coroutine as delayed task instead of immediate soft interrupt and 
replacement of the big kernel lock by subsystem locking have all changed 
since. Some of that has been taken care of in NCR5380.c from what I've 
seen. atari_NCR5380.c still uses global locking, manually delays the 
task queue and fiddles with the queue pointers explicitly. I'll have to 
go over the whole file manually and make it as close to NCR5380.c as I 
can while still keeping the Falcon specific bits in.
> But if someone else were to rewrite the core 5380 driver as was done with 
> esp_scsi.c then I would be willing to tackle the mac portion (the 
> equivalent of mac_esp.c)...
>   
I lack an understanding of how the current SCSI error handling code is 
supposed to work - that part still needs to be done for NCR5380.c but 
I'm at a loss to find a good example of a current SCSI driver to look at.

All I manage so far is get the kernel to lock up solid once a request 
times out, but I've pretty much started from scratch so there will be 
bits missing to be patched.

Cheers,

    Michael

Re: Debian kernel 2.6.38-5

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>  1. The critical bugfixes will go in via v2.6.38-stable anyway,
>  2. The ARAnyM/NatFeat support will be in v2.6.39, which may be a
>sufficiently convincing argument for the Debian Kernel Team to accept
>it in Debian's v2.6.38,

Good news: one of my ARAnyMs will be compiling kernels for the next
full week or so, I think (CPU power provided by Thomas Goirand this
time, the other VMs run on boxen at tarent GmbH, if someone is in-
terested):

• Accepted linux-2.6 2.6.38-5 (source all i386) Ben Hutchings
http://lists.debian.org/debian-devel-changes/2011/05/msg00736.html

>  3. If there's anything left that you really need, please tell us, so
>"we" can get it in a good shape for v2.6.40.

Bad news: Christian T. Steigies has problems on real Amiga hardware:

> However, the current (TLS) kernels have problems with the ariadne2 network
> card, which, I think all Amigas here but crest have (ariadne1 in crest).
> I get error messages like this with 2.6.32 and 2.6.38
>
>  eth0: mismatched read page pointers 4f vs 4c.

Does that ring a bell anywhere? That’s running 2.6.38-4 plus
my patches, I think, so I expect 2.6.38-5 won’t change this.

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
	-- me, wondering why it’s not Jerry Potter………

Re: Debian kernel 2.6.38-5

[Christian T. Steigies]

On Sun, May 08, 2011 at 12:58:10PM +0000, Thorsten Glaser wrote:
> Geert Uytterhoeven dixit:
> 
> >  1. The critical bugfixes will go in via v2.6.38-stable anyway,
> >  2. The ARAnyM/NatFeat support will be in v2.6.39, which may be a
> >sufficiently convincing argument for the Debian Kernel Team to accept
> >it in Debian's v2.6.38,
> 
> Good news: one of my ARAnyMs will be compiling kernels for the next
> full week or so, I think (CPU power provided by Thomas Goirand this
> time, the other VMs run on boxen at tarent GmbH, if someone is in-
> terested):
> 
> ??? Accepted linux-2.6 2.6.38-5 (source all i386) Ben Hutchings
> http://lists.debian.org/debian-devel-changes/2011/05/msg00736.html

Why don't you cross-compile it? I just managed to rebuild your previous
build after I spent a day setting up a cross-compiler. Took only a couple of
hours.
 
> >  3. If there's anything left that you really need, please tell us, so
> >"we" can get it in a good shape for v2.6.40.
> 
> Bad news: Christian T. Steigies has problems on real Amiga hardware:
> 
> > However, the current (TLS) kernels have problems with the ariadne2 network
> > card, which, I think all Amigas here but crest have (ariadne1 in crest).
> > I get error messages like this with 2.6.32 and 2.6.38
> >
> >  eth0: mismatched read page pointers 4f vs 4c.
> 
> Does that ring a bell anywhere? That???s running 2.6.38-4 plus
> my patches, I think, so I expect 2.6.38-5 won???t change this.

The network (zorro8390) worked with the kernel from Stephen's netinstall iso,
it was 2.6.26. I am trying to cross-build older kernel versions, maybe I can
locate the problem. However, now I have two new problems.

How do I get the older versions from Geert's git? I don't see any other
branches, I only see tags. What is the magic word to get for example the 2.6.30
tree? 

When crosscompiling Geert's tree, shouldn't make ARCH=m68k be sufficient
(after setting up a propper .config)?
After creating a symlink to m68k-linux-gnu-gcc-4.4, this seems to work now: 
make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu-
It's been so long, is this the correct way to cross-build linux-m68k? I
should write that down somewhere...

Christian

Re: Debian kernel 2.6.38-5

[Geert Uytterhoeven]

On Sun, May 8, 2011 at 18:59, Christian T. Steigies <cts@debian.org> wrote:
> How do I get the older versions from Geert's git? I don't see any other
> branches, I only see tags.

Doesn't `git branch -r` show all branches?

> What is the magic word to get for example the 2.6.30 tree?

git checkout m68k-v2.6.30

That's actually a bad example, as I don't have a v2.6.30 version, due
to spending too
much time in a dial-up country those days :-)
I have m68k-v2.6.28..m68k-v2.6.38, but no .30.

Anyway, plain v2.6.30 should work on Amiga.

> When crosscompiling Geert's tree, shouldn't make ARCH=m68k be sufficient
> (after setting up a propper .config)?
> After creating a symlink to m68k-linux-gnu-gcc-4.4, this seems to work now:
> make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu-
> It's been so long, is this the correct way to cross-build linux-m68k? I
> should write that down somewhere...

If your compiler is called m68k-linux-gnu-gcc, `make ARCH=m68k' should work.

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: Debian kernel 2.6.38-5

[Thorsten Glaser]

Christian T. Steigies dixit:

>> ??? Accepted linux-2.6 2.6.38-5 (source all i386) Ben Hutchings
>> http://lists.debian.org/debian-devel-changes/2011/05/msg00736.html
>
>Why don't you cross-compile it?

I cross-built the kernels I ran for testing the patches, but that
was an exception – packages that I upload to Debian are *always*
built natively.

>How do I get the older versions from Geert's git? I don't see any other
>branches, I only see tags. What is the magic word to get for example the 2.6.30
>tree? 

tg@zigo:~/linux-m68k $ git branch -r
  origin/HEAD -> origin/master
  origin/atari-aranym
  origin/atari-ethernat
  origin/atari-ethernec
  origin/atari-fat
  origin/atari-scc
  origin/for-2.6.33
  origin/for-2.6.34
  origin/for-2.6.35
  origin/for-2.6.36
  origin/for-2.6.37
  origin/for-2.6.38
  origin/for-2.6.39
  origin/for-linus
  origin/for-next
  origin/m68k-queue
  origin/m68k-v2.6.28
  origin/m68k-v2.6.29
  origin/m68k-v2.6.31
  origin/m68k-v2.6.32
  origin/m68k-v2.6.33
  origin/m68k-v2.6.34
  origin/m68k-v2.6.35
  origin/m68k-v2.6.36
  origin/m68k-v2.6.37
  origin/m68k-v2.6.38
  origin/master
  origin/misc
  origin/postponed

>When crosscompiling Geert's tree, shouldn't make ARCH=m68k be sufficient
>(after setting up a propper .config)?

I’ll leave that to the Linux experts.

>It's been so long, is this the correct way to cross-build linux-m68k?

sudo cowbuilder --debbuildopts -am68k --binary-arch --build linux*.dsc
is the correct way in Debian (but will build all 6 images and more; it
takes about half a day, cross).

https://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage#Building_only_a_single_kernel_variant
lists another way, where you only “dpkg-source -x linux*.dsc” then
“cd linux-*/” and “fakeroot debian/rules binary-arch_m68k_none_amiga”
I think (but cross parameters might need to be added). This is also
in README.Debian in the source package.

But, like I said above, I’m building packages for the archive and
follow archive rules. Basically, I “am” a buildd now ;-)

bye,
//mirabilos, still mumbling about how setting up sbuild is arcane
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
	-- me, wondering why it’s not Jerry Potter………

Re: Debian kernel 2.6.38-5

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>Anyway, plain v2.6.30 should work on Amiga.

Not on his, he’s got the TLS eglibc already. Applying
http://svn.debian.org/viewsvn/kernel/dists/squeeze/linux-2.6/debian/patches/bugfix/m68k/linux-2.6.git-9674cdc74d63f346870943ef966a034f8c71ee57.patch?revision=16861&view=markup
might help, though.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

Re: Debian kernel 2.6.38-5

[Geert Uytterhoeven]

On Sun, May 8, 2011 at 20:49, Thorsten Glaser <tg@mirbsd.de> wrote:
> Geert Uytterhoeven dixit:
>
>>Anyway, plain v2.6.30 should work on Amiga.
>
> Not on his, he’s got the TLS eglibc already. Applying
> http://svn.debian.org/viewsvn/kernel/dists/squeeze/linux-2.6/debian/patches/bugfix/m68k/linux-2.6.git-9674cdc74d63f346870943ef966a034f8c71ee57.patch?revision=16861&view=markup
> might help, though.

Oops yes, forgot about his TLS dependency.

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: Debian kernel 2.6.38-5

[Christian T. Steigies]

On Sun, May 08, 2011 at 06:40:40PM +0000, Thorsten Glaser wrote:
> Christian T. Steigies dixit:
> 
> >> ??? Accepted linux-2.6 2.6.38-5 (source all i386) Ben Hutchings
> >> http://lists.debian.org/debian-devel-changes/2011/05/msg00736.html
> >
> >Why don't you cross-compile it?
> 
> I cross-built the kernels I ran for testing the patches, but that
> was an exception ??? packages that I upload to Debian are *always*
> built natively.

Brave
 
> >How do I get the older versions from Geert's git? I don't see any other
> >branches, I only see tags. What is the magic word to get for example the 2.6.30
> >tree? 
> 
> tg@zigo:~/linux-m68k $ git branch -r

I did not know about -r, it was not mentioned in the tutorial I read...
How do I switch back and forth between different branches? I got a conflict
and could not switch back anymore. Then I deleted all files (except .git), I
should be able to get everything back with git checkout? Well, I didn't. git
newbie here...
 
> >It's been so long, is this the correct way to cross-build linux-m68k?
> 
> sudo cowbuilder --debbuildopts -am68k --binary-arch --build linux*.dsc
> is the correct way in Debian (but will build all 6 images and more; it
> takes about half a day, cross).

I haven't used cowbuilder yet, for debian packages I us this, which I guess
is equivalent to your cowbuilder script:
DEB_HOST_ARCH=m68k debuild -B -am68k
 
> https://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage#Building_only_a_single_kernel_variant
> lists another way, where you only ???dpkg-source -x linux*.dsc??? then
> ???cd linux-*/??? and ???fakeroot debian/rules binary-arch_m68k_none_amiga???
> I think (but cross parameters might need to be added). This is also
> in README.Debian in the source package.

Yes, but I am not trying to build a debian package, I try to build directly
from linux-m68k. This has worked, only the Amiga complained a missing
modules.dep (but I built in the network driver):

make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- 
make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- INSTALL_MOD_PATH=/data/m68k modules_install 

The kernel boots, it configures the network (static). When I try to ping a
host on my network, I get this oops(?).  A few seconds later I also get the
mismatch message I reported earlier (does not show up in dmesg?).

PS 2.6.28 did not boot: kernel too old. When was TLS introduced? I'll try to
apply the patch you mentioned in your other message.

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.39-rc6+ (cts@ima) (gcc version 4.4.6 (Debian 4.4.6-3) ) #1 Sun May 8 19:05:46 CEST 2011
[    0.000000] Enabling workaround for errata I14
[    0.000000] Amiga hardware found: [A3000] VIDEO BLITTER AMBER_FF AUDIO FLOPPY A3000_SCSI KEYBOARD MOUSE SERIAL PARALLEL A3000_CLK CHIP_RAM PAULA DENISE_HR AGNUS_HR_PAL MAGIC_REKICK ZORRO3 
[    0.000000] Ignoring memory chunk at 0x7000000:0x1000000 before the first chunk
[    0.000000] Fix your bootloader or use a memfile to make use of this area!
[    0.000000] On node 0 totalpages: 28672
[    0.000000] free_area_init_node: node 0, pgdat 0036ab74, node_mem_map 003f4000
[    0.000000]   DMA zone: 252 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 28420 pages, LIFO batch:7
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0 
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 28420
[    0.000000] Kernel command line: root=/dev/sda3 fb=false video=amifb:ntsc-lace BOOT_IMAGE=Work:linux/vmlinux-2.6.39+rc6+
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 109496k/109496k available (2776k kernel code, 2280k data, 136k init)
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] Calibrating delay loop... 99.22 BogoMIPS (lpj=496128)
[    0.090000] pid_max: default: 32768 minimum: 301
[    0.090000] Security Framework initialized
[    0.090000] TOMOYO Linux initialized
[    0.090000] Mount-cache hash table entries: 512
[    0.100000] Initializing cgroup subsys ns
[    0.100000] ns_cgroup deprecated: consider using the 'clone_children' flag without the ns_cgroup.
[    0.100000] Initializing cgroup subsys cpuacct
[    0.100000] Initializing cgroup subsys devices
[    0.100000] Initializing cgroup subsys freezer
[    0.110000] devtmpfs: initialized
[    0.120000] NET: Registered protocol family 16
[    0.170000] bio: create slab <bio-0> at 0
[    0.180000] SCSI subsystem initialized
[    0.330000] NET: Registered protocol family 2
[    0.340000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.350000] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.350000] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[    0.350000] TCP: Hash tables configured (established 4096 bind 4096)
[    0.350000] TCP reno registered
[    0.360000] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.360000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.360000] NET: Registered protocol family 1
[    0.390000] VFS: Disk quotas dquot_6.5.2
[    0.390000] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.410000] NTFS driver 2.1.30 [Flags: R/W].
[    0.410000] msgmni has been set to 213
[    0.420000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    0.420000] io scheduler noop registered
[    0.420000] io scheduler deadline registered
[    0.420000] io scheduler cfq registered (default)
[    0.560000] Console: switching to colour frame buffer device 80x25
[    0.620000] fb0: Amiga ECS frame buffer device, using 640K of video memory
[    0.640000] Amiga-builtin serial driver version 4.30
[    0.650000] ttyS0 is the amiga builtin serial port
[    0.660000] FD: probing units
[    0.660000] found 
[    0.670000] fd: drive 0 didn't identify, setting default ffffffff
[    0.680000] fd0 
[    0.790000] brd: module loaded
[    0.800000] Uniform Multi-Platform E-IDE driver
[    0.810000] ide-gd driver 1.18
[    0.820000] ide-cd driver 5.00
[    0.830000] fd: drive 0 didn't identify, setting default ffffffff
[    0.850000] wd33c93-0: chip=WD33c93A/0 no_sync=0xff no_dma=0 debug_flags=0x00
[    0.860000]            setup_args=,,,,,,,,,,
[    0.880000]            Version 1.26++ - 10/Feb/2007, Compiled May  8 2011 at 18:59:13
[    0.890000] scsi0 : Amiga 3000 built-in SCSI
[    0.910000] Zorro: Probing AutoConfig expansion devices: 2 devices
[    0.930000] eth0: Ariadne II at 0x00e90000, Ethernet Address 00:60:30:00:41:5b
[    0.940000] mousedev: PS/2 mouse device common for all mice
[    0.960000] input: amiga-keyboard as /devices/platform/amiga-keyboard/input/input0
[    0.970000] input: amiga-mouse as /devices/platform/amiga-mouse/input/input1
[    1.000000] TCP cubic registered
[    1.010000] NET: Registered protocol family 17
[    1.020000] NET: Registered protocol family 15
[    1.030000] Registering the dns_resolver key type
[    1.040000] registered taskstats version 1
[    1.050000] scsi: waiting for bus probes to complete ...
[    1.410000]  sending SDTR 0103015e00 0103015e00 sync_xfer=30
[    1.430000] scsi 0:0:3:0: CD-ROM            TOSHIBA  CD-ROM XM-5701TA 0167 PQ: 0 ANSI: 2
[    1.680000]  sending SDTR 0103015e00 0103015e00 sync_xfer=30
[    1.710000] scsi 0:0:6:0: Direct-Access     ST325082 4A               3.AA PQ: 0 ANSI: 2
[    1.750000] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    1.770000] sd 0:0:6:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
[    1.780000] sd 0:0:6:0: [sda] Write Protect is off
[    1.790000] sd 0:0:6:0: [sda] Mode Sense: 03 00 00 08
[    1.800000] sd 0:0:6:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.850000]  sda: RDSK (512) sda1 (DOS^C)(res 2 spb 1) sda2 (DOS^C)(res 2 spb 1) sda3 (LNX^@)(res 2 spb 1) sda4 (LNX^@)(res 2 spb 1) sda5 (LNX^@)(res 2 spb 1) sda6 (LNX^@)(res 2 spb 1) sda7 (LNX^@)(res 2 spb 1) sda8 (SWP^@)(res 2 spb 1)
[    1.890000] sd 0:0:6:0: [sda] Attached SCSI disk
[    1.940000] EXT3-fs: barriers not enabled
[    1.960000] kjournald starting.  Commit interval 5 seconds
[    1.970000] EXT3-fs (sda3): mounted filesystem with ordered data mode
[    1.980000] VFS: Mounted root (ext3 filesystem) readonly on device 8:3.
[    2.030000] Not activating Mandatory Access Control now since /sbin/tomoyo-init doesn't exist.
[   13.180000] udevd (74): /proc/74/oom_adj is deprecated, please use /proc/74/oom_score_adj instead.
[   33.560000] Z2RAM: using 0K Zorro II RAM and 1152K Chip RAM (Total 1152K)
[   46.140000] Adding 2096092k swap on /dev/sda8.  Priority:-1 extents:1 across:2096092k 
[   48.550000] EXT3-fs (sda3): using internal journal
[  130.870000] eth0: trigger_send() called with the transmitter busy.
[  132.240000] ------------[ cut here ]------------
[  132.240000] WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x1ac/0x1cc()
[  132.250000] NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
[  132.260000] Modules linked in:
[  132.260000] Call Trace: [<0002a162>] warn_slowpath_common+0x48/0x6a
[  132.270000]  [<0002a170>] warn_slowpath_common+0x56/0x6a
[  132.280000]  [<0002a1fc>] warn_slowpath_fmt+0x2a/0x32
[  132.290000]  [<002511a2>] dev_watchdog+0x1ac/0x1cc
[  132.290000]  [<002511a2>] dev_watchdog+0x1ac/0x1cc
[  132.300000]  [<0003373a>] cascade+0x0/0xb0
[  132.310000]  [<00023c0e>] update_rq_clock+0x24/0x5c
[  132.310000]  [<0000ffff>] stanh+0x103/0x140
[  132.320000]  [<0000ffff>] stanh+0x103/0x140
[  132.320000]  [<000338ea>] run_timer_softirq+0x100/0x2ba
[  132.330000]  [<0000ffff>] stanh+0x103/0x140
[  132.340000]  [<0005b1d4>] rcu_bh_qs+0x0/0x5a
[  132.340000]  [<002b2b42>] printk+0x0/0x18
[  132.350000]  [<00004106>] m68k_handle_int+0x0/0x32
[  132.350000]  [<00250ff6>] dev_watchdog+0x0/0x1cc
[  132.360000]  [<0002ee26>] __do_softirq+0x6e/0xd2
[  132.370000]  [<002b2f1a>] schedule+0x0/0x450
[  132.370000]  [<0002ef5a>] do_softirq+0x28/0x2c
[  132.380000]  [<000026d0>] ret_from_exception+0x0/0xc
[  132.390000]  [<00002aaa>] default_idle+0x0/0xc
[  132.390000]  [<00002cca>] cpu_idle+0x16/0x20
[  132.400000]  [<002b2b42>] printk+0x0/0x18
[  132.410000]  [<003b012a>] start_kernel+0x37e/0x38a
[  132.410000]  [<00006aee>] devm_free_irq+0x1c/0x56
[  132.420000]  [<00006aee>] devm_free_irq+0x1c/0x56
[  132.420000]  [<003af2fc>] _sinittext+0x2fc/0x988
[  132.430000] 
[  132.430000] ---[ end trace baa6881e53412090 ]---
[  132.440000] eth0: Tx timed out, excess collisions. TSR=0xff, ISR=0xff, t=57.
[  132.870000] eth0: trigger_send() called with the transmitter busy.
[  134.240000] eth0: Tx timed out, excess collisions. TSR=0xff, ISR=0xff, t=34.
[  134.900000] eth0: trigger_send() called with the transmitter busy.
[  136.240000] eth0: Tx timed out, excess collisions. TSR=0xff, ISR=0xff, t=34.
[  136.930000] eth0: trigger_send() called with the transmitter busy.
[  138.240000] eth0: Tx timed out, excess collisions. TSR=0xff, ISR=0xff, t=31.
[  138.930000] eth0: trigger_send() called with the transmitter busy.
[  140.240000] eth0: Tx timed out, excess collisions. TSR=0xff, ISR=0xff, t=28.
[  140.960000] eth0: trigger_send() called with the transmitter busy.
[  142.240000] eth0: Tx timed out, excess collisions. TSR=0xff, ISR=0xff, t=28.


Christian

Re: Debian kernel 2.6.38-5

[Geert Uytterhoeven]

On Sun, May 8, 2011 at 22:08, Christian T. Steigies <cts@debian.org> wrote:
> On Sun, May 08, 2011 at 06:40:40PM +0000, Thorsten Glaser wrote:
>> Christian T. Steigies dixit:
>> >How do I get the older versions from Geert's git? I don't see any other
>> >branches, I only see tags. What is the magic word to get for example the 2.6.30
>> >tree?
>>
>> tg@zigo:~/linux-m68k $ git branch -r
>
> I did not know about -r, it was not mentioned in the tutorial I read...
> How do I switch back and forth between different branches? I got a conflict

git checkout <branch>

> and could not switch back anymore. Then I deleted all files (except .git), I
> should be able to get everything back with git checkout? Well, I didn't. git
> newbie here...

`git reset --hard` will reset the state of your checked-out copy.

> Yes, but I am not trying to build a debian package, I try to build directly
> from linux-m68k. This has worked, only the Amiga complained a missing
> modules.dep (but I built in the network driver):
>
> make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu-
> make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- INSTALL_MOD_PATH=/data/m68k modules_install
>
> The kernel boots, it configures the network (static). When I try to ping a
> host on my network, I get this oops(?).  A few seconds later I also get the
> mismatch message I reported earlier (does not show up in dmesg?).

Hmm, tx timed out.

> PS 2.6.28 did not boot: kernel too old. When was TLS introduced? I'll try to
> apply the patch you mentioned in your other message.

m68k-v2.6.32

For older versions, you can use 'git cherry-pick <commit>' to backport.

> [  130.870000] eth0: trigger_send() called with the transmitter busy.

This is the real problem...

> [  132.240000] ------------[ cut here ]------------
> [  132.240000] WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x1ac/0x1cc()
> [  132.250000] NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out

And a bit later the watchdog kicks in.

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: Debian kernel 2.6.38-5

[Michael Schmitz]

On Mon, May 9, 2011 at 12:58 AM, Thorsten Glaser <tg@mirbsd.de> wrote:
> Bad news: Christian T. Steigies has problems on real Amiga hardware:
>
>> However, the current (TLS) kernels have problems with the ariadne2 network
>> card, which, I think all Amigas here but crest have (ariadne1 in crest).
>> I get error messages like this with 2.6.32 and 2.6.38
>>
>>  eth0: mismatched read page pointers 4f vs 4c.
>
> Does that ring a bell anywhere? That’s running 2.6.38-4 plus
> my patches, I think, so I expect 2.6.38-5 won’t change this.

I think I've seen that on occasion on the EtherNEC  (another NE2k
variant) under heavy traffic. From all I can tell it was harmless
(i.e. TCP sorts it out for you).

The transmit timeouts look bad though - is anything ever going out on the wire?

For some reason or other, I haven't had EtherNEC compiled in for quite
some time now. Perhaps it's time to give that another good beating.
Something might have broken in the NE2k code for m68k.

Cheers,

  Michael

Re: Debian kernel 2.6.38-5

[Michael Schmitz]

Christian,

> Yes, but I am not trying to build a debian package, I try to build directly
> from linux-m68k. This has worked, only the Amiga complained a missing
> modules.dep (but I built in the network driver):

Run depmod -a after the Amiga has booted.

> make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu-
> make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- INSTALL_MOD_PATH=/data/m68k modules_install
>
> The kernel boots, it configures the network (static). When I try to ping a
> host on my network, I get this oops(?).  A few seconds later I also get the
> mismatch message I reported earlier (does not show up in dmesg?).

It should show up - if it's being printed to the console it has to be
in the kernel log buffer for klogd to pick up.

Cheers,

  Michael

Re: Debian kernel 2.6.38-5

[Thorsten Glaser]

Christian T. Steigies dixit:

>> I cross-built the kernels I ran for testing the patches, but that
>> was an exception ??? packages that I upload to Debian are *always*
>> built natively.
>
>Brave

No, it’s a must, clean build environment and native builds.
But I’m a BSD person so I’m used to slow boxen ;)

>I haven't used cowbuilder yet, for debian packages I us this, which I guess
>is equivalent to your cowbuilder script:
>DEB_HOST_ARCH=m68k debuild -B -am68k

No, debuild doesn’t create a clean chroot environment with
only the necessary build dependencies installed, and as such
your command, sorry, WILL produce broken packages.

Only cowbuilder, sbuild/buildd and pbuilder (which cowbuilder
is just the user-friendly, decent and fast wrapper around)
can produce “clean” packages. (And can be persuaded to cross-
compile at least binutils; gcc is possible too, easily because
it allows to create a “COW shell”, in which I can then do the
necessary steps.)

>Yes, but I am not trying to build a debian package, I try to build directly
>from linux-m68k.

Yeah but the last time I’ve done that was a one-off with
2.4.3-aa7-aa1-rwsem I think, before that 2.0.3x kernels…

>PS 2.6.28 did not boot: kernel too old. When was TLS introduced?

Much later, 2.6.32 got only a backport of it.

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
	-- me, wondering why it’s not Jerry Potter………

Re: Debian kernel 2.6.38-5

[Christian T. Steigies]

On Mon, May 09, 2011 at 08:58:00AM +1200, Michael Schmitz wrote:
> Christian,
> 
> > Yes, but I am not trying to build a debian package, I try to build directly
> > from linux-m68k. This has worked, only the Amiga complained a missing
> > modules.dep (but I built in the network driver):
> 
> Run depmod -a after the Amiga has booted.

I guess I did not have the modules on the linux partition yet...
 
> > make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu-
> > make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- INSTALL_MOD_PATH=/data/m68k modules_install
> >
> > The kernel boots, it configures the network (static). When I try to ping a
> > host on my network, I get this oops(?).  A few seconds later I also get the
> > mismatch message I reported earlier (does not show up in dmesg?).
> 
> It should show up - if it's being printed to the console it has to be
> in the kernel log buffer for klogd to pick up.

You are right, I did not wait long enough. In 2.6.32 I see it in dmesg, same
error as before :-(
In addition the network module (and I thought it was built in...) did not
get loaded on boot. After insmoding it (modprobe did not work), the errors
came back. In addition sshd was blocking the kernel, so the system was
fairly unresponsive.

2.6.30 with TLS patch does not boot, I guess I did something wrong (do I
need to activate a kernel option?).

enough for today... but since Geert has found the problem, I hope a patch is
not far away :-)

Christian

Re: Debian kernel 2.6.38-5

[Finn Thain]

On Sun, 8 May 2011, Christian T. Steigies wrote:

> 
> PS 2.6.28 did not boot: kernel too old. When was TLS introduced? I'll try to
> apply the patch you mentioned in your other message.

I sometimes test network cards with busybox. It can be built without 
linking in glibc and doesn't need TLS.


> [  130.870000] eth0: trigger_send() called with the transmitter busy.
> [  132.240000] ------------[ cut here ]------------
> [  132.240000] WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x1ac/0x1cc()
> [  132.250000] NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out

Looks a lot like this problem:

http://patchwork.ozlabs.org/patch/27774/

Finn

Re: Debian kernel 2.6.38-5

[Geert Uytterhoeven]

On Mon, May 9, 2011 at 01:14, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Sun, 8 May 2011, Christian T. Steigies wrote:
>> PS 2.6.28 did not boot: kernel too old. When was TLS introduced? I'll try to
>> apply the patch you mentioned in your other message.
>
> I sometimes test network cards with busybox. It can be built without
> linking in glibc and doesn't need TLS.
>
>
>> [  130.870000] eth0: trigger_send() called with the transmitter busy.
>> [  132.240000] ------------[ cut here ]------------
>> [  132.240000] WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x1ac/0x1cc()
>> [  132.250000] NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
>
> Looks a lot like this problem:
>
> http://patchwork.ozlabs.org/patch/27774/

Yeah, that's a very likely culprit. Thx!

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: Debian kernel 2.6.38-5

[Christian T. Steigies]

On Mon, May 09, 2011 at 09:16:16AM +0200, Geert Uytterhoeven wrote:
> On Mon, May 9, 2011 at 01:14, Finn Thain <fthain@telegraphics.com.au> wrote:
> > On Sun, 8 May 2011, Christian T. Steigies wrote:
> >> PS 2.6.28 did not boot: kernel too old. When was TLS introduced? I'll try to
> >> apply the patch you mentioned in your other message.
> >
> > I sometimes test network cards with busybox. It can be built without
> > linking in glibc and doesn't need TLS.
> >
> >
> >> [  130.870000] eth0: trigger_send() called with the transmitter busy.
> >> [  132.240000] ------------[ cut here ]------------
> >> [  132.240000] WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x1ac/0x1cc()
> >> [  132.250000] NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
> >
> > Looks a lot like this problem:
> >
> > http://patchwork.ozlabs.org/patch/27774/
> 
> Yeah, that's a very likely culprit. Thx!

I applied the following patch and it works! apt-get update that is, there is
no sshd on this freshly installed system yet...

I also changed this line to have 4 underscores at the beginning:

	{ 0xec940559, "____alloc_ei_netdev" },

it does not show up in git diff, so I am not sure if this is a leftover from
a previous checkout, or if it is also needed. And if it is needed, if it
should be two underscores or four or none, and if so why or why not...
Looking at the other drivers, there does not seem to be a lot of consistency?

thanks Finn!
Christian

diff --git a/drivers/net/zorro8390.c b/drivers/net/zorro8390.c
index b78a38d9..8c7c522 100644
--- a/drivers/net/zorro8390.c
+++ b/drivers/net/zorro8390.c
@@ -126,7 +126,7 @@ static int __devinit zorro8390_init_one(struct zorro_dev *z,
 
     board = z->resource.start;
     ioaddr = board+cards[i].offset;
-    dev = alloc_ei_netdev();
+    dev = ____alloc_ei_netdev(0);
     if (!dev)
 	return -ENOMEM;
     if (!request_mem_region(ioaddr, NE_IO_EXTENT*2, DRV_NAME)) {
@@ -146,15 +146,15 @@ static int __devinit zorro8390_init_one(struct zorro_dev *z,
 static const struct net_device_ops zorro8390_netdev_ops = {
 	.ndo_open		= zorro8390_open,
 	.ndo_stop		= zorro8390_close,
-	.ndo_start_xmit		= ei_start_xmit,
-	.ndo_tx_timeout		= ei_tx_timeout,
-	.ndo_get_stats		= ei_get_stats,
-	.ndo_set_multicast_list = ei_set_multicast_list,
+	.ndo_start_xmit		= __ei_start_xmit,
+	.ndo_tx_timeout		= __ei_tx_timeout,
+	.ndo_get_stats		= __ei_get_stats,
+	.ndo_set_multicast_list = __ei_set_multicast_list,
 	.ndo_validate_addr	= eth_validate_addr,
 	.ndo_set_mac_address 	= eth_mac_addr,
 	.ndo_change_mtu		= eth_change_mtu,
 #ifdef CONFIG_NET_POLL_CONTROLLER
-	.ndo_poll_controller	= ei_poll,
+	.ndo_poll_controller	= __ei_poll,
 #endif
 };
 

zorro8390 (was: Re: Debian kernel 2.6.38-5)

[Geert Uytterhoeven]

On Mon, 9 May 2011, Finn Thain wrote:
> On Sun, 8 May 2011, Christian T. Steigies wrote:
> > [  130.870000] eth0: trigger_send() called with the transmitter busy.
> > [  132.240000] ------------[ cut here ]------------
> > [  132.240000] WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x1ac/0x1cc()
> > [  132.250000] NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
> 
> Looks a lot like this problem:
> 
> http://patchwork.ozlabs.org/patch/27774/

Does the patch below fix it?
If yes, hydra and ne-h8300 are probably affected, too, as they include
lib8390.c theirselves and are linked with 8390.o.

>From 7e1d9c48bda247d77e7d478d43fc0b9dd1d6c515 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Mon, 9 May 2011 22:19:31 +0200
Subject: [PATCH] zorro8390: Fix regression caused during net_device_ops conversion

Changeset b6114794a1c394534659f4a17420e48cf23aa922 ("zorro8390: convert to
net_device_ops") broke zorro8390 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in zorro8390.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c.

Fix based on commit 217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390: fix
regression caused during net_device_ops conversion) and
4e0168fa4842e27795a75b205a510f25b62181d9 ("mac8390: fix build with
NET_POLL_CONTROLLER").

Reported-by: Christian T. Steigies <cts@debian.org>
Suggested-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 drivers/net/Makefile    |    2 +-
 drivers/net/zorro8390.c |   12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 9ba2838..501fe36 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -219,7 +219,7 @@ obj-$(CONFIG_SC92031) += sc92031.o
 obj-$(CONFIG_LP486E) += lp486e.o
 
 obj-$(CONFIG_ETH16I) += eth16i.o
-obj-$(CONFIG_ZORRO8390) += zorro8390.o 8390.o
+obj-$(CONFIG_ZORRO8390) += zorro8390.o
 obj-$(CONFIG_HPLANCE) += hplance.o 7990.o
 obj-$(CONFIG_MVME147_NET) += mvme147.o 7990.o
 obj-$(CONFIG_EQUALIZER) += eql.o
diff --git a/drivers/net/zorro8390.c b/drivers/net/zorro8390.c
index b78a38d..8c7c522 100644
--- a/drivers/net/zorro8390.c
+++ b/drivers/net/zorro8390.c
@@ -126,7 +126,7 @@ static int __devinit zorro8390_init_one(struct zorro_dev *z,
 
     board = z->resource.start;
     ioaddr = board+cards[i].offset;
-    dev = alloc_ei_netdev();
+    dev = ____alloc_ei_netdev(0);
     if (!dev)
 	return -ENOMEM;
     if (!request_mem_region(ioaddr, NE_IO_EXTENT*2, DRV_NAME)) {
@@ -146,15 +146,15 @@ static int __devinit zorro8390_init_one(struct zorro_dev *z,
 static const struct net_device_ops zorro8390_netdev_ops = {
 	.ndo_open		= zorro8390_open,
 	.ndo_stop		= zorro8390_close,
-	.ndo_start_xmit		= ei_start_xmit,
-	.ndo_tx_timeout		= ei_tx_timeout,
-	.ndo_get_stats		= ei_get_stats,
-	.ndo_set_multicast_list = ei_set_multicast_list,
+	.ndo_start_xmit		= __ei_start_xmit,
+	.ndo_tx_timeout		= __ei_tx_timeout,
+	.ndo_get_stats		= __ei_get_stats,
+	.ndo_set_multicast_list = __ei_set_multicast_list,
 	.ndo_validate_addr	= eth_validate_addr,
 	.ndo_set_mac_address 	= eth_mac_addr,
 	.ndo_change_mtu		= eth_change_mtu,
 #ifdef CONFIG_NET_POLL_CONTROLLER
-	.ndo_poll_controller	= ei_poll,
+	.ndo_poll_controller	= __ei_poll,
 #endif
 };
 
-- 
1.7.0.4

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: Debian kernel 2.6.38-5

[Michael Schmitz]

Christian,


> I applied the following patch and it works! apt-get update that is, there is
> no sshd on this freshly installed system yet...
>
> I also changed this line to have 4 underscores at the beginning:
>
>        { 0xec940559, "____alloc_ei_netdev" },

Where does that appear? Can't find it in drivers/net anywhere.

> it does not show up in git diff, so I am not sure if this is a leftover from
> a previous checkout, or if it is also needed. And if it is needed, if it
> should be two underscores or four or none, and if so why or why not...
> Looking at the other drivers, there does not seem to be a lot of consistency?

____alloc_ei_netdev is the function defined in lib8390.c which is
called by the individual drivers from their respective
__alloc_ei_netdev().

The only symbol exported by zorro8390.c should be __alloc_ei_netdev -
if your above change was done in some symbol exports file it should
probably have been left at __alloc_ei_netdev.

Cheers,

  Michael

Re: Debian kernel 2.6.38-5

[Christian T. Steigies]

On Tue, May 10, 2011 at 10:49:45AM +1200, Michael Schmitz wrote:
> Christian,
> 
> 
> > I applied the following patch and it works! apt-get update that is, there is
> > no sshd on this freshly installed system yet...
> >
> > I also changed this line to have 4 underscores at the beginning:
> >
> >        { 0xec940559, "____alloc_ei_netdev" },
> 
> Where does that appear? Can't find it in drivers/net anywhere.

It's in zorro8390.mod.c, but *.mod.c is listed in .gitignore, so it must be
a remnant of my experiments with git and older branches. I wonder why it has
been compiled, though, I did not change any of the Makefiles.
 
> > it does not show up in git diff, so I am not sure if this is a leftover from
> > a previous checkout, or if it is also needed. And if it is needed, if it
> > should be two underscores or four or none, and if so why or why not...
> > Looking at the other drivers, there does not seem to be a lot of consistency?
> 
> ____alloc_ei_netdev is the function defined in lib8390.c which is
> called by the individual drivers from their respective
> __alloc_ei_netdev().
> 
> The only symbol exported by zorro8390.c should be __alloc_ei_netdev -
> if your above change was done in some symbol exports file it should
> probably have been left at __alloc_ei_netdev.

I did none of that, but to be sure, I should build another kernel with
Geert's patch on a clean checkout. 

I installed a few packages, rebooted to check if the network is set up
automatically (it is!), and installed more packages. Now I am upgrading
some more and I see reasonable download speeds: 140kB/s. However, I also saw
this flying by:

eth0: Interrupted while interrupts are masked! isr=0x0 imr=0x0.

Three times in about one minute. The whole system is a bit more responsive
now (I an log in on a second console without a long delay). I could not log
in with ssh yet, though I get a little bit further than yesterday, there is
some response already from the remote system.

Christian

Re: Debian kernel 2.6.38-5

[Michael Schmitz]

Hi Christian,

>> > I also changed this line to have 4 underscores at the beginning:
>> >
>> >        { 0xec940559, "____alloc_ei_netdev" },
>>
>> Where does that appear? Can't find it in drivers/net anywhere.
>
> It's in zorro8390.mod.c, but *.mod.c is listed in .gitignore, so it must be
> a remnant of my experiments with git and older branches. I wonder why it has
> been compiled, though, I did not change any of the Makefiles.

This is being compiled whenever zorro8390.c is compiled as module - do
not change it.

>> The only symbol exported by zorro8390.c should be __alloc_ei_netdev -
>> if your above change was done in some symbol exports file it should
>> probably have been left at __alloc_ei_netdev.
>
> I did none of that, but to be sure, I should build another kernel with
> Geert's patch on a clean checkout.

Should not change anything - the .mod.c should be rebuilt when any
dependent file is changed.

> I installed a few packages, rebooted to check if the network is set up
> automatically (it is!), and installed more packages. Now I am upgrading
> some more and I see reasonable download speeds: 140kB/s. However, I also saw
> this flying by:
>
> eth0: Interrupted while interrupts are masked! isr=0x0 imr=0x0.

Looks like you're not getting packets off the card fast enough on
receive. I'd have to look at the source to know what the status and
mask register values mean though.

> Three times in about one minute. The whole system is a bit more responsive
> now (I an log in on a second console without a long delay). I could not log
> in with ssh yet, though I get a little bit further than yesterday, there is
> some response already from the remote system.

ssh login should work if sshd is up and running, and the network
appears to be working as you describe.

Cheers,

  MIchael

Re: Debian kernel 2.6.38-5

[Geert Uytterhoeven]

On Mon, May 9, 2011 at 01:14, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Sun, 8 May 2011, Christian T. Steigies wrote:
>>
>> PS 2.6.28 did not boot: kernel too old. When was TLS introduced? I'll try to
>> apply the patch you mentioned in your other message.
>
> I sometimes test network cards with busybox. It can be built without
> linking in glibc and doesn't need TLS.
>
>
>> [  130.870000] eth0: trigger_send() called with the transmitter busy.
>> [  132.240000] ------------[ cut here ]------------
>> [  132.240000] WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x1ac/0x1cc()
>> [  132.250000] NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
>
> Looks a lot like this problem:
>
> http://patchwork.ozlabs.org/patch/27774/

Finn, could it also work if you remove the "#include "lib8390.c" from *8390.c?
That would reduce code size for distro kernels, which would have too many copies
of lib8390.c (for zorro8390, mac8390, hydra)?

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: Debian kernel 2.6.38-5

[Finn Thain]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2008 bytes --]


On Tue, 10 May 2011, Geert Uytterhoeven wrote:

> On Mon, May 9, 2011 at 01:14, Finn Thain <fthain@telegraphics.com.au> 
> wrote:
> > On Sun, 8 May 2011, Christian T. Steigies wrote:
> >>
> >> PS 2.6.28 did not boot: kernel too old. When was TLS introduced? I'll 
> >> try to apply the patch you mentioned in your other message.
> >
> > I sometimes test network cards with busybox. It can be built without 
> > linking in glibc and doesn't need TLS.
> >
> >
> >> [  130.870000] eth0: trigger_send() called with the transmitter busy.
> >> [  132.240000] ------------[ cut here ]------------
> >> [  132.240000] WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0x1ac/0x1cc()
> >> [  132.250000] NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
> >
> > Looks a lot like this problem:
> >
> > http://patchwork.ozlabs.org/patch/27774/
> 
> Finn, could it also work if you remove the "#include "lib8390.c" from 
> *8390.c? That would reduce code size for distro kernels, which would 
> have too many copies of lib8390.c (for zorro8390, mac8390, hydra)?

ISTR that I tried the approach you suggest back when I fixed mac8390 but 
couldn't make it fly but I don't recall why not.

I see that ax88796.c and ne-h8300.c also #include <lib8390.c>. In 
ax88796.c I find this:

#define __ei_open ax_ei_open
#define __ei_close ax_ei_close
...
#include "lib8390.c"

which would have been better than my patch for mac8390; without this 
renaming you may not be able to link a sane multi-sub-arch m68k kernel. 
OTOH, I don't know if it is possible to build a single 8390.o that can 
work for multiple drivers either.

BTW, ne-h8300 appears to lack the fixes in your patch and mine and so it 
probably doesn't work properly either.

I'm not really sure how to tackle this; I'd like to think that we could 
use 8390.o for the m68k drivers at least but I need to investigate 
further.

Finn

> 
> Gr{oetje,eeting}s,
> 
>                         Geert

Re: Debian kernel 2.6.38-5

[Geert Uytterhoeven]

On Tue, May 10, 2011 at 13:57, Finn Thain <fthain@telegraphics.com.au> wrote:
> BTW, ne-h8300 appears to lack the fixes in your patch and mine and so it
> probably doesn't work properly either.

Yep, just like hydra.

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