On Thu, 2013-09-26 at 14:22 -0700, Greg Kroah-Hartman wrote:
> So, I shouldn't apply this patch? We should do something to fix this,
> if Debian has to drag this patch on for 5 years, that's an indication
> that this might be one solution we should use, right?
Ah sorry, dropped the ball on that
On Sun, 2013-09-01 at 17:24 +0100, Ben Hutchings wrote:
> The original version of this was done by Bastian Blank, who wrote:
>
> > The problem is the following:
> > - Architecture specific code sets preferred console to something bogus.
> > - Command line handling tries to set preferred console bu
On Mon, 2011-04-04 at 16:10 -0600, dann frazier wrote:
> I'm just reporting this as a build-time regression in stable as it
> caused an issue when we merged recent stable updates into the Debian
> tree. I've never personally tried to configure kdump on powerpc.
>
> fwiw, a quick test shows that k
On Sun, 2011-04-03 at 00:10 +0530, Kamalesh Babulal wrote:
> * dann frazier [2011-04-02 11:23:03]:
>
> > 2.6.32.36 also fails to build on powerpc/SMP:
> >
> > CC arch/powerpc/kernel/crash.o
> > arch/powerpc/kernel/crash.c: In function 'crash_kexec_wait_realmode':
> > arch/powerpc/kernel/c
On Tue, 2011-03-08 at 13:00 +0100, Michel Dänzer wrote:
> On Die, 2011-03-08 at 07:30 +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2011-03-07 at 10:45 +0100, Michel Dänzer wrote:
> > >
> > > I've been using radeon KMS on my PowerBook ever since I got it w
The uninorth AGP driver doesn't allow AGP transfer rates beyond
> 1x to work reliably with KMS. Benjamin Herrenschmidt (CC'd) was
> working on a fix for this, any progress Ben?
I have hacks. But I never got it working reliably. In fact, on the
laptop I have here, even
On Thu, 2009-01-08 at 21:57 +0100, Wolfgang Kroener wrote:
> Hi,
> On Wed, Oct 01, 2008 at 08:10:10, Benjamin Herrenschmidt wrote:
> > Can you resend it with a proper Signed-off-by: line ? Thanks !
>
> I think the mail (http://lkml.org/lkml/2008/10/1/134) got lost
> some
On Mon, 2007-07-30 at 20:41 +0200, Stephane Louise wrote:
> Bonjour Ben, merci pour le suivit.
>
> Benjamin Herrenschmidt a écrit :
> > Does this happen also without radeonfb and with X alone using the X
> > "radeon" driver ?
>
> Yes, unless I misunderstan
The log is incomplete... looks like the bcm43xx driver is so verbose, it
kicked useful things out. Thus I can't see the output from the video
driver which is the interesting bit...
Also, is it nvidiafb or rivafb ?
Cheers,
Ben.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "
> Console: switching to colour frame buffer device 210x65
> radeonfb (:00:10.0): ATI Radeon Yb
> Generic RTC Driver v1.07
> Macintosh non-volatile memory driver v1.1
> serial8250_init: nothing to do on PowerMac
> pmac_zilog: 0.6 (Benjamin Herrenschmidt <[EMAIL PROTECTED]>)
On Mon, 2007-01-22 at 16:05 +0100, Matthias Grimm wrote:
> On Mon, 22 Jan 2007 14:33:35 +1100
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > > Which solution you prefer is up to you but I would be glad if at least
> > > solution #1 could be realised.
> This will allow modern systems to be compiled only with
> CONFIG_PMAC_BACKLIGHT and a user space daemon does the rest. I hope my
> point could be seen. I would really appreciate if the configuration
> could be cleaned up.
>
> Other solutions could be:
>
> 2. If the sysfs backlight driver is ope
On Thu, 2006-11-30 at 23:04 +0100, Étienne Bersac wrote:
> Hi,
>
> Beware not to confuse iMac G5 rev A&B and rev C (among PowerMac G5).
> iMac G5 rev C (chip PowerMac 12,1) do not have yet their windfarm
> driver. Benh told that he began the work on this driver but has
> difficulties to get access
> This message is generally a sign that something else went wrong. Magnus, the
> best way on this would be to file a bug report against initramfs-tools about
> this second problem, and if possible provide the whole log.
>
> Benjamin, BTW, there seems to be some issue about pmac_zilog and the norm
On Thu, 2006-05-04 at 08:41 +0200, Sven Luther wrote:
> On Thu, May 04, 2006 at 04:38:07PM +1000, Benjamin Herrenschmidt wrote:
> >
> > > Hey, cool. so ARCH=ppc will work both for apus and prep, and the rest
> > > should
> > > go with ARCH=powerpc. This
> Hey, cool. so ARCH=ppc will work both for apus and prep, and the rest should
> go with ARCH=powerpc. This is the case both for 2.6.16 and the upcoming
> 2.6.17, right ?
I don't remember when he fixed it precisely but I think 2.6.16 got it
yes.
> So, the basic plan is to have a -prep ARCH=ppc f
On Sun, 2005-10-16 at 12:28 +0200, Sven Luther wrote:
> Hello,
>
> I have here two 32bit power[34] build failure patches that the debian kernels
> has been using for some time, and which i think i did post here in the past,
> but it doesn't seem to be applied.
>
> Well, those are 32 bit issues, a
kernels. So I don't care very much
> about what you put in the package.
>
> Regards,
> Gabriel
>
>
--
Benjamin Herrenschmidt <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Fri, 2004-10-01 at 17:39, Francesco P. Lovergine wrote:
> Could you suggest any hook point in the code where I can augment
> verbosity level to see what's going on?
>
> In the meantime is there any possibility to add the old radeonfb module
> along with the new one? That code is anyway there
On Sat, 2004-09-25 at 23:51, Francesco Paolo Lovergine wrote:
> On Sat, Sep 18, 2004 at 02:42:10PM +1000, Benjamin Herrenschmidt wrote:
> > Sorry for the delay, I've been kept very busy with other things.
> >
> > Can you send me dmesg logs after enabling radeonfb ver
Sorry for the delay, I've been kept very busy with other things.
Can you send me dmesg logs after enabling radeonfb verbose debug of
the boot that leads to incorrect detection ? Also tell me what the
real resolution should be in both cases, and send me also the XFree
log. Also, make sure you are t
> > Well... That isn't really what I said ;) What I said is that I don't
> > have time to actively maintain the PowerMac support in 2.4, that is make
> > it evolve & support newer machines. That doesn't mean that PPC will be
> > going away from 2.4 ;)
>
> I think the exact quote was that you are
t; >
> > If all this does happen before the sarge release, and if the userland
> > issues are solved, then i would strongly recomend going for 2.6 for
> > powerpc at least, especially as the members of the debian kernel team
> > with interest in powerpc care very little about 2.4 kernels.
> >
> > Friendly,
> >
> > Sven Luther
> > >
> > >
> > > --
> > > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> > >
> >
> >
> > --
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> >
--
Benjamin Herrenschmidt <[EMAIL PROTECTED]>
s testing, and the enhancement we did forward ported to it if
> needed ?
>
> But again, this is not going to work out if you take this heavy handed
> attitude about it.
>
> Friendly,
>
> Sven Luther
--
Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Christoph, i am not really sure i care all that much for this "please
> let's it included upstream first" philosophy. It let the control over
> what we will have or not in the debian kernel totally out of our hand,
> which is not something i am 100% confortable with.
This is also the way other
On Sun, 2004-05-30 at 22:36, Christoph Hellwig wrote:
> On Sun, May 30, 2004 at 01:11:30PM +0200, Goswin von Brederlow wrote:
> > As for 3 this is a general problem of scsi disks. Wouldn't it be
> > possible for the code that scans partitions to allocate device nodes
> > dynamically for partitions
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
be happy with completely depracating the -power3 and
> > -power4 kernels until we have a 64 bit biarch compiler package.
>
> Nope, first we need to get the biarch toolchain, and then we can
> deprecate the power3 and power4 kernels. This is how things work in
> debian.
>
> Friendly,
>
> Svne Luther
--
Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > Again, i, as the pegasos upstream and the
> > powerpc kernel maintainer, take the responsability for this, so i
> > believe it is ok for inclusion in the debian powerpc kernel package. I
>
> You abuse your position as powerpc kernel maintainer to get your
> pet patches in without proper revie
30 matches
Mail list logo