watchdog (?) on linux 3.0.0 and 2.6.39.3

watchdog (?) on linux 3.0.0 and 2.6.39.3

[Tuomas Vainikka]

Hello,

This happens with both stable 3.0.0 and 2.6.39.3 kernels:

------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x1a4/0x1c4()
NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
Modules linked in: nfsd exportfs ipv6 gayle parport_amiga amiflop 
dmasound_paula ide_core parport dmasound_core amimouse soundcore
Call Trace: [<0001c134>] warn_slowpath_common+0x48/0x6a
  [<0001c142>] warn_slowpath_common+0x56/0x6a
  [<0001c1ce>] warn_slowpath_fmt+0x2a/0x32
  [<001cbff6>] dev_watchdog+0x1a4/0x1c4
  [<001cbff6>] dev_watchdog+0x1a4/0x1c4
  [<00025b9c>] run_timer_softirq+0xce/0x224
  [<0000ffff>] _060_fpsp_effadd+0x83e3/0xd518
  [<00044424>] rcu_bh_qs+0x0/0x2e
  [<0023eb90>] printk+0x0/0x18
  [<000208fc>] __do_softirq+0x88/0xc8
  [<002406b4>] schedule+0x0/0x34e
  [<00020a0c>] do_softirq+0x28/0x2c
  [<000025f0>] ret_from_exception+0x0/0xc
  [<00002892>] default_idle+0x0/0xc
  [<000028e2>] cpu_idle+0x16/0x20
  [<0023eb90>] printk+0x0/0x18
  [<002fefd0>] start_kernel+0x33a/0x348
  [<0000f9a2>] _060_fpsp_effadd+0x7d86/0xd518
  [<0000f9a2>] _060_fpsp_effadd+0x7d86/0xd518
  [<002fe2fc>] _sinittext+0x2fc/0x988

---[ end trace 9649de43a8c19796 ]---

The message above comes only once.

Then, there's a lot of these:

eth0: Tx timed out, lost interrupt? TSR=0x4, ISR=0x15, t=52.
eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=33.
eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=36.

but the PCMCIA network card of mine can also be flakey.

Both kernels have been cross-compiled with gcc 4.6.1.
I'll be happy to provide you with the kernel config and the full dmesg 
output if you need them.

Regards,
Tuomas

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Geert Uytterhoeven]

On Mon, Aug 1, 2011 at 14:12, Tuomas Vainikka <tuomas.vainikka@aalto.fi> wrote:
> This happens with both stable 3.0.0 and 2.6.39.3 kernels:
>
> ------------[ cut here ]------------
> WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x1a4/0x1c4()
> NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
> Modules linked in: nfsd exportfs ipv6 gayle parport_amiga amiflop
> dmasound_paula ide_core parport dmasound_core amimouse soundcore
> Call Trace: [<0001c134>] warn_slowpath_common+0x48/0x6a
>  [<0001c142>] warn_slowpath_common+0x56/0x6a
>  [<0001c1ce>] warn_slowpath_fmt+0x2a/0x32
>  [<001cbff6>] dev_watchdog+0x1a4/0x1c4
>  [<001cbff6>] dev_watchdog+0x1a4/0x1c4
>  [<00025b9c>] run_timer_softirq+0xce/0x224
>  [<0000ffff>] _060_fpsp_effadd+0x83e3/0xd518
>  [<00044424>] rcu_bh_qs+0x0/0x2e
>  [<0023eb90>] printk+0x0/0x18
>  [<000208fc>] __do_softirq+0x88/0xc8
>  [<002406b4>] schedule+0x0/0x34e
>  [<00020a0c>] do_softirq+0x28/0x2c
>  [<000025f0>] ret_from_exception+0x0/0xc
>  [<00002892>] default_idle+0x0/0xc
>  [<000028e2>] cpu_idle+0x16/0x20
>  [<0023eb90>] printk+0x0/0x18
>  [<002fefd0>] start_kernel+0x33a/0x348
>  [<0000f9a2>] _060_fpsp_effadd+0x7d86/0xd518
>  [<0000f9a2>] _060_fpsp_effadd+0x7d86/0xd518
>  [<002fe2fc>] _sinittext+0x2fc/0x988
>
> ---[ end trace 9649de43a8c19796 ]---
>
> The message above comes only once.
>
> Then, there's a lot of these:
>
> eth0: Tx timed out, lost interrupt? TSR=0x4, ISR=0x15, t=52.
> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=33.
> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=36.
>
> but the PCMCIA network card of mine can also be flakey.

This is the apne driver? Another 8390 driver that has tx timeouts :-(

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: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Finn Thain]

On Mon, 1 Aug 2011, Tuomas Vainikka wrote:

> NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
...
> eth0: Tx timed out, lost interrupt? TSR=0x4, ISR=0x15, t=52.
> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=33.
> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=36.

This differs from the earlier bug report, where the kernel complained of 
"mismatched read page pointers". But the timeout is the same.

Perhaps you could build and test a new kernel with no DP8390-based driver 
except apne (probably easiest to disable all ethernet drivers except 
CONFIG_APNE).

Please let us know if that helps, as it may shed some light on the other 
bug too.

Finn

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Tuomas Vainikka]

On 08/02/2011 08:33 AM, Finn Thain wrote:
> On Mon, 1 Aug 2011, Tuomas Vainikka wrote:
>
>> NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
> ...
>> eth0: Tx timed out, lost interrupt? TSR=0x4, ISR=0x15, t=52.
>> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=33.
>> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=36.
> This differs from the earlier bug report, where the kernel complained of
> "mismatched read page pointers". But the timeout is the same.
>
> Perhaps you could build and test a new kernel with no DP8390-based driver
> except apne (probably easiest to disable all ethernet drivers except
> CONFIG_APNE).
>
> Please let us know if that helps, as it may shed some light on the other
> bug too.
>
> Finn

Hello,

The other network drivers were previously compiled as modules, and I 
only had apne built-in.
Now I removed the other drivers being built in any way, but I still get 
an error:

------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x1a4/0x1c4()
NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
Modules linked in: parport_amiga(+) gayle(+) dmasound_paula amimouse 
parport ide_core dmasound_core soundcore amiflop
Call Trace: [<0001c134>] warn_slowpath_common+0x48/0x6a
  [<0001c142>] warn_slowpath_common+0x56/0x6a
  [<0001c1ce>] warn_slowpath_fmt+0x2a/0x32
  [<001cefb2>] dev_watchdog+0x1a4/0x1c4
  [<001cefb2>] dev_watchdog+0x1a4/0x1c4
  [<00025b9c>] run_timer_softirq+0xce/0x224
  [<00044b10>] rcu_bh_qs+0x0/0x2e
  [<00241b44>] printk+0x0/0x18
  [<000208fc>] __do_softirq+0x88/0xc8
  [<0006ac22>] kmem_cache_alloc+0x0/0x74
  [<00020a0c>] do_softirq+0x28/0x2c
  [<000025f0>] ret_from_exception+0x0/0xc
  [<00081f2a>] dup_fd+0x24/0x258
  [<0006ac22>] kmem_cache_alloc+0x0/0x74
  [<0001b4c2>] copy_process+0x7de/0xb0c
  [<0001b894>] do_fork+0x8c/0x1f2
  [<00002a3c>] m68k_clone+0x2c/0x34
  [<0000275e>] sys_clone+0xe/0x18
  [<000025be>] syscall+0x8/0xc
  [<0010c00c>] decode_fsinfo+0x2f4/0x460

---[ end trace 29b6452540065c1f ]---

The error is a bit different, and seems to happen at an earlier stage 
than the previously reported one, since parport and gayle are not yet 
inserted.
The end of dmesg output is again:

...
eth0: Tx timed out, lost interrupt? TSR=0x4, ISR=0x15, t=78.
eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=39.
eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=28.
eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=94.
eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x17, t=27.
eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=93.

These outputs are from a cross-compiled linux 3.0.0.


Regards,
Tuomas

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Michael Schmitz]

On Fri, Aug 5, 2011 at 4:59 AM, Tuomas Vainikka
<tuomas.vainikka@aalto.fi> wrote:
> Hello,
>
> The other network drivers were previously compiled as modules, and I only
> had apne built-in.
> Now I removed the other drivers being built in any way, but I still get an
> error:

Is there a way to get timestamps logged with each of the entries in
the call trace below (i.e. could we rig some profiling code for that)?
Would be interesting to know where exactly the kernel was spinning
when the watchdog fired. But maybe that's obvious to someone.

Are there potential deadlocks with printk called from softirq context
(I think not ...)? What is the message printed immediately after the
trace?

Last - has anyone ever tried to bisect this?

Cheers,

  Michael


>
> ------------[ cut here ]------------
> WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0x1a4/0x1c4()
> NETDEV WATCHDOG: eth0 (): transmit queue 0 timed out
> Modules linked in: parport_amiga(+) gayle(+) dmasound_paula amimouse parport
> ide_core dmasound_core soundcore amiflop
> Call Trace: [<0001c134>] warn_slowpath_common+0x48/0x6a
>  [<0001c142>] warn_slowpath_common+0x56/0x6a
>  [<0001c1ce>] warn_slowpath_fmt+0x2a/0x32
>  [<001cefb2>] dev_watchdog+0x1a4/0x1c4
>  [<001cefb2>] dev_watchdog+0x1a4/0x1c4
>  [<00025b9c>] run_timer_softirq+0xce/0x224
>  [<00044b10>] rcu_bh_qs+0x0/0x2e
>  [<00241b44>] printk+0x0/0x18
>  [<000208fc>] __do_softirq+0x88/0xc8
>  [<0006ac22>] kmem_cache_alloc+0x0/0x74
>  [<00020a0c>] do_softirq+0x28/0x2c
>  [<000025f0>] ret_from_exception+0x0/0xc
>  [<00081f2a>] dup_fd+0x24/0x258
>  [<0006ac22>] kmem_cache_alloc+0x0/0x74
>  [<0001b4c2>] copy_process+0x7de/0xb0c
>  [<0001b894>] do_fork+0x8c/0x1f2
>  [<00002a3c>] m68k_clone+0x2c/0x34
>  [<0000275e>] sys_clone+0xe/0x18
>  [<000025be>] syscall+0x8/0xc
>  [<0010c00c>] decode_fsinfo+0x2f4/0x460
>
> ---[ end trace 29b6452540065c1f ]---
>
> The error is a bit different, and seems to happen at an earlier stage than
> the previously reported one, since parport and gayle are not yet inserted.
> The end of dmesg output is again:
>
> ...
> eth0: Tx timed out, lost interrupt? TSR=0x4, ISR=0x15, t=78.
> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=39.
> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=28.
> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=94.
> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x17, t=27.
> eth0: Tx timed out, lost interrupt? TSR=0x5, ISR=0x3, t=93.
>
> These outputs are from a cross-compiled linux 3.0.0.
>
>
> Regards,
> Tuomas
> --
> 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: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Finn Thain]

On Fri, 5 Aug 2011, Michael Schmitz wrote:

> 
> Last - has anyone ever tried to bisect this?

I think that's going to be the best approach. I've run out of ideas and I 
haven't been able to reproduce the problem. (I have more 8390 cards that I 
can test but no amiga hardware.)

Finn

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Tuomas Vainikka]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

On 08/04/2011 11:45 PM, Michael Schmitz wrote:
> On Fri, Aug 5, 2011 at 4:59 AM, Tuomas Vainikka
> <tuomas.vainikka@aalto.fi>  wrote:
>> Hello,
>>
>> The other network drivers were previously compiled as modules, and I only
>> had apne built-in.
>> Now I removed the other drivers being built in any way, but I still get an
>> error:
> Is there a way to get timestamps logged with each of the entries in
> the call trace below (i.e. could we rig some profiling code for that)?
> Would be interesting to know where exactly the kernel was spinning
> when the watchdog fired. But maybe that's obvious to someone.
>
> Are there potential deadlocks with printk called from softirq context
> (I think not ...)? What is the message printed immediately after the
> trace?
I've attached full dmesg outputs from ten sequential boots with the 
kernel config.
You can see that the trace can happen any time, or not at all.
> Last - has anyone ever tried to bisect this?
>
> Cheers,
>
>    Michael
>


[-- Attachment #2: dmesg.tar.gz --]
[-- Type: application/x-gzip, Size: 16070 bytes --]

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Michael Schmitz]

Hi Tuomas,

there is a pattern to this - most of the times the watchdog fires when 
the IDE interface is probed. In that case we have  TSR=0x3, ISR=0x3 
(need to look up what that means in the driver headers).

Other times, it is either the floppy interface getting probed, or in one 
case, the mouse. The TSR is different there (0x5).

It appears interrupts from the card get lost when other drivers disable 
interrupts for too long. I'd go back to a version of the kernel before 
we moved to the genirq framework (that was at the end of May this year). 
If that still works, bisect from there (man git-bisect) to find the 
approximate commit that broke Amiga ethernet.

If you cannot use git-bisect, I'd have to build kernels for you to test 
again and again until we find the last one that works - quite slow a 
procedure but it might be the only thing.

Geert: is the genirq change simple to back out, just for tests?

Cheers,

   Michael

On 05/08/11 23:53, Tuomas Vainikka wrote:
> On 08/04/2011 11:45 PM, Michael Schmitz wrote:
>> On Fri, Aug 5, 2011 at 4:59 AM, Tuomas Vainikka
>> <tuomas.vainikka@aalto.fi>  wrote:
>>> Hello,
>>>
>>> The other network drivers were previously compiled as modules, and I 
>>> only
>>> had apne built-in.
>>> Now I removed the other drivers being built in any way, but I still 
>>> get an
>>> error:
>> Is there a way to get timestamps logged with each of the entries in
>> the call trace below (i.e. could we rig some profiling code for that)?
>> Would be interesting to know where exactly the kernel was spinning
>> when the watchdog fired. But maybe that's obvious to someone.
>>
>> Are there potential deadlocks with printk called from softirq context
>> (I think not ...)? What is the message printed immediately after the
>> trace?
> I've attached full dmesg outputs from ten sequential boots with the 
> kernel config.
> You can see that the trace can happen any time, or not at all.
>> Last - has anyone ever tried to bisect this?
>>
>> Cheers,
>>
>>    Michael
>>
>

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Geert Uytterhoeven]

On Sat, Aug 6, 2011 at 00:32, Michael Schmitz <schmitzmic@googlemail.com> wrote:
> there is a pattern to this - most of the times the watchdog fires when the
> IDE interface is probed. In that case we have  TSR=0x3, ISR=0x3 (need to
> look up what that means in the driver headers).
>
> Other times, it is either the floppy interface getting probed, or in one
> case, the mouse. The TSR is different there (0x5).
>
> It appears interrupts from the card get lost when other drivers disable
> interrupts for too long. I'd go back to a version of the kernel before we
> moved to the genirq framework (that was at the end of May this year). If
> that still works, bisect from there (man git-bisect) to find the approximate
> commit that broke Amiga ethernet.
>
> If you cannot use git-bisect, I'd have to build kernels for you to test
> again and again until we find the last one that works - quite slow a
> procedure but it might be the only thing.
>
> Geert: is the genirq change simple to back out, just for tests?

The genirq conversion is not complete, and not yet on the master branch.
So it's unrelated.

> On 05/08/11 23:53, Tuomas Vainikka wrote:
>>
>> On 08/04/2011 11:45 PM, Michael Schmitz wrote:
>>>
>>> On Fri, Aug 5, 2011 at 4:59 AM, Tuomas Vainikka
>>> <tuomas.vainikka@aalto.fi>  wrote:
>>>>
>>>> Hello,
>>>>
>>>> The other network drivers were previously compiled as modules, and I
>>>> only
>>>> had apne built-in.
>>>> Now I removed the other drivers being built in any way, but I still get
>>>> an
>>>> error:
>>>
>>> Is there a way to get timestamps logged with each of the entries in
>>> the call trace below (i.e. could we rig some profiling code for that)?
>>> Would be interesting to know where exactly the kernel was spinning
>>> when the watchdog fired. But maybe that's obvious to someone.
>>>
>>> Are there potential deadlocks with printk called from softirq context
>>> (I think not ...)? What is the message printed immediately after the
>>> trace?
>>
>> I've attached full dmesg outputs from ten sequential boots with the kernel
>> config.
>> You can see that the trace can happen any time, or not at all.
>>>
>>> Last - has anyone ever tried to bisect this?

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: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Michael Schmitz]

Hi Geert,

>> Geert: is the genirq change simple to back out, just for tests?
>
> The genirq conversion is not complete, and not yet on the master branch.
> So it's unrelated.

Thanks for clarifying - if there had been any major change to the
Amiga interrupt code I'm sure you would have mentioned.

Christian - can you remember which 2.6 kernel that last had ethernet
working for you?

Cheers,

  Michael

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Christian T. Steigies]

On Mon, Aug 08, 2011 at 08:01:33AM +1200, Michael Schmitz wrote:
> Hi Geert,
> 
> >> Geert: is the genirq change simple to back out, just for tests?
> >
> > The genirq conversion is not complete, and not yet on the master branch.
> > So it's unrelated.
> 
> Thanks for clarifying - if there had been any major change to the
> Amiga interrupt code I'm sure you would have mentioned.
> 
> Christian - can you remember which 2.6 kernel that last had ethernet
> working for you?

I haven't been testing kernels a lot recently... from the logfiles it would
seem the last kernel that was running on kullervo was this one:

Linux version 2.6.24-1-amiga (Debian 2.6.24-4) (waldi@debian.org) (gcc version 3.3.6) #1 Tue Feb 12 10:05:37 CET 2008

I think the kernel from Stephens d-i image was working also, but I have not
tested that intensively, only for installing from scratch. In May I wrote
this was:

Linux kullervo 2.6.26-1-amiga #1 Thu Oct 16 08:59:25 CDT 2008 m68k GNU/Linux

Christian

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Michael Schmitz]

Hi Christian,

>> Christian - can you remember which 2.6 kernel that last had ethernet
>> working for you?
>
> I haven't been testing kernels a lot recently... from the logfiles it would
> seem the last kernel that was running on kullervo was this one:
>
> Linux version 2.6.24-1-amiga (Debian 2.6.24-4) (waldi@debian.org) (gcc version 3.3.6) #1 Tue Feb 12 10:05:37 CET 2008
>
> I think the kernel from Stephens d-i image was working also, but I have not
> tested that intensively, only for installing from scratch. In May I wrote
> this was:
>
> Linux kullervo 2.6.26-1-amiga #1 Thu Oct 16 08:59:25 CDT 2008 m68k GNU/Linux

Thanks, I'll look up the likely commit to start from using 2.6.24
then. I have the .config Tuomas used for his kernel - do you need any
modules built as well, Tuomas?

Cheers,

  Michael

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Tuomas Vainikka]

On 08/08/2011 03:23 AM, Michael Schmitz wrote:
> Hi Christian,
>
>>> Christian - can you remember which 2.6 kernel that last had ethernet
>>> working for you?
>> I haven't been testing kernels a lot recently... from the logfiles it would
>> seem the last kernel that was running on kullervo was this one:
>>
>> Linux version 2.6.24-1-amiga (Debian 2.6.24-4) (waldi@debian.org) (gcc version 3.3.6) #1 Tue Feb 12 10:05:37 CET 2008
>>
>> I think the kernel from Stephens d-i image was working also, but I have not
>> tested that intensively, only for installing from scratch. In May I wrote
>> this was:
>>
>> Linux kullervo 2.6.26-1-amiga #1 Thu Oct 16 08:59:25 CDT 2008 m68k GNU/Linux
> Thanks, I'll look up the likely commit to start from using 2.6.24
> then. I have the .config Tuomas used for his kernel - do you need any
> modules built as well, Tuomas?
>
>
I believe that with the .config I provided none of the modules are 
obligatory, but the IDE and floppy modules would be nice, since, as you 
pointed out, the watchdog barks once they are probed.
You could also go for amiga_defconfig with built-in apne and nfsroot.

Regards,
Tuomas

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Michael Schmitz]

Hi Christian,
>> Christian - can you remember which 2.6 kernel that last had ethernet
>> working for you?
>>     
>
> I haven't been testing kernels a lot recently... from the logfiles it would
> seem the last kernel that was running on kullervo was this one:
>
> Linux version 2.6.24-1-amiga (Debian 2.6.24-4) (waldi@debian.org) (gcc version 3.3.6) #1 Tue Feb 12 10:05:37 CET 2008
>   
Plain 2.6.24 from Geert's tree does show TX timeouts again - no watchdog 
firing this time because IDE wasn't even built as module (something 
cause make oldconfig to drop all IDE stuff when starting from Tuomas' 
.config).

Speaking of which - I cannot even build IDE at all in that release:

  CC [M]  drivers/ide/ide-lib.o
drivers/ide/ide-lib.c: In function `ide_dump_atapi_status':
drivers/ide/ide-lib.c:601: internal compiler error: in 
verify_local_live_at_start, at flow.c:600
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

I'm sure we've seen that before and it did eventually get fixed.
> I think the kernel from Stephens d-i image was working also, but I have not
> tested that intensively, only for installing from scratch. In May I wrote
> this was:
>
> Linux kullervo 2.6.26-1-amiga #1 Thu Oct 16 08:59:25 CDT 2008 m68k GNU/Linux
>   
OK; I'll give that a shot - I'll probably have to go back before 2.6.24 
though if the timeout already happened in 2.6.24. Can you test my 2.6.26 
on kullervo some time, to confirm you have the same ethernet timeouts 
there?

Is there a simple way to cross-build an initrd image?
It seems we'd need that to really test under conditions comparable to 
the Debian kernel situation.

Cheers,

  Michael

Re: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Geert Uytterhoeven]

On Sun, Aug 14, 2011 at 06:26, Michael Schmitz
<schmitzmic@googlemail.com> wrote:
>>> Christian - can you remember which 2.6 kernel that last had ethernet
>>> working for you?
>>>
>>
>> I haven't been testing kernels a lot recently... from the logfiles it
>> would
>> seem the last kernel that was running on kullervo was this one:
>>
>> Linux version 2.6.24-1-amiga (Debian 2.6.24-4) (waldi@debian.org) (gcc
>> version 3.3.6) #1 Tue Feb 12 10:05:37 CET 2008
>>
>
> Plain 2.6.24 from Geert's tree does show TX timeouts again - no watchdog
> firing this time because IDE wasn't even built as module (something cause
> make oldconfig to drop all IDE stuff when starting from Tuomas' .config).
>
> Speaking of which - I cannot even build IDE at all in that release:
>
>  CC [M]  drivers/ide/ide-lib.o
> drivers/ide/ide-lib.c: In function `ide_dump_atapi_status':
> drivers/ide/ide-lib.c:601: internal compiler error: in
> verify_local_live_at_start, at flow.c:600
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>
> I'm sure we've seen that before and it did eventually get fixed.

You can probably work around that by building with "make V=1" to show
the compile command,
and manually executing it with a lower optimization level.

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: watchdog (?) on linux 3.0.0 and 2.6.39.3

[Michael Schmitz]

Hi Geert,


>>  CC [M]  drivers/ide/ide-lib.o
>> drivers/ide/ide-lib.c: In function `ide_dump_atapi_status':
>> drivers/ide/ide-lib.c:601: internal compiler error: in
>> verify_local_live_at_start, at flow.c:600
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
>>
>> I'm sure we've seen that before and it did eventually get fixed.
>
> You can probably work around that by building with "make V=1" to show
> the compile command,
> and manually executing it with a lower optimization level.

I actually had to add -O0 to the EXTRA_CFLAGS in drivers/ide/Makefile
- otherwise I'd manually compile it OK once, and the subsequent make
command would attempt to compile it again (with -Os).

Thanks,

  Michael