Nabble - debian-68k

Re: First steps towards PCMCIA support on the PB190

2009-11-27T19:48:28Z

Just as a note, I never saw the original message come across the mailing
list. Also, you might want to include linux-m68k@...
on this sort of topic.

On Tue, Nov 24, 2009 at 07:01:30PM -0200, diego wrote:

> in case anyone is interested, I decided to pick up Brad's idea and did
> some work towards turning it into reality.
> I just took the driver from the nubus-pmac project, adapted it to
> kernel 2.6 and did some hacking to get at least
> a few card drivers to work with it.
> Below patchset contains enough to add basic socket services support on
> the PB190 and to drive a Orinoco Gold Wireless
> card with kernel 2.6.31-2.
> Note that this code is far from complete (or mergeable) at the moment,
> I just posted this in the hope
> that it will inspire others interested in pcmcia support on the PB190
> to read it and maybe fill in some of the gaps.

I do have a PB190 laying around, so hopefully I'll find some time to
try out this code. I should have some time over the holiday season. It's
good to see some code that at least works to some degree. This was one
thing keeping me from bothering, since I wanted ethernet support. I'm
not sure if there is already a Linux driver for the ethernet card I have,
but that's something I'll have to check.

> Unfortunately I don't have all too much time to work on this, that's
> why I decided to just post my current effort
> (in it's half finished state) and provide a quick line-out of the
> major issues involved in getting pcmcia support to work
> on this platform.
> The main question being, whether there are enough people using linux
> on a PB190 to justify the effort.
> I also apologize beforehand for the unclean code / patch.

I think it's better to share what you have. I've been guilty of keeping
code to myself when I'm not happy with it. To be honest, there probably
aren't enough people using Linux on m68k to justify the work in pure
practical terms anyway. I drag it out once in a while because it is
interesting and a chance to try out things I wouldn't otherwise try.

> There are mainly three problems l'm facing here....
> The first two should be fairly easy to work out, whereas the 3rd
> represents a major roadblock at the moment:
>
> 1. Proper mac specific definitions that wrap around ISA bus access.
>
> 2. If you look at the patches to the orinoco driver, you will see that
> there's another enemy hiding, his name is ioport_map.

These should be relatively simple. We need to clean up some of that
stuff anyway. It's just a matter of taking the time to do it right.
This is the sort of thing that ought to be handled better in the
common code anyway.

> 3. This has already been haunting the driver in the nubus-ppc
> project, and I couldn't come up with anything better either:
> I can't figure out how to make the TREX chip use IO memory and
> attribute memory simultaneously. From the little docs
> provided by apple it appears that it would be possible, then again
> they don't provide any documentation on how this
> chip works at the register level.
> The original author of the driver did find out how to switch between
> the two modes, but this requires the ugly patches to
> pcmcia_resource.c to, which in turn makes it impossible to merge this
> into an all-arch kernel tree.
> This wasn't a problem for the nubus-ppc port since they maintained
> their own development tree, but obviously in the
> case of m68k this would represent a major problem.
> Another thing is that it breaks some drivers that implement more
> exotic features like requesting card configuration
> changes etc..
> If anyone happens to know how to program the TREX chip to use both
> attribute and IO mem simultaneously then this
> wouldn['t be an issue anymore.
> The alternative would be to convince the pcmcia core maintainers to
> have mercy with cards that need switching between
> these modes, but I doubt that this is a realistic alternative.

This is pretty much the sort of thing we've constantly encountered
trying to get old Macs to work. Unless someone can get official docs
on the chip, we may need to try to reverse engineer the Apple drivers
for all of this stuff.

Brad Boyer
flar@...

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: etch-m68k and newer packages

2009-11-27T17:03:41Z

On Fri, November 27, 2009 10:46 am, Ingo Jürgensmann wrote:

> On Fri, Nov 27, 2009 at 10:10:49AM -0600, Stephen R. Marenka wrote:
>> On Fri, November 27, 2009 3:12 am, Ingo JÃ¼rgensmann wrote:
>> > On a sidenote it seems that Arrakis and Spice aren't building packages
>> > anymore. Are they still needed?
>> Sid is broken last I checked. I haven't really seen a great deal of
>> interest in getting it fixed. We haven't built anything in some months I
>> believe.
>> It's a bummer.
>
> Hmpf... so, currently it doesn't make much sense to keep the machines
> running, until some issues are solved?

That's my opinion. I'd be inclined to leave the virtual machines running
if they aren't eating much in resources, but the real machines use a fair
amount of electricity and generate heat (of course, it is winter there,
right? ;).

Ultimately heat it why I shut mine down.

Peace,

Stephen

--
Stephen R. Marenka If life's not fun, you're not doing it right!
<stephen@...>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: etch-m68k and newer packages

2009-11-27T08:46:38Z

On Fri, Nov 27, 2009 at 10:10:49AM -0600, Stephen R. Marenka wrote:
> On Fri, November 27, 2009 3:12 am, Ingo JÃ¼rgensmann wrote:
> > On a sidenote it seems that Arrakis and Spice aren't building packages
> > anymore. Are they still needed?
> Sid is broken last I checked. I haven't really seen a great deal of
> interest in getting it fixed. We haven't built anything in some months I
> believe.
> It's a bummer.

Hmpf... so, currently it doesn't make much sense to keep the machines
running, until some issues are solved?

--
Ciao... // Fon: 0381-2744150
Ingo \X/ http://blog.windfluechter.net

gpg pubkey: http://www.juergensmann.de/ij_public_key.asc

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: etch-m68k and newer packages

2009-11-27T08:10:49Z

On Fri, November 27, 2009 3:12 am, Ingo JÃ¼rgensmann wrote:

> Heya!
>
> I'm still operating 3 m68k buildds and would like to update them.
> Currently sources.list points to etch-m68k which is, uhm, fairly old and
> outdated, I believe.
> Is there anything newer? Would it make sense to switch to
> ftp://ftp.debian-ports.org/debian/pool-m68k/ - or to say it differently:
> tracking unstable instead of trying to "release" some stable versions for
> the port in whole?
>
> On a sidenote it seems that Arrakis and Spice aren't building packages
> anymore. Are they still needed?

Sid is broken last I checked. I haven't really seen a great deal of
interest in getting it fixed. We haven't built anything in some months I
believe.

It's a bummer.

Peace,

Stephen

--
Stephen R. Marenka If life's not fun, you're not doing it right!
<stephen@...>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

etch-m68k and newer packages

2009-11-27T01:12:01Z

Heya!

I'm still operating 3 m68k buildds and would like to update them.
Currently sources.list points to etch-m68k which is, uhm, fairly old and
outdated, I believe.
Is there anything newer? Would it make sense to switch to
ftp://ftp.debian-ports.org/debian/pool-m68k/ - or to say it differently:
tracking unstable instead of trying to "release" some stable versions for
the port in whole?

On a sidenote it seems that Arrakis and Spice aren't building packages
anymore. Are they still needed?

--
Ciao... // Fon: 0381-2744150
. Ingo \X/ http://blog.windfluechter.net

gpg pubkey: http://www.juergensmann.de/ij_public_key.asc

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Forum Creativity Training VIII

2009-11-19T04:00:13Z

السيد الفاضل

الموضوع: منتدى الإبداع التدريبي الثامن

من بعد التحية الطيبة، والدعاء لكم بتمام التوفيق والنجاح، والازدهار في أعمالكم، وإشارة إلى النجاح الطيب الذي أحرزته شركة الإبداع الخليجي خلال منتدياتها السبعة الماضية، ذاك النجاح الذي كان مشفوعاً بمشاركة كبرى الشركات الخليجية الخاصة منها والحكومية، تتقدم الشركة بمزيد من الثقة نحو إقامة منتداها الثامن في نهاية عام 2009 تحت شعار (صناعة المستقبل في ضوء الأزمات).

وعليه فإنه يسرنا أن نضع بين أيديكم فرصة المشاركة في فعاليات "منتدى الإبداع التدريبي الثامن"، والذي سيعقد بمشيئة الله تعالى في مدينة دبي الاقتصادية في الفترة من 27 - 30 ديسمبر 2009، وتتكون فعاليات هذا المنتدى من ستة برامج تدريبية تشكل في مجموعها منظومة إدارية متكاملة تتناول أحدث البرامج الإدارية في مختلف الجوانب مع تسليط الضوء على حلول ومعالجات للأزمة المالية والاقتصادية العالمية، وعلى أيدي أمهر المدربين في العالم العربي.

بالدخول إلى بروشور المنتدى المدرج ستجدون تفاصيل وافية عن برامج المنتدى، مع استعدادنا التام للرد على أي من استفساراتكم وتقديم المساعدة على الهواتف 22404883- 965+ الداخلي (666)، أو فاكس : 22404852 أو إرسال رسالة عبر البريد الالكتروني على:info@...

وتقبلوا خالص الاحترام والتقدير،،،

powered by

unsubscribe

forward

update profile

This mailing system may only be used for sending permission based email.

If you did not give permission to receive emails from this sender, please notify us.

This email was sent to debian-68k@... by info@... | Print / PDF version | Read our Privacy Policy.
gulf innovation - kuwait, shareq, 965, Kuwait

Re: Add private syscalls to support NPTL

2009-11-10T08:11:19Z

On Tue, 10 Nov 2009, Maxim Kuvyrkov wrote:

> Finn Thain wrote:
>
> >
> > Do you think my patch is a reasonable solution? I don't understand it, I
> > just copied it from x86 -- "monkey see, monkey do."
>
> I can't spot anything wrong in it.

Thanks for looking it over. I'll send it upstream.

> >
> > I used the eglibc-2.10/EGLIBC.cross-building script to test this. I
> > configured eglibc with "--enable-add-ons=ports,nptl" to prevent
> > localedef from breaking the configure step. Package versions were
> > binutils-2.19.51, gcc-4.4.1 (patched), linux-2.6.31 (patched), eglibc
> > 2_10 branch (patched).
>
> What hardware / emulator do you use to test the result? I tested all
> the work on ColdFire systems, but I also would like to run some tests on
> a usual m68k.

I've been testing on 68040 machines. I've not yet tried the test suites.

The latest random test I did was to build the cross toolchain using
patched debian sid source packages. Then I copied sshd and its supporting
libraries etc from an etch-m68k system into the toolchain sysroot, along
with a few old busybox bits and pieces that I had lying around. I then
exported the sysroot with NFS and booted that. After some messing around I
was able to log in with ssh and gather the info below.

So far, so good!

Finn

# cat /proc/cpuinfo
CPU: 68040
MMU: 68040
FPU: 68040
Clocking: 24.6MHz
BogoMips: 16.43
Calibration: 82176 loops
# cat /proc/version
Linux version 2.6.31.5-mac (fthain@nippy) (gcc version 4.4.1 (GCC) ) #2 Wed Nov 11 00:52:38 EST 2009
# /lib/libc.so.6
GNU C Library (EGLIBC) stable release version 2.10.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.1.
Compiled on a Linux >>2.6.31.5<< system on 2009-11-10.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
Support for some architectures added on, not maintained in glibc core.
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.eglibc.org/issues/>.
# cat /proc/649/maps
80000000-80047000 r-xp 00000000 00:0c 84898 /etch-m68k-root/usr/sbin/sshd
80048000-80049000 rw-p 00046000 00:0c 84898 /etch-m68k-root/usr/sbin/sshd
80049000-8006f000 rwxp 00000000 00:00 0 [heap]
c0000000-c0018000 r-xp 00000000 00:0c 115132 /lib/ld-2.10.1.so
c0018000-c0019000 rw-p 00000000 00:00 0
c0019000-c001a000 r--p 00019000 00:0c 115132 /lib/ld-2.10.1.so
c001a000-c001b000 rw-p 0001a000 00:0c 115132 /lib/ld-2.10.1.so
c001b000-c0022000 r-xp 00000000 00:0c 442806 /usr/local/lib/libwrap.so.0.7.6
c0022000-c0023000 ---p 00007000 00:0c 442806 /usr/local/lib/libwrap.so.0.7.6
c0023000-c0024000 rw-p 00006000 00:0c 442806 /usr/local/lib/libwrap.so.0.7.6
c0024000-c0025000 rw-p 00000000 00:00 0
c0025000-c002c000 r-xp 00000000 00:0c 442808 /usr/local/lib/libpam.so.0.79
c002c000-c002d000 ---p 00007000 00:0c 442808 /usr/local/lib/libpam.so.0.79
c002d000-c002f000 rw-p 00006000 00:0c 442808 /usr/local/lib/libpam.so.0.79
c002f000-c0030000 rw-p 00000000 00:00 0
c0030000-c0032000 r-xp 00000000 00:0c 115080 /lib/libdl-2.10.1.so
c0032000-c0033000 ---p 00002000 00:0c 115080 /lib/libdl-2.10.1.so
c0033000-c0034000 r--p 00001000 00:0c 115080 /lib/libdl-2.10.1.so
c0034000-c0035000 rw-p 00002000 00:0c 115080 /lib/libdl-2.10.1.so
c0035000-c0046000 r-xp 00000000 00:0c 442809 /usr/local/lib/libselinux.so.1
c0046000-c0047000 ---p 00011000 00:0c 442809 /usr/local/lib/libselinux.so.1
c0047000-c0048000 rw-p 00010000 00:0c 442809 /usr/local/lib/libselinux.so.1
c0048000-c0049000 rw-p 00000000 00:00 0
c0049000-c0058000 r-xp 00000000 00:0c 115096 /lib/libresolv-2.10.1.so
c0058000-c005a000 ---p 0000f000 00:0c 115096 /lib/libresolv-2.10.1.so
c005a000-c005b000 r--p 0000f000 00:0c 115096 /lib/libresolv-2.10.1.so
c005b000-c005c000 rw-p 00010000 00:0c 115096 /lib/libresolv-2.10.1.so
c005c000-c005e000 rw-p 00000000 00:00 0
c005e000-c016b000 r-xp 00000000 00:0c 442810 /usr/local/lib/libcrypto.so.0.9.8
c016b000-c016c000 ---p 0010d000 00:0c 442810 /usr/local/lib/libcrypto.so.0.9.8
c016c000-c0180000 rw-p 0010c000 00:0c 442810 /usr/local/lib/libcrypto.so.0.9.8
c0180000-c0184000 rw-p 00000000 00:00 0
c0184000-c0186000 r-xp 00000000 00:0c 115130 /lib/libutil-2.10.1.so
c0186000-c0187000 ---p 00002000 00:0c 115130 /lib/libutil-2.10.1.so
c0187000-c0188000 r--p 00001000 00:0c 115130 /lib/libutil-2.10.1.so
c0188000-c0189000 rw-p 00002000 00:0c 115130 /lib/libutil-2.10.1.so
c0189000-c019a000 r-xp 00000000 00:0c 442812 /usr/local/lib/libz.so.1.2.3
c019a000-c019b000 ---p 00011000 00:0c 442812 /usr/local/lib/libz.so.1.2.3
c019b000-c019c000 rw-p 00010000 00:0c 442812 /usr/local/lib/libz.so.1.2.3
c019c000-c019d000 rw-p 00000000 00:00 0
c019d000-c01af000 r-xp 00000000 00:0c 115120 /lib/libnsl-2.10.1.so
c01af000-c01b0000 ---p 00012000 00:0c 115120 /lib/libnsl-2.10.1.so
c01b0000-c01b1000 r--p 00011000 00:0c 115120 /lib/libnsl-2.10.1.so
c01b1000-c01b2000 rw-p 00012000 00:0c 115120 /lib/libnsl-2.10.1.so
c01b2000-c01b4000 rw-p 00000000 00:00 0
c01b4000-c01bd000 r-xp 00000000 00:0c 115088 /lib/libcrypt-2.10.1.so
c01bd000-c01bf000 ---p 00009000 00:0c 115088 /lib/libcrypt-2.10.1.so
c01bf000-c01c0000 r--p 00009000 00:0c 115088 /lib/libcrypt-2.10.1.so
c01c0000-c01c1000 rw-p 0000a000 00:0c 115088 /lib/libcrypt-2.10.1.so
c01c1000-c01e8000 rw-p 00000000 00:00 0
c01e8000-c01ff000 r-xp 00000000 00:0c 442814 /usr/local/lib/libgssapi_krb5.so.2.2
c01ff000-c0200000 ---p 00017000 00:0c 442814 /usr/local/lib/libgssapi_krb5.so.2.2
c0200000-c0201000 rw-p 00016000 00:0c 442814 /usr/local/lib/libgssapi_krb5.so.2.2
c0201000-c0269000 r-xp 00000000 00:0c 442816 /usr/local/lib/libkrb5.so.3.2
c0269000-c026a000 ---p 00068000 00:0c 442816 /usr/local/lib/libkrb5.so.3.2
c026a000-c026d000 rw-p 00067000 00:0c 442816 /usr/local/lib/libkrb5.so.3.2
c026d000-c028d000 r-xp 00000000 00:0c 442822 /usr/local/lib/libk5crypto.so.3.0
c028d000-c028e000 ---p 00020000 00:0c 442822 /usr/local/lib/libk5crypto.so.3.0
c028e000-c0290000 rw-p 0001f000 00:0c 442822 /usr/local/lib/libk5crypto.so.3.0
c0290000-c0292000 r-xp 00000000 00:0c 442818 /usr/local/lib/libcom_err.so.2.1
c0292000-c0293000 ---p 00002000 00:0c 442818 /usr/local/lib/libcom_err.so.2.1
c0293000-c0294000 rw-p 00001000 00:0c 442818 /usr/local/lib/libcom_err.so.2.1
c0294000-c0295000 rw-p 00000000 00:00 0
c0295000-c0298000 r-xp 00000000 00:0c 442820 /usr/local/lib/libkrb5support.so.0.0
c0298000-c0299000 ---p 00003000 00:0c 442820 /usr/local/lib/libkrb5support.so.0.0
c0299000-c029b000 rw-p 00002000 00:0c 442820 /usr/local/lib/libkrb5support.so.0.0
c029b000-c03b7000 r-xp 00000000 00:0c 114361 /lib/libc-2.10.1.so
c03b7000-c03b9000 r--p 0011c000 00:0c 114361 /lib/libc-2.10.1.so
c03b9000-c03bc000 rw-p 0011e000 00:0c 114361 /lib/libc-2.10.1.so
c03bc000-c03bf000 rw-p 00000000 00:00 0
c03bf000-c03f1000 r-xp 00000000 00:0c 442823 /usr/local/lib/libsepol.so.1
c03f1000-c03f2000 ---p 00032000 00:0c 442823 /usr/local/lib/libsepol.so.1
c03f2000-c03f4000 rw-p 00031000 00:0c 442823 /usr/local/lib/libsepol.so.1
c03f4000-c0401000 rw-p 00000000 00:00 0
c0401000-c0407000 r-xp 00000000 00:0c 115126 /lib/libnss_compat-2.10.1.so
c0407000-c0408000 ---p 00006000 00:0c 115126 /lib/libnss_compat-2.10.1.so
c0408000-c0409000 r--p 00005000 00:0c 115126 /lib/libnss_compat-2.10.1.so
c0409000-c040a000 rw-p 00006000 00:0c 115126 /lib/libnss_compat-2.10.1.so
c040a000-c0412000 r-xp 00000000 00:0c 115122 /lib/libnss_nis-2.10.1.so
c0412000-c0413000 ---p 00008000 00:0c 115122 /lib/libnss_nis-2.10.1.so
c0413000-c0414000 r--p 00007000 00:0c 115122 /lib/libnss_nis-2.10.1.so
c0414000-c0415000 rw-p 00008000 00:0c 115122 /lib/libnss_nis-2.10.1.so
c0415000-c041e000 r-xp 00000000 00:0c 115108 /lib/libnss_files-2.10.1.so
c041e000-c0420000 ---p 00009000 00:0c 115108 /lib/libnss_files-2.10.1.so
c0420000-c0421000 r--p 00009000 00:0c 115108 /lib/libnss_files-2.10.1.so
c0421000-c0422000 rw-p 0000a000 00:0c 115108 /lib/libnss_files-2.10.1.so
efcb7000-efccc000 rw-p 00000000 00:00 0 [stack]

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Add private syscalls to support NPTL

2009-11-10T02:51:00Z

Finn Thain wrote:

>
> On Fri, 6 Nov 2009, Maxim Kuvyrkov wrote:
>
>> Finn Thain wrote:
>>> On Wed, 28 Oct 2009, Maxim Kuvyrkov wrote:
>>>
>>>> ...
>>>>
>>>> We [CodeSourcery] have just updated all of our toolchains, and the
>>>> GNU/Linux toolchain is based on EGLIBC 2.10 and has well tested
>>>> TLS/NPTL support. If you are targeting ColdFire you can simply
>>>> download the toolchain at
>>>> <http://www.codesourcery.com/sgpp/lite/coldfire>.
>> ...
>>> I did run into a problem with this second patch. It doesn't apply to
>>> the eglibc_2.10 branch in svn as of yesterday. The following hunk is
>>> the problem:
>> The patches posted are all against FSF GLIBC, not EGLIBC, so some
>> conflicts are expected. ...
>
> OK. I suppose that means no back-porting of other patches is required.
>
>>> Using the above patches, I am almost able to compile eglibc_2.10. But
>>> there is an old build failure (since glibc-2.4 I think) when linking
>>> libc.so:
>>>
>>> /tmp/build/glibc-m68k-linux-gnu-3/libc_pic.os: In function `fchownat':
>>> (.text+0x911c2): undefined reference to `__atfct_seterrno'
>>> /tmp/gcc-4.4.1/lib/gcc/m68k-linux-gnu/4.4.1/../../../../m68k-linux-gnu/bin/ld:
>>> /tmp/build/glibc-m68k-linux-gnu-3/libc.so: hidden symbol `__atfct_seterrno'
>>> isn't defined
>>> /tmp/gcc-4.4.1/lib/gcc/m68k-linux-gnu/4.4.1/../../../../m68k-linux-gnu/bin/ld:
>>> final link failed: Nonrepresentable section on output
>>> collect2: ld returned 1 exit status
>>> make[1]: *** [/tmp/build/glibc-m68k-linux-gnu-3/libc.so] Error 1
>>> make[1]: Leaving directory `/tmp/build/glibc-2.10.1'
>>> make: *** [all] Error 2
>>>
>>> To try to fix this issue, I've basically copied this patch:
>>> http://sources.redhat.com/ml/libc-hacker/2006-08/msg00004.html
>>> An m68k version is attached. Can someone have a look at it and tell
>>> whether this is the correct fix or not?
>> I don't really know, this is the first time I see this failure.
>
> I found out why it happens.
>
> If you build eglibc with "--enable-kernel=2.6.31" it fails as above.
> If you omit that option, it works.
>
> Do you think my patch is a reasonable solution? I don't understand it, I
> just copied it from x86 -- "monkey see, monkey do."

I can't spot anything wrong in it.

>
> I used the eglibc-2.10/EGLIBC.cross-building script to test this. I
> configured eglibc with "--enable-add-ons=ports,nptl" to prevent localedef
> from breaking the configure step. Package versions were binutils-2.19.51,
> gcc-4.4.1 (patched), linux-2.6.31 (patched), eglibc 2_10 branch (patched).

What hardware / emulator do you use to test the result? I tested all
the work on ColdFire systems, but I also would like to run some tests on
a usual m68k.

Regards,

--
Maxim Kuvyrkov
CodeSourcery
maxim@...
(650) 331-3385 x724

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Add private syscalls to support NPTL

2009-11-09T20:20:32Z

On Tue, Nov 10, 2009 at 03:07:28PM +1100, Finn Thain wrote:

> I also tried eglibc trunk but the build failed elsewhere:
>
> ../sysdeps/unix/sysv/linux/i386/fcntl.c: In function '__fcntl_nocancel':
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:133: error: storage size of 'fex' isn't known
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: 'F_GETOWN_EX' undeclared (first use in this function)
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: (Each undeclared identifier is reported only once
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: for each function it appears in.)
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:136: error: 'F_OWNER_GID' undeclared (first use in this function)
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:133: warning: unused variable 'fex'
> make[2]: *** [/home/fthain/cross-build/m68k/obj/eglibc/io/fcntl.o] Error 1
> make[2]: Leaving directory `/home/fthain/cross-build/src/eglibc-trunk-r9191/io'
> make[1]: *** [io/subdir_lib] Error 2
> make[1]: Leaving directory `/home/fthain/cross-build/src/eglibc-trunk-r9191'
> make: *** [all] Error 2
>
> For now I'm content with eglibc-2.10, since that is the version in the
> debian archive.

It looks like this needs a newer version of the kernel headers. That stuff
was added relatively recently:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ba0a6c9f6fceed11c6a99e8326f0477fe383e6b5

If I'm reading the dates correctly, this commit wasn't in 2.6.31.

As a side note, there is already a patch floating around to fix that commit,
which apparently broke stuff.

http://patchwork.kernel.org/patch/56568/

Brad Boyer
flar@...

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Add private syscalls to support NPTL

2009-11-09T20:07:28Z

On Fri, 6 Nov 2009, Maxim Kuvyrkov wrote:

> Finn Thain wrote:
> > On Wed, 28 Oct 2009, Maxim Kuvyrkov wrote:
> >
> > > ...
> > >
> > > We [CodeSourcery] have just updated all of our toolchains, and the
> > > GNU/Linux toolchain is based on EGLIBC 2.10 and has well tested
> > > TLS/NPTL support. If you are targeting ColdFire you can simply
> > > download the toolchain at
> > > <http://www.codesourcery.com/sgpp/lite/coldfire>.
> ...
> > I did run into a problem with this second patch. It doesn't apply to
> > the eglibc_2.10 branch in svn as of yesterday. The following hunk is
> > the problem:
>
> The patches posted are all against FSF GLIBC, not EGLIBC, so some
> conflicts are expected. ...

OK. I suppose that means no back-porting of other patches is required.

> > Using the above patches, I am almost able to compile eglibc_2.10. But
> > there is an old build failure (since glibc-2.4 I think) when linking
> > libc.so:
> >
> > /tmp/build/glibc-m68k-linux-gnu-3/libc_pic.os: In function `fchownat':
> > (.text+0x911c2): undefined reference to `__atfct_seterrno'
> > /tmp/gcc-4.4.1/lib/gcc/m68k-linux-gnu/4.4.1/../../../../m68k-linux-gnu/bin/ld:
> > /tmp/build/glibc-m68k-linux-gnu-3/libc.so: hidden symbol `__atfct_seterrno'
> > isn't defined
> > /tmp/gcc-4.4.1/lib/gcc/m68k-linux-gnu/4.4.1/../../../../m68k-linux-gnu/bin/ld:
> > final link failed: Nonrepresentable section on output
> > collect2: ld returned 1 exit status
> > make[1]: *** [/tmp/build/glibc-m68k-linux-gnu-3/libc.so] Error 1
> > make[1]: Leaving directory `/tmp/build/glibc-2.10.1'
> > make: *** [all] Error 2
> >
> > To try to fix this issue, I've basically copied this patch:
> > http://sources.redhat.com/ml/libc-hacker/2006-08/msg00004.html
> > An m68k version is attached. Can someone have a look at it and tell
> > whether this is the correct fix or not?
>
> I don't really know, this is the first time I see this failure.

I found out why it happens.

If you build eglibc with "--enable-kernel=2.6.31" it fails as above.
If you omit that option, it works.

Do you think my patch is a reasonable solution? I don't understand it, I
just copied it from x86 -- "monkey see, monkey do."

I used the eglibc-2.10/EGLIBC.cross-building script to test this. I
configured eglibc with "--enable-add-ons=ports,nptl" to prevent localedef
from breaking the configure step. Package versions were binutils-2.19.51,
gcc-4.4.1 (patched), linux-2.6.31 (patched), eglibc 2_10 branch (patched).

I also tried eglibc trunk but the build failed elsewhere:

../sysdeps/unix/sysv/linux/i386/fcntl.c: In function '__fcntl_nocancel':
../sysdeps/unix/sysv/linux/i386/fcntl.c:133: error: storage size of 'fex' isn't known
../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: 'F_GETOWN_EX' undeclared (first use in this function)
../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: (Each undeclared identifier is reported only once
../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: for each function it appears in.)
../sysdeps/unix/sysv/linux/i386/fcntl.c:136: error: 'F_OWNER_GID' undeclared (first use in this function)
../sysdeps/unix/sysv/linux/i386/fcntl.c:133: warning: unused variable 'fex'
make[2]: *** [/home/fthain/cross-build/m68k/obj/eglibc/io/fcntl.o] Error 1
make[2]: Leaving directory `/home/fthain/cross-build/src/eglibc-trunk-r9191/io'
make[1]: *** [io/subdir_lib] Error 2
make[1]: Leaving directory `/home/fthain/cross-build/src/eglibc-trunk-r9191'
make: *** [all] Error 2

For now I'm content with eglibc-2.10, since that is the version in the
debian archive.

>
> > The end result is that I now have a NPTL/TLS m68k toolchain
> > (binutils-2.19.51 and patched gcc-4.4.1). Thank you for making that
> > possible. I've not run the test suites yet, but so far it seems to
> > work.
> >
> > Only, I did find that a statically linked binary (pccardctl) built
> > with this toolchain segfaults ("unknown errorSegmentation fault") when
> > run under a linux-2.6.31 kernel that lacks your patches. Is this
> > expected?
>
> The binary will certainly not work,

Right. I see that this is documented in the CodeSourcery G++ Lite m68k
docs.

Finn

> but I remember run-time linker gracefully exiting with a proper error
> message when invoked on a system with unpatched kernel. I don't think I
> tested statically linked binaries on such system.
>
>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Add private syscalls to support NPTL

2009-11-06T00:59:09Z

Finn Thain wrote:
> On Wed, 28 Oct 2009, Maxim Kuvyrkov wrote:
>
>> ...
>>
>> We [CodeSourcery] have just updated all of our toolchains, and the
>> GNU/Linux toolchain is based on EGLIBC 2.10 and has well tested TLS/NPTL
>> support. If you are targeting ColdFire you can simply download the
>> toolchain at <http://www.codesourcery.com/sgpp/lite/coldfire>.
...
> I did run into a problem with this second patch. It doesn't apply to the
> eglibc_2.10 branch in svn as of yesterday. The following hunk is the
> problem:

The patches posted are all against FSF GLIBC, not EGLIBC, so some
conflicts are expected.
...

> Using the above patches, I am almost able to compile eglibc_2.10. But
> there is an old build failure (since glibc-2.4 I think) when linking
> libc.so:
>
> /tmp/build/glibc-m68k-linux-gnu-3/libc_pic.os: In function `fchownat': (.text+0x911c2): undefined reference to `__atfct_seterrno'
> /tmp/gcc-4.4.1/lib/gcc/m68k-linux-gnu/4.4.1/../../../../m68k-linux-gnu/bin/ld: /tmp/build/glibc-m68k-linux-gnu-3/libc.so: hidden symbol `__atfct_seterrno' isn't defined
> /tmp/gcc-4.4.1/lib/gcc/m68k-linux-gnu/4.4.1/../../../../m68k-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
> collect2: ld returned 1 exit status
> make[1]: *** [/tmp/build/glibc-m68k-linux-gnu-3/libc.so] Error 1
> make[1]: Leaving directory `/tmp/build/glibc-2.10.1'
> make: *** [all] Error 2
>
> To try to fix this issue, I've basically copied this patch:
> http://sources.redhat.com/ml/libc-hacker/2006-08/msg00004.html
> An m68k version is attached. Can someone have a look at it and tell
> whether this is the correct fix or not?

I don't really know, this is the first time I see this failure.

> The end result is that I now have a NPTL/TLS m68k toolchain
> (binutils-2.19.51 and patched gcc-4.4.1). Thank you for making that
> possible. I've not run the test suites yet, but so far it seems to work.
>
> Only, I did find that a statically linked binary (pccardctl) built with
> this toolchain segfaults ("unknown errorSegmentation fault") when run
> under a linux-2.6.31 kernel that lacks your patches. Is this expected?

The binary will certainly not work, but I remember run-time linker
gracefully exiting with a proper error message when invoked on a system
with unpatched kernel. I don't think I tested statically linked
binaries on such system.

--
Maxim Kuvyrkov
CodeSourcery
maxim@...
(650) 331-3385 x724

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Add private syscalls to support NPTL

2009-11-06T00:38:36Z

On Wed, 28 Oct 2009, Maxim Kuvyrkov wrote:

>...
>
> We [CodeSourcery] have just updated all of our toolchains, and the
> GNU/Linux toolchain is based on EGLIBC 2.10 and has well tested TLS/NPTL
> support. If you are targeting ColdFire you can simply download the
> toolchain at <http://www.codesourcery.com/sgpp/lite/coldfire>.
>
> > I suppose you can't really backport to eglibc 2.10 until the siginfo
> > question is resolved. It appears from the list traffic that the
> > consensus is to adopt the generic struct layout here. Is that the
> > solution that you've used in testing?
>
> I'm not sure if any parts of the m68k kernel port depend on the custom
> layout of siginfo, so I've only fixed the pieces which I'm sure are
> wrong. I.e, I've been testing with this
> <http://marc.info/?l=linux-m68k&m=125447365311948&w=2> patch.
>
> > If so, can you send the patches you been testing?
>
> All the patches are in the mailing lists.
>
> The kernel patches are at
>
> http://marc.info/?l=linux-m68k&m=125447760017098&w=2

For the benefit of anyone playing along at home, I found that the first
attachment ("patch.diff") is already merged in the second attachment
of the same message ("0001-Add-NPTL-support-for-m68k.patch").

> http://marc.info/?l=linux-m68k&m=125447365311948&w=2
>
> The [E]GLIBC patches are at
>
> [M68K/ColdFire patch 1/n] Update sysdep.h
> http://sourceware.org/ml/libc-ports/2009-08/msg00006.html
>
> [M68K/ColdFire patch 2/n] Add CFI information to dl-trampoline.S
> http://sourceware.org/ml/libc-ports/2009-08/msg00007.html
>
> [M68K/ColdFire patch 3/n] Update jmpbuf-unwind.h
> http://sourceware.org/ml/libc-ports/2009-08/msg00008.html
>
> [M68K/ColdFire patch 4/n] Remove kernel headers
> Update by hand to match your kernel

I suppose I don't need to remove or update anything, since I build eglibc
against fresh new kernel headers, from linux-2.6.31 patched with your TLS
patches.

> [M68K/ColdFire patch 5/n] Main NPTL patch
> http://sourceware.org/ml/libc-ports/2009-10/msg00006.html

For the benefit of anyone else attempting this, the first patch in that
email ("Don't bind rtld's vdso pointers to libc symbols") is merged into
the second patch in the same email ("Nptl support for m68k/ColdFire").

I did run into a problem with this second patch. It doesn't apply to the
eglibc_2.10 branch in svn as of yesterday. The following hunk is the
problem:

--- a/sysdeps/unix/sysv/linux/m68k/Versions
+++ b/sysdeps/unix/sysv/linux/m68k/Versions
@@ -31,5 +31,17 @@ libc {
}
GLIBC_2.11 {
fallocate64;
+ __m68k_read_tp;
+ }
+ GLIBC_PRIVATE {
+ __vdso_atomic_cmpxchg_32; __vdso_atomic_barrier;
+ }
+}
+
+ld {
+ GLIBC_PRIVATE {
+ __rtld___vdso_read_tp;
+ __rtld___vdso_atomic_cmpxchg_32;
+ __rtld___vdso_atomic_barrier;
}
}

It appears that another patch is needed, to allow your patch to apply:
http://sourceware.org/ml/libc-ports/2009-05/msg00028.html
And probably this patch too (I used both):
http://sourceware.org/ml/libc-hacker/2009-05/msg00003.html

Should I be using any other patches?

> http://sourceware.org/ml/libc-ports/2009-10/msg00030.html
>
> [M68K/ColdFire patch 6/n] Add TLS relocations to elf/elf.h
> http://sourceware.org/ml/libc-ports/2009-08/msg00012.html

(Trap for the uwary: this patch is for eglibc/libc, the others are for
eglibc/ports.)

> Should I post this one to glibc-alpha@ for the review?
>
> [M68K/ColdFire patch 7/n] Handle libgcc_s.so.2
> http://sourceware.org/bugzilla/show_bug.cgi?id=4457

The two patches attached to that bug are already in the eglibc_2.10
branch, BTW.

>
> Let me know if you find any particular problems with these patches.
>

Using the above patches, I am almost able to compile eglibc_2.10. But
there is an old build failure (since glibc-2.4 I think) when linking
libc.so:

/tmp/build/glibc-m68k-linux-gnu-3/libc_pic.os: In function `fchownat': (.text+0x911c2): undefined reference to `__atfct_seterrno'
/tmp/gcc-4.4.1/lib/gcc/m68k-linux-gnu/4.4.1/../../../../m68k-linux-gnu/bin/ld: /tmp/build/glibc-m68k-linux-gnu-3/libc.so: hidden symbol `__atfct_seterrno' isn't defined
/tmp/gcc-4.4.1/lib/gcc/m68k-linux-gnu/4.4.1/../../../../m68k-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[1]: *** [/tmp/build/glibc-m68k-linux-gnu-3/libc.so] Error 1
make[1]: Leaving directory `/tmp/build/glibc-2.10.1'
make: *** [all] Error 2

To try to fix this issue, I've basically copied this patch:
http://sources.redhat.com/ml/libc-hacker/2006-08/msg00004.html
An m68k version is attached. Can someone have a look at it and tell
whether this is the correct fix or not?

The end result is that I now have a NPTL/TLS m68k toolchain
(binutils-2.19.51 and patched gcc-4.4.1). Thank you for making that
possible. I've not run the test suites yet, but so far it seems to work.

Only, I did find that a statically linked binary (pccardctl) built with
this toolchain segfaults ("unknown errorSegmentation fault") when run
under a linux-2.6.31 kernel that lacks your patches. Is this expected?

Etch-m68k seems to run fine with or without the kernel patches. I've CC'd
the debian-m68k list but I suppose they can't use any of this until both
the siginfo ABI is resolved and eglibc passes its tests on m68k
hardware.

Finn

--- glibc-2.5/ports/sysdeps/unix/sysv/linux/m68k/fchownat.c.orig 2007-09-18 00:25:39.000000000 +1000
+++ glibc-2.5/ports/sysdeps/unix/sysv/linux/m68k/fchownat.c 2007-09-18 00:38:21.000000000 +1000
@@ -40,6 +40,24 @@
int
fchownat (int fd, const char *file, uid_t owner, gid_t group, int flag)
{
+ int result;
+
+#ifdef __NR_fchownat
+# ifndef __ASSUME_ATFCTS
+ if (__have_atfcts >= 0)
+# endif
+ {
+ result = INLINE_SYSCALL (fchownat, 5, fd, file, owner, group, flag);
+# ifndef __ASSUME_ATFCTS
+ if (result == -1 && errno == ENOSYS)
+ __have_atfcts = -1;
+ else
+# endif
+ return result;
+ }
+#endif
+
+#ifndef __ASSUME_ATFCTS
if (flag & ~AT_SYMLINK_NOFOLLOW)
{
__set_errno (EINVAL);
@@ -66,18 +84,17 @@
file = buf;
}

- int result;
INTERNAL_SYSCALL_DECL (err);

-#if __ASSUME_32BITUIDS > 0
+# if __ASSUME_32BITUIDS > 0
if (flag & AT_SYMLINK_NOFOLLOW)
result = INTERNAL_SYSCALL (lchown32, err, 3, CHECK_STRING (file), owner,
group);
else
result = INTERNAL_SYSCALL (chown32, err, 3, CHECK_STRING (file), owner,
group);
-#else
-# ifdef __NR_chown32
+# else
+# ifdef __NR_chown32
if (__libc_missing_32bit_uids <= 0)
{
if (flag & AT_SYMLINK_NOFOLLOW)
@@ -94,7 +111,7 @@

__libc_missing_32bit_uids = 1;
}
-# endif /* __NR_chown32 */
+# endif /* __NR_chown32 */

if (((owner + 1) > (gid_t) ((__kernel_uid_t) -1U))
|| ((group + 1) > (gid_t) ((__kernel_gid_t) -1U)))
@@ -109,7 +126,7 @@
else
result = INTERNAL_SYSCALL (chown, err, 3, CHECK_STRING (file), owner,
group);
-#endif
+# endif

if (__builtin_expect (INTERNAL_SYSCALL_ERROR_P (result, err), 0))
{
@@ -117,6 +134,7 @@
__atfct_seterrno (INTERNAL_SYSCALL_ERRNO (result, err), fd, buf);
result = -1;
}
+#endif

return result;
}

We have lists tailored specifically for your type of business

2009-11-05T16:36:56Z

Here are some of the USA contact databases we have for sale:

Physicians
Chiropractors
Alternative Medicine
Dentists
Veterinarians
Hospitals
Nursing Homes
Pharmaceutical Companies
Physical Therapists
Acupuncturists
Massage Therapists
Medical Equipment Suppliers
Mental Health Counselors
Visiting Nurses & RN's
Optometrists
Psychologists

Each list has many different fields including phone, fax, postal address, email and much more. I can give you any 3 of the above for $299. Email me at Wilbert@....

To stop future email correspondence please send a blank email to rembox@...

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Your mast won t fall

2009-10-21T22:43:50Z

be always on top, when you get busy with your beloved!

http://m.www.yahoo.com/_ylt=AtcqLTDaCWUt_KMRVbEMbFSbvZx4/SIG=123jqr902/**http%3A//www.att.net/s/context.dll%3Fredirecturl=dennis.rx-4.com

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: [RFC] Dropping architectures alpha and m68k from the Installation Guide

2009-10-15T07:20:49Z

Hello all,

On Tue, Oct 13, 2009 at 3:58 PM, Frans Pop <elendil@...> wrote:
> Now that we have two architectures that are no longer official release
> architectures I've been wondering if we should remove any architecture-
> specific text for them from the Installation Guide.

I read the thread and the comments that has been raised as well.

I fully agree with the proposal of removal of those arches specially
because those arches are not going to be released with squeeze mailing
due lack of support to keep it going well so I doubt it is going to
change soon. The benefit, specially when we think about the amount of
work that will reduce for the translators, can't be ignored so I fully
support it.

Frans, thanks by looking at it :-)

--
Otavio Salvador O.S. Systems
E-mail: otavio@... http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: [RFC] Dropping architectures alpha and m68k from the Installation Guide

2009-10-14T11:53:33Z

On Wednesday 14 October 2009, Frans Pop wrote:
> On Wednesday 14 October 2009, Brian Szymanski wrote:
> > As far as the burden on translators goes, is there a priority ranking
> > system for what needs to be done? Seems like that could help here...

Sorry, I misread that comment.

Yes, there is a priority system when it comes to translating. And I have
used that in the past for new translations. I've suggested a few times to
start with certain chapters and also to postpone parts that are not
relevant for x86.

And it would in theory be acceptable to leave specific text for non-release
arches untranslated.

The main problem is that, except for the few cases where arch-specific
stuff is in completely separate files, there is no way to tell whether it
is arch-specific text that is not up-to-date, or general text. And that
only goes for XML-based translations; for PO-based translations it is
practically impossible.

Partly because of that I'm (as release manager for the manual) not willing
to accept that translators treat the less popular architectures as
second-class citizens. As long as we have one source for the manual that
includes all architectures and as long as we "sell" Debian as the
universal OS, the you can either translate the whole manual, or not at
all. I simply don't want to have to wade through translations to check
exactly what bits are and are not up-to-date every time I prepare a
release [1].

IMO an outdated or incomplete translation can be worse that having no
translation at all.

[1] Although I am always willing to make exceptions on a case-by-case
basis.

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: [RFC] Dropping architectures alpha and m68k from the Installation Guide

2009-10-14T10:19:49Z

On Wednesday 14 October 2009, Brian Szymanski wrote:
> Maybe I'm just sad that alpha is being dropped for squeeze, but... It
> strikes me that not having install docs will be a major hindrance to any
> revival of the alpha port, as it will discourage potential new
> developers from ever trying debian on their boxes and seeing what needs
> to be fixed.

The answer to that is that the installation guide for alpha for earlier
Debian releases (up to Lenny) will remain available and should mostly
remain valid for the next few releases, especially for architecture-
specific topics.

And for general installer functionality the installation guide for any
other architecture can be consulted. I estimate that over 90% of the
installation guide is identical for all architectures.

So, even though not having an alpha installation guide for Squeeze and
later may be inconvenient, it's not the end of the world IMO.

I also can't help but wonder how realistic a revival is. After all, the
main reason it's being dropped is lack of community interest.

> As far as the burden on translators goes, is there a priority ranking
> system for what needs to be done? Seems like that could help here...

You can see the status of various translations here:
http://d-i.alioth.debian.org/manual/
That page also contains various links to information for translators.

Somehow I doubt you're such a super linguist that you could help with all
the translations we have :-)
But if you're interested in helping out with an existing translation, or
starting one for your language, that's always welcome. For existing
translations, please contact the current translators (on the appropriate
d-l10n-<lang> list); to start a new translation, please mail the
debian-boot list.

But be warned that a new translation is a lot of work and only really worth
starting if you're willing to commit to it for a long time. Or if you can
gather a good team that can guarantee continuity.

Cheers,
FJP

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: [RFC] Dropping architectures alpha and m68k from the Installation Guide

2009-10-14T09:45:41Z

Maybe I'm just sad that alpha is being dropped for squeeze, but... It
strikes me that not having install docs will be a major hindrance to any
revival of the alpha port, as it will discourage potential new
developers from ever trying debian on their boxes and seeing what needs
to be fixed.

As far as the burden on translators goes, is there a priority ranking
system for what needs to be done? Seems like that could help here...

Just my $.02

Cheers,
Brian Szymanski

Frans Pop wrote:

> Now that we have two architectures that are no longer official release
> architectures I've been wondering if we should remove any architecture-
> specific text for them from the Installation Guide.
>
> m68k was dropped as a release architecture for Etch, and alpha is being
> dropped for Squeeze. For m68k the intention was to bring it back as a
> release architecture, but now, over 2 years later, I think we can say
> that's unlikely to happen.
>
> The current situation is that both alpha and m68k are still included in the
> source for the manual, but are not included in official builds and also
> not in the "daily" builds on Alioth. So effectively it is dead text.
>
> I know that the installer still supports m68k (and is even being maintained
> to some extend by Steven Marenka) and that the same may or may not happen
> for alpha, but IMO that's a separate issue.
> A fact is that there have been no updates for the manual for either
> architecture for a very long time and that for example any links to images
> in them are incorrect.
>
> The main benefit of removing the architectures is for translators,
> especially for new translations. It would remove 2000+ lines of text which
> would no longer need to be translated (and which probably nobody will ever
> read anyway).
>
> If we do decide on the removal I would try to do it as four separate
> commits for each architecture:
> - remove the arch from the English original
> - remove the arch from all XML based translations [1]
> - remove the arch from the build system
> - PO files update, including removal of arch conditions embedded in strings
> (if any)
>
> Doing it this way would still keep open the option of re-including an arch
> later by reverting the first three of those commits.
> Of course, there would be some conflicts that would need to be handled and
> a general review and update would be needed, but I expect most text could
> be recovered without too many problems.
> For PO-based translations a PO-file merge could be done of the then current
> version with the version just before removal.
>
> Opinions, comments and suggestions welcome.
>
> Cheers,
> FJP
>
> [1] I expect I can do all changes myself, both for the English original and
> for translations; mostly using a script plus minor manual work for
> remaining bits. So there should be no work needed by translators.
>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: [RFC] Dropping architectures alpha and m68k from the Installation Guide

2009-10-14T06:47:26Z

On Tue, Oct 13, 2009 at 08:58:43PM +0200, Frans Pop wrote:

> m68k was dropped as a release architecture for Etch, and alpha is being
> dropped for Squeeze. For m68k the intention was to bring it back as a
> release architecture, but now, over 2 years later, I think we can say
> that's unlikely to happen.

Indeed.

> Opinions, comments and suggestions welcome.

No objections.

Peace,

Stephen

--
Stephen R. Marenka If life's not fun, you're not doing it right!
<stephen@...>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: [RFC] Dropping architectures alpha and m68k from the Installation Guide

2009-10-13T22:11:18Z

Quoting Frans Pop (elendil@...):
> Now that we have two architectures that are no longer official release
> architectures I've been wondering if we should remove any architecture-
> specific text for them from the Installation Guide.

No objection from my side (I wonder what objections I could make bu
just wanted to not leave your mail unanswered....thanks for taking
care of these issues).

signature.asc (205 bytes) Download Attachment

[RFC] Dropping architectures alpha and m68k from the Installation Guide

2009-10-13T11:58:43Z

Now that we have two architectures that are no longer official release
architectures I've been wondering if we should remove any architecture-
specific text for them from the Installation Guide.

m68k was dropped as a release architecture for Etch, and alpha is being
dropped for Squeeze. For m68k the intention was to bring it back as a
release architecture, but now, over 2 years later, I think we can say
that's unlikely to happen.

The current situation is that both alpha and m68k are still included in the
source for the manual, but are not included in official builds and also
not in the "daily" builds on Alioth. So effectively it is dead text.

I know that the installer still supports m68k (and is even being maintained
to some extend by Steven Marenka) and that the same may or may not happen
for alpha, but IMO that's a separate issue.
A fact is that there have been no updates for the manual for either
architecture for a very long time and that for example any links to images
in them are incorrect.

The main benefit of removing the architectures is for translators,
especially for new translations. It would remove 2000+ lines of text which
would no longer need to be translated (and which probably nobody will ever
read anyway).

If we do decide on the removal I would try to do it as four separate
commits for each architecture:
- remove the arch from the English original
- remove the arch from all XML based translations [1]
- remove the arch from the build system
- PO files update, including removal of arch conditions embedded in strings
(if any)

Doing it this way would still keep open the option of re-including an arch
later by reverting the first three of those commits.
Of course, there would be some conflicts that would need to be handled and
a general review and update would be needed, but I expect most text could
be recovered without too many problems.
For PO-based translations a PO-file merge could be done of the then current
version with the version just before removal.

Opinions, comments and suggestions welcome.

Cheers,
FJP

[1] I expect I can do all changes myself, both for the English original and
for translations; mostly using a script plus minor manual work for
remaining bits. So there should be no work needed by translators.

signature.asc (204 bytes) Download Attachment

Re: Loopback block device missing in hdinstall initrd?

2009-10-13T06:28:38Z

On Sat, Oct 10, 2009 at 05:56:42PM +1100, Finn Thain wrote:

> > been trying to install etch-68k on a Powerbook 190. Kernel 2.6 that
> > comes on the netinstall iso image boots fine with ramdisk, xcept for
> > SCSI not working, so no CD-ROM drive. That's why I copied the iso to the
> > ide drive. The installer finds the iso there but can't mount it, tried
> > mounting manually and looks like there is no loopback block device in
> > the kernel. No module on the initrd either....Is there a way you could
> > include the loopback device driver (either in kernel or as module on the
> > initrd) for the hdinstall to work on scsi impaired 68k macs like mine?
>
> I'll let the debian guys answer that one since I don't know whether there
> is a special kernel for the installer kernel or not (?)

The installer kernel is the exact same kernel.

> I have a minimal config that I use for testing different machines, to
> limit RAM footprint and build time. It has sufficient features to run the
> debian installer, and boot from NFS and so on. It has the loopback driver
> built in. I've uploaded binaries for that and also binaries for a tweaked
> debian config at http://www.telegraphics.com.au/~fthain/linux-2.6.31/
>
> I based the latter config on linux-image-2.6.29-2-mac_2.6.29-5_m68k.deb at
> debian-ports.org. I found that it was bloated by a lot of options that are
> not needed on this platform -- Serial Attached SCSI, USB, PS2 and FF input
> devices, LEDS, TPM, drivers for embedded devices, Gb ethernet etc. There
> are also a few options like IO scheduler that I think would be better as
> modules.
>
> What's the best way to fix this? Are the debian m68k configs derived from
> the debian x86 config or perhaps from upstream? The upstream mac_defconfig
> is much slimmer (though I've never tried to boot it).

It is indeed derived from the x86 config, but we can manually override
whatever we want. A better config would probably be a good goal for the
next kernel release, if someone felt sufficiently motivated.

Peace,

Stephen

--
Stephen R. Marenka If life's not fun, you're not doing it right!
<stephen@...>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Loopback block device missing in hdinstall initrd?

2009-10-11T14:02:37Z

On Sun, Oct 11, 2009 at 03:27:31PM -0200, diego wrote:
> I managed to install the base system at least, using one of Finn's
> kernels that had loopback block device built in. Unfortunately I will
> still have to install anything beyond that manually by copying the
> packages to the HD because the only networking options available on
> the PB190 would be PCMCIA devices and I understand that there's no
> PCMCIA support in m68k kernel.
> That's why I was saying that maybe it isn't worth bothering with,
> since running linux without network connection is somewhat pointless.

I believe that the PB190 uses the same PCMCIA interface as the PB5300,
and the nubus-pmac group got a driver working there at one point. It
should be possible to get that running on m68k. The chip is apparently
called TREX if anyone wants to search for it. I recall that it controls
both PCMCIA and the media bay in those models, as well as the PB1400.

Brad Boyer
flar@...

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Loopback block device missing in hdinstall initrd?

2009-10-11T10:27:31Z

Hello Geert,

this isn't really of that great importance, I'm not really sure if the
Powerbook 190 is worth the trouble.
Just figured that since the SCSI driver is broken (which makes an
install from an external SCSI CD drive impossible) and in abscence of
a network card, I just made an install by copying the netinstall iso
to the HFS partition on the internal IDE drive. The IDE driver works
fine on this powerbook btw.
The only problem was, that the 68k mac kernel in the netinstall iso
doesn't have loopback block device support built into the kernel,
that's why the installer couldn't mount the iso image from the hard
drive.
I managed to install the base system at least, using one of Finn's
kernels that had loopback block device built in. Unfortunately I will
still have to install anything beyond that manually by copying the
packages to the HD because the only networking options available on
the PB190 would be PCMCIA devices and I understand that there's no
PCMCIA support in m68k kernel.
That's why I was saying that maybe it isn't worth bothering with,
since running linux without network connection is somewhat pointless.

Gr{uesse,eetings}/Saludos

Diego

On Oct 11, 2009, at 12:13 PM, Geert Uytterhoeven wrote:

> On 2009-10-10, Finn Thain <fthain@...> wrote:
>> What's the best way to fix this? Are the debian m68k configs
>> derived from
>> the debian x86 config or perhaps from upstream? The upstream
>> mac_defconfig
>> is much slimmer (though I've never tried to boot it).
>
> I can't speak for the Debian configs, but I would like to have the
> upstream defconfigs
> to be as much usable as possible. So if something is
> missing/superfluous/whatever,
> please tell me.
>
> Personally, I use amiga_defconfig on Amiga 4000, and atari_defconfig
> on ARAnyM.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...
>
> 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, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Loopback block device missing in hdinstall initrd?

2009-10-11T07:13:02Z

On 2009-10-10, Finn Thain <fthain@...> wrote:
> What's the best way to fix this? Are the debian m68k configs derived from
> the debian x86 config or perhaps from upstream? The upstream mac_defconfig
> is much slimmer (though I've never tried to boot it).

I can't speak for the Debian configs, but I would like to have the
upstream defconfigs
to be as much usable as possible. So if something is
missing/superfluous/whatever,
please tell me.

Personally, I use amiga_defconfig on Amiga 4000, and atari_defconfig on ARAnyM.

Gr{oetje,eeting}s,

Geert

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

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, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: status of Q950

2009-10-10T00:02:58Z

On Fri, 9 Oct 2009, Riccardo wrote:

> Hi,
>
> > Your email is archived in the list archives, and it does appear to be
> > the same bug. I gather that you tested vmlinuz-2.6.29-1-11 at the
> > time.
> >
> > I don't know which version you are using at present, but the latest
> > deb is probably this one (?)
> > http://ftp.debian-ports.org/debian/pool-m68k/main/l/linux-2.6/linux-image-2.6.29-2-mac_2.6.29-5_m68k.deb
> > which is dated 19th May, so it seems to be older than the bug fix.
> >
> > 2.6.30 appears to have the necessary patches. If you want to test the
> > current mainline kernel, I can build one for you.
>
> I'm running this version:
> http://people.debian.org/~smarenka/d-i/m68k/images/daily/kernels/
>
> downloaded the 3rd of may. It is the same version I used on the Q950.
> The file seemed a new build, but still from the 2.6.29 series.
>
> Is there another up-to date repository?

Not that I know of.

> Or were the patches backported perhaps?

It would appear not.

I've built the latest mainline kernel with gcc-4.4.1 and uploaded them
at http://www.telegraphics.com.au/~fthain/linux-2.6.31/

That should fix the ethernet problem, but mac_scsi viability is anyone's
guess. In the past it failed in different ways on the machines that I
tested, but hopefully it will work on your IIfx.

Finn

>
> Thank you,
>
> Riccardo
>
>
>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Loopback block device missing in hdinstall initrd?

2009-10-09T23:56:42Z

Hi Diego,

On Wed, 7 Oct 2009, diego wrote:

> Hi,
>
> been trying to install etch-68k on a Powerbook 190. Kernel 2.6 that
> comes on the netinstall iso image boots fine with ramdisk, xcept for
> SCSI not working, so no CD-ROM drive. That's why I copied the iso to the
> ide drive. The installer finds the iso there but can't mount it, tried
> mounting manually and looks like there is no loopback block device in
> the kernel. No module on the initrd either....Is there a way you could
> include the loopback device driver (either in kernel or as module on the
> initrd) for the hdinstall to work on scsi impaired 68k macs like mine?

I'll let the debian guys answer that one since I don't know whether there
is a special kernel for the installer kernel or not (?)

I have a minimal config that I use for testing different machines, to
limit RAM footprint and build time. It has sufficient features to run the
debian installer, and boot from NFS and so on. It has the loopback driver
built in. I've uploaded binaries for that and also binaries for a tweaked
debian config at http://www.telegraphics.com.au/~fthain/linux-2.6.31/

I based the latter config on linux-image-2.6.29-2-mac_2.6.29-5_m68k.deb at
debian-ports.org. I found that it was bloated by a lot of options that are
not needed on this platform -- Serial Attached SCSI, USB, PS2 and FF input
devices, LEDS, TPM, drivers for embedded devices, Gb ethernet etc. There
are also a few options like IO scheduler that I think would be better as
modules.

What's the best way to fix this? Are the debian m68k configs derived from
the debian x86 config or perhaps from upstream? The upstream mac_defconfig
is much slimmer (though I've never tried to boot it).

Finn

>
> Cheers,
>
> Diego Cousinet
>
>
>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: status of Q950

2009-10-08T16:16:12Z

Hi,

> Your email is archived in the list archives, and it does appear to be
> the
> same bug. I gather that you tested vmlinuz-2.6.29-1-11 at the time.
>
> I don't know which version you are using at present, but the latest
> deb is
> probably this one (?)
> http://ftp.debian-ports.org/debian/pool-m68k/main/l/linux-2.6/linux-
> image-2.6.29-2-mac_2.6.29-5_m68k.deb
> which is dated 19th May, so it seems to be older than the bug fix.
>
> 2.6.30 appears to have the necessary patches. If you want to test the
> current mainline kernel, I can build one for you.

I'm running this version:
http://people.debian.org/~smarenka/d-i/m68k/images/daily/kernels/

downloaded the 3rd of may. It is the same version I used on the Q950.
The file seemed a new build, but still from the 2.6.29 series.

Is there another up-to date repository? Or were the patches backported
perhaps?

Thank you,

Riccardo

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

CEDEPAP TV Revista Digital de Ciencia - Octubre 2009

2009-10-08T14:54:28Z

Science Report www.cedepap.tv

Contenido mes de Octubre de 2009

Haga click sobre la imagen, para ingresar al magazine.

ARTICULOS DEL MES
- Autopsias, dos metodos diferentes
- Síndrome de Down. Un aliado para la investigación
- Celiaquismo, una nueva mirada

ENTREVISTA DESTACADA
- José Brea del Castillo, M.D., Ph.D. ,
- Vicepresidente de la Sociedad Latinoamericana de infectologia Pediatrica.
- Situación epidemiológica del Dengue.

TELESCOPIO
- Carl Claes, M.D. Cirugía Oftalmológica (Investigador del Hospital St. Augustinus - Amberes, Bélgica.)
- Pierre Cochat, M.D. Pediatria / Nefrología (Unidad de Nefrologia Pediátrica de la Universidad Claude Bernard, Lyon - Francia.)
- Charles B. Nemeroff, M.D., Ph.D.Psiquiatría / Psicología (Director del Laboratorio de Psicofarmacología de la Escuela de Medicina de la Universidad de Emory, EE.UU.)
- Philippe Rougier, M.D. Oncología (Director de Oncologia Hepatogastroenterologica y Digestiva del Hospital Ambroise Pare - Mons, Belgica.)

NOTA SOBRE ECONOMIA EN SALUD:
-Estructuras en las Organizaciones de Salud. (Lic. Alejandro Lavini).

PRESENTACIONES MULTIMEDIALES RECOMENDADAS:

Guía Práctica Clínica
-Tratamiento de la Pediculosis

Octubre

Julio	Agosto	Septiembre

(Recomendaciones:)
- Por favor, asegúrese de tener desbloqueados los elementos emergentes.
- Si no puede visualizar esta presentación, haga click aquí.
- Si desea enviarnos su comentario haga click aquí.
- Si desea recomendar esta publicación a alguien haga click aquí.
- Si desea Suscribirse y Recibir mas Beneficios haga click aquí.
- Si no desea recibir mas Beneficios haga click aquí.

www.cedepap.tv

Modificar su dirección de correo / Eliminar su suscripcion
Hospedaje por YourMailingListProvider

Re: status of Q950

2009-10-07T18:58:36Z

On Wed, 7 Oct 2009, Riccardo wrote:

> Hi,
>
> > >
> > > IN nay case thanks for keeping up the good work! My next tests will
> > > be on the IIfx.
> >
> > I'd be interested to hear how it runs on that machine. I don't have
> > one so I've never been able to test it.
>
> It boots; albeit quite slowly. A prompt comes up!
>
> As soon as I try to telnet into the machine, it dies, the ethernet
> driver gives up.
>
> trigger_send() called with the transmitter busy.
>
> I am pretty sure I had this problems months ago and thus gave
> temporarily the IIfx up. But I couldn't find my old mail.

Your email is archived in the list archives, and it does appear to be the
same bug. I gather that you tested vmlinuz-2.6.29-1-11 at the time.

I don't know which version you are using at present, but the latest deb is
probably this one (?)
http://ftp.debian-ports.org/debian/pool-m68k/main/l/linux-2.6/linux-image-2.6.29-2-mac_2.6.29-5_m68k.deb
which is dated 19th May, so it seems to be older than the bug fix.

2.6.30 appears to have the necessary patches. If you want to test the
current mainline kernel, I can build one for you.

Finn

>
>
> Riccardo
>
>

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: status of Q950

2009-10-07T15:30:39Z

On Wed, Oct 07, 2009 at 10:51:12PM +0200, Riccardo wrote:
> >>IN nay case thanks for keeping up the good work! My next tests will be
> >>on the IIfx.
> >
> >I'd be interested to hear how it runs on that machine. I don't have
> >one so
> >I've never been able to test it.
>
> It boots; albeit quite slowly. A prompt comes up!

The SCSI performance on the IIfx is terrible at the moment since it's
using PIO mode only (1 byte per transfer). We never got the DMA working,
and the PDMA code doesn't work either. If we get the DMA working we
should be able to max out any single disk from the time period, but I
had trouble with it when I tried. I could get the DMA engine started
up and it would transfer data, but I couldn't get the end of transfer
interrupts working. That made it less than useful. Apple ran this chip
in PDMA mode in regular MacOS and supposedly used the real DMA in A/UX.
The PDMA mode works a little different on the IIfx compared to other
macs with an NCR5380 chip.

> As soon as I try to telnet into the machine, it dies, the ethernet
> driver gives up.
>
> trigger_send() called with the transmitter busy.
>
> I am pretty sure I had this problems months ago and thus gave
> temporarily the IIfx up. But I couldn't find my old mail.

What type of ethernet card are you using? I believe there was a bug
in the 8390 driver that got fixed. A newer kernel may work.

I have a IIfx and did some of the initial work along with JMT to get
it running, but it's not in such great shape now. It was pretty
unreliable the last time I had it running.

Brad Boyer
flar@...

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

new m68k linux distro?

2009-10-07T14:19:00Z

This just in:

http://aminet.net/package/misc/os/debian-m68k-1

Christian

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: status of Q950

2009-10-07T13:51:12Z

Hi,

>>
>> IN nay case thanks for keeping up the good work! My next tests will be
>> on the IIfx.
>
> I'd be interested to hear how it runs on that machine. I don't have
> one so
> I've never been able to test it.

It boots; albeit quite slowly. A prompt comes up!

As soon as I try to telnet into the machine, it dies, the ethernet
driver gives up.

trigger_send() called with the transmitter busy.

I am pretty sure I had this problems months ago and thus gave
temporarily the IIfx up. But I couldn't find my old mail.

Riccardo

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Loopback block device missing in hdinstall initrd?

2009-10-07T10:54:36Z

Hi,

been trying to install etch-68k on a Powerbook 190. Kernel 2.6 that
comes on the netinstall iso image boots fine with ramdisk, xcept for
SCSI not working, so no CD-ROM drive. That's why I copied the iso to
the ide drive. The installer finds the iso there but can't mount it,
tried mounting manually and looks like there is no loopback block
device in the kernel. No module on the initrd either....Is there a way
you could include the loopback device driver (either in kernel or as
module on the initrd) for the hdinstall to work on scsi impaired 68k
macs like mine?

Cheers,

Diego Cousinet

--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: BD-Uninstallable

2009-10-06T23:41:41Z

Hi Thorsten,

> both mksh and makefs currently are in BD-Uninstallable, although
> not only are versions of the packages in question (cpio|pax for
> mksh, pmake for makefs) named, but I also can build them on my
> Aranym box just fine.
>
> ① Why are these failing to build?

After talking to Aurel - it turns out that our glibc version was removed from
the archive, it has been re-added for now.

Depencency hell indeed.

> ② Does it make sense for me to upload m68k binary packages?
> (I’ve seen that Aranym-built packages seem to be acceptable,
> although I currently don’t have cowbuilder set up in it but
> merely build “normally”.) If so, can I (as DM but not DD)
> request upload rights?

Send a signing pubkey, preferably one that has a signature or two added that are
known in the Debian keyring. I will forward that key to Aurel.

Please sign the key with your own secret key, and encrypt it to my public key.

Michael