Geert,
Neither do I - but the IRQ being disabled is the device specific one,
not the master chip interrupt dispatching the device specific one.
The only way around that is to share this one with a dummy handler
(and Paul did veto that).
I forgot to mention one alternative: add a handle_polled
Geert,
In the mean time, have you found a better solution that the noirqdebug
kernel option?
I don't like that one.
Neither do I - but the IRQ being disabled is the device specific one,
not the master chip interrupt dispatching the device specific one. The
only way around that is to share t
Hi Geert,
The last patch series I sent was in August (IRQ chip definition for timer D
interrupt, and make use of that in the NE2000 driver). With these changes
(and the ones before, from June) there should be no need for more than
minimal changes to ne.c. So what else do I need to provide for tha
Hi Michael,
On Thu, Nov 15, 2012 at 8:02 AM, schmitz
wrote:
>> On Thu, Nov 15, 2012 at 5:10 AM, schmitz
>> wrote:
>>> (What is the status of the Atari ethernet drivers in your tree, Geert?
>>> What
>>> needs to be done to get them submitted upstream?)
>>
>> The same as last time when we had stra
Hi Geert,
On Thu, Nov 15, 2012 at 5:10 AM, schmitz
wrote:
(What is the status of the Atari ethernet drivers in your tree, Geert? What
needs to be done to get them submitted upstream?)
The same as last time when we had strawberries in our garden ;-)
The last patch series I sent was
Ingo Jürgensmann wrote:
Fröm i understood from asking waldi on irc the new kernels left some options in
unconfigured state that needs to be set.
Can somebody provide more details (bug number, kernel version, what
subarch kernel)?
Cheers,
Michael
--
To UNSUBSCRIBE, email to debian-68k-
On Thu, Nov 15, 2012 at 5:20 AM, Ingo Jürgensmann
wrote:
> Fröm i understood from asking waldi on irc the new kernels left some options
> in unconfigured state that needs to be set.
Yeah, I have to update the defconfigs.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven
Hi Michael,
On Thu, Nov 15, 2012 at 5:10 AM, schmitz
wrote:
> (What is the status of the Atari ethernet drivers in your tree, Geert? What
> needs to be done to get them submitted upstream?)
The same as last time when we had strawberries in our garden ;-)
Gr{oetje,eeting}s,
(on the off chance this actually makes it through to Thorsten)
Thorsten Glaser wrote:
On that note, waldi requests that someone clean up the
m68k kernel config as it’s in danger of being removed
entirely otherwise; I referred him to this list too, but
while writing I thought I’d better remark th
Fröm i understood from asking waldi on irc the new kernels left some options in
unconfigured state that needs to be set.
--
Ingo Jürgensmann
http://blog.windfluechter.net
http://npbhro.de
Am 15.11.2012 um 05:10 schrieb schmitz :
> (on the off chance this actually makes it through to Thorsten
Ingo Jürgensmann dixit:
> Yeah, of course, but it seems that some packages are missing as well in the
> chroot, so I gave building on the host itself a try.
Probably because you cannot debootstrap from “unstable” alone.
It is almost certainly easiest to start from the chroot tarball
I made: https
On 2012-11-13 14:06, Thorsten Glaser wrote:
elgar:~/temp# apt-get build-dep aptitude
aptitude is a monstrum. Besides, you don’t really need it.
It was just an example. ;)
The following packages have unmet dependencies:
build-essential : Depends: libc6-dev but it is not going to be
installed
Ingo Jürgensmann dixit:
> On 2012-11-13 06:08, Finn Thain wrote:
>> For those packages that behave anomalously under emulation, and their
>> dependencies, it may be useful to run all the test suites on real
>> hardware.
It’s not just about testsuites. I’ve got no skills in parallel
programming,
On 2012-11-13 06:08, Finn Thain wrote:
> When building or when running packages/software?
See the Qt thread and at least one other. Java? too, I believe.
For those packages that behave anomalously under emulation, and their
dependencies, it may be useful to run all the test suites on real
hardw
On Mon, 12 Nov 2012, Thorsten Glaser wrote:
> > > ... I still believe we have a problem with threads and/or
> > > locks/waits/whatever.
> >
> > When building or when running packages/software?
>
> See the Qt thread and at least one other. Java? too, I believe.
For those packages that behave an
(If you write in quoted-printable or base64 instead of 8bit,
the broken Debian mail servers have no reason to trash mails
when sending them to me. Just a note.)
Ingo Jürgensmann dixit:
>> Mhm. I havenb> either, and I still believe we have a problem with threads
>> and/or locks/waits/whatever.
>
>
On 2012-11-12 08:14, Thorsten Glaser wrote:
Anyway, we're up to 4833 packages in Needs-Build:
Mhm. I haven’t done much of anything since June/July or so,
either, and I still believe we have a problem with threads
and/or locks/waits/whatever.
When building or when running packages/software?
4
Ingo Jürgensmann dixit:
> Anyway, we're up to 4833 packages in Needs-Build:
Mhm. I haven’t done much of anything since June/July or so,
either, and I still believe we have a problem with threads
and/or locks/waits/whatever.
> 4833 out of 9906. It's obvious that m68k will be never again uptodate
on Nov 12 06:51:13 CET 2012
-
Distribution unstable:
-
Installed : 1321
Needs-Build : 4833
Building: 0
Uploaded: 0
Failed : 0
Dep-Wait: 0
Reupload-Wait :
19 matches
Mail list logo
