Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

On Mon, Jan 06, 2020 at 08:11:47PM +0100, Romain Dolbeau wrote: > Interesting idea (and I have a 6600 aka NV43 in there, indeed) but I > don't think so, as > a) 'nouveau' works in 4.19 with 64 KiB pages > b) using "module_blacklist=nouveau" doesn't help, I just tried > c) my original 'bisect' was

Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

On Mon, Jan 06, 2020 at 07:18:30PM +0100, Romain Dolbeau wrote: > Applied, recompiled with 64 KiB pages, still crashes. > > The backtrace seems more readable this time (and wasn't overwritten by > something else), bad photo here: > Is it

Re: [PATCH v2] Fix loading of module radeonfb on PowerMac

eu Malaterre <ma...@debian.org> > > Link: https://bugs.debian.org/826629#57 > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=119741 > > Suggested-by: Lennart Sorensen <lsore...@csclub.uwaterloo.ca> > > --- > > Please always have a changelog in

Re: [PATCH] Fix loading of module radeonfb on PowerMac

On Wed, Nov 02, 2016 at 10:28:55AM +0200, Tomi Valkeinen wrote: > On 08/10/16 15:09, Mathieu Malaterre wrote: > > When the linux kernel is build with (typical kernel ship with Debian > > installer): > > > > CONFIG_FB_OF=y > > CONFIG_VT_HW_CONSOLE_BINDING=y > > CONFIG_FB_RADEON=m > > > > The offb

Re: [PATCH] powerpc: Fix sstep compile on powerpcspe

On Thu, May 05, 2016 at 04:44:44PM -0400, Lennart Sorensen wrote: > powerpc: Fix sstep compile on powerpcspe > > Commit be96f63375a14ee8e690856ac77e579c75bd0bae introduced ldarx and stdcx > into the instructions in sstep.c, which are not accepted by the assembler > on powerpcspe

[PATCH] powerpc: Fix sstep compile on powerpcspe

powerpc: Fix sstep compile on powerpcspe Commit be96f63375a14ee8e690856ac77e579c75bd0bae introduced ldarx and stdcx into the instructions in sstep.c, which are not accepted by the assembler on powerpcspe, but does seem to be accepted by the normal powerpc assembler even in 32 bit mode. Wrap

Re: net: ucc: tbi phy detection broken by 058112c7efc9ef43bb511c137293dddbe6e42908

On Sat, Dec 20, 2014 at 09:08:51AM -0800, Florian Fainelli wrote: 2014-12-18 19:49 GMT-08:00 Lennart Sorensen lsore...@csclub.uwaterloo.ca: I have been trying to move an 8360 based system from a 3.0 kernel to a 3.12 (on the way to 3.14 with ipipe/xenomai) kernel and encountered an oops

Re: net: ucc: tbi phy detection broken by 058112c7efc9ef43bb511c137293dddbe6e42908

On Sat, Dec 20, 2014 at 09:08:51AM -0800, Florian Fainelli wrote: There are some comments in ucc_geth that also lead me to believe this is a just a hack instead of a real Ethernet PHY device. Part of what I think got broken is because of this comment: /* Initialize TBI PHY interface for

net: ucc: tbi phy detection broken by 058112c7efc9ef43bb511c137293dddbe6e42908

I have been trying to move an 8360 based system from a 3.0 kernel to a 3.12 (on the way to 3.14 with ipipe/xenomai) kernel and encountered an oops in the ucc_geth driver when using RTBI mode on one of the ucc ports. I haven't managed to find any commits to of_mdio or ucc_geth or fsl_pq_mdio that

ethtool occationally fails to communicate with with ucc_geth

We are occationally seeing ethtool fail to communicate with ucc_geth. I think I have tracked down why it happens, but I don't see a good way to fix it. When the phy state changes, adjust_link() checks if the state has changed and if the link is up. If it is it does: if

Re: ethtool occationally fails to communicate with with ucc_geth

On Wed, Feb 06, 2013 at 09:08:32PM +, Ben Hutchings wrote: This seems to be a workaround for a bug in phylib: phy_state_machine() calls netif_carrier_on() before adjust_link(), so the TX scheduler can start immediately even though the MAC has not been configured. A better workaround

ucc_geth broken in 2.6.32 by 864fdf884e82bacbe8ca5e93bd43393a61d2e2b4

We use the ucc_geth for 6 ports (4 100Mbit and 2 Gbit ports) on an mpc8360e. Up to 2.6.31 this worked fine. 2.6.32 on the other hand crashes very quickly after boot. I managed to see the same crash when I was selectively trying to add newer ucc_geth patches to the 2.6.31 kernel a couple of

Re: ucc_geth broken in 2.6.32 by 864fdf884e82bacbe8ca5e93bd43393a61d2e2b4

On Wed, Dec 23, 2009 at 09:04:15PM +0300, Anton Vorontsov wrote: On Wed, Dec 23, 2009 at 12:40:19PM -0500, Lennart Sorensen wrote: We use the ucc_geth for 6 ports (4 100Mbit and 2 Gbit ports) on an mpc8360e. Up to 2.6.31 this worked fine. 2.6.32 on the other hand crashes very quickly

Re: ucc_geth broken in 2.6.32 by 864fdf884e82bacbe8ca5e93bd43393a61d2e2b4

On Wed, Dec 23, 2009 at 03:09:48PM -0500, Lennart Sorensen wrote: On Wed, Dec 23, 2009 at 09:04:15PM +0300, Anton Vorontsov wrote: On Wed, Dec 23, 2009 at 12:40:19PM -0500, Lennart Sorensen wrote: We use the ucc_geth for 6 ports (4 100Mbit and 2 Gbit ports) on an mpc8360e. Up to 2.6.31

Re: ucc_geth broken in 2.6.32 by 864fdf884e82bacbe8ca5e93bd43393a61d2e2b4

On Wed, Dec 23, 2009 at 11:22:26PM +0300, Anton Vorontsov wrote: On Wed, Dec 23, 2009 at 03:09:48PM -0500, Lennart Sorensen wrote: [...] So there result is: Unable to handle kernel paging request for data at address 0x0058 Faulting instruction address: 0xc024f2fc Oops: Kernel

Re: ucc_geth broken in 2.6.32 by 864fdf884e82bacbe8ca5e93bd43393a61d2e2b4

On Thu, Dec 24, 2009 at 01:21:16AM +0300, Anton Vorontsov wrote: On Wed, Dec 23, 2009 at 05:10:47PM -0500, Lennart Sorensen wrote: [...] That seems to be it. It works now. No more crashes. Those two patches together seem to do the trick. Great! I really hope they can go