On Mon, 2004-05-24 at 18:03, Christoph Hellwig wrote:
> On Mon, May 24, 2004 at 10:06:58AM +0200, Sven Luther wrote:
> > > Is there any ppc machine we still need floppy support on? Can floppy be
> > > made a module only?
> >
> > All old world pmacs (that is those prior to the blue&white G3, but no
> > And x86 could have:
> >
> > static inline no_isa_blind_probe() { return 0;}
>
> That sounds nice.
Just a note: beware with the 8250 driver, it may still be useful on pmac
for people using a pcmcia modem. There is currently a problem in that you
cannot have both pmac_zilog and 8250 since
> Yeah, but until we have a ppc64 toolchain, that is all we have got, and
> furthermore, the actual testing will go into the infrastructure around
> the kernel, the mkvmlinuz needed to create the zImage.chrp-rs6k from the
> vmlinux and the creation of the initrd, which altough it works well on
> p
On Mon, May 24, 2004 at 10:03:32AM +0200, Christoph Hellwig wrote:
> On Mon, May 24, 2004 at 10:06:58AM +0200, Sven Luther wrote:
> > > Is there any ppc machine we still need floppy support on? Can floppy be
> > > made a module only?
> >
> > All old world pmacs (that is those prior to the blue&whi
On Mon, May 24, 2004 at 10:06:58AM +0200, Sven Luther wrote:
> > Is there any ppc machine we still need floppy support on? Can floppy be
> > made a module only?
>
> All old world pmacs (that is those prior to the blue&white G3, but not
> the nubus ones which we don't support) have and need the flo
On Sun, May 23, 2004 at 10:21:15PM +0200, Jens Schmalzing wrote:
> Hi,
>
> Christoph Hellwig writes:
>
> > Ugly patch from SuSE that should fix it.
>
> It may be ugly, but works nicely. Thanks a lot.
>
> > BTW, Jens did you mean this issue
>
> Indeed.
BTW, i had something similar in the 2.4
On Sun, May 23, 2004 at 05:27:02PM -0500, Troy Benjegerdes wrote:
> On Sun, May 23, 2004 at 11:52:07PM +0200, Christoph Hellwig wrote:
> > On Sun, May 23, 2004 at 11:33:15PM +0200, Jens Schmalzing wrote:
> > > Someone had to write that patch in the first place. That's what all
> > > this is about,
On Sun, May 23, 2004 at 12:20:40PM -0500, Troy Benjegerdes wrote:
> On Sun, May 23, 2004 at 07:00:56PM +0200, Christoph Hellwig wrote:
> > On Sun, May 23, 2004 at 06:42:32PM +0200, Jens Schmalzing wrote:
> > > Hi,
> > >
> > > Christoph Hellwig writes:
> > >
> > > > Feel free to send forward bugs
On Sun, May 23, 2004 at 04:36:16PM -0500, Troy Benjegerdes wrote:
> On Sun, May 23, 2004 at 06:53:04PM +0200, Jens Schmalzing wrote:
> > Hi,
> >
> > Troy Benjegerdes writes:
> >
> > > > Have you tried running the 2.6.6 kernel-image packages on them?
> > >
> > > No, all of them have > 4GB of memo
On Sun, May 23, 2004 at 11:52:07PM +0200, Christoph Hellwig wrote:
> On Sun, May 23, 2004 at 11:33:15PM +0200, Jens Schmalzing wrote:
> > Someone had to write that patch in the first place. That's what all
> > this is about, and when I asked on debian-powerpc nobody cared to
> > answer, so I kludg
Hi,
Christoph Hellwig writes:
> There's a few more patches of that style in SuSE's tree. I've attached
> them, but if you don't actually need them I'd say hide them in your
> closet for the time beeing :)
Since the drivers involved are not built into the kernel, I'd rather
keep those patches hi
On Sun, May 23, 2004 at 11:33:15PM +0200, Jens Schmalzing wrote:
> Someone had to write that patch in the first place. That's what all
> this is about, and when I asked on debian-powerpc nobody cared to
> answer, so I kludged around it as well as I could. Thanks to
> Christoph, who dug up an ugly
Hi,
Troy Benjegerdes writes:
> I for one would support a ppc patch that lets the same kernel work
> on G5 and pSeries.
Someone had to write that patch in the first place. That's what all
this is about, and when I asked on debian-powerpc nobody cared to
answer, so I kludged around it as well as
On Sun, May 23, 2004 at 04:36:16PM -0500, Troy Benjegerdes wrote:
> Also, would it make more sense to have '-g5, -g5-smp, -pSeries-smp,
> -iSeries-smp' kernels instead of power3 and power4 non-smp variants? Are
> there any single-cpu power3/power4 machines?
the 43p/170 is UP power3, 43p/260 (first
On Sun, May 23, 2004 at 06:53:04PM +0200, Jens Schmalzing wrote:
> Hi,
>
> Troy Benjegerdes writes:
>
> > > Have you tried running the 2.6.6 kernel-image packages on them?
> >
> > No, all of them have > 4GB of memory, and a 32 bit kernel is quite
> > useless. Thus my strong interest in ppc64 gc
On Sun, May 23, 2004 at 06:09:48PM +0200, Christoph Hellwig wrote:
> Because collecting random cludges becomes a maintaince horror long term.
> I've spent half of yesterday splitting kernel-patch-debian apart and
> reviewing all parts, checking for correctnes, sending upstrea, etc..
> That's lots o
On Sun, May 23, 2004 at 07:25:05PM +0200, Jens Schmalzing wrote:
> Hi,
>
> Troy Benjegerdes writes:
>
> > The legacy-peecee 16550 uart serial driver probes IO addresses blindly.
> > You need the driver built in for IBM pSeries machines, and the G5 gets
> > real unhappy when the driver probes none
Hi,
Christoph Hellwig writes:
> Ugly patch from SuSE that should fix it.
It may be ugly, but works nicely. Thanks a lot.
> BTW, Jens did you mean this issue
Indeed.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Hi,
Troy Benjegerdes writes:
> The legacy-peecee 16550 uart serial driver probes IO addresses blindly.
> You need the driver built in for IBM pSeries machines, and the G5 gets
> real unhappy when the driver probes nonexistant IO addresses.
That much I know. This is the reason for having separat
On Sun, May 23, 2004 at 12:20:40PM -0500, Troy Benjegerdes wrote:
> The legacy-peecee 16550 uart serial driver probes IO addresses blindly.
> You need the driver built in for IBM pSeries machines, and the G5 gets
> real unhappy when the driver probes nonexistant IO addresses.
>
> G4's had the same
On Sun, May 23, 2004 at 07:00:56PM +0200, Christoph Hellwig wrote:
> On Sun, May 23, 2004 at 06:42:32PM +0200, Jens Schmalzing wrote:
> > Hi,
> >
> > Christoph Hellwig writes:
> >
> > > Feel free to send forward bugs for filled against your
> > > kernel-image-powerpc forward upstream.
> >
> > Th
Hi,
Troy Benjegerdes writes:
> > Have you tried running the 2.6.6 kernel-image packages on them?
>
> No, all of them have > 4GB of memory, and a 32 bit kernel is quite
> useless. Thus my strong interest in ppc64 gcc/glibc/etc ;)
Fair enough :)
Can you still give it at least a try? From 2.4 t
On Sun, May 23, 2004 at 06:42:32PM +0200, Jens Schmalzing wrote:
> Hi,
>
> Christoph Hellwig writes:
>
> > Feel free to send forward bugs for filled against your
> > kernel-image-powerpc forward upstream.
>
> The serial driver hangs the Powermac G5.
>
> The rivafb driver is totally broken (Bug#
Hi,
Christoph Hellwig writes:
> Feel free to send forward bugs for filled against your
> kernel-image-powerpc forward upstream.
The serial driver hangs the Powermac G5.
The rivafb driver is totally broken (Bug#248134).
The ohci driver has a small glitch with cascaded hubs (Bug#248396).
The fi
On Sun, May 23, 2004 at 06:39:03PM +0200, Sven Luther wrote:
> > Huh? I complained that you don't get out of your little
>
> Well, sure, but you started making big plans about the new kernel
> maintenance, without even bothering to find out who where the current
> maintainers, and to include them
On Sun, May 23, 2004 at 09:58:36AM +0200, Jens Schmalzing wrote:
> Hi,
>
> Troy Benjegerdes writes:
>
> > Can you elaborate on what tests you run, and how you determine
> > pass/fail?
>
> Nothing fancy, I just make sure the machine boots up alright, check
> that the attached hardware works, and
On Sun, May 23, 2004 at 06:09:48PM +0200, Christoph Hellwig wrote:
> On Sun, May 23, 2004 at 05:44:40PM +0200, Sven Luther wrote:
> > > The via changes are almost guaranteed to break on x86. Any reason you
> > > can't simply assign the irqs in the arch-specific pci fixups code so
> > > the driver
On Sun, May 23, 2004 at 05:44:40PM +0200, Sven Luther wrote:
> > The via changes are almost guaranteed to break on x86. Any reason you
> > can't simply assign the irqs in the arch-specific pci fixups code so
> > the driver doesn't need to mess it? That's the way we usually deal
> > with broken pl
On Sun, May 23, 2004 at 05:20:06PM +0200, Christoph Hellwig wrote:
> On Sun, May 23, 2004 at 05:18:56PM +0200, Sven Luther wrote:
> > Well, i need to cleanup still the via-ide driver kludge i have there.
> > Still, i believe it breaks nothing on ppc since we probably are the only
> > one using via-
On Sun, May 23, 2004 at 05:18:56PM +0200, Sven Luther wrote:
> Well, i need to cleanup still the via-ide driver kludge i have there.
> Still, i believe it breaks nothing on ppc since we probably are the only
> one using via-ide there, but i wouldn't bet on that this kludge would
> ever be accepted
On Sun, May 23, 2004 at 05:00:45PM +0200, Christoph Hellwig wrote:
> On Sun, May 23, 2004 at 04:38:34PM +0200, Sven Luther wrote:
> > Well, it is a nice tentative, but ppc needs still the pegasos patches,
> > as well as the apus ones, and it is a nice possibility to be able to add
> > stuff without
On Sat, May 22, 2004 at 11:27:35PM +0200, Thiemo Seufer wrote:
> An Example:
> Starting with 2.4.20, the mips cache code underwent major changes. This
> broke the r4k-kn04 subarchitecture, and some of the r4k-ip22 machines.
> Most of the latter were fixed relatively quickly, with improved
> perform
On Sun, May 23, 2004 at 04:38:34PM +0200, Sven Luther wrote:
> Well, it is a nice tentative, but ppc needs still the pegasos patches,
> as well as the apus ones, and it is a nice possibility to be able to add
> stuff without really worrying about breaking stuff on non ppc arches.
except for an eas
On Sat, May 22, 2004 at 04:20:01PM -0500, Troy Benjegerdes wrote:
> >
> > > I'd like to propose we attempt to build x86, amd64, ppc, and ia64
> > > kernels from the same source tree.
> >
> > Your proposal has first- and second-class archs in it as well. And it
> > means that several machines wo
On Sat, May 22, 2004 at 01:22:16PM -0500, Troy Benjegerdes wrote:
> (Sorry I could't correctly reply, I just subscribed)
>
> Jens Schmalzing <[EMAIL PROTECTED]> wrote:
>
> >> and with that I mean the existing maintainers should cooperate.
>
> >Indeed. But cooperation already exists. So far, it
Hi,
Troy Benjegerdes writes:
> Can you elaborate on what tests you run, and how you determine
> pass/fail?
Nothing fancy, I just make sure the machine boots up alright, check
that the attached hardware works, and exercise everything a little.
> As an admin for Ames Laboratory, I have about 5 di
On Sun, May 23, 2004 at 12:17:01AM +0200, Jens Schmalzing wrote:
> Hi,
>
> Troy Benjegerdes writes:
>
> > Testing is probably the biggest issue. How is this currently
> > handled? How do you verify a new package is okay?
>
> In my job as a University sysadmin, I have physical access to about a
Hi,
Troy Benjegerdes writes:
> Testing is probably the biggest issue. How is this currently
> handled? How do you verify a new package is okay?
In my job as a University sysadmin, I have physical access to about a
dozen different Apple PowerPC machines. Apart from my personal work
machine, th
Troy Benjegerdes wrote:
[snip]
> Testing is probably the biggest issue. How is this currently handled?
> How do you verify a new package is okay?
By actually using it.
> Is there any way to automate
> this.. or at least make it semi-automated? Obviously if if something
> fails, a machine probably
Christoph Hellwig wrote:
> On Sat, May 22, 2004 at 10:00:25PM +0200, Thiemo Seufer wrote:
> > The real problem isn't the unified source tree, but how to create
> > kernels from it. A single debian source package for all architectures
> > means there is no way to keep an older version for one of the
>
> > I'd like to propose we attempt to build x86, amd64, ppc, and ia64
> > kernels from the same source tree.
>
> Your proposal has first- and second-class archs in it as well. And it
> means that several machines would be required in order to build all
> binary packages from that one source p
On Sat, May 22, 2004 at 10:00:25PM +0200, Thiemo Seufer wrote:
> The real problem isn't the unified source tree, but how to create
> kernels from it. A single debian source package for all architectures
> means there is no way to keep an older version for one of them. So we
> lose the flexibility t
William Lee Irwin III wrote:
[snip]
> On Sat, May 22, 2004 at 01:22:16PM -0500, Troy Benjegerdes wrote:
> > I'd like to propose we attempt to build x86, amd64, ppc, and ia64
> > kernels from the same source tree. Arches like mips and m68k will
> > probably still need extra patches. But we should re
On Sat, May 22, 2004 at 01:22:16PM -0500, Troy Benjegerdes wrote:
>> I'd like to propose we attempt to build x86, amd64, ppc, and ia64
>> kernels from the same source tree. Arches like mips and m68k will
>> probably still need extra patches. But we should really be working to
>> mainline those patc
Hi,
Troy Benjegerdes writes:
> It may be efficient for maintainers, but it leads to non-x86 arches
> being second-class citizens if everyone has to wait for the x86
> maintainer to prepare arch-specific kernels. The result is I just go
> download source and build for all my PPC debian machines. I
>>> and with that I mean the existing maintainers should cooperate.
Jens Schmalzing <[EMAIL PROTECTED]> wrote:
>> Indeed. But cooperation already exists. So far, it meant that
>> Herbert took the upstream source, prepared a kernel-source package,
>> and put it up on people.d.o for the other main
Hi,
On Sat, May 22, 2004 at 01:22:16PM -0500, Troy Benjegerdes wrote:
> I'd like to propose we attempt to build x86, amd64, ppc, and ia64
> kernels from the same source tree. Arches like mips and m68k will
> probably still need extra patches. But we should really be working to
> mainline those pat
On Sat, May 22, 2004 at 01:22:16PM -0500, Troy Benjegerdes wrote:
> I'd like to propose we attempt to build x86, amd64, ppc, and ia64
> kernels from the same source tree. Arches like mips and m68k will
> probably still need extra patches. But we should really be working to
> mainline those patches.
(Sorry I could't correctly reply, I just subscribed)
Jens Schmalzing <[EMAIL PROTECTED]> wrote:
>> and with that I mean the existing maintainers should cooperate.
>Indeed. But cooperation already exists. So far, it meant that
>Herbert took the upstream source, prepared a kernel-source package,
49 matches
Mail list logo
