Is the kernel arch tree for alphas not maintained anymore? If I download
the vanilla 2.5.26 I can't build it at all. Even a make clean fails
due to missing directives in arch/alpha/kernel/Makefile.
Has anybody any idea?
Martin
>>On Sat, 20 Jul 2002, Martin Brulisauer wrote:
>> Is the kernel arch tree for alphas not maintained anymore? If I download
>> the vanilla 2.5.26 I can't build it at all. Even a make clean fails
>> due to missing directives in arch/alpha/kernel/Makefile.
>
>On Sat, 20 Jul 2002, Thunder from the hill wrote:
>What exactly are you experiencing?
>
make mrproper: ok.
make defconfig: ok.
make dep:
make[1]: Entering directory `/usr/src/linux-2.5.27'
make[1]: Nothing to be done for `include/linux/modversions.h'.
make[1]: Leaving directory `/usr/src/linux-2.5.27'
make boot:
make[1]: Entering directory `/usr/src/linux-2.5.27/scripts'
gcc -Wp,-MD,./.split-include.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o split-include split-include.c
In file included from /usr/include/linux/errno.h:4,
from /usr/include/bits/errno.h:25,
from /usr/include/errno.h:36,
from split-include.c:26:
/usr/include/asm/errno.h:4: asm-generic/errno-base.h: No such file or directory
make[1]: *** [split-include] Error 1
make[1]: Leaving directory `/usr/src/linux-2.5.27/scripts'
make: *** [scripts] Error 2
make clean:
make[1]: Entering directory `/usr/src/linux-2.5.27/arch/alpha/kernel'
make[1]: *** No rule to make target `clean'. Stop.
make[1]: Leaving directory `/usr/src/linux-2.5.27/arch/alpha/kernel'
make: *** [archclean] Error 2
Looks to me like noone ever tried to compile this
kernel on this platform. That is why I asked my
silly question.
Regards,
Martin
On 21 Jul 2002, at 18:57, Oliver Pitzeier wrote:
> Oh... I did... :o( :o) But it's currently a mission
> impossible. The last kernel running fine for my alpha
> is 2.5.18 (with a lot of patches...)
>
> I'm also currently not sure that kernel 2.6.X will
> ever run on alpha. There are not very much alpha-users.
> And there are lesser alpha kernel maintainers.
> Ivan Kokshaysky and "Thunder from the hill" are two
> persons who often work an the Alpha Code. And me
> as well (a bit....). But it's currently not easy
> to fix the new errors (for alpha) in every kernel
> release, because they are growing...
Do you think it's worth the time to patch the current
version? Will Linus apply the patch so we will hopefully
have a 2.6.x kernel that compiles (at least) on alpha's?
Is there anybody who is willing to test such a patch
on different alpha's (I only have some XLT's, an AS800
and one AS250, so all alcor based systems with
ISA and PCI but without EISA and all are using sys_alcor.c)?
Further I can't test SMP with this _very_ old hardware.
Regards,
Martin Brulisauer
On Tue, 2002-07-23 14:42:03 +0200, Martin Brulisauer <[email protected]>
wrote in message <3D3D6B3B.25754.1392D3FD@localhost>:
> On 21 Jul 2002, at 18:57, Oliver Pitzeier wrote:
> > Oh... I did... :o( :o) But it's currently a mission
> > impossible. The last kernel running fine for my alpha
> > is 2.5.18 (with a lot of patches...)
There was a quite good patch sent to l-k some weeks ago which
(basically) still applies. I'm using this one (with watering eyes
waiting for a compileable Linus-Kernel...).
> Is there anybody who is willing to test such a patch
> on different alpha's (I only have some XLT's, an AS800
> and one AS250, so all alcor based systems with
> ISA and PCI but without EISA and all are using sys_alcor.c)?
> Further I can't test SMP with this _very_ old hardware.
I cannot test SMP either (I've not got a SMP alpha), but I can test on
Miata, Avanit and NoName.
MfG, JBG
--
Jan-Benedict Glaw . [email protected] . +49-172-7608481
-- New APT-Proxy written in shell script --
http://lug-owl.de/~jbglaw/software/ap2/
On Tuesday 23 July 2002 08:42, Martin Brulisauer wrote:
> On 21 Jul 2002, at 18:57, Oliver Pitzeier wrote:
> > I'm also currently not sure that kernel 2.6.X will
> > ever run on alpha. There are not very much alpha-users.
> > And there are lesser alpha kernel maintainers.
> > Ivan Kokshaysky and "Thunder from the hill" are two
> > persons who often work an the Alpha Code. And me
> > as well (a bit....). But it's currently not easy
> > to fix the new errors (for alpha) in every kernel
> > release, because they are growing...
2.6.x will run on alpha. There are still a handfull of people that still
activly maintian Linux on Alpha. Since there is only a few people that
activly work on Alpha, they tend to chose a kernel versions, then work with
that version for a while until it is stable. In the past few months most of
the efforts have been spent on 2.4.9. Currently there have been discussions
in regard to:
1) porting all those patches for 2.4.9 forward to 2.4.[18-19] and 2.5.x.
2) taking a look at the latest 2.5.x in the next few weeks, as we are aware
that 2.5.x does not compile on Alpha.
>
> Do you think it's worth the time to patch the current
> version? Will Linus apply the patch so we will hopefully
> have a 2.6.x kernel that compiles (at least) on alpha's?
It is certainly worth the time. It is not too difficult to get any sane
patch applied to the kernel for Alpha.
>
> Is there anybody who is willing to test such a patch
> on different alpha's (I only have some XLT's, an AS800
> and one AS250, so all alcor based systems with
> ISA and PCI but without EISA and all are using sys_alcor.c)?
> Further I can't test SMP with this _very_ old hardware.
I have access to a Lab that is filled with Alpha systems. I would be happy
to test any patch as I have time.
Please let me know if I can be of further assistence.
Best Regards,
--George.
On Tuesday 23 July 2002 11:05, George France wrote:
> 2.6.x will run on alpha. There are still a handfull of people that still
> activly maintian Linux on Alpha. Since there is only a few people that
> activly work on Alpha, they tend to chose a kernel versions, then work with
> that version for a while until it is stable. In the past few months most
> of the efforts have been spent on 2.4.9. Currently there have been
> discussions in regard to:
Just out of curiosity, on what mailing lists discussions are taking place ?
I'm subscribed to some alpha mailing lists, but still, most of the kernel
patches for alpha I see are comming from LKML ...
Thanks,
ghoz
On 23 Jul 2002, at 11:05, George France wrote:
> that version for a while until it is stable. In the past few months most of
> the efforts have been spent on 2.4.9. Currently there have been discussions
> in regard to:
>
> 1) porting all those patches for 2.4.9 forward to 2.4.[18-19] and 2.5.x.
I am currently running 2.4.18 from SuSE without any (major)
problems. I found it here:
ftp://ftp.suse.com/pub/people/sf/axp/7.1/RPMS/kernel-source-
2.4.18.SuSE-0.alpha.rpm.
Then I took arch/alpha/kernel/core_cia.c from version 2.4.12
(the current version does not run on XLT's booting with MILO;
the latest one is 2.4.12).
> 2) taking a look at the latest 2.5.x in the next few weeks, as we are aware
> that 2.5.x does not compile on Alpha.
Hopefully I can fix core_cia.c to run on XLT's (it's hard to find any
documentation on this toppic) and arch/alpha/kernel/setup.c for
machines booting with linload.exe/MILO because the hwrpb
struct is built by MILO and does not match the one booting from
SRM (eg. empty percpu struct resulting in a cpucount of zero
in /proc/cpuinfo).
Regards,
Martin
On Tuesday 23 July 2002 13:01, Martin Brulisauer wrote:
> On 23 Jul 2002, at 11:05, George France wrote:
> > that version for a while until it is stable. In the past few months most
> > of the efforts have been spent on 2.4.9. Currently there have been
> > discussions in regard to:
> >
> > 1) porting all those patches for 2.4.9 forward to 2.4.[18-19] and 2.5.x.
>
> I am currently running 2.4.18 from SuSE without any (major)
> problems. I found it here:
> ftp://ftp.suse.com/pub/people/sf/axp/7.1/RPMS/kernel-source-
> 2.4.18.SuSE-0.alpha.rpm.
> Then I took arch/alpha/kernel/core_cia.c from version 2.4.12
> (the current version does not run on XLT's booting with MILO;
> the latest one is 2.4.12).
I have not tried Stefan's 2.4.18 kernel. I am glad to hear that it works for
you. I will give it a try.
> > 2) taking a look at the latest 2.5.x in the next few weeks, as we are
> > aware that 2.5.x does not compile on Alpha.
>
> Hopefully I can fix core_cia.c to run on XLT's (it's hard to find any
> documentation on this toppic) and arch/alpha/kernel/setup.c for
> machines booting with linload.exe/MILO because the hwrpb
> struct is built by MILO and does not match the one booting from
> SRM (eg. empty percpu struct resulting in a cpucount of zero
> in /proc/cpuinfo).
I am not very familiar with the XLT systems. Maybe Jay can help. He has been
working on Alpha systems for a very long time.
Jay, do you have any suggestions???
Best Regards,
--George
On Tue, 23 Jul 2002, George France wrote:
> On Tuesday 23 July 2002 13:01, Martin Brulisauer wrote:
> > Hopefully I can fix core_cia.c to run on XLT's (it's hard to find any
> > documentation on this toppic) and arch/alpha/kernel/setup.c for
> > machines booting with linload.exe/MILO because the hwrpb
> > struct is built by MILO and does not match the one booting from
> > SRM (eg. empty percpu struct resulting in a cpucount of zero
> > in /proc/cpuinfo).
>
> I am not very familiar with the XLT systems. Maybe Jay can help. He has been
> working on Alpha systems for a very long time.
I am using Stock 2.4.19-rc2 with the following simple patch on an xl-300
with milo:
(without it, it breaks while initalizing the ncr-scsi-controller)
--- linux/arch/alpha/kernel/core_cia.c.orig Sun Oct 21 19:30:58 2001
+++ linux/arch/alpha/kernel/core_cia.c Fri Jul 19 16:11:46 2002
@@ -382,10 +382,10 @@
for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
ppte[i] = pte;
- *(vip)CIA_IOC_PCI_W1_BASE = CIA_BROKEN_TBIA_BASE | 3;
- *(vip)CIA_IOC_PCI_W1_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1)
+ *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBIA_BASE | 3;
+ *(vip)CIA_IOC_PCI_W3_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1)
& 0xfff00000;
- *(vip)CIA_IOC_PCI_T1_BASE = virt_to_phys(ppte) >> 2;
+ *(vip)CIA_IOC_PCI_T3_BASE = virt_to_phys(ppte) >> 2;
}
static void __init
I've got the patch from Alexander Stokman, who was kind to send it to me
~3 month after sending my question to lkml
c'ya
sven
--
The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)
On Tue, Jul 23, 2002 at 03:00:50PM -0400, George France wrote:
> On Tuesday 23 July 2002 13:01, Martin Brulisauer wrote:
> >
> > Hopefully I can fix core_cia.c to run on XLT's (it's hard to find any
> > documentation on this toppic) and arch/alpha/kernel/setup.c for
> > machines booting with linload.exe/MILO because the hwrpb
> > struct is built by MILO and does not match the one booting from
> > SRM (eg. empty percpu struct resulting in a cpucount of zero
> > in /proc/cpuinfo).
>
> I am not very familiar with the XLT systems. Maybe Jay can help. He
> has been working on Alpha systems for a very long time.
>
> Jay, do you have any suggestions???
Yup, use the following patches, based on pre8-2.4.19, to fix the
DMA windowing problem with the early (read: 300MHz) XLT boxes.
As for the CPU count being zero, well, aside from looking bad, what
seems to be the problem? ;-}
--Jay++
-----------------------------------------------------------------------------
Jay A Estabrook HPTC - LINUX support
Hewlett-Packard Company - MRO1-2/K15 (508) 467-2080
200 Forest Street, Marlboro MA 01752 [email protected]
-----------------------------------------------------------------------------
On Tue, Jul 23, 2002 at 09:08:26PM +0200, Sven Koch wrote:
>
> I am using Stock 2.4.19-rc2 with the following simple patch on an xl-300
> with milo:
> (without it, it breaks while initalizing the ncr-scsi-controller)
>
> --- linux/arch/alpha/kernel/core_cia.c.orig Sun Oct 21 19:30:58 2001
> +++ linux/arch/alpha/kernel/core_cia.c Fri Jul 19 16:11:46 2002
> @@ -382,10 +382,10 @@
> for (i = 0; i < CIA_BROKEN_TBIA_SIZE / sizeof(unsigned long); ++i)
> ppte[i] = pte;
>
> - *(vip)CIA_IOC_PCI_W1_BASE = CIA_BROKEN_TBIA_BASE | 3;
> - *(vip)CIA_IOC_PCI_W1_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1)
> + *(vip)CIA_IOC_PCI_W3_BASE = CIA_BROKEN_TBIA_BASE | 3;
> + *(vip)CIA_IOC_PCI_W3_MASK = (CIA_BROKEN_TBIA_SIZE*1024 - 1)
> & 0xfff00000;
> - *(vip)CIA_IOC_PCI_T1_BASE = virt_to_phys(ppte) >> 2;
> + *(vip)CIA_IOC_PCI_T3_BASE = virt_to_phys(ppte) >> 2;
> }
>
> static void __init
Yes, this will help on XLT-300.
What this patch does is revert the code to an older version which uses
PCI DMA window #3 for the scatter/gather operations, thus avoiding the
use of window #1 for that operation.
On older machines like the XLT-300 and EB164, their core logic, CIA
Rev 1, appears to have a bug in that PCI DMA windows #1 and #2 cannot
be used for scatter/gather. Boxes based on CIA rev 2, and PYXIS, do
not have the same problem.
The patches I attached to an earlier posting essentially do this for
the rev 1 CIA machines, but leave active the code for dual-address
cycle (DAC) support for the CIA rev 2 and PYXIS based machines.
--Jay++
-----------------------------------------------------------------------------
Jay A Estabrook HPTC - LINUX support
Hewlett-Packard Company - MRO1-2/K15 (508) 467-2080
200 Forest Street, Marlboro MA 01752 [email protected]
-----------------------------------------------------------------------------
On 24 Jul 2002, at 1:05, Oliver Pitzeier wrote:
> > On 23 Jul 2002, at 18:29, George France wrote:
> > > site or mailing list. It is probably better to utilize
> > what exist. Either
> > > the [email protected], [email protected],
> > > [email protected] or [email protected]. In the
> > > worst
> >
> > As long as these lists are kernel (?) and not user oriented
> > and not too distribution specific.
>
> That's why I think it would be the best to setup a new one. But you'll
> never be able to lock out distribution specify questions and so
> replies... :o(
>
All these mailing lists are used to have kind of a "virtual" team,
are they? If we move the linux/alpha discussions away from
linux-kernel and/or vger.kernel.org how big is the risk that we
solve problems in this list others have already done?
In my oppinion linux/alpha should not be treated as a separate
task, offline from other kernel discussions. Too much information
could get lost - and as we can see now - linux/alpha is way
behind the current tree Linus maintains.
If Linus will participate in a linux/alpha mailing list, then it would
be a good idea - If not ... (guess if he will ;-}).
Regards,
Martin
On 24 Jul 2002, at 0:52, Oliver Pitzeier wrote:
> (Maybe an CVS tree for alpha-kernel developers. Those people
> must be trusted you can imagine...)
As I can see in the kernel howto, there is only one
linux version _all_ patches have to go to at least -
that's the one Linus maintains. And this makes
all sense to me - it keeps the kernel alive and
avoids falling apart over the time.
Martin
Martin Brulisauer wrote:
[ ... ]
> Do you think it's worth the time to patch the current
> version? Will Linus apply the patch so we will hopefully
> have a 2.6.x kernel that compiles (at least) on alpha's?
I hope linus joins this thread some day... :o)
[ ... ]
-Oliver
Jan-Benedict Glaw wrote:
> On Tue, 2002-07-23 14:42:03 +0200, Martin Brulisauer
> <[email protected]> wrote in message
> <3D3D6B3B.25754.1392D3FD@localhost>:
> > On 21 Jul 2002, at 18:57, Oliver Pitzeier wrote:
> > > Oh... I did... :o( :o) But it's currently a mission
> impossible. The
> > > last kernel running fine for my alpha is 2.5.18 (with a lot of
> > > patches...)
>
> There was a quite good patch sent to l-k some weeks ago which
> (basically) still applies. I'm using this one (with watering
> eyes waiting for a compileable Linus-Kernel...).
I go and search it...
> > Is there anybody who is willing to test such a patch
> > on different alpha's (I only have some XLT's, an AS800
> > and one AS250, so all alcor based systems with
> > ISA and PCI but without EISA and all are using
> sys_alcor.c)? Further I
> > can't test SMP with this _very_ old hardware.
>
> I cannot test SMP either (I've not got a SMP alpha), but I
> can test on Miata, Avanit and NoName.
I've got a AS1000. Noritake. But I do only have _one_ processor.
I don't believe that anybody buys me a second... :o(
Our Dual-Processor Machine (a DS20e) has been moved back to
Compaq a few month ago... On our seconds DS20e are running postgresql
databases which cannot be stopped. Not even for a few minutes while
rebooting...
-Oliver
George France wrote:
[ ... ]
> > I am currently running 2.4.18 from SuSE without any (major)
> > problems. I found it here:
> > ftp://ftp.suse.com/pub/people/sf/axp/7.1/RPMS/kernel-source-
> > 2.4.18.SuSE-0.alpha.rpm.
> > Then I took arch/alpha/kernel/core_cia.c from version 2.4.12
> > (the current version does not run on XLT's booting with MILO;
> > the latest one is 2.4.12).
>
> I have not tried Stefan's 2.4.18 kernel. I am glad to hear
> that it works for you. I will give it a try.
For 2.4.18 I have a very good experience. It's running on
our mailserver (as well an alpha-machine [ds10]) with ext3.
Without patches it worked well. Now I have a few patches
(most of them are from l-k list)...
> > > 2) taking a look at the latest 2.5.x in the next few
> weeks, as we are
> > > aware that 2.5.x does not compile on Alpha.
[ ... ]
Just a comment:
2.5.26/27 doesn't create a modversions.h on my machine... So
make dep/clean and so on doesn't work for me...
-Oliver
Martin Brulisauer wrote:
> >>On Sat, 20 Jul 2002, Martin Brulisauer wrote:
> >> Is the kernel arch tree for alphas not maintained anymore? If I
> >>download the vanilla 2.5.26 I can't build it at all. Even a make
> >>clean fails due to missing directives in
> arch/alpha/kernel/Makefile.
As I saw it... There is no modversions.h created while trying to
compile the kernel on an alpha... I'll take a look at this in
a few hours (after sleeping... :-) ).
> >On Sat, 20 Jul 2002, Thunder from the hill wrote:
> >What exactly are you experiencing?
[ ... ]
> Looks to me like noone ever tried to compile this
> kernel on this platform. That is why I asked my
> silly question.
Have you ever ended this discussion??? I only mean
you two. Because I havn't found a reply from Thunder
to Martin...
However... Let me know...
-Oliver
Hi,
On Wed, 24 Jul 2002, Oliver Pitzeier wrote:
> Have you ever ended this discussion??? I only mean
> you two. Because I havn't found a reply from Thunder
> to Martin...
IIRC, no.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
Hi,
On Wed, 24 Jul 2002, Oliver Pitzeier wrote:
> > There was a quite good patch sent to l-k some weeks ago which
> > (basically) still applies. I'm using this one (with watering
> > eyes waiting for a compileable Linus-Kernel...).
>
> I go and search it...
Possibly this one?
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
Hi,
On Wed, 24 Jul 2002, Thunder from the hill wrote:
> Possibly this one?
No, I can't find it any more, either. It was a big fat file labeled
alpha-2.5.20.bz2 or such, IIRC. I've used it until 2.5.24 or so.
Unfortunately, it never ended up in the patches directories (wonder why).
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
On 24 Jul 2002, at 0:53, Thunder from the hill wrote:
> Hi,
>
> On Wed, 24 Jul 2002, Oliver Pitzeier wrote:
> > > There was a quite good patch sent to l-k some weeks ago which
> > > (basically) still applies. I'm using this one (with watering
> > > eyes waiting for a compileable Linus-Kernel...).
> >
> > I go and search it...
>
> Possibly this one?
Don't waste our time. If you have to say anything
constructive do it. If not - keep out of the thread.
Best Regards,
Martin
Hi,
On Wed, 24 Jul 2002, Martin Brulisauer wrote:
> Don't waste our time. If you have to say anything
> constructive do it. If not - keep out of the thread.
Instead of complaining, could you please try out this one? I'm seriously
trying to be constructive.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
On Tue, Jul 23, 2002 at 03:28:11PM +0200, Jan-Benedict Glaw wrote:
> There was a quite good patch sent to l-k some weeks ago which
> (basically) still applies. I'm using this one (with watering eyes
> waiting for a compileable Linus-Kernel...).
Fortunately there is not so much new "breakage" introduced since 2.5.24
(last kernel I checked). Updated patch attached. By now tested only
on sx164. SMP is still broken, sorry.
I'm planning to split this in a reasonable fashion and start
feeding it to Linus/Richard. Hopefully early in August...
Ivan.
On 23 Jul 2002, at 18:29, George France wrote:
> On Tuesday 23 July 2002 14:48, Oliver Pitzeier wrote:
> >
> > [ ... ]
> >
> > > You have made me aware that we have unintentionally created a
> > > private sort of club. I apologize. This will have to be corrected.
> >
> > That's not what I expected to read...
> > I think that this "private club" is not wrong at all... It just would
> > be nicer if there would be some kind of batch every week where all
> > alpha users/developers get a mail...
>
> I agree. We should send a weekly e-mail with the current status.
I did not see any news on the alpha/linux topic in lkml lately.
What is the way to keep in touch with the "private club" to help/
assist in getting further to a running 2.5.x kernel on alpha? I
am still on 2.4.18 on my test system.
Did anybody use gcc-3.0.x or gcc-3.1? With gcc-3.0.4 I
successfully built 2.4.18 but some applications don't run
correctly (eg. MySQL -> Parser). Is the kernel compilable
with gcc-3.1? Today I am using gcc-2.95.3 and I think is
ok; better than egcs (generates less unaligned traps at
runtime without changing the source).
Greetings,
Martin
Hello Martin,
I am glad to have received your e-mail. I was just thinking about
you. For a quick update, as I am attempting to get demos out the
door for LWE:
Bryce has convinced me to setup a daily diary on advantgo.
http://www.advogato.org/person/France
which I plan on updating this afternoon. In short for me on alpha this
week:
Monday: I worked on the usb-uhci.c driver which has a few
32 bitisms. I will not have time to submit a tested
patch until after LWE. The problem appears to be
unsigned int io_addr = pci_resource_start()
and possibly
unsigned int io_size = pci_resource_len()
putting a 64bit address into a 32bit slot just does not
work very well. :-) Even after changes the 'int' to 'long',
the USB device worked extremely well, but upon inserting or
removing a USB device, the SCSI controller on my system
hangs for about 30 secs while it resets due to receiving
an invalid instruction. I suspect that there is corruption
of some kind on the PCI bus, but I do not have time this
week to track this down.
Tuesday: My Binutils patch was accepted for adding
-mev67, -mev68, -m21264a and -m21264b
Chatted with Bryce on several Alpha related issues.
Wed: Meet with Jay, Jeff, John and Harry in Nashua.
Jeff has 2.5.x (x=29 IIRC) working with smp and non smp systems.
after some testing the patches should make it to the kernel soon.
I pushed out updates for RH7.2 (Alpha) for gcc, util-linux, glibc
and openssl.
I worked on the RSS patches for the autobuild system.
Thur: I chatted (e-mail) with Peter Petrakis today. He would like me to upgrade
the system which hosts alphanews.net and linuxalpha.org to use RH7.2
I hope to have time on Friday (today, yikes!), before I leave for LWE.
As for gcc 3.1 in the kernel, most Alpha kernel hackers use egcs or 2.95.
Personally I tend to use 2.95 for my kernels.
I have UNH students that build several complete toolchains everyday
for alpha including 2.95.x, 3.0.x, 3.1.x and gcc-head. By complete tool
chain I mean binutils, gcc, gdb, glibc and all the support programs.
http://handhelds.org/projects/toolchain/autobuild/build-results.php3
I am certain that they would like to chat with you in great detail about
toolchain issues related to the Alpha architecture.
I agree that communications in regard to Alpha could and should be better.
We should probably setup a wiki or webpage to help keep track of Alpha
issues or maybe just use one of the existing alpha mailing lists or I could
setup something on alpha.crl.dec.com next week.
I hope this helps.
Best Regards,
--George
On Friday 09 August 2002 06:00, Martin Brulisauer wrote:
> On 23 Jul 2002, at 18:29, George France wrote:
> > On Tuesday 23 July 2002 14:48, Oliver Pitzeier wrote:
> > > [ ... ]
> > >
> > > > You have made me aware that we have unintentionally created a
> > > > private sort of club. I apologize. This will have to be corrected.
> > >
> > > That's not what I expected to read...
> > > I think that this "private club" is not wrong at all... It just would
> > > be nicer if there would be some kind of batch every week where all
> > > alpha users/developers get a mail...
> >
> > I agree. We should send a weekly e-mail with the current status.
>
> I did not see any news on the alpha/linux topic in lkml lately.
>
> What is the way to keep in touch with the "private club" to help/
> assist in getting further to a running 2.5.x kernel on alpha? I
> am still on 2.4.18 on my test system.
>
> Did anybody use gcc-3.0.x or gcc-3.1? With gcc-3.0.4 I
> successfully built 2.4.18 but some applications don't run
> correctly (eg. MySQL -> Parser). Is the kernel compilable
> with gcc-3.1? Today I am using gcc-2.95.3 and I think is
> ok; better than egcs (generates less unaligned traps at
> runtime without changing the source).
>
"Martin Brulisauer" <[email protected]> writes:
> Did anybody use gcc-3.0.x or gcc-3.1? With gcc-3.0.4 I
> successfully built 2.4.18 but some applications don't run
> correctly (eg. MySQL -> Parser). Is the kernel compilable
> with gcc-3.1? Today I am using gcc-2.95.3 and I think is
> ok; better than egcs (generates less unaligned traps at
> runtime without changing the source).
I've been using gcc 3.1 to compile kernel for a while (since it was
released). I don't have any problems with 2.4.18 and upward. I don't
remember which compiler I used previously.
--
M?ns Rullg?rd
[email protected]
Hi,
On Fri, 9 Aug 2002, Martin Brulisauer wrote:
> Is the kernel compilable with gcc-3.1?
Works with me. I didn't have problems on Alpha for now...
Well, yes, I did have problems compiling the stock kernels. But that's a
different page.
Thunder
--
--./../...-/. -.--/---/..-/.-./..././.-../..-. .---/..-/.../- .-
--/../-./..-/-/./--..-- ../.----./.-../.-.. --./../...-/. -.--/---/..-
.- -/---/--/---/.-./.-./---/.--/.-.-.-
--./.-/-.../.-./.././.-../.-.-.-