Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)
On 2020-01-06 8:11 p.m., Romain Dolbeau wrote: > > Unfortunately I don't have a PCIe OpenFirmware ATI card to test the > theory further. FWIW, a non-OF Radeon >= R(V)5xx card should work in Linux (though obviously won't light up in OF itself or MacOS). -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Re: PowerPC agpmode issues
On 20/09/16 12:43 PM, Herminio Hernandez, Jr. wrote: > > Yes to both, however when I set radeon.agpmode=1 most of the time the > kernel freezes when booting. When I do get past that I get these errors: [...] > *[ 11.415769] [drm:.radeon_agp_init [radeon]] *ERROR* Illegal AGP > Mode: 1 (valid 4, 8), leaving at 8* As you can see, AGP 1x isn't supported by your setup, only 4x or 8x. How about radeon.agpmode=4? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Re: PowerPC agpmode issues
On 19/09/16 09:36 PM, Mathieu Malaterre wrote: > > Finally your dmesg looks odd since the line `[drm] Forcing AGP to PCI > mode` comes only after the first error. That isn't odd but the AGP->PCI(e) fallback mechanism working as intended, trying AGP first and falling back to PCIe if AGP fails. Herminio, does the problem also occur if you specify radeon.agpmode=-1 (or maybe =1) on the kernel command line? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Re: radeonhd and xorg issues on powerpc p5020 and G5
On 23.04.2016 02:06, luigi burdo wrote: > > On Quad G5 with 2 video boards > if i set radeon.modeset=1 nouveau.modeset=1 Xorg -configure dont found > at all the video boards > if i set radeon.modeset=0 nouveau.modeset=1 Xorg -configure dont found > the nouveau board > if i set radeon.modeset=1 nouveau.modeset=0 Xorg -configure dont found > the radeon board Xorg -configure has various known issues and shouldn't be used anymore. Xorg is normally able to automatically detect and use all GPUs in a system without any xorg.conf file. > if i set radeon.modeset=0 nouveau.modeset=0 no video working ... no tty > too ;-) That disables both kernel drivers, which are required for fbcon and Xorg. > On P5020 > last of my test is this machine with a radeon hd 7770 core edition > if radeon drv is running the system run in softpipe mode and i face many > drm errors and fence issue. > i atteched the dmesg files. Which kernel version are you testing? There were some fixes in 4.4/4.5 which may help for the kernel driver issues, but note that the Mesa radeonsi driver for >= 7xxx Radeons still needs a lot of work to be usable on big endian systems. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC agpmode issues
On 05.02.2016 11:47, Mike wrote: > Hi. > Managed to get the Radeon R300 running on mesa 11.1.1 with an old 2013 > patch from Michel Dànzer, next problem is of course enabling agpmode, > running with pci-mode with radeon.agpmode=-1 works, but is of course > slow, and seems to load the cpu a lot. > > Upon initial investigation i could not initially believe agp could be > this this broken for this long, until i found this. > "committed with Ben Skeggs on Feb 26, 2013" > https://github.com/DespairFactor/bullhead/commit/650e1203c11354ba84d69ba445abc0efcfe3890a > http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nouveau_agp.c?v=4.2 > #ifdef __powerpc__ > /* Disable AGP by default on all PowerPC machines for > * now -- At least some UniNorth-2 AGP bridges are > * known to be broken: DMA from the host to the card > * works just fine, but writeback from the card to the > * host goes straight to memory untranslated bypassing > * the GATT somehow, making them quite painful to deal > * with... > */ > if (nouveau_agpmode == -1) > return false; > #endif > > and now later this: > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/nouveau/nvkm/subdev/pci/agp.c > #ifdef __powerpc__ > /* Disable AGP by default on all PowerPC machines for now -- At > * least some UniNorth-2 AGP bridges are known to be broken: > * DMA from the host to the card works just fine, but writeback > * from the card to the host goes straight to memory > * untranslated bypassing that GATT somehow, making them quite > * painful to deal with... > */ > mode = 0; > #endif > > All seems to point to serious issues had around the time of change to > ums to kms and a serious regression hitting the linux kernel? No? Not really. UMS was just using a static GART mapping, whereas KMS is dynamically binding pages into the GART as needed. Apparently, older revisions of UniNorth have trouble with the latter. I think it would make sense to change radeon.agpmode to default to -1 on powerpc as well. Any takers? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC agpmode issues
On 08.02.2016 22:28, Mike wrote: > Certainly 750~800 fps in glxgears vs 3000+ in debian squeeze, i cant > bring myself to say that it's an acceptable situation no matter how > tired i am of the problem knowing how well the setup could do. It's > clear that the implementation is broken for everything but x86, [...] Why is that? It was working fine on my last-gen PowerBook. AFAIK Darwin / OS X never used anything but a static AGP GART mapping though, so it seems very likely that the issues with older UniNorth revisions are simply due to the hardware being unable to support the usage patterns of modern GPU drivers. That said, if you guys have specific suggestions for a "proper" solution, nobody's standing in your way. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerMac G5 Quad Issue reporting
On 20.01.2015 20:52, luigi burdo wrote: Hello all LinuxPPc Developer, need to report a issue that im facing from kernel 3.16 and up. The fans of powermac g5 quad start boosting like a turbo jet after the system is been loaded and up. Usually this become after about 30-60 seconds when the system is loaded. You need to load the i2c_powermac kernel module. Need to report to Michel D. from amd.com . The RadeonHD 6570 now is working on PowerMac G5 too look like the Xorg bigendian issue related Evergreen / Northern is been fixed ;-) Xorg itself has always been working, only OpenGL can be problematic. Have you verified r600_dri.so is used for that? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Fan management PowerMac7,2
On 19.11.2014 21:04, Martin Kukač wrote: Hello, I was directed to this list on #ppc64/freenode IRC channel. I have PowerMac7,2 (AGP, 2xPowerPC 970(2.2) 2GHz) and I wanted to try kernel supporting kvm-pr module, which is not in 3.2.63 kernel provided with Debian Wheezy. I downloaded 3.14.24, compiled it using original config from 3.2.63 and after booting fan management does not work. I tried therm_pm72 (which is deprecated, but works well with Debian kernel) and windfarm_pm72 modules, but neither worked - after about five minutes from boot all fans go to maximum and stay this way no matter the CPU load or frequency. I downloaded vanilla 3.2.64, compiled it the same way and there fans work with therm_p72 well. This kernel does not have kvm-pr, so I reverted to original kernel provided with Wheezy. I looked to logs, i tried to search the web whether anyone had already the same problem, but it seems that nobody else described not to say solved this. Can anyone please point me to anything that would help? I can provide whatever log files required. Might be the same problem as discussed in https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-August/109700.html and the following posts: The i2c_powermac module doesn't get loaded automatically with recent kernels. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: TTM placement caching issue/questions
On 04.09.2014 11:36, Jerome Glisse wrote:
On Wed, Sep 03, 2014 at 10:31:18PM -0400, Jerome Glisse wrote:
On Thu, Sep 04, 2014 at 12:25:23PM +1000, Benjamin Herrenschmidt wrote:
On Wed, 2014-09-03 at 22:07 -0400, Jerome Glisse wrote:
So in the meantime the attached patch should work, it just silently ignore
the caching attribute request on non x86 instead of pretending that things
are setup as expected and then latter the radeon ou nouveau hw unsetting
the snoop bit.
It's not tested but i think it should work.
I'm still getting placements with !CACHED going from bo_memcpy in
ttm_io_prot() though ... I'm looking at filtering the placement
attributes instead.
Ben.
Ok so this one should do the trick.
Ok final version ... famous last word.
[...]
+#else /* CONFIG_X86 */
+int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t *placement)
+{
+ if (*placement (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
+ ttm-caching_state = tt_cached;
+ *placement = ~TTM_PL_MASK_CACHING;
+ *placement |= TTM_PL_FLAG_CACHED;
NAK, this will break AGP on PowerMacs.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: TTM placement caching issue/questions
On 04.09.2014 10:55, Jerome Glisse wrote: While i agree about the issue of incoherent double map of same page, i think we have more issue. For instance lattely AMD have been pushing a lot of patches to move things to use uncached memory for radeon and as usual thoses patches comes with no comment to the motivations of those changes. That would have been a fair review comment... What i understand is that uncached mapping for some frequently use buffer give a significant performance boost (i am assuming this has to do with all the snoop pci transaction overhead). Exactly, although it's a win even if the data is written by the CPU only once and read by the GPU only once. This also means that we need to fix ttm_tt_set_placement_caching so that when it returns an error it switches to cached mapping. Which will always work. GTT with AGP being one exception. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: TTM placement caching issue/questions
On 04.09.2014 16:54, Benjamin Herrenschmidt wrote:
On Thu, 2014-09-04 at 16:19 +0900, Michel Dänzer wrote:
+#else /* CONFIG_X86 */
+int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t
*placement)
+{
+ if (*placement (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
+ ttm-caching_state = tt_cached;
+ *placement = ~TTM_PL_MASK_CACHING;
+ *placement |= TTM_PL_FLAG_CACHED;
NAK, this will break AGP on PowerMacs.
... which doesn't work reliably anyway with DRI2 :-)
Define 'not reliably'. I have uptimes of weeks, and I'm pretty sure I'm
not alone, at least with AGP 1x it seems to work quite well for most
people. So I don't see the justification for intentionally breaking it
completely for all of us.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: TTM placement caching issue/questions
On 04.09.2014 16:59, Michel Dänzer wrote:
On 04.09.2014 16:54, Benjamin Herrenschmidt wrote:
On Thu, 2014-09-04 at 16:19 +0900, Michel Dänzer wrote:
+#else /* CONFIG_X86 */
+int ttm_tt_set_placement_caching(struct ttm_tt *ttm, uint32_t
*placement)
+{
+ if (*placement (TTM_PL_TT | TTM_PL_FLAG_SYSTEM)) {
+ ttm-caching_state = tt_cached;
+ *placement = ~TTM_PL_MASK_CACHING;
+ *placement |= TTM_PL_FLAG_CACHED;
NAK, this will break AGP on PowerMacs.
... which doesn't work reliably anyway with DRI2 :-)
Define 'not reliably'. I have uptimes of weeks, and I'm pretty sure I'm
not alone, at least with AGP 1x it seems to work quite well for most
people. So I don't see the justification for intentionally breaking it
completely for all of us.
Even more so because PCI GART is unusably slow in general.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: G5 Quad working with Linux PPC and RadeonHD
On 17.05.2014 17:28, Luigi Burdo wrote: on X1000 r600 boards dont gave decoration problems there is probably needed some other trick about for the other architecture. https://bugs.freedesktop.org/show_bug.cgi?id=74939 That bug is specific to Evergreen / Northern Islands family cards, which includes your 6570, but not your 4650 for example. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: G5 Quad working with Linux PPC and RadeonHD
On 16.05.2014 19:31, Luigi Burdo wrote: Hi all i start one week ago to write massage in ubuntu about my object i have Radeon Hd working on my Quad G5 thanks to linuxPPC . But there are some things to fix One RadeonHD mesa colors are wrong . See https://bugs.freedesktop.org/show_bug.cgi?id=72877 . No progress yet unfortunately. On RadeonHD 4650 ddr3 512mb i have full video acceleration and hdmi audio working On RadeonHD 6570 ddr3 2048mb i have video but no chars on windows and icons . The latter sounds like https://bugs.freedesktop.org/show_bug.cgi?id=74939 , which is fixed in http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=8da17f30c70f4494ce22ad781a1cee17041812f3 . -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Mon, 2013-08-05 at 20:53 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-08-05 at 12:32 +0200, Michel Dänzer wrote:
I did that, sorry should have mentioned that.
@@ -468,5 +478,3 @@ static struct platform_driver
i2c_powermac_driver
=
{
};
module_platform_driver(i2c_powermac_driver);
-
-MODULE_ALIAS(platform:i2c-powermac);
Maybe add the module alias back ? It shouldn't be necessary...
Doesn't help.
Hrm, that might require some more involved debugging, figuring out
what's up with udev etc... that or maybe bisecting.
From what I can tell, we do attach an OF node to the platform device,
but since the driver has no of match table, we should still fallback to
the old platform matching style.
I think I see... adding Grant.
Did that work? He's not in Cc on the post I received from the list, but
that might be due to his mailman settings.
Grant, something broke the auto-loading the of i2c-powermac module. It's
a platform device, but while it does have a populated of_node, its
driver doesn't have an OF match table and relies on the old style
platform device matching.
That's broken with newer kernels, platform_uevent() calls
of_device_uevent_modalias() which sees the of_node and thus doesn't
return -ENOMEM, and we don't create a platform modalias anymore.
Is it legit to add several MODALIAS ? If yes we could add both ... if
not, we have a problem. Doing real OF matching with that critter is
tricky at best for various reasons but it needs the of_node because it
uses it to scan for children.
Any suggestion ?
Any news on this? I recently learned the hard way that loading
i2c-powermac manually via /etc/modules isn't a good workaround, as that
only happens after fsck...
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Sam, 2013-08-03 at 07:02 +1000, Benjamin Herrenschmidt wrote:
On Fri, 2013-08-02 at 18:52 +0200, Michel Dänzer wrote:
Thanks for the suggestion. The same windfarm modules were loaded in both
cases, but i2c_powermac wasn't loaded with the newer kernels. Loading it
manually fixes the problem.
How is i2c_powermac supposed to get loaded with current kernels?
It's a platform driver, but it's missing a module device-table
Can you try this completely untested patch ?
diff --git a/drivers/i2c/busses/i2c-powermac.c
b/drivers/i2c/busses/i2c-powermac.c
index 8dc90da..5af5153 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -458,9 +458,15 @@ static int i2c_powermac_probe(struct platform_device
*dev)
return rc;
}
+static const struct platform_device_id i2c_powermac_id = {
+ .name = i2c-powermac
+};
+MODULE_DEVICE_TABLE(platform, i2c_powermac_id);
+
static struct platform_driver i2c_powermac_driver = {
.probe = i2c_powermac_probe,
.remove = i2c_powermac_remove,
+ .id_table = *i2c_powermac_id,
This fails to build:
CC [M] drivers/i2c/busses/i2c-powermac.o
drivers/i2c/busses/i2c-powermac.c:469:14: error: invalid type argument of unary
‘*’ (have ‘const struct platform_device_id’)
make[1]: *** [drivers/i2c/busses/i2c-powermac.o] Error 1
The version below builds, but the module still doesn't get loaded
automagically (unless I'm missing some command I need to run between
copying the new module to /lib/modules/$(uname -r)/ and rebooting?).
Looking at other drivers in drivers/i2c/busses/, maybe
i2c_powermac_driver.driver needs an of_match_table entry?
diff --git a/drivers/i2c/busses/i2c-powermac.c
b/drivers/i2c/busses/i2c-powermac.c
index 8dc90da..74066fc 100644
--- a/drivers/i2c/busses/i2c-powermac.c
+++ b/drivers/i2c/busses/i2c-powermac.c
@@ -458,9 +458,19 @@ static int i2c_powermac_probe(struct
platform_device *dev)
return rc;
}
+static const struct platform_device_id i2c_powermac_id[] = {
+ {
+ .name = i2c-powermac
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(platform, i2c_powermac_id);
+
static struct platform_driver i2c_powermac_driver = {
.probe = i2c_powermac_probe,
.remove = i2c_powermac_remove,
+ .id_table = i2c_powermac_id,
.driver = {
.name = i2c-powermac,
.bus = platform_bus_type,
@@ -468,5 +478,3 @@ static struct platform_driver i2c_powermac_driver =
{
};
module_platform_driver(i2c_powermac_driver);
-
-MODULE_ALIAS(platform:i2c-powermac);
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Mon, 2013-08-05 at 19:22 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2013-08-05 at 11:13 +0200, Michel Dänzer wrote:
The version below builds, but the module still doesn't get loaded
automagically (unless I'm missing some command I need to run between
copying the new module to /lib/modules/$(uname -r)/ and rebooting?).
depmod -a ?
I did that, sorry should have mentioned that.
@@ -468,5 +478,3 @@ static struct platform_driver i2c_powermac_driver
=
{
};
module_platform_driver(i2c_powermac_driver);
-
-MODULE_ALIAS(platform:i2c-powermac);
Maybe add the module alias back ? It shouldn't be necessary...
Doesn't help.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Sam, 2013-07-20 at 23:33 +0300, Aaro Koskinen wrote:
Hi,
On Sat, Jul 20, 2013 at 09:16:49AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2013-07-19 at 20:43 +0300, Aaro Koskinen wrote:
I booted a Xserve today with 3.11-rc1, and noticed the noise is coming
from slots-fan (PCI fan?) which is always 99%, although the slots-temp is
just 33. Is it on purpose the rm31 slots PID params are totally different
from therm_pm72 slots params? It seems like they have been copied from
pm72 drive bay PID params instead.
Could be my mistake. What happens if you change them to match the old code ?
I tried the change below (use SLOTS_PID_* values from therm_pm72.h),
and the noise level is considerably lower. The slots-fan stays at 19%,
and slots-temp rises to 42'C but not higher after running couple of hours.
diff --git a/drivers/macintosh/windfarm_rm31.c
b/drivers/macintosh/windfarm_rm31.c
index 0b9a79b..82fc86a 100644
--- a/drivers/macintosh/windfarm_rm31.c
+++ b/drivers/macintosh/windfarm_rm31.c
@@ -439,15 +439,15 @@ static void backside_setup_pid(void)
/* Slots fan */
static const struct wf_pid_param slots_param = {
- .interval = 5,
- .history_len= 2,
- .gd = 30 20,
- .gp = 5 20,
- .gr = 0,
- .itarget= 40 16,
- .additive = 1,
- .min= 300,
- .max= 4000,
+ .interval = 1,
+ .history_len= 20,
+ .gd = 0,
+ .gp = 0,
+ .gr = 0x0010,
+ .itarget= 320,
+ .additive = 0,
+ .min= 20,
+ .max= 100,
};
static void slots_fan_tick(void)
Could a similar change fix the same problem on desktop G5s? The same
values for slots_param in windfarm_pm112.c don't help, unfortunately.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Fre, 2013-08-02 at 22:51 +1000, Benjamin Herrenschmidt wrote: On Fri, 2013-08-02 at 12:03 +0200, Michel Dänzer wrote: Could a similar change fix the same problem on desktop G5s? The same values for slots_param in windfarm_pm112.c don't help, unfortunately. You have a 11,2 and a noisy fan ? Odd, mine(s) don't I can dbl check the values vs. what Darwin uses tomorrow... Yes, see /proc/cpuinfo below. With older kernels (currently still using Debian's 3.2.0-4-powerpc64 because of this problem), the fans go basically silent as soon as the windfarm modules are loaded. With current kernels, the fans stay at the level OF sets them to, until after a while they go into 'airplane mode'. One thing I notice now is that the lines like [9.539173] windfarm: CPUs control loops started. [ 16.209962] windfarm: Backside control loop started. [ 16.262274] windfarm: Slots control loop started. [ 16.371642] windfarm: Drive bay control loop started. no longer appear in dmesg with current kernels. Should they? processor : 0 cpu : PPC970MP, altivec supported clock : 2500.00MHz revision: 1.1 (pvr 0044 0101) processor : 1 cpu : PPC970MP, altivec supported clock : 2500.00MHz revision: 1.1 (pvr 0044 0101) processor : 2 cpu : PPC970MP, altivec supported clock : 2500.00MHz revision: 1.1 (pvr 0044 0101) processor : 3 cpu : PPC970MP, altivec supported clock : 2500.00MHz revision: 1.1 (pvr 0044 0101) timebase: platform: PowerMac model : PowerMac11,2 machine : PowerMac11,2 motherboard : PowerMac11,2 MacRISC4 Power Macintosh detected as : 337 (PowerMac G5 Dual Core) pmac flags : L2 cache: 1024K unified pmac-generation : NewWorld -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: therm_pm72 units, interface
On Fre, 2013-08-02 at 18:58 +0300, Aaro Koskinen wrote: On Fri, Aug 02, 2013 at 04:47:51PM +0200, Michel Dänzer wrote: On Fre, 2013-08-02 at 22:51 +1000, Benjamin Herrenschmidt wrote: On Fri, 2013-08-02 at 12:03 +0200, Michel Dänzer wrote: Could a similar change fix the same problem on desktop G5s? The same values for slots_param in windfarm_pm112.c don't help, unfortunately. You have a 11,2 and a noisy fan ? Odd, mine(s) don't I can dbl check the values vs. what Darwin uses tomorrow... Yes, see /proc/cpuinfo below. With older kernels (currently still using Debian's 3.2.0-4-powerpc64 because of this problem), the fans go basically silent as soon as the windfarm modules are loaded. With current kernels, the fans stay at the level OF sets them to, until after a while they go into 'airplane mode'. One thing I notice now is that the lines like [9.539173] windfarm: CPUs control loops started. [ 16.209962] windfarm: Backside control loop started. [ 16.262274] windfarm: Slots control loop started. [ 16.371642] windfarm: Drive bay control loop started. no longer appear in dmesg with current kernels. Should they? Yes. They are printed once all the sensor and control modules are loaded and registered. If the loops are not started, it's basically doing nothing. Maybe something goes wrong in module loading? What lsmod is showing? Thanks for the suggestion. The same windfarm modules were loaded in both cases, but i2c_powermac wasn't loaded with the newer kernels. Loading it manually fixes the problem. How is i2c_powermac supposed to get loaded with current kernels? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powermac/cpufreq_32: set non-infinite transition time for 7447A driver
On Mon, 2012-10-29 at 10:15 +0100, Andreas Schwab wrote: The transition time for the 7447A is around 8ms which makes it possible to use the ondemand governor. This has been tested on the iBook G4 (PowerBook6,7). Signed-off-by: Andreas Schwab sch...@linux-m68k.org Tested-by: Michel Dänzer mic...@daenzer.net -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] bluetooth: opcode field of sent commands is little endian.
Fixes built-in Bluetooth not working on Apple PowerBooks, regression from
commit 75fb0e324daa48ec458fb5c2960eb07b80cfad9d ('Bluetooth: Fix init sequence
for some CSR based controllers').
Cc: sta...@vger.kernel.org [v3.4]
Signed-off-by: Michel Dänzer mic...@daenzer.net
---
net/bluetooth/hci_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d6dc44c..e039e3d 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -92,7 +92,7 @@ void hci_req_complete(struct hci_dev *hdev, __u16 cmd, int
result)
* command.
*/
- if (cmd != HCI_OP_RESET || sent-opcode == HCI_OP_RESET)
+ if (cmd != HCI_OP_RESET || sent-opcode ==
cpu_to_le16(HCI_OP_RESET))
return;
skb = skb_clone(hdev-sent_cmd, GFP_ATOMIC);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] bluetooth: opcode field of sent commands is little endian.
On Son, 2012-06-24 at 23:51 -0700, Marcel Holtmann wrote:
Hi Michel,
Fixes built-in Bluetooth not working on Apple PowerBooks, regression from
commit 75fb0e324daa48ec458fb5c2960eb07b80cfad9d ('Bluetooth: Fix init
sequence
for some CSR based controllers').
Cc: sta...@vger.kernel.org [v3.4]
Signed-off-by: Michel Dänzer mic...@daenzer.net
---
net/bluetooth/hci_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d6dc44c..e039e3d 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -92,7 +92,7 @@ void hci_req_complete(struct hci_dev *hdev, __u16 cmd,
int result)
* command.
*/
- if (cmd != HCI_OP_RESET || sent-opcode == HCI_OP_RESET)
+ if (cmd != HCI_OP_RESET || sent-opcode ==
cpu_to_le16(HCI_OP_RESET))
return;
actually you could use __constant_cpu_to_le16() here.
Yes, but I checked and that's not used anywhere in the bluetooth code
yet, so I thought I'd stay consistent for now.
That said, this got actually fixed differently upstream. So I prefer if
that patch gets merged into stable and not this one.
commit 1036b89042df96e71c0cb941be212f8053e0
Author: Andrei Emeltchenko andrei.emeltche...@intel.com
Date: Mon Mar 12 15:59:33 2012 +0200
Bluetooth: Fix opcode access in hci_complete
Fine with me, though FWIW that not only doesn't use
__constant_cpu_to_le16() but actually swaps the non-constant value.
Also, it would have been nice if that fix was promoted to stable, so I
wouldn't have had to spend a good part of the weekend bisecting...
In general patches need to get into Linus' tree first before you can
even request them for stable.
I know, that's why I only put the stable tag in commit logs but don't
submit patches there via e-mail.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] bluetooth: opcode field of sent commands is little endian.
On Mon, 2012-06-25 at 00:22 -0700, Marcel Holtmann wrote:
Hi Michel,
Fixes built-in Bluetooth not working on Apple PowerBooks, regression
from
commit 75fb0e324daa48ec458fb5c2960eb07b80cfad9d ('Bluetooth: Fix init
sequence
for some CSR based controllers').
Cc: sta...@vger.kernel.org [v3.4]
Signed-off-by: Michel Dänzer mic...@daenzer.net
---
net/bluetooth/hci_core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index d6dc44c..e039e3d 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -92,7 +92,7 @@ void hci_req_complete(struct hci_dev *hdev, __u16
cmd, int result)
* command.
*/
- if (cmd != HCI_OP_RESET || sent-opcode == HCI_OP_RESET)
+ if (cmd != HCI_OP_RESET || sent-opcode ==
cpu_to_le16(HCI_OP_RESET))
return;
actually you could use __constant_cpu_to_le16() here.
Yes, but I checked and that's not used anywhere in the bluetooth code
yet, so I thought I'd stay consistent for now.
not sure what code you are looking at, but I count 18 occurrences and we
have been fixing the ones we missed initially.
Okay, good then. As you probably noticed from the rest of my posts, I
only checked up to 3.4.
That said, this got actually fixed differently upstream. So I prefer if
that patch gets merged into stable and not this one.
commit 1036b89042df96e71c0cb941be212f8053e0
Author: Andrei Emeltchenko andrei.emeltche...@intel.com
Date: Mon Mar 12 15:59:33 2012 +0200
Bluetooth: Fix opcode access in hci_complete
Fine with me, though FWIW that not only doesn't use
__constant_cpu_to_le16() but actually swaps the non-constant value.
Don't see what point you are trying to make here. Swapping the value
from the actual command structure is always fine with me.
The point is that the result of swapping a constant value is just
another constant value, whereas the fix in mainline swaps a value from
memory. Not a big deal.
Also, it would have been nice if that fix was promoted to stable, so I
wouldn't have had to spend a good part of the weekend bisecting...
Thinks like this happen. However after you bisected the issue you could
have just checked what is in Linus' or bluetooth-next tree.
You're probably right. It just didn't occur to me that someone would
have fixed this but not forwarded the fix to stable, because I generally
do that. :}
Will you submit the fix to stable, or should I?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] bluetooth: opcode field of sent commands is little endian.
On Mon, 2012-06-25 at 10:20 +0100, David Laight wrote: Fine with me, though FWIW that not only doesn't use __constant_cpu_to_le16() but actually swaps the non-constant value. Don't see what point you are trying to make here. Swapping the value from the actual command structure is always fine with me. The point is that the result of swapping a constant value is just another constant value, whereas the fix in mainline swaps a value from memory. Not a big deal. Surely, but surely, the definition of cpu_to_le16() uses gcc 'magic' to determine that the argument is a constant and then automatically selects the 'constant' form. It can only do that if the argument is constant in the first place though. :) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mon, 2012-04-23 at 18:45 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote: What I didn't understand yet is how this uncacheable memory is allocated (well, I never took the time to look at this again). The functions in ttm_page_alloc.c seem to allocate normal cacheable memory and try to set the page flags with set_pages_array_uc(), which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on the other side is only used with SWIOTLB!? [...] Could it be that the memory is finally mapped uncacheable by radeon_bo_kmap()/ ttm_bo_kmap()/..some other TTM functions../vmap()? Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes, and vmap() is used to enforce them for kernel mappings. Okay, that sounds like the approach used by arch/powerpc/mm/dma- noncoherent.c in my (green) ears. What about the PCIGART mode? Is the driver free to use cached memory in this mode? Yes, it assumes PCI(e) GART to be CPU cache coherent. Okay. I guess it should be possible to modify it so that it makes use of uncacheable memory - just for testing!? Sure. Just set man-available_caching and man-default_caching as in the AGP case in radeon_init_mem_type(). PCIGART was working somehow on my platform up to the ~2.6.39 kernel, i.e. I could login to GNOME and open a program until the machine locked-up. :-) But it's worse with newer kernels? BTW: I see that the uninorth driver defines needs_scratch_page. What is this actually good for? It causes the code in drivers/char/agp/backend.c to allocate a scratch page (bridge-scratch_page) which the driver can use for unused GART entries. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: The former case is an explanation, why I see data corruption with my AGPGART driver (more or less a copy of the uninorth driver) on my non-coherent platform. There are no cache flushes done for writes to already mapped pages. As I said, the radeon driver always maps AGP memory uncacheable for the CPU, so no such CPU cache flushes should be necessary. I know. We also discussed this topic over two years ago. :-) What I didn't understand yet is how this uncacheable memory is allocated (well, I never took the time to look at this again). The functions in ttm_page_alloc.c seem to allocate normal cacheable memory and try to set the page flags with set_pages_array_uc(), which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on the other side is only used with SWIOTLB!? [...] Could it be that the memory is finally mapped uncacheable by radeon_bo_kmap()/ ttm_bo_kmap()/..some other TTM functions../vmap()? Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes, and vmap() is used to enforce them for kernel mappings. Okay, that sounds like the approach used by arch/powerpc/mm/dma- noncoherent.c in my (green) ears. What about the PCIGART mode? Is the driver free to use cached memory in this mode? Yes, it assumes PCI(e) GART to be CPU cache coherent. [5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM-GTT copy 0: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf148-0xf158) [...] The VRAM-GTT copy totally puzzles me, as it returns a wrong page address, but the offset is fine!? Maybe it's still the values from the GTT-VRAM test, i.e. either the GPU writes didn't make it to the memory mapped into the AGP GART (some AGP bridges are known to have issues with that) or the CPU doesn't see it. What is the workaround for such an AGP bridge? If there is one at all... The only workaround short of not using AGP would be not doing GPU-AGP transfers, but that's not implemented or even planned at all. BTW, does your driver set cant_use_aperture, or is the linear aperture accessible by the CPU? The driver sets cant_use_aperture. I couldn't get it working at all without it. Does the hardware really not allow the CPU to access the linear aperture though? Because if it does, I wonder if that might be more reliable. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: The former case is an explanation, why I see data corruption with my AGPGART driver (more or less a copy of the uninorth driver) on my non-coherent platform. There are no cache flushes done for writes to already mapped pages. As I said, the radeon driver always maps AGP memory uncacheable for the CPU, so no such CPU cache flushes should be necessary. I know. We also discussed this topic over two years ago. :-) What I didn't understand yet is how this uncacheable memory is allocated (well, I never took the time to look at this again). The functions in ttm_page_alloc.c seem to allocate normal cacheable memory and try to set the page flags with set_pages_array_uc(), which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on the other side is only used with SWIOTLB!? [...] Could it be that the memory is finally mapped uncacheable by radeon_bo_kmap()/ ttm_bo_kmap()/..some other TTM functions../vmap()? Yeah, AFAICT, basically ttm_io_prot() defines the mapping attributes, and vmap() is used to enforce them for kernel mappings. Here is an excerpt of the 2.6.39 kernel log. IIRC the testing code changed in the meantime so I guess it would make sense to repeat it with a newer kernel version. I was going to suggest that. :) [5.490569] [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: Got 0xf13268c0, expected 0xf1326160 (GTT map 0xf1326000-0xf1426000) [5.503397] [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: Got 0xf13268c4, expected 0xf1326164 (GTT map 0xf1326000-0xf1426000) [5.516202] [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: Got 0xf13268c0, expected 0xf1326168 (GTT map 0xf1326000-0xf1426000) [5.528993] [drm:radeon_test_moves] *ERROR* Incorrect GTT-VRAM copy 0: Got 0xf13268c4, expected 0xf132616c (GTT map 0xf1326000-0xf1426000) [...] [5.878809] [drm:radeon_test_moves] *ERROR* Incorrect VRAM-GTT copy 0: Got 0xf1416ec0, expected 0xf1570ec0 (VRAM map 0xf148-0xf158) For the GTT-VRAM copy it looks like the AGPGART driver at least gets the graphics aperture translation table right, as both the returned and expected values are within a page. But the page offset of the returned values (0x8c0, 0x8c4) makes me wonder whether I'm fooled by a hardware bug or a cache coherency problem. Hard to say... at least it managed to transfer the first 352 bytes correctly. ;) The VRAM-GTT copy totally puzzles me, as it returns a wrong page address, but the offset is fine!? Maybe it's still the values from the GTT-VRAM test, i.e. either the GPU writes didn't make it to the memory mapped into the AGP GART (some AGP bridges are known to have issues with that) or the CPU doesn't see it. BTW, does your driver set cant_use_aperture, or is the linear aperture accessible by the CPU? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c) Neither changes anything. How small aperture sizes have you tried? 32M. With the old UMS driver 3D once worked fine ... That doesn't necessarily mean much per se, as with UMS memory is only statically mapped into the AGP GART once (so most of those 32M are wasted at least most of the time), whereas with KMS it's dynamically (un)mapped on demand. That may be a stupid question, but is it allowed (for a DRM client or whatever does the mapping) to change the content of a page mapped into the AGP GART or is it necessary to explicitly unmap the page, change its content and map it again? The former. I know that the uninorth AGPGART driver does a cache flushing for newly mapped pages, Ah, right, that probably explains why the map_page_into_agp change doesn't make any difference. but is there any code in the driver that handles the former case (or isn't this necessary on PPC Macs)? If by 'former case' you mean userspace modifying memory mapped into the AGP GART, then no, this generally doesn't require special treatment on PowerMacs. (Ignoring the potential issue mentioned by Ben in this thread) I would say it's necessary to unmap the page first (sounds more like the pci_[un]map_page() approach) - at least when it should work with non-coherent architectures, too. I'm afraid non-coherent platforms haven't really been a concern yet for KMS, and always doing the above dance would probably have a significant performance impact on coherent platforms. Are there any plans for a page flushing API? I suppose that wouldn't have such a big performance impact on coherent platforms (but probably an impact on the userspace API). Not that I know of. Note that this isn't necessarily the only possible approach for addressing this problem. The driver knows which memory buffers are used by a GPU command stream sequence, so it should be able to take any measures necessary to ensure the device sees their contents as of when the command stream was submitted. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: That may be a stupid question, but is it allowed (for a DRM client or whatever does the mapping) to change the content of a page mapped into the AGP GART or is it necessary to explicitly unmap the page, change its content and map it again? The former. I know that the uninorth AGPGART driver does a cache flushing for newly mapped pages, but is there any code in the driver that handles the former case (or isn't this necessary on PPC Macs)? If by 'former case' you mean userspace modifying memory mapped into the AGP GART, then no, this generally doesn't require special treatment on PowerMacs. (Ignoring the potential issue mentioned by Ben in this thread) I guess you refer to the ordering issue here. Yeah. The former case is an explanation, why I see data corruption with my AGPGART driver (more or less a copy of the uninorth driver) on my non-coherent platform. There are no cache flushes done for writes to already mapped pages. As I said, the radeon driver always maps AGP memory uncacheable for the CPU, so no such CPU cache flushes should be necessary. I tested this with radeon.test=1, but I'm not even sure if this code changes already mapped pages [...] It does. radeon_bo_pin(..., RADEON_GEM_DOMAIN_GTT, ...) binds the buffer memory into the AGP GART, and the test only maps it to the CPU after that. I take it the test fails for you? How exactly? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Die, 2012-04-17 at 20:49 +0100, o jordan wrote: I've been trying to get Kernel Mode Setting working on my iBook with Ubuntu 12.04. I can only get it working by forcing PCI mode (agpmode=-1). Setting agpmode=1 or a higher number just results in freezing and a flashing screen. At which point? When radeon KMS initializes, or only when X starts? I've tried the Debian experimental kernel with the same results. I notice with Fedora 16 they also recommend setting agpmode=-1 with a radeon card. So I'm guessing there is no easy fix?? Probably not (AGP is flaky in general, but in particular with older UniNorth bridges), but it might be interesting to see some kernel output from booting without agpmode=-1. If you can't get it via ssh, maybe you can via netconsole or so. With Userspace Mode Setting there is nolonger any 3D hardware acceleration (https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/946677 ) From the Mesa upstream POV, the drivers from the 7.11 branch could be used for this. CONFIG_DRM_RADEON_KMS=y CONFIG_FB_RADEON=y Not sure it's a good idea to set both of these =y: It will prevent the radeon driver from initializing at all by default if radeonfb is active. If you want CONFIG_FB_RADEON=y, I'd suggest leaving CONFIG_DRM_RADEON_KMS disabled. KMS can always be enabled at boot time with radeon.modeset=1. CONFIG_FB_ATY128=y CONFIG_FB_ATY=y There's no KMS for pre-Radeon ATI cards yet, so these are not directly related. I'm not sure if CONFIG_AGP_UNINORTH should be compiled as a module or built in. I think it would only need to be built in if the radeon driver was built in, which is not recommended. P.S. The dri-devel list at freedesktop.org might be better for this, at least in addition to linuxppc-dev. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: Not sure it's a good idea to set both of these =y: It will prevent the radeon driver from initializing at all by default if radeonfb is active. You can say video=radeonfb:off. I know, I'm referring to the default behaviour without any relevant kernel command line options. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: Probably not (AGP is flaky in general, but in particular with older UniNorth bridges), but it might be interesting to see some kernel output from booting without agpmode=-1. If you can't get it via ssh, maybe you can via netconsole or so. While logging into KDE: radeon :00:10.0: GPU lockup CP stall for more than 10064msec GPU lockup (waiting for 0x03EE last fence id 0x03ED) radeon: wait for empty RBBM fifo failed ! Bad things might happen. Failed to wait GUI idle while programming pipes. Bad things might happen. radeon :00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137 radeon :00:10.0: GPU reset succeed radeon :00:10.0: GPU reset succeed radeon :00:10.0: (r300_asic_reset:414) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:433) RBBM_STATUS=0x8802C137 radeon :00:10.0: (r300_asic_reset:445) RBBM_STATUS=0x8802C137 radeon :00:10.0: GPU reset succeed radeon: wait for empty RBBM fifo failed ! Bad things might happen. Failed to wait GUI idle while programming pipes. Bad things might happen. That's even with agpmode=1? Note that I'm interested in seeing the full dmesg or at least all agp/drm/radeon related messages. After that is is dead. The whole machine? That's probably due to something going wrong (e.g. an MCE) while trying to reset the GPU. I fixed one such problem recently, but it's still not as reliable as on x86 unfortunately. GPU lockup appears to be a common problem with the radeon driver. It's what happens when anything goes wrong with the GPU. If it doesn't happen with agpmode=-1, it's probably an AGP related coherency issue. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote: On Wed, 2012-04-18 at 10:02 +0200, Michel Dänzer wrote: GPU lockup appears to be a common problem with the radeon driver. It's what happens when anything goes wrong with the GPU. If it doesn't happen with agpmode=-1, it's probably an AGP related coherency issue. I had some success hacking the DRM to do an in_le32 from the ring head after writing it. Just a gross hack but it seemed to help on a G5. AFAICT radeon_ring_commit() does that already: DRM_MEMORYBARRIER(); WREG32(ring-wptr_reg, (ring-wptr ring-ptr_reg_shift) ring-ptr_reg_mask); (void)RREG32(ring-wptr_reg); We added the readback about a decade ago. :) I suspect there's a fundamental design issue with apple bridge in that the CPU to memory path isn't coherent at all with the GPU to memory path ie. even vs. cache flush instructions (ie buffers in the memory controllers can still be out of sync). Darwin does some gross hacks to work around that, some of them visible in the AGP drivers, some burried in the Apple driver, I don't know for sure. It's possible that they end up mapping all AGP memory as cache inhibited, but we can't do that because of our linear mapping. We are doing that though... -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote: On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote: I suspect there's a fundamental design issue with apple bridge in that the CPU to memory path isn't coherent at all with the GPU to memory path ie. even vs. cache flush instructions (ie buffers in the memory controllers can still be out of sync). Darwin does some gross hacks to work around that, some of them visible in the AGP drivers, some burried in the Apple driver, I don't know for sure. It's possible that they end up mapping all AGP memory as cache inhibited, but we can't do that because of our linear mapping. We are doing that though... This reminded me, I've been running with the patch below, but I'm not sure it makes any difference. Maybe Andreas or Jordan can try it. diff --git a/arch/powerpc/include/asm/agp.h b/arch/powerpc/include/asm/agp.h index 416e12c..eb34fa5 100644 --- a/arch/powerpc/include/asm/agp.h +++ b/arch/powerpc/include/asm/agp.h @@ -2,9 +2,12 @@ #define _ASM_POWERPC_AGP_H #ifdef __KERNEL__ +#include asm/cacheflush.h #include asm/io.h -#define map_page_into_agp(page) +#define map_page_into_agp(page)\ + flush_dcache_range((unsigned long)page_address(page), \ + (unsigned long)page_address(page) + PAGE_SIZE) #define unmap_page_from_agp(page) #define flush_agp_cache() mb() -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 20:37 +1000, Benjamin Herrenschmidt wrote: On Wed, 2012-04-18 at 20:35 +1000, Benjamin Herrenschmidt wrote: On Wed, 2012-04-18 at 09:46 +0200, Andreas Schwab wrote: Benjamin Herrenschmidt b...@kernel.crashing.org writes: Note also that KMS doesn't afaik have the power management code that radeonfb has for those old Mac chipsets, so suspend/resume won't work. How hard would it be to add it? The code itself is relatively self contained, but the KMS power management side is a bit ... messy :-) That's an interesting way to put it, given the hacks to make it work between radeonfb and uninorth_agp. :) (Which are complicating making at least hibernation work with KMS on uninorth_agp) In contrast, radeon KMS uses the standard Linux device suspend/resume hooks. So the real deal is to figure out how best to hook it up there. There's some duplication Argh... bloody x220 touchpad... So I was saying, there's also some duplication in the area of dynamic clocks configuration. Some of this could be an issue as afaik, to work reliably, the suspend/resume code really wants the stuff to be setup exactly the way the code in radeon_pm does Are you referring to radeon_pm in radeonfb or radeon KMS? Most of the latter isn't used on PPC laptops because it relies on an x86 video BIOS. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 13:25 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 09:42 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: Not sure it's a good idea to set both of these =y: It will prevent the radeon driver from initializing at all by default if radeonfb is active. You can say video=radeonfb:off. I know, I'm referring to the default behaviour without any relevant kernel command line options. Which is exactly the right behaviour for me. You do understand that 'prevent the radeon driver from initializing at all' means direct rendering won't work at all, even with older Mesa drivers? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 21:23 +1000, Benjamin Herrenschmidt wrote: Right, we might be able to easily port my old code over by simply making it ppc specific. In radeonfb, it's also used for some thinkpads among others but KMS does that with the BIOS on these no ? (ie. D2 state). KMS doesn't have any non-BIOS suspend/resume code yet, so it's either that or no suspend/resume. :) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 21:19 +1000, Benjamin Herrenschmidt wrote: On Wed, 2012-04-18 at 12:44 +0200, Michel Dänzer wrote: On Mit, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote: On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote: I suspect there's a fundamental design issue with apple bridge in that the CPU to memory path isn't coherent at all with the GPU to memory path ie. even vs. cache flush instructions (ie buffers in the memory controllers can still be out of sync). Darwin does some gross hacks to work around that, some of them visible in the AGP drivers, some burried in the Apple driver, I don't know for sure. It's possible that they end up mapping all AGP memory as cache inhibited, but we can't do that because of our linear mapping. We are doing that though... This reminded me, I've been running with the patch below, but I'm not sure it makes any difference. Maybe Andreas or Jordan can try it. It certainly is something we need to do, provided we also know there will be no subsequent access to that page via a cachable mapping until it's removed from AGP. TTM should take care of that. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 15:22 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: You do understand that 'prevent the radeon driver from initializing at all' means direct rendering won't work at all, even with older Mesa drivers? Until radeondrmfb has suspend support, this is what I want. Then you could disable CONFIG_DRM_RADEON, or prevent the radeon module from loading. *shrug* -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 21:17 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote:
On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2012-04-18 at 10:02 +0200, Michel Dänzer wrote:
GPU lockup appears to be a common problem with the radeon driver.
It's what happens when anything goes wrong with the GPU. If it doesn't
happen with agpmode=-1, it's probably an AGP related coherency issue.
I had some success hacking the DRM to do an in_le32 from the ring head
after writing it. Just a gross hack but it seemed to help on a G5.
AFAICT radeon_ring_commit() does that already:
DRM_MEMORYBARRIER();
WREG32(ring-wptr_reg, (ring-wptr ring-ptr_reg_shift)
ring-ptr_reg_mask);
(void)RREG32(ring-wptr_reg);
We added the readback about a decade ago. :)
Hrm, I have a different hack in that old tree I was playing with a while
back, let me see...
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
Note that radeon_cp.c is UMS code, for KMS you need to look at
radeon_ring.c.
@@ -2245,6 +2245,9 @@ void radeon_commit_ring(drm_radeon_private_t
*dev_priv)
DRM_MEMORYBARRIER();
GET_RING_HEAD( dev_priv );
+#ifdef CONFIG_PPC
+ in_be32(dev_priv-ring.start);
+#endif
if ((dev_priv-flags RADEON_FAMILY_MASK) = CHIP_R600) {
I think that my rational was to ensure that all previous stores to
AGP (indirect buffers etc...) were pushed out ordered vs the ring
wptr update or something like that, bcs I think those path aren't well
ordered in HW. In fact I suspect we might even need a bigger hammer than
that in_be32().
Probably wouldn't hurt trying something like that in the KMS code as
well.
Another hack I had around was removing the SBA reset from agp-uninorth
completely on binding new pages, it seemed to cause hangs.
You mean like commit 5613beb46d54da6ef7f1c4589e9f2e60eeb10721? :)
I suspect there's a fundamental design issue with apple bridge in that
the CPU to memory path isn't coherent at all with the GPU to memory path
ie. even vs. cache flush instructions (ie buffers in the memory
controllers can still be out of sync).
Darwin does some gross hacks to work around that, some of them visible
in the AGP drivers, some burried in the Apple driver, I don't know for
sure. It's possible that they end up mapping all AGP memory as cache
inhibited, but we can't do that because of our linear mapping.
We are doing that though...
Are we really ? I thought we were taking existing cachable RAM objects
and mapping them into the AGP gart.
No, the radeon driver has always mapped memory uncacheable to the CPU
while it's bound into the AGP GART.
Are we replacing both kernel user mappings for those objects with an
equivalent cache inhibited mapping ?
I'm not -that- familiar with how ttm works here.
I'm hardly more familiar with how it all works than you. :)
In any case it can cause bus checkstops because the same pages can be
prefetched into the cache via the linear mapping which is covered by
BATs
So you've been saying for about a decade. :) But I've never seen any
problems tracked down to that.
(unless you make your graphic objects HIGHMEM only but good luck with
that :-)
FWIW I think TTM indeed prefers highmem pages for GPU access. The radeon
driver normally doesn't need kernel mappings for them.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 13:30 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 09:54 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: This was a test with agpmode=1: Linux agpgart interface v0.103 agpgart-uninorth :00:0b.0: Apple UniNorth 2 chipset agpgart-uninorth :00:0b.0: configuring for size idx: 64 agpgart-uninorth :00:0b.0: AGP aperture is 256M @ 0x0 Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c) After that is is dead. The whole machine? No pings any more. You might be able to get more information via netconsole. That's how I tracked down and fixed one cause of MCEs during the GPU reset. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c) Neither changes anything. How small aperture sizes have you tried? The purpose of radeon.test=1 isn't to change anything but to catch problems transferring data between system memory bound via AGP GART and video RAM. Does it pass for the whole AGP aperture? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c) Neither changes anything. How small aperture sizes have you tried? 32M. With the old UMS driver 3D once worked fine ... That doesn't necessarily mean much per se, as with UMS memory is only statically mapped into the AGP GART once (so most of those 32M are wasted at least most of the time), whereas with KMS it's dynamically (un)mapped on demand. The purpose of radeon.test=1 isn't to change anything but to catch problems transferring data between system memory bound via AGP GART and video RAM. Does it pass for the whole AGP aperture? AFAICT yes. For the default 256M it printed [drm] Tested GTT-VRAM and VRAM-GTT copy for GTT offset for every other offset from 0x201000 to 0xfe01000. Okay, so apparently there's at least no obvious problem with 256M on your UniNorth revision either. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC radeon KMS - is it possible?
On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Mit, 2012-04-18 at 16:55 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: On Mit, 2012-04-18 at 16:28 +0200, Andreas Schwab wrote: Michel Dänzer mic...@daenzer.net writes: Have you tried smaller aperture sizes (uninorth_agp.aperture) and/or radeon.test=1? (See commit 52f072cb084bbb460d3a4ae09f0b6efc3e7e8a8c) Neither changes anything. How small aperture sizes have you tried? 32M. With the old UMS driver 3D once worked fine ... That doesn't necessarily mean much per se, as with UMS memory is only statically mapped into the AGP GART once (so most of those 32M are wasted at least most of the time), whereas with KMS it's dynamically (un)mapped on demand. That may be a stupid question, but is it allowed (for a DRM client or whatever does the mapping) to change the content of a page mapped into the AGP GART or is it necessary to explicitly unmap the page, change its content and map it again? The former. I would say it's necessary to unmap the page first (sounds more like the pci_[un]map_page() approach) - at least when it should work with non-coherent architectures, too. I'm afraid non-coherent platforms haven't really been a concern yet for KMS, and always doing the above dance would probably have a significant performance impact on coherent platforms. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] agp/uninorth: Fix lockups with radeon KMS and 1x.
From: Michel Dänzer daen...@vmware.com
This was based on a description by Ben Herrenschmidt:
I've removed that SBA reset from the normal TLB invalidation path and
left it only once after turning AGP on.
About six months ago, he said:
I did it a bit differently, but yeah, you get the idea. I'm doing a
patch series so don't bother pushing things too hard yet.
But I haven't seen anything from him about this since then, and people are
regularly hitting these lockups, so here we are...
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 47c2218..55af723 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -80,7 +80,7 @@ static void uninorth_tlbflush(struct agp_memory *mem)
ctrl | UNI_N_CFG_GART_INVAL);
pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL, ctrl);
- if (uninorth_rev = 0x30) {
+ if (!mem uninorth_rev = 0x30) {
pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
ctrl | UNI_N_CFG_GART_2xRESET);
pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
--
1.7.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
On Mit, 2011-04-13 at 18:43 -0500, kevin diggs wrote: On Wed, Apr 13, 2011 at 6:21 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2011-04-13 at 12:52 -0500, kevin diggs wrote: Actually I do get a crash in X later on... something in the radeon DRM interrupt code is getting what looks like a NULL dereference. I'll try to dig that one later on. I don't know if it's related to your problem at all though. In this context, what does 'crash' mean? The X thingy goes down? Or the whole OS? Depends, with xmon enabled you get into xmon :-) Dunno if the oops is fatal but it could be. Cheers, Ben. As I think I have the same hardware as you (7,3, radeon 9600) If you can tell me how to reproduce it maybe I can poke around a little. Thus, at least temporarily, freeing you up for other stuff. I kinda need a break from fighting with GCC. FWIW, the problem Ben refers to might be fixed in current mainline by commit d87dfdbfc91c5e37288e7e8f7afdd992ba61a60d which reverts 69a07f0b117a40fcc1a479358d8e1f41793617f2 . -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote: On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote: On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote: On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote: With no_wb=1 the driver goes a bit further but the X server ends up in an infinite ioctl loop and the logs are: Which ioctl does it loop on? Please provide the Xorg.0.log file as well. From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE. Note that it's normal for this ioctl to be called every time before the GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl always returns an error, this may not indicate a problem on its own. It seems to be an infinite loop, always returning EINTR because of regular SIGALRM delivery. That does sound like the GPU locks up. Do you get any messages in dmesg about lockups and attempts to reset the GPU at any time? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
On Mit, 2011-04-13 at 14:27 +0200, Gabriel Paubert wrote: On Wed, Apr 13, 2011 at 02:12:16PM +0200, Michel Dänzer wrote: On Mit, 2011-04-13 at 09:59 +0200, Gabriel Paubert wrote: On Tue, Apr 12, 2011 at 07:29:22PM +0200, Michel Dänzer wrote: On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote: On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote: With no_wb=1 the driver goes a bit further but the X server ends up in an infinite ioctl loop and the logs are: Which ioctl does it loop on? Please provide the Xorg.0.log file as well. From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE. Note that it's normal for this ioctl to be called every time before the GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl always returns an error, this may not indicate a problem on its own. It seems to be an infinite loop, always returning EINTR because of regular SIGALRM delivery. That does sound like the GPU locks up. Do you get any messages in dmesg about lockups and attempts to reset the GPU at any time? No. Hmm, I guess the constant SIGALRMs might prevent the lockup detection from kicking in... Maybe you can try starting the X server with -dumbSched to see if that gets things along any further, but in the end there's probably no way around figuring out what causes the lockup and fixing that anyway. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
On Die, 2011-04-12 at 13:30 +0200, Gabriel Paubert wrote: On Mon, Apr 11, 2011 at 05:32:43PM +0200, Michel Dänzer wrote: Have you ruled out any MSI related problems? I think the IRQ not working could explain the symptoms... Booting with MSI disabled does not change anything. Actually on this machine the Ethernet (tigon3) uses MSI and everything is fine. OTOH, on my home PC (dual code Athlon64 4 1/2 years old), MSI has never worked. Okay, the fact no_wb helps probably rules out an IRQ problem anyway. Make sure this line changes to 'WB disabled' with no_wb=1. There's a writeback endianness bug with modeset=1, see http://lists.freedesktop.org/archives/dri-devel/2011-April/009960.html . With no_wb=1 the driver goes a bit further but the X server ends up in an infinite ioctl loop and the logs are: Which ioctl does it loop on? Please provide the Xorg.0.log file as well. kernel: [drm] radeon kernel modesetting enabled. kernel: checking generic (c000 14) vs hw (c000 1000) kernel: fb: conflicting fb hw usage radeondrmfb vs OFfb vga,Displa - removing generic driver kernel: [drm] initializing kernel modesetting (RV530 0x1002:0x71C7). kernel: radeon :f1:00.0: Using 64-bit DMA iommu bypass kernel: [drm] register mmio base: 0xE800 kernel: [drm] register mmio size: 65536 kernel: radeon :f1:00.0: Invalid ROM contents kernel: ATOM BIOS: X1650PRO kernel: [drm] Generation 2 PCI interface, using max accessible memory kernel: radeon :f1:00.0: VRAM: 512M 0x - 0x1FFF (512M used) kernel: radeon :f1:00.0: GTT: 512M 0x2000 - 0x3FFF kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). kernel: [drm] Driver supports precise vblank timestamp query. kernel: [drm] radeon: irq initialized. kernel: [drm] Detected VRAM RAM=512M, BAR=256M kernel: [drm] RAM width 128bits DDR kernel: [TTM] Zone kernel: Available graphics memory: 1003018 kiB. kernel: [TTM] Initializing pool allocator. kernel: [drm] radeon: 512M of VRAM memory ready kernel: [drm] radeon: 512M of GTT memory ready. kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072 kernel: [drm] radeon: 1 quad pipes, 2 z pipes initialized. kernel: [drm] PCIE GART of 512M enabled (table at 0x0004). kernel: radeon :f1:00.0: WB disabled kernel: [drm] Loading R500 Microcode kernel: [drm] radeon: ring at 0x20001000 kernel: [drm] ring test succeeded in 6 usecs kernel: [drm] radeon: ib pool ready. kernel: [drm] ib test succeeded in 0 usecs kernel: [drm] Radeon Display Connectors kernel: [drm] Connector 0: kernel: [drm] DVI-I kernel: [drm] HPD1 kernel: [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c kernel: [drm] Encoders: kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1 kernel: [drm] DFP1: INTERNAL_KLDSCP_TMDS1 kernel: [drm] Connector 1: kernel: [drm] S-video kernel: [drm] Encoders: kernel: [drm] TV1: INTERNAL_KLDSCP_DAC2 kernel: [drm] Connector 2: kernel: [drm] DVI-I kernel: [drm] HPD2 kernel: [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c kernel: [drm] Encoders: kernel: [drm] CRT2: INTERNAL_KLDSCP_DAC2 kernel: [drm] DFP3: INTERNAL_LVTM1 kernel: [drm] Possible lm63 thermal controller at 0x4c kernel: [drm] fb mappable at 0xC00C kernel: [drm] vram apper at 0xC000 kernel: [drm] size 9216000 kernel: [drm] fb depth is 24 kernel: [drm]pitch is 7680 kernel: checking generic (c000 14) vs hw (c000 1000) kernel: fb: conflicting fb hw usage radeondrmfb vs OFfb vga,Displa - removing generic driver kernel: fb1: radeondrmfb frame buffer device Hmm, I think this should say fb0, but that should only matter for console, not X. kernel: drm: registered panic notifier kernel: [drm] Initialized radeon 2.8.0 20080528 for :f1:00.0 on minor 0 kernel: [drm:drm_mode_getfb] *ERROR* invalid framebuffer id BTW, if your kernel contains commit 69a07f0b117a40fcc1a479358d8e1f41793617f2, can you try if reverting that helps? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
On Die, 2011-04-12 at 14:00 +0200, Gabriel Paubert wrote: On Tue, Apr 12, 2011 at 01:46:10PM +0200, Michel Dänzer wrote: With no_wb=1 the driver goes a bit further but the X server ends up in an infinite ioctl loop and the logs are: Which ioctl does it loop on? Please provide the Xorg.0.log file as well. From memory, the code was 0x64, which is DRM_RADEON_GEM_WAIT_IDLE. Note that it's normal for this ioctl to be called every time before the GPU accessible pixmap memory is accessed by the CPU. Unless the ioctl always returns an error, this may not indicate a problem on its own. The Xorg.0.log from the previous boot is attached. I don't see any obvious problems in it. Can you describe the symptoms of the problem you're having with X a bit more? One thing I notice is that the X server/driver are rather oldish. Maybe you can try newer versions from testing, sid or even experimental to see if that makes any difference. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
[ Adding the dri-devel list ] On Mon, 2011-04-11 at 15:31 +0200, Gabriel Paubert wrote: On Thu, Apr 07, 2011 at 04:04:35PM +0200, Michel Dänzer wrote: On Mit, 2011-04-06 at 22:43 +0200, Gabriel Paubert wrote: The probem is that, at least on one of my machines, the new driver does not work: the system hangs (apparently solid, but it's before networking starts up and I've not yet hooked up a serial console), after the radeon: ib pool ready message. Does radeon.agpmode=-1 radeon.no_wb=1 help? You might be able to get more information via netconsole if you prevent the radeon module from loading automatically (or load it with radeon.modeset=0 first) and then load it e.g. via ssh with modeset=1. Loading the module with modeset=1 results in insmod blocked in kernel state (not consuming CPU cycles either). The last kernel message is always the same (ib pool ready). This seems to be independent of agpmode and no_wb. The kernel messages when loading the driver are: kernel: [drm] radeon kernel modesetting enabled. kernel: checking generic (c000 14) vs hw (c000 1000) kernel: fb: conflicting fb hw usage radeondrmfb vs OFfb vga,Displa - removing generic driver kernel: [drm] initializing kernel modesetting (RV530 0x1002:0x71C7). kernel: radeon :f1:00.0: Using 64-bit DMA iommu bypass kernel: [drm] register mmio base: 0xE800 kernel: [drm] register mmio size: 65536 kernel: radeon :f1:00.0: Invalid ROM contents kernel: ATOM BIOS: X1650PRO kernel: [drm] Generation 2 PCI interface, using max accessible memory kernel: radeon :f1:00.0: VRAM: 512M 0x - 0x1FFF (512M used) kernel: radeon :f1:00.0: GTT: 512M 0x2000 - 0x3FFF kernel: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). kernel: [drm] Driver supports precise vblank timestamp query. kernel: irq: irq 9 on host /mpic mapped to virtual irq 24 kernel: u3msi: allocated virq 0x18 (hw 0x9) addr 0xf8004090 kernel: radeon :f1:00.0: radeon: using MSI. Have you ruled out any MSI related problems? I think the IRQ not working could explain the symptoms... kernel: [drm] radeon: irq initialized. kernel: [drm] Detected VRAM RAM=512M, BAR=256M kernel: [drm] RAM width 128bits DDR kernel: [TTM] Zone kernel: Available graphics memory: 1002914 kiB. kernel: [TTM] Initializing pool allocator. kernel: [drm] radeon: 512M of VRAM memory ready kernel: [drm] radeon: 512M of GTT memory ready. kernel: [drm] GART: num cpu pages 131072, num gpu pages 131072 kernel: [drm] radeon: 1 quad pipes, 2 z pipes initialized. kernel: [drm] PCIE GART of 512M enabled (table at 0x0004). kernel: radeon :f1:00.0: WB enabled Make sure this line changes to 'WB disabled' with no_wb=1. There's a writeback endianness bug with modeset=1, see http://lists.freedesktop.org/archives/dri-devel/2011-April/009960.html . kernel: [drm] Loading R500 Microcode kernel: [drm] radeon: ring at 0x20001000 kernel: [drm] ring test succeeded in 6 usecs kernel: [drm] radeon: ib pool ready. For now, with modeset=0, agpmode=-1 and no_wb=1, the driver seems to work. The agpmode and no_wb options only have an effect with modeset=1, and you don't seem to be using AGP anyway. :) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
On Mit, 2011-04-06 at 22:43 +0200, Gabriel Paubert wrote: The probem is that, at least on one of my machines, the new driver does not work: the system hangs (apparently solid, but it's before networking starts up and I've not yet hooked up a serial console), after the radeon: ib pool ready message. Does radeon.agpmode=-1 radeon.no_wb=1 help? You might be able to get more information via netconsole if you prevent the radeon module from loading automatically (or load it with radeon.modeset=0 first) and then load it e.g. via ssh with modeset=1. It would be interesting to see at least all agp/drm/radeon related kernel messages before the problem occurs. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
On Die, 2011-04-05 at 01:52 +0200, Gabriel Paubert wrote: Actually I thought that the name radeon_cp that is registered there would appear somwhere under /sys (or /proc) but failed to find it... FWIW the radeon_cp* functions are in drivers/gpu/drm/radeon. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PMU_IOC_SLEEP failed
On Die, 2010-12-28 at 13:25 +0100, jjDaNiMoTh wrote: what could be the problem here? [r...@myhost ~]# /usr/lib/hal/hal-system-power-pmu sleep power-pmu : PMU_IOC_SLEEP failed (same with pm-suspend, kernel version: any = 2.6.33. I'm now on a .37-rc). KMS is disabled (modprobe radeon modeset=0, and I can't switch over VT). What exactly does can't switch over VT mean? Sleep requires radeonfb, is that enabled? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Introduce support for little endian PowerPC
On Sam, 2010-10-02 at 06:50 +1000, Benjamin Herrenschmidt wrote: On Fri, 2010-10-01 at 18:20 +0200, Michel Dänzer wrote: On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote: Now, the main reasons in practice are anything touching graphics. There's quite a few IP cores out there for SoCs that don't have HW swappers, and -tons- of more or less ugly code that can't deal with non native pixel ordering (hell, even Xorg isn't good at it, we really only support cards that have HW swappers today). That's not true. Even the radeon driver doesn't really need the HW swappers anymore with KMS. And last I looked X still pukes if you give it a pixmap in non native byte order but that might have been fixed. I'm not sure what exactly you mean by that, but I'm not aware of any such issues offhand. There's an even bigger pile of application code that deals with graphics without any regard for endianness and is essentially unfixable. Out of curiosity, what kind of APIs are those apps using? X11 and OpenGL have well-defined semantics wrt endianness, allowing the drivers to handle any necessary byte swapping internally, and IME the vast majority of apps handle this correctly. So why is it so hard to get any video card working on ppc ? :-) I didn't say anything about that, just that IME it should be mostly possible to deal with endianness within the driver stack. Note that I'm not arguing against these changes, just pointing out some apparent inaccuracies in the reasoning for them. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Introduce support for little endian PowerPC
On Fre, 2010-10-01 at 22:14 +1000, Benjamin Herrenschmidt wrote: Now, the main reasons in practice are anything touching graphics. There's quite a few IP cores out there for SoCs that don't have HW swappers, and -tons- of more or less ugly code that can't deal with non native pixel ordering (hell, even Xorg isn't good at it, we really only support cards that have HW swappers today). That's not true. Even the radeon driver doesn't really need the HW swappers anymore with KMS. There's an even bigger pile of application code that deals with graphics without any regard for endianness and is essentially unfixable. Out of curiosity, what kind of APIs are those apps using? X11 and OpenGL have well-defined semantics wrt endianness, allowing the drivers to handle any necessary byte swapping internally, and IME the vast majority of apps handle this correctly. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 16:03 +0200, jjDaNiMoTh wrote: When trying new 2.6.35-rc4, our kernel team (ArchLinuxPPC) has tried to setup KMS acceleration for radeon based machine. We have removed radeonfb, and all others framebuffer driver, and added fbcon and KMS enabled by default for radeon driver. With a clean start, the screen freeze, when the control pass from yaboot to kernel. If we start with video=fbcon (or video=radeondrmfb), we could reach the loading modules point, [...] Which framebuffer device (if any) is it trying to initialize otherwise? OFfb? The first paragraph above implies none, but then I'm not sure why the video= parameters would make any difference. Jul 13 15:31:39 jim kernel: [drm] Initialized drm 1.1.0 20060810 Jul 13 15:31:39 jim kernel: [drm] radeon kernel modesetting enabled. Jul 13 15:31:39 jim kernel: [drm] initializing kernel modesetting (RV350 0x1002:0x4E50). Jul 13 15:31:39 jim kernel: [drm] register mmio base: 0xB000 Jul 13 15:31:39 jim kernel: [drm] register mmio size: 65536 Jul 13 15:31:39 jim kernel: [drm] Using generic clock info Jul 13 15:31:39 jim kernel: agpgart-uninorth :00:0b.0: putting AGP V2 device into 4x mode Jul 13 15:31:39 jim kernel: radeon :00:10.0: putting AGP V2 device into 4x mode Jul 13 15:31:39 jim kernel: radeon :00:10.0: GTT: 256M 0x - 0x0FFF Jul 13 15:31:39 jim kernel: [drm] Generation 2 PCI interface, using max accessible memory Jul 13 15:31:39 jim kernel: radeon :00:10.0: VRAM: 64M 0xB800 - 0xBBFF (64M used) Jul 13 15:31:39 jim kernel: [drm] radeon: irq initialized. Jul 13 15:31:39 jim kernel: [drm] Detected VRAM RAM=64M, BAR=128M Jul 13 15:31:39 jim kernel: [drm] RAM width 128bits DDR Jul 13 15:31:39 jim kernel: [TTM] Zone kernel: Available graphics memory: 384990 kiB. Jul 13 15:31:39 jim kernel: [TTM] Zone highmem: Available graphics memory: 516062 kiB. Jul 13 15:31:39 jim kernel: [TTM] Initializing pool allocator. Jul 13 15:31:39 jim kernel: [drm] radeon: 64M of VRAM memory ready Jul 13 15:31:39 jim kernel: [drm] radeon: 256M of GTT memory ready. Jul 13 15:31:39 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. Jul 13 15:31:39 jim kernel: [drm] Loading R300 Microcode Jul 13 15:31:39 jim kernel: [drm] radeon: ring at 0x Jul 13 15:31:39 jim kernel: [drm] ring test succeeded in 3 usecs Jul 13 15:31:39 jim kernel: [drm] radeon: ib pool ready. So far, so good. Jul 13 15:31:40 jim kernel: GPU lockup (waiting for 0x0001 last fence id 0x) The GPU locks up, and things go downhill from there... Does KMS work better with radeon.agpmode=1 (or 2 or -1)? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 16:51 +0200, jjDaNiMoTh wrote:
2010/7/13 Michel Dänzer mic...@daenzer.net:
Does KMS work better with radeon.agpmode=1 (or 2 or -1)?
with radeon.agpmode=-1, we could start X server (no black screen),
with both radeon.modeset={0,1}.
Note that radeon.agpmode is only effective with radeon.modeset=1,
otherwise you need to use Option AGPMode in xorg.conf (and vice
versa).
In all cases, Xorg works fine, except when we try to load an OpenGL
application (like glxgears), Xorg freeze, we could move only the
mouse, we couldn't switch to a backup console.
Could be a GPU lockup again, possibly due to still using AGP 4x with
modeset=0.
Same situations with glxgears in both modeset=0 and =1. In the log
(Xorg.0.log) we have found:
[.. other xorg log, no EE only WW]
[65.238] (II) RADEON(0): Panel infos found from DDC detailed: 1280x854
[65.238] (II) RADEON(0): EDID vendor APP, prod id 39968
[65.249] (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
[65.249] Unhandled monitor type 0
[65.249] (II) RADEON(0): Output: S-video, Detected Monitor Type: 0
[ 137.813] [mi] EQ overflowing. The server is probably stuck in an
infinite loop.
[ 137.813]
Backtrace:
[ 137.814] 0: /usr/bin/X (xorg_backtrace+0x58) [0x100582cc]
[ 137.814] 1: /usr/bin/X (mieqEnqueue+0x1c8) [0x1004e5d8]
[ 137.814] 2: /usr/bin/X (xf86PostButtonEventP+0xf4) [0x10061be8]
[ 137.814] 3: /usr/bin/X (xf86PostButtonEvent+0xb4) [0x10061d2c]
[ 137.814] 4: /usr/lib/xorg/modules/input/evdev_drv.so
(0xf38+0x3d88) [0xf383d88]
[ 137.814] 5: /usr/bin/X (0x1000+0x68784) [0x10068784]
[ 137.814] 6: /usr/bin/X (0x1000+0x11a7e4) [0x1011a7e4]
[ 137.814] 7: (vdso) (__kernel_sigtramp32+0x0) [0x100344]
[ 137.814] 8: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x48534) [0xf43d534]
[ 137.814] 9: /usr/lib/libdrm.so.2 (drmIoctl+0x40) [0xf8b8f64]
[ 137.814] 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x24) [0xf8bbe60]
[ 137.814] 11: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x46944) [0xf43b944]
[ 137.814] 12: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x64d8c) [0xf459d8c]
[ 137.814] 13: /usr/lib/xorg/modules/extensions/libglx.so
(0xf93+0x40f78) [0xf970f78]
[ 137.814] 14: /usr/lib/xorg/modules/extensions/libglx.so
(0xf93+0x44be4) [0xf974be4]
[ 137.814] 15: /usr/bin/X (0x1000+0x34a24) [0x10034a24]
[ 137.815] 16: /usr/bin/X (0x1000+0x18bc4) [0x10018bc4]
[ 137.815] 17: /lib/libc.so.6 (0xfb39000+0x1f544) [0xfb58544]
[ 137.815] 18: /lib/libc.so.6 (0xfb39000+0x1f6d0) [0xfb586d0]
What does the log file contain with modeset=1?
Do we need to compile mesa, ati-dri, x.org and xf86-video-ati from git?
Shouldn't be necessary.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 18:02 +0200, jjDaNiMoTh wrote: 2010/7/13 Michel Dänzer mic...@daenzer.net: What does the log file contain with modeset=1? We have no message, after the X.org freeze. messages.log: [...] Jul 13 17:11:01 jim kernel: [drm] Num pipes: 1 Jul 13 17:13:39 jim kernel: Using PowerMac machine description (we have rebooted) In Xorg.0.log there aren't information after the crash, only a right startup. Are you looking at the right log file, not the one from the new X server after the reboot? Maybe you could post the full dmesg, Xorg.0.log and X server stderr output (should be captured in the gdm/kdm log file) from trying with modeset=1. At this time, I think it isn't a kernel problem, am I right? With modeset=1 it most likely is a kernel (configuration) problem. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
On Die, 2010-07-13 at 19:05 +0200, jjDaNiMoTh wrote: So, I've now the acceleration. The main problem was radeon.agpmode, setting it to -1 (and removing all files in xorg.conf.d related to radeon) fixes all issue (also the freeze on glxgears). Now I have ~1500 FPS, and I'm fine with it (before I got 100 FPS). I get the acceleration also with a non-KMS capable kernel, so I think we got the point. I will add the option to modprobe.conf for archPPC. Note that e.g. on my PowerBook agpmode=1 works (mostly) stable, and if AGP works it performs significantly better than PCI. I tried a program which use a lot opengl, the only thing I see is ERROR: GL error 1282 ERROR: Ignoring 1 openGL errors Something the app does causes Mesa to raise a GL_INVALID_OPERATION error. This may be a bug in the app or in Mesa. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] agp/uninorth: Fix oops caused by flushing too much
On Mit, 2010-06-02 at 15:33 +1000, Paul Mackerras wrote: This fixes a sporadic oops at boot on G5 Power Macs. The table_end variable has the address of the last byte of the table. Adding on PAGE_SIZE means we flush too much, and if the page after the table is not mapped for any reason, the kernel will oops. Instead we add on 1 because flush_dcache_range() interprets its second argument as the first byte past the range to be flushed. Signed-off-by: Paul Mackerras pau...@samba.org Reviewed-by: Michel Dänzer mic...@daenzer.net Tested-by: Michel Dänzer mic...@daenzer.net Thanks for the good catch, Paul. --- diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c index 6f48931..9aaa0eb 100644 --- a/drivers/char/agp/uninorth-agp.c +++ b/drivers/char/agp/uninorth-agp.c @@ -413,7 +413,7 @@ static int uninorth_create_gatt_table(struct agp_bridge_data *bridge) bridge-gatt_table_real = (u32 *) table; /* Need to clear out any dirty data still sitting in caches */ flush_dcache_range((unsigned long)table, -(unsigned long)(table_end + PAGE_SIZE)); +(unsigned long)table_end + 1); bridge-gatt_table = vmap(pages, (1 page_order), 0, PAGE_KERNEL_NCG); if (bridge-gatt_table == NULL) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Xorg on Fujitsu Lime with MPC5200b?
On Fre, 2010-04-16 at 08:14 +0200, Roman Fietze wrote: On Thursday 15 April 2010 18:07:03 Bill Gatliff wrote: I would love it if you posted your code! Thanks!! In this source file I just added my own routines: Index: programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c === --- programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c (revision 6) +++ programs/Xserver/hw/xfree86/drivers/fbdev/fbdev.c (revision 7) @@ -139,8 +139,8 @@ shadowInit, shadowSetup, shadowUpdatePacked, - shadowUpdatePackedSwapped16Weak, - shadowUpdatePackedSwapped32Weak, + shadowUpdatePackedSwapped16, + shadowUpdatePackedSwapped32, shadowUpdateRotatePacked, NULL }; @@ -619,6 +619,7 @@ ScrnInfoPtr pScrn = xf86Screens[pScreen-myNum]; FBDevPtr fPtr = FBDEVPTR(pScrn); VisualPtr visual; + ShadowUpdateProc pupdate; int init_picture = 0; int ret,flags,width,height; @@ -794,7 +795,7 @@ xf86DrvMsg(pScrn-scrnIndex, X_WARNING, RENDER extension initialisation failed.\n); - pupdate = pScrn-bitsPerPixel 16 ? shadowUpdatePackedSwapped32Weak() : shadowUpdatePackedSwapped16Weak(); + pupdate = pScrn-bitsPerPixel 16 ? shadowUpdatePackedSwapped32 : shado wUpdatePackedSwapped16; if (fPtr-shadowFB (!shadowSetup(pScreen) || !shadowAdd(pScreen, NULL, I hope you're aware that this really just hacks around the kernel framebuffer device not exposing the framebuffer to userspace according to the fbdev interface (see struct fb_bitfield in /usr/include/linux/fb.h), and this will affect everything else using the framebuffer device as well. It would be better to handle this in the kernel framebuffer device, either via hardware byte swapping facilities if available, or otherwise e.g. via FB_DEFERRED_IO. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] No otheros feature on new PS3 slim ?
On Fri, 2010-02-26 at 12:30 +, David Woodhouse wrote: On Fri, 2009-08-21 at 09:58 -0700, geoffrey.lev...@am.sony.com wrote: The feature of Install Other OS was removed from the new Slim PS3 model to focus on delivering games and other entertainment content. Please be assured that SCE is committed to continue the support for previously sold models that have the Install Other OS feature and that this feature will not be disabled in future firmware releases. Although it's disappointing that Sony have removed the feature from new models, It's good to have this public assurance from Sony that at least the feature won't be removed from older models which are already working. I suppose it shouldn't be too much of a surprise -- if people have bought PS3s specifically to use the advertised 'OtherOS' feature and Sony were to break that with a firmware update, then there may well be legal ramifications. But it's nice to have the promise in writing anyway. Unfortunately, it wasn't enough - firmware version 3.21 completely removes 'other OS' support due to 'security concerns'. :( http://blog.us.playstation.com/2010/03/28/ps3-firmware-v3-21-update/ -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Booting headless PowerMac G5
On Fri, 2010-03-26 at 11:20 +0100, Romain Goyet wrote: 2010/3/25 Michel Dänzer mic...@daenzer.net: On Wed, 2010-03-24 at 11:32 +0100, Romain Goyet wrote: By the way, as of writing this, grub2 on PPC from debian gives a out of memory issue. Known bug. That's on the G5? It's working on my PowerBook, but I haven't updated the grub2 binaries on the bootstrap partition in a while... Yeah, that's on a PowerMac QuadG5. I think that's a known issue : http://www.mail-archive.com/grub-de...@gnu.org/msg04455.html However it might be another one since it's working for you. I'm using grub2 from Debian stable. According to http://packages.debian.org/stable/grub2 that's version 1.96 +20080724-16, which is pretty old. Current in sid is 1.98, and it's only become usable for me in the course of the last year or so. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Booting headless PowerMac G5
On Wed, 2010-03-24 at 11:32 +0100, Romain Goyet wrote: Here's a summary about how to boot a PowerMac G5 without a screen attached. As many people have noticed, default yaboot install won't boot unless a screen is attached. Actually, the workaround is really simple. Thing is, that's the ofboot.b script that messes things up. This script is a bridge, that actually either starts yaboot or let you boot off of a CD. I don't know what's the point, since OpenFirmware already lets you boot off of the CD by pressing C on boot… So basically, to boot headless, all you have to do is to tell OpenFirmware to boot straight off the yaboot binary, and to skip the ofboot.b Just boot into OpenFirmware (Command-Option-O-F), and type : setenv boot-device hd:2,yaboot (where 2 is the number of the partition containing yaboot) boot And here you go, you can unplug that useless monitor :-) References : http://saintaardvarkthecarpeted.com/blog/archive/2005/02/THE_WINE_OF_BOOT.html http://grub.enbug.org/TestingOnPowerPC That's good to know, thanks. By the way, as of writing this, grub2 on PPC from debian gives a out of memory issue. Known bug. That's on the G5? It's working on my PowerBook, but I haven't updated the grub2 binaries on the bootstrap partition in a while... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] agp/uninorth: Also handle user memory types in u3_remove_memory().
From: Michel Dänzer daen...@vmware.com
Also short-circuit empty updates.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c | 29 ++---
1 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 703959e..4e05021 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -151,9 +151,6 @@ static int uninorth_insert_memory(struct agp_memory *mem,
off_t pg_start,
void *temp;
int mask_type;
- temp = agp_bridge-current_size;
- num_entries = A_SIZE_32(temp)-num_entries;
-
if (type != mem-type)
return -EINVAL;
@@ -163,6 +160,12 @@ static int uninorth_insert_memory(struct agp_memory *mem,
off_t pg_start,
return -EINVAL;
}
+ if (mem-page_count == 0)
+ return 0;
+
+ temp = agp_bridge-current_size;
+ num_entries = A_SIZE_32(temp)-num_entries;
+
if ((pg_start + mem-page_count) num_entries)
return -EINVAL;
@@ -194,9 +197,6 @@ static int u3_insert_memory(struct agp_memory *mem, off_t
pg_start, int type)
u32 *gp;
int mask_type;
- temp = agp_bridge-current_size;
- num_entries = A_SIZE_32(temp)-num_entries;
-
if (type != mem-type)
return -EINVAL;
@@ -206,6 +206,12 @@ static int u3_insert_memory(struct agp_memory *mem, off_t
pg_start, int type)
return -EINVAL;
}
+ if (mem-page_count == 0)
+ return 0;
+
+ temp = agp_bridge-current_size;
+ num_entries = A_SIZE_32(temp)-num_entries;
+
if ((pg_start + mem-page_count) num_entries)
return -EINVAL;
@@ -234,10 +240,19 @@ int u3_remove_memory(struct agp_memory *mem, off_t
pg_start, int type)
{
size_t i;
u32 *gp;
+ int mask_type;
+
+ if (type != mem-type)
+ return -EINVAL;
- if (type != 0 || mem-type != 0)
+ mask_type = agp_bridge-driver-agp_type_to_mask_type(agp_bridge, type);
+ if (mask_type != 0) {
/* We know nothing of memory types */
return -EINVAL;
+ }
+
+ if (mem-page_count == 0)
+ return 0;
gp = (u32 *) agp_bridge-gatt_table[pg_start];
for (i = 0; i mem-page_count; ++i)
--
1.6.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] agp/uninorth: Unify U3 and pre-U3 insert_memory and remove_memory hooks.
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c | 64 +++
1 files changed, 11 insertions(+), 53 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 4e05021..d89da4a 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -144,53 +144,7 @@ static int uninorth_configure(void)
return 0;
}
-static int uninorth_insert_memory(struct agp_memory *mem, off_t pg_start,
- int type)
-{
- int i, j, num_entries;
- void *temp;
- int mask_type;
-
- if (type != mem-type)
- return -EINVAL;
-
- mask_type = agp_bridge-driver-agp_type_to_mask_type(agp_bridge, type);
- if (mask_type != 0) {
- /* We know nothing of memory types */
- return -EINVAL;
- }
-
- if (mem-page_count == 0)
- return 0;
-
- temp = agp_bridge-current_size;
- num_entries = A_SIZE_32(temp)-num_entries;
-
- if ((pg_start + mem-page_count) num_entries)
- return -EINVAL;
-
- j = pg_start;
-
- while (j (pg_start + mem-page_count)) {
- if (agp_bridge-gatt_table[j])
- return -EBUSY;
- j++;
- }
-
- for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
- agp_bridge-gatt_table[j] =
- cpu_to_le32((page_to_phys(mem-pages[i])
0xF000UL) | 0x1UL);
- flush_dcache_range((unsigned
long)__va(page_to_phys(mem-pages[i])),
- (unsigned
long)__va(page_to_phys(mem-pages[i]))+0x1000);
- }
- (void)in_le32((volatile u32*)agp_bridge-gatt_table[pg_start]);
- mb();
-
- uninorth_tlbflush(mem);
- return 0;
-}
-
-static int u3_insert_memory(struct agp_memory *mem, off_t pg_start, int type)
+static int uninorth_insert_memory(struct agp_memory *mem, off_t pg_start, int
type)
{
int i, num_entries;
void *temp;
@@ -219,14 +173,18 @@ static int u3_insert_memory(struct agp_memory *mem, off_t
pg_start, int type)
for (i = 0; i mem-page_count; ++i) {
if (gp[i]) {
dev_info(agp_bridge-dev-dev,
-u3_insert_memory: entry 0x%x occupied (%x)\n,
+uninorth_insert_memory: entry 0x%x occupied
(%x)\n,
i, gp[i]);
return -EBUSY;
}
}
for (i = 0; i mem-page_count; i++) {
- gp[i] = (page_to_phys(mem-pages[i]) PAGE_SHIFT) |
0x8000UL;
+ if (is_u3)
+ gp[i] = (page_to_phys(mem-pages[i]) PAGE_SHIFT) |
0x8000UL;
+ else
+ gp[i] = cpu_to_le32((page_to_phys(mem-pages[i])
0xF000UL) |
+ 0x1UL);
flush_dcache_range((unsigned
long)__va(page_to_phys(mem-pages[i])),
(unsigned
long)__va(page_to_phys(mem-pages[i]))+0x1000);
}
@@ -236,7 +194,7 @@ static int u3_insert_memory(struct agp_memory *mem, off_t
pg_start, int type)
return 0;
}
-int u3_remove_memory(struct agp_memory *mem, off_t pg_start, int type)
+int uninorth_remove_memory(struct agp_memory *mem, off_t pg_start, int type)
{
size_t i;
u32 *gp;
@@ -551,7 +509,7 @@ const struct agp_bridge_driver uninorth_agp_driver = {
.create_gatt_table = uninorth_create_gatt_table,
.free_gatt_table= uninorth_free_gatt_table,
.insert_memory = uninorth_insert_memory,
- .remove_memory = agp_generic_remove_memory,
+ .remove_memory = uninorth_remove_memory,
.alloc_by_type = agp_generic_alloc_by_type,
.free_by_type = agp_generic_free_by_type,
.agp_alloc_page = agp_generic_alloc_page,
@@ -577,8 +535,8 @@ const struct agp_bridge_driver u3_agp_driver = {
.agp_enable = uninorth_agp_enable,
.create_gatt_table = uninorth_create_gatt_table,
.free_gatt_table= uninorth_free_gatt_table,
- .insert_memory = u3_insert_memory,
- .remove_memory = u3_remove_memory,
+ .insert_memory = uninorth_insert_memory,
+ .remove_memory = uninorth_remove_memory,
.alloc_by_type = agp_generic_alloc_by_type,
.free_by_type = agp_generic_free_by_type,
.agp_alloc_page = agp_generic_alloc_page,
--
1.6.5.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: term_adt746x: Invert bit required on this Powerbook G4
[ Resending with linuxppc-dev list domain fixed ] On Wed, 2009-11-04 at 13:23 +0100, Max Vozeler wrote: I installed Ubuntu 8.10 on this Powerbook G4 (alu I think) for a friend of mine. As soon as therm_adt746x got loaded, the fan turned into a noise steam engine. This was on Ubuntu's 2.6.31 kernel (2.6.31-14-powerpc) which includes 0512a9a8e277a9de2. I could reproduce it with latest mainline as well. The effect was just as Michel described in the changelog; The fan was running while temps were well below any of the limits, and it stopped only when I set ridiculously low limits. [ 1087.141482] adt746x: version 1 (supported) [ 1087.141495] adt746x: Thermostat bus: 1, address: 0x2e, limit_adjust: 0, fan_speed: -1 [ 1087.141503] sensor 0: HDD BOTTOMSIDE [ 1087.141507] sensor 1: CPU TOPSIDE [ 1087.141512] sensor 2: GPU ON DIE [ 1087.161365] adt746x: ADT7460 initializing [ 1087.165245] adt746x: Lowering max temperatures from 73, 80, 109 to 70, 50, 70 [ 1087.165261] adt746x: Setting speed to 0 for CPU TOPSIDE fan. [ 1087.166302] adt746x: Setting speed to 0 for GPU ON DIE fan. (What worked was limit_adjust=-30, fan did turn off, but so did the Powerbook shortly after, despite being cold.) After some poking around, in which everything seemed to be according to plan including write of 0 to both FAN_SPD_SET regs, I noticed that explicitly *setting* the invert bit as in -write_reg(th, MANUAL_MODE[fan], -(manual|MANUAL_MASK) (~INVERT_MASK)); +write_reg(th, MANUAL_MODE[fan], +(manual|MANUAL_MASK|INVERT_MASK)); seems to cure it. The fan appears to behave normally now, it turns on slowly when the temp limits are reached, otherwise it stays off. The temperature is reasonable (ie, no too hot). So, puzzeled, I checked the spec, and it appears very clear on the question of invert: It should be off by default. Right, that's what I based my patch on. However, it sounds like your PowerBook model (mine is a PowerBook5,8) is wired up such that the invert bit needs to be enabled. I can think of two basic approaches for dealing with this offhand: * Set or clear the invert bit depending on the machine model or whatever is relevant. * Save the bit value during initialization and preserve it whenever writing to the register. Or maybe even add proper suspend/resume hooks which save/restore all hardware state, it seems like it may be luck that the current code works more or less for suspend/resume. I'm not too interested in working on this anymore and I definitely won't have time this or next week, anyone feel free to take it on. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SMU-base PowerMac and server_mode
On Tue, 2009-10-06 at 11:16 +0200, Romain Goyet wrote: I have this Quad G5 here, running GentooPPC64. Runs fine. Had a hard time getting it to boot without a screen attached, but I eventually managed to (yaboot was the culprit). Out of curiosity, how did you solve this? I still have an unused monitor connected to mine... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SMU-base PowerMac and server_mode
On Tue, 2009-10-06 at 13:44 +0200, Romain Goyet wrote: Acutally I didn't figure it out by myself : http://saintaardvarkthecarpeted.com/blog/archive/2005/02/THE_WINE_OF_BOOT.html However, here's my 2 cents about it : 1/ The fix (removing screen line in ofboot.b on yaboot partition) doesn't work with all versions of the yaboot binary. Works with the one from Debian. Doesn't with yaboot-static on GentooPPC64. But you still can fetch the right binary from the .deb archive No need, see my .sig. :) Thanks for the pointer, I failed to find the above when I googled about this a while ago. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
On Wed, 2009-09-16 at 07:51 +1000, Benjamin Herrenschmidt wrote: On Tue, 2009-09-15 at 09:53 -0700, Linus Torvalds wrote: It got a conflict with the AGP merge, but I fixed it up in what _seemed_ to be the obvious manner. But somebody should check out the resulting drivers/char/agp/uninorth-agp.c file. Thanks. Michel, can you dbl check it ? Looks good to me, thanks. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] agp/uninorth: Unify U3 and pre-U3 insert_memory and remove_memory hooks.
On Thu, 2009-08-13 at 17:05 +1000, Benjamin Herrenschmidt wrote:
On Tue, 2009-08-04 at 23:51 +0200, Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
Hi Michel !
While your two previous patches apply just fine, this one doesn't,
the uninorth_insert_memory() function seems to be slightly different
upstream. Does this depend on some separate yet unapplied patches ?
I previously sent the attached patches to Dave in the course of the
radeon KMS issues thread. Not sure which of these he's picked up yet, if
any.
I'm putting 1/3 and 2/3 into my -test branch and they should hit my
-next branch in a couple of days.
Or do you prefer us to merge that via Dave ?
The thing is, stuff in -powerpc is much more likely to get some amount
of testing on actual ppc hardware than stuff in random other trees :-)
I'm fine with either way.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
From b73acc1a48cbea4d9ba9caa41451b38223bed516 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michel=20D=C3=A4nzer?= daen...@vmware.com
Date: Thu, 13 Aug 2009 08:42:36 +0200
Subject: [PATCH] uninorth: Handle user memory types.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 03f95ec..880d3f6 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -146,13 +146,20 @@ static int uninorth_insert_memory(struct agp_memory *mem, off_t pg_start,
{
int i, j, num_entries;
void *temp;
+ int mask_type;
temp = agp_bridge-current_size;
num_entries = A_SIZE_32(temp)-num_entries;
- if (type != 0 || mem-type != 0)
+ if (type != mem-type)
+ return -EINVAL;
+
+ mask_type = agp_bridge-driver-agp_type_to_mask_type(agp_bridge, type);
+ if (mask_type != 0) {
/* We know nothing of memory types */
return -EINVAL;
+ }
+
if ((pg_start + mem-page_count) num_entries)
return -EINVAL;
@@ -184,13 +191,20 @@ static int u3_insert_memory(struct agp_memory *mem, off_t pg_start, int type)
int i, num_entries;
void *temp;
u32 *gp;
+ int mask_type;
temp = agp_bridge-current_size;
num_entries = A_SIZE_32(temp)-num_entries;
- if (type != 0 || mem-type != 0)
+ if (type != mem-type)
+ return -EINVAL;
+
+ mask_type = agp_bridge-driver-agp_type_to_mask_type(agp_bridge, type);
+ if (mask_type != 0) {
/* We know nothing of memory types */
return -EINVAL;
+ }
+
if ((pg_start + mem-page_count) num_entries)
return -EINVAL;
--
1.6.3.3
From 0e4f25a616fdb5136372ab0523a43af39ff7fcd6 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michel=20D=C3=A4nzer?= daen...@vmware.com
Date: Thu, 13 Aug 2009 08:42:38 +0200
Subject: [PATCH] uninorth: Also handle user memory types in u3_remove_memory().
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Also short-circuit empty updates.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c | 29 ++---
1 files changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 880d3f6..cd63d76 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -148,9 +148,6 @@ static int uninorth_insert_memory(struct agp_memory *mem, off_t pg_start,
void *temp;
int mask_type;
- temp = agp_bridge-current_size;
- num_entries = A_SIZE_32(temp)-num_entries;
-
if (type != mem-type)
return -EINVAL;
@@ -160,6 +157,12 @@ static int uninorth_insert_memory(struct agp_memory *mem, off_t pg_start,
return -EINVAL;
}
+ if (mem-page_count == 0)
+ return 0;
+
+ temp = agp_bridge-current_size;
+ num_entries = A_SIZE_32(temp)-num_entries;
+
if ((pg_start + mem-page_count) num_entries)
return -EINVAL;
@@ -193,9 +196,6 @@ static int u3_insert_memory(struct agp_memory *mem, off_t pg_start, int type)
u32 *gp;
int mask_type;
- temp = agp_bridge-current_size;
- num_entries = A_SIZE_32(temp)-num_entries;
-
if (type != mem-type)
return -EINVAL;
@@ -205,6 +205,12 @@ static int u3_insert_memory(struct agp_memory *mem, off_t pg_start, int type)
return -EINVAL;
}
+ if (mem-page_count == 0)
+ return 0;
+
+ temp = agp_bridge-current_size;
+ num_entries = A_SIZE_32(temp)-num_entries;
+
if ((pg_start + mem-page_count) num_entries)
return -EINVAL;
@@ -234,10 +240,19 @@ int u3_remove_memory(struct agp_memory *mem, off_t pg_start, int type)
{
size_t i;
u32 *gp;
+ int mask_type;
+
+ if (type != mem-type)
+ return -EINVAL;
- if (type != 0 || mem-type != 0)
+ mask_type = agp_bridge-driver-agp_type_to_mask_type(agp_bridge, type);
+ if (mask_type != 0) {
/* We know nothing of memory types */
return
[PATCH 2/3] agp/uninorth: Simplify cache flushing.
From: Michel Dänzer daen...@vmware.com
Map the GART table uncached, so we don't always need to flush the CPU caches
explicitly after updates.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c | 33 +
1 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index eed2195..bc8b43a 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -7,6 +7,7 @@
#include linux/pagemap.h
#include linux/agp_backend.h
#include linux/delay.h
+#include linux/vmalloc.h
#include asm/uninorth.h
#include asm/pci-bridge.h
#include asm/prom.h
@@ -184,8 +185,6 @@ static int uninorth_insert_memory(struct agp_memory *mem,
off_t pg_start,
}
(void)in_le32((volatile u32*)agp_bridge-gatt_table[pg_start]);
mb();
- flush_dcache_range((unsigned long)agp_bridge-gatt_table[pg_start],
- (unsigned long)agp_bridge-gatt_table[pg_start +
mem-page_count]);
uninorth_tlbflush(mem);
return 0;
@@ -232,7 +231,6 @@ static int u3_insert_memory(struct agp_memory *mem, off_t
pg_start, int type)
(unsigned
long)__va(page_to_phys(mem-pages[i]))+0x1000);
}
mb();
- flush_dcache_range((unsigned long)gp, (unsigned long) gp[i]);
uninorth_tlbflush(mem);
return 0;
@@ -260,7 +258,6 @@ int u3_remove_memory(struct agp_memory *mem, off_t
pg_start, int type)
for (i = 0; i mem-page_count; ++i)
gp[i] = 0;
mb();
- flush_dcache_range((unsigned long)gp, (unsigned long) gp[i]);
uninorth_tlbflush(mem);
return 0;
@@ -413,6 +410,7 @@ static int uninorth_create_gatt_table(struct
agp_bridge_data *bridge)
int i;
void *temp;
struct page *page;
+ struct page **pages;
/* We can't handle 2 level gatt's */
if (bridge-driver-size_type == LVL2_APER_SIZE)
@@ -441,21 +439,39 @@ static int uninorth_create_gatt_table(struct
agp_bridge_data *bridge)
if (table == NULL)
return -ENOMEM;
+ pages = kmalloc((1 page_order) * sizeof(struct page*), GFP_KERNEL);
+ if (pages == NULL)
+ goto enomem;
+
table_end = table + ((PAGE_SIZE * (1 page_order)) - 1);
- for (page = virt_to_page(table); page = virt_to_page(table_end);
page++)
+ for (page = virt_to_page(table), i = 0; page = virt_to_page(table_end);
+page++, i++) {
SetPageReserved(page);
+ pages[i] = page;
+ }
bridge-gatt_table_real = (u32 *) table;
- bridge-gatt_table = (u32 *)table;
+ /* Need to clear out any dirty data still sitting in caches */
+ flush_dcache_range((unsigned long)table,
+ (unsigned long)(table_end + PAGE_SIZE));
+ bridge-gatt_table = vmap(pages, (1 page_order), 0, PAGE_KERNEL_NCG);
+
+ if (bridge-gatt_table == NULL)
+ goto enomem;
+
bridge-gatt_bus_addr = virt_to_gart(table);
for (i = 0; i num_entries; i++)
bridge-gatt_table[i] = 0;
- flush_dcache_range((unsigned long)table, (unsigned long)table_end);
-
return 0;
+
+enomem:
+ kfree(pages);
+ if (table)
+ free_pages((unsigned long)table, page_order);
+ return -ENOMEM;
}
static int uninorth_free_gatt_table(struct agp_bridge_data *bridge)
@@ -473,6 +489,7 @@ static int uninorth_free_gatt_table(struct agp_bridge_data
*bridge)
* from the table.
*/
+ vunmap(bridge-gatt_table);
table = (char *) bridge-gatt_table_real;
table_end = table + ((PAGE_SIZE * (1 page_order)) - 1);
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] agp/uninorth: Unify U3 and pre-U3 insert_memory and remove_memory hooks.
From: Michel Dänzer daen...@vmware.com
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c | 64 +++
1 files changed, 11 insertions(+), 53 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index bc8b43a..75aa33a 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -144,53 +144,7 @@ static int uninorth_configure(void)
return 0;
}
-static int uninorth_insert_memory(struct agp_memory *mem, off_t pg_start,
- int type)
-{
- int i, j, num_entries;
- void *temp;
- int mask_type;
-
- if (type != mem-type)
- return -EINVAL;
-
- mask_type = agp_bridge-driver-agp_type_to_mask_type(agp_bridge, type);
- if (mask_type != 0) {
- /* We know nothing of memory types */
- return -EINVAL;
- }
-
- if (mem-page_count == 0)
- return 0;
-
- temp = agp_bridge-current_size;
- num_entries = A_SIZE_32(temp)-num_entries;
-
- if ((pg_start + mem-page_count) num_entries)
- return -EINVAL;
-
- j = pg_start;
-
- while (j (pg_start + mem-page_count)) {
- if (agp_bridge-gatt_table[j])
- return -EBUSY;
- j++;
- }
-
- for (i = 0, j = pg_start; i mem-page_count; i++, j++) {
- agp_bridge-gatt_table[j] =
- cpu_to_le32((page_to_phys(mem-pages[i])
0xF000UL) | 0x1UL);
- flush_dcache_range((unsigned
long)__va(page_to_phys(mem-pages[i])),
- (unsigned
long)__va(page_to_phys(mem-pages[i]))+0x1000);
- }
- (void)in_le32((volatile u32*)agp_bridge-gatt_table[pg_start]);
- mb();
-
- uninorth_tlbflush(mem);
- return 0;
-}
-
-static int u3_insert_memory(struct agp_memory *mem, off_t pg_start, int type)
+static int uninorth_insert_memory(struct agp_memory *mem, off_t pg_start, int
type)
{
int i, num_entries;
void *temp;
@@ -219,14 +173,18 @@ static int u3_insert_memory(struct agp_memory *mem, off_t
pg_start, int type)
for (i = 0; i mem-page_count; ++i) {
if (gp[i]) {
dev_info(agp_bridge-dev-dev,
-u3_insert_memory: entry 0x%x occupied (%x)\n,
+uninorth_insert_memory: entry 0x%x occupied
(%x)\n,
i, gp[i]);
return -EBUSY;
}
}
for (i = 0; i mem-page_count; i++) {
- gp[i] = (page_to_phys(mem-pages[i]) PAGE_SHIFT) |
0x8000UL;
+ if (is_u3)
+ gp[i] = (page_to_phys(mem-pages[i]) PAGE_SHIFT) |
0x8000UL;
+ else
+ gp[i] = cpu_to_le32((page_to_phys(mem-pages[i])
0xF000UL) |
+ 0x1UL);
flush_dcache_range((unsigned
long)__va(page_to_phys(mem-pages[i])),
(unsigned
long)__va(page_to_phys(mem-pages[i]))+0x1000);
}
@@ -236,7 +194,7 @@ static int u3_insert_memory(struct agp_memory *mem, off_t
pg_start, int type)
return 0;
}
-int u3_remove_memory(struct agp_memory *mem, off_t pg_start, int type)
+int uninorth_remove_memory(struct agp_memory *mem, off_t pg_start, int type)
{
size_t i;
u32 *gp;
@@ -551,7 +509,7 @@ const struct agp_bridge_driver uninorth_agp_driver = {
.create_gatt_table = uninorth_create_gatt_table,
.free_gatt_table= uninorth_free_gatt_table,
.insert_memory = uninorth_insert_memory,
- .remove_memory = agp_generic_remove_memory,
+ .remove_memory = uninorth_remove_memory,
.alloc_by_type = agp_generic_alloc_by_type,
.free_by_type = agp_generic_free_by_type,
.agp_alloc_page = agp_generic_alloc_page,
@@ -577,8 +535,8 @@ const struct agp_bridge_driver u3_agp_driver = {
.agp_enable = uninorth_agp_enable,
.create_gatt_table = uninorth_create_gatt_table,
.free_gatt_table= uninorth_free_gatt_table,
- .insert_memory = u3_insert_memory,
- .remove_memory = u3_remove_memory,
+ .insert_memory = uninorth_insert_memory,
+ .remove_memory = uninorth_remove_memory,
.alloc_by_type = agp_generic_alloc_by_type,
.free_by_type = agp_generic_free_by_type,
.agp_alloc_page = agp_generic_alloc_page,
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] agp/uninorth: Allow larger aperture sizes on pre-U3 bridges.
From: Michel Dänzer daen...@vmware.com
Using the radeon KMS test functionality, I verified that the AGP bridge of the
Intrepid2 chipset in my PowerBook supports aperture sizes up to 256M. So allow
aperture sizes up to 256M on pre-U3 bridges as well, and bump the default size
to 256M. It's possible that older revisions only support smaller sizes, but
it'll be easy to verify that with the raden KMS test functionality. Also,
there's only a problem on an actual attempt to access the aperture beyond the
maximum size supported by the hardware, and non-KMS X still defaults to using
only 32M.
Also use ARRAY_SIZE for the aperture size arrays.
Signed-off-by: Michel Dänzer daen...@vmware.com
---
drivers/char/agp/uninorth-agp.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index 7d0a93e..eed2195 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -27,6 +27,8 @@
static int uninorth_rev;
static int is_u3;
+#define DEFAULT_APERTURE_SIZE 256
+#define DEFAULT_APERTURE_STRING 256
static char *aperture = NULL;
static int uninorth_fetch_size(void)
@@ -55,7 +57,7 @@ static int uninorth_fetch_size(void)
if (!size) {
for (i = 0; i agp_bridge-driver-num_aperture_sizes; i++)
- if (values[i].size == 32)
+ if (values[i].size == DEFAULT_APERTURE_SIZE)
break;
}
@@ -489,13 +491,11 @@ void null_cache_flush(void)
/* Setup function */
-static const struct aper_size_info_32 uninorth_sizes[7] =
+static const struct aper_size_info_32 uninorth_sizes[] =
{
-#if 0 /* Not sure uninorth supports that high aperture sizes */
{256, 65536, 6, 64},
{128, 32768, 5, 32},
{64, 16384, 4, 16},
-#endif
{32, 8192, 3, 8},
{16, 4096, 2, 4},
{8, 2048, 1, 2},
@@ -506,7 +506,7 @@ static const struct aper_size_info_32 uninorth_sizes[7] =
* Not sure that u3 supports that high aperture sizes but it
* would strange if it did not :)
*/
-static const struct aper_size_info_32 u3_sizes[8] =
+static const struct aper_size_info_32 u3_sizes[] =
{
{512, 131072, 7, 128},
{256, 65536, 6, 64},
@@ -522,7 +522,7 @@ const struct agp_bridge_driver uninorth_agp_driver = {
.owner = THIS_MODULE,
.aperture_sizes = (void *)uninorth_sizes,
.size_type = U32_APER_SIZE,
- .num_aperture_sizes = 4,
+ .num_aperture_sizes = ARRAY_SIZE(uninorth_sizes),
.configure = uninorth_configure,
.fetch_size = uninorth_fetch_size,
.cleanup= uninorth_cleanup,
@@ -549,7 +549,7 @@ const struct agp_bridge_driver u3_agp_driver = {
.owner = THIS_MODULE,
.aperture_sizes = (void *)u3_sizes,
.size_type = U32_APER_SIZE,
- .num_aperture_sizes = 8,
+ .num_aperture_sizes = ARRAY_SIZE(u3_sizes),
.configure = uninorth_configure,
.fetch_size = uninorth_fetch_size,
.cleanup= uninorth_cleanup,
@@ -732,7 +732,7 @@ module_param(aperture, charp, 0);
MODULE_PARM_DESC(aperture,
Aperture size, must be power of two between 4MB and an\n
\t\tupper limit specific to the UniNorth revision.\n
-\t\tDefault: 32M);
+\t\tDefault: DEFAULT_APERTURE_STRING M);
MODULE_AUTHOR(Ben Herrenschmidt Paul Mackerras);
MODULE_LICENSE(GPL);
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Preemption question (4xx related)
On Thu, 2009-07-02 at 08:13 +1000, Benjamin Herrenschmidt wrote: On Tue, 2009-06-30 at 05:55 -0700, Felix Radensky wrote: Hi, Preemption is disabled on the vast majority of powerpc targets. Are there any known problems in this area ? I'd like to enable CONFIG_PREEMPT_VOLUNTARY on AMCC 405EX target, to increase application responsiveness. Is it a bad idea ? In theory it should work, but as you may have noticed, it's generally disabled and thus not very well tested. It would be a good idea for us, some of the core devs, to turn that on in our usual test configs in fact. FWIW, on my PowerBook I've been running with CONFIG_PREEMPT_VOLUNTARY enabled for a long time (more than a year). No problems so far, and it definitely seems to help a lot for interactivity. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] therm_adt746x: Always clear hardware bit which inverts fan speed range.
This bit would get enabled sometimes (probably after suspend/resume), so the
fan would run at full speed below the temperature thresholds, but slow down and
eventually stop if temperatures rose above the thresholds... not exactly what
you want.
Signed-off-by: Michel Dänzer mic...@daenzer.net
---
drivers/macintosh/therm_adt746x.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/macintosh/therm_adt746x.c
b/drivers/macintosh/therm_adt746x.c
index 82607ad..321eaad 100644
--- a/drivers/macintosh/therm_adt746x.c
+++ b/drivers/macintosh/therm_adt746x.c
@@ -37,6 +37,7 @@
#define CONFIG_REG 0x40
#define MANUAL_MASK 0xe0
#define AUTO_MASK0x20
+#define INVERT_MASK 0x10
static u8 TEMP_REG[3]= {0x26, 0x25, 0x27}; /* local, sensor1, sensor2 */
static u8 LIMIT_REG[3] = {0x6b, 0x6a, 0x6c}; /* local, sensor1, sensor2 */
@@ -229,7 +230,8 @@ static void write_fan_speed(struct thermostat *th, int
speed, int fan)
if (speed = 0) {
manual = read_reg(th, MANUAL_MODE[fan]);
- write_reg(th, MANUAL_MODE[fan], manual|MANUAL_MASK);
+ write_reg(th, MANUAL_MODE[fan],
+ (manual|MANUAL_MASK) (~INVERT_MASK));
write_reg(th, FAN_SPD_SET[fan], speed);
} else {
/* back to automatic */
--
1.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ANN] Introducing new test branch in powerpc.git tree
On Fri, 2009-02-06 at 18:42 +0100, Michel Dänzer wrote: On Thu, 2009-02-05 at 15:58 -0500, Josh Boyer wrote: On Fri, Feb 06, 2009 at 07:56:22AM +1100, Benjamin Herrenschmidt wrote: Which begs the question of what master is for. So far, it's just been a mirror of next from what I can tell. Maybe it should just track Linus' tree? I've been wondering myself what to do with it ... I may just leave it to track linus indeed. Or maybe just delete it. I don't think you can delete it without hosing people who try to clone it. The branch to check out by git clone can be overridden via a special file in the .git directory in the shared repository. Unfortunately though, I don't remember what it's called... According to Julien Cristau of the Debian X Strike Force (none of the Git repos of which have a master branch), it should be .git/HEAD. Some experiments of mine seem to confirm this. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ANN] Introducing new test branch in powerpc.git tree
On Thu, 2009-02-05 at 15:58 -0500, Josh Boyer wrote: On Fri, Feb 06, 2009 at 07:56:22AM +1100, Benjamin Herrenschmidt wrote: Which begs the question of what master is for. So far, it's just been a mirror of next from what I can tell. Maybe it should just track Linus' tree? I've been wondering myself what to do with it ... I may just leave it to track linus indeed. Or maybe just delete it. I don't think you can delete it without hosing people who try to clone it. The branch to check out by git clone can be overridden via a special file in the .git directory in the shared repository. Unfortunately though, I don't remember what it's called... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
therm_adt746x: CPU fan speed inversion
On my PowerBook5,8, every now and then (haven't figured out any pattern to when it happens) the therm_adt746x module stops controlling the fan speed properly. The problem seems to be that the fan speed range is inverted, i.e. the fan stops when therm_adt746x thinks it's setting it to full speed and vice versa. See below for a log of therm_adt746x loaded with verbose=1 while the problem is in effect; while it looks like the fan speed ramps up and down again, the GNOME sensors applet agrees with my ears that the opposite happened. I haven't found any way to recover from this other than rebooting. Has anyone else seen this? Any ideas what the problem could be, or how to track it down? FWIW I'm currently running 2.6.28 kernels self-built from the kernel.org stable tree, but I first noticed this a long time ago, possibly forever since I've used this module. Now it's finally bothered me enough to report it. :) [150811.783627] adt746x: version 1 (supported) [150811.783639] adt746x: Thermostat bus: 0, address: 0x2e, limit_adjust: 0, fan_speed: -1 [150811.783648] sensor 0: CPU/INTREPID BOTTOMSIDE [150811.783653] sensor 1: CPU BOTTOMSIDE [150811.783658] sensor 2: PWR SUPPLY BOTTOMSIDE [150811.800813] adt746x: ADT7467 initializing [150811.803623] adt746x: Lowering max temperatures from 81, 80, 87 to 70, 50, 70 [150811.803699] adt746x: Setting speed to 0 for CPU BOTTOMSIDE fan. [153827.141765] adt746x: Setting fans speed to 64 (limit exceeded by 0 on CPU BOTTOMSIDE) [153827.141773] adt746x: Setting speed to 64 for CPU BOTTOMSIDE fan. [153861.697327] adt746x: Setting fans speed to 91 (limit exceeded by 2 on CPU BOTTOMSIDE) [153861.697335] adt746x: Setting speed to 91 for CPU BOTTOMSIDE fan. [153898.391372] adt746x: Setting fans speed to 145 (limit exceeded by 4 on CPU BOTTOMSIDE) [153898.391379] adt746x: Setting speed to 145 for CPU BOTTOMSIDE fan. [153936.733051] adt746x: Setting fans speed to 199 (limit exceeded by 6 on CPU BOTTOMSIDE) [153936.733059] adt746x: Setting speed to 199 for CPU BOTTOMSIDE fan. [153977.150356] adt746x: Setting fans speed to 253 (limit exceeded by 8 on CPU BOTTOMSIDE) [153977.150363] adt746x: Setting speed to 253 for CPU BOTTOMSIDE fan. [154017.403671] adt746x: Setting fans speed to 199 (limit exceeded by 6 on CPU BOTTOMSIDE) [154017.403682] adt746x: Setting speed to 199 for CPU BOTTOMSIDE fan. [154047.440196] adt746x: Setting fans speed to 145 (limit exceeded by 4 on CPU BOTTOMSIDE) [154047.440208] adt746x: Setting speed to 145 for CPU BOTTOMSIDE fan. [154073.466771] adt746x: Setting fans speed to 91 (limit exceeded by 2 on CPU BOTTOMSIDE) [154073.466783] adt746x: Setting speed to 91 for CPU BOTTOMSIDE fan. [154101.502629] adt746x: Setting fans speed to 64 (limit exceeded by 0 on CPU BOTTOMSIDE) [154101.502640] adt746x: Setting speed to 64 for CPU BOTTOMSIDE fan. [154153.606437] adt746x: Stopping fans. [154153.606449] adt746x: Setting speed to 0 for CPU BOTTOMSIDE fan. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] uninorth agp: don't mark module parameter __devinit
On Thu, 2008-10-30 at 09:45 +0100, Johannes Berg wrote: Michel Dänzer wrote: Can uninorth_fetch_size be marked __devinit then? I'm not sure, and none of the other AGP backend drivers seems to do so... Well, either it can, or marking aperture is wrong, no? Makes sense, but I'm not sure about all the conditions and implications involved. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] uninorth agp: don't mark module parameter __devinit
On Wed, 2008-10-29 at 03:11 +0100, Johannes Berg wrote: A module parameter can possibly be shown via sysfs, which isn't a good idea if the section has been removed, so remove the __devinit annotation. Under what circumstances could it be shown in sysfs? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] uninorth agp: don't mark module parameter __devinit
On Wed, 2008-10-29 at 13:12 +0100, Johannes Berg wrote: On Wed, 2008-10-29 at 13:09 +0100, Michel Dänzer wrote: On Wed, 2008-10-29 at 03:11 +0100, Johannes Berg wrote: A module parameter can possibly be shown via sysfs, which isn't a good idea if the section has been removed, so remove the __devinit annotation. Under what circumstances could it be shown in sysfs? Sorry, my mistake, I overlooked that it had 0 permission: module_param(aperture, charp, 0); otherwise it would of course be in sysfs. Can uninorth_fetch_size be marked __devinit then? I'm not sure, and none of the other AGP backend drivers seems to do so... -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: radeonfb, dedicate memory to something else
On Tue, 2008-07-22 at 09:31 +0100, Matt Sealey wrote: Jon Smirl wrote: On 7/20/08, Matt Sealey [EMAIL PROTECTED] wrote: Hi guys, I know this isn't a PPC question, but since some of the RadeonFB developers live here I thought best (and it's about a PPC platform). Is there any way to hack up the RadeonFB driver - or anything related - to reserve portions of the memory for a fake MTD or so, and still use the Radeon as a graphics device? What I am talking about basically is turning a 64MB Radeon card into a 32MB Radeon card, or a 128MB one into a 64MB card.. Somebody write this long ago. Maybe around 2000. That's all I remember. I think they made the video memory into a ram disk. Yeah making it into a ramdisk precludes the use of the card as a video card though.. this is what I am trying to get around. If fbdev and X can cooperate on believing that a 64MB card is a 32MB card, then the upper 32MB can be used to attach the MTD ram driver at a certain address (maybe we can even make a hacky stub driver that recognizes this configuration based on OF tree..) There are obvious limitations in that the Pegasos/Efika firmware only will map 128MB of video memory, and the PCI BAR is limited to 256MB chunks anyway, but that shouldn't matter. I just wonder, how it can be done that radeonfb or other graphics drivers can be told please only use the first 32MB and then either manually or automatically, map the rest as ramdisk. You can limit the amount of video RAM used by X using the VideoRam directive in xorg.conf(5). I believe there is more to it, the GART window may be smaller than the total RAM on the card. You need to use the GART to map in the appropriate pieces. The problem here is the PCI bus on the Efika is a PCI bus, with an AGP riser. It doesn't add any AGP functionality like real GART on the host controller side, so there is nothing to map system memory into AGP's view of the system.. it always confused me how pcigart is meant to work and how an AGP GART does anything different to how PCI works in the first place (the documentation/spec doesn't make it that clear in my opinion :) GART doesn't have anything to do with this. I suspect he was thinking of the PCI BARs not covering all video RAM. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Linux-fbdev-devel] [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
On Wed, 2008-04-23 at 08:21 +1000, Benjamin Herrenschmidt wrote: On Tue, 2008-04-22 at 17:55 +0200, Christian Ehrhardt wrote: I wanted to ask if there are any known workarounds atm that would allow me to use my X11 for now? X is doing a mmap of /dev/mem instead of /dev/fb ? You can normally map the fb mapping /dev/fb and then map the registers using /dev/fb at an offset beyond the framebuffer (fix-smem_len). If X is using /dev/mem instead, then it's being stupid and needs to be fixed... It's up to the driver, and again, the current radeon driver doesn't use radeonfb at all anymore... -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pci issue - wrong detection of pci ressources
On Tue, 2008-04-22 at 16:21 +0200, Christian Ehrhardt wrote: radeonfb: EDID probed Parsing EDID data for panel info Setting up default mode based on panel info radeonfb (:00:0a.0): ATI Radeon Y` Hm, what's that Y`? Thats the final message in the radeonfb driver ater initializing everything. printk (radeonfb (%s): %s\n, pci_name(rinfo-pdev), rinfo-name); I wonder why that rinfo-name is clobbered - maybe another issue, I have to keep that in mind. It isn't clobbered, it's just the PCI device ID printed as characters. That was a human readable string with early Radeons and thus convenient for identifying them between humans, but that's no longer the case with newer ones. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] radeonfb: Fix 64 bits resources on 32 bits archs
On Tue, 2008-04-22 at 17:55 +0200, Christian Ehrhardt wrote: You see it e.g. when you try to initialize X11, the x11 radeon driver issues a FBIOGET_FSCREENINFO ioctl [...] FWIW, current versions of the xf86-video-ati radeon driver no longer use radeonfb for anything. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Mon, 2008-01-28 at 13:56 +0100, Ingo Molnar wrote: * Peter Zijlstra [EMAIL PROTECTED] wrote: i think it would be OK to do half of this: make it easier to preempt a +nice task. Michel, do you really need the -nice portion as well? It's not a problem to super-preempt positively reniced tasks, but it can be quite annoying if negatively reniced tasks have super-slices. This should do that (unless I need a stronger cup of tea). cool - thanks Peter. Michel, could you check Peter's patch, does it resolve all the interactivity problems you've been seeing? I'm now running with this patch and Srivatsa's patch, and together they provide good interactivity even with CONFIG_FAIR_USER_SCHED enabled and the default value of /proc/sys/kernel/sched_wakeup_granularity_ns. :) So both patches seem to have the expected effect. /proc/sys/kernel/sched_features contains 7. Thanks, -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Mon, 2008-01-28 at 15:25 +1100, Benjamin Herrenschmidt wrote: On Sun, 2008-01-27 at 17:13 +0100, Michel Dänzer wrote: Do you see behavior change (from good-bad) immediately after applying that patch during your bisect process? Yes, confirmed by trying that commit and its parent again. Just to be paranoid... can you try with a different gcc version in case something gets miscompiled ? Is that really necessary - after all, 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is related to process wakeup behaviour? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Mon, 2008-01-28 at 09:50 +0100, Peter Zijlstra wrote: On Sun, 2008-01-27 at 17:13 +0100, Michel Dänzer wrote: In summary, there are two separate problems with similar symptoms, which had me confused at times: * With CONFIG_FAIR_USER_SCHED disabled, there are severe interactivity hickups with a niced CPU hog and top running. This started with commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8. The revert at the bottom causes the wakeup granularity to shrink for + nice and to grow for - nice. That is, it becomes easier to preempt a + nice task, and harder to preempt a - nice task. Yeah, that matches my observations. :) I think we originally had that; didn't comment it, forgot the reason changed it because the units didn't match. Another reason might have been the more difficult preemption of - nice tasks. That might - niced tasks to cause horrible latencies - Ingo, any recollection? Are you perhaps running with a very low HZ (HZ=100)? (If wakeup preemption fails, tick preemption will take over). I haven't had it below 250 since that became an option, and I'm currently at 1000 (and NO_HZ, but disabling that didn't seem to make a difference). Also, could you try lowering: /proc/sys/kernel/sched_wakeup_granularity_ns Will try. * With CONFIG_FAIR_USER_SCHED enabled, X becomes basically unusable with a niced CPU hog, with or without top running. I don't know when this started, possibly when this option was first introduced. Srivatsa found an issue that might explain the very bad behaviour under group scheduling. But I gather you're not at all interested in this feature? That's right, but it's good to hear you have a lead there as well, and if you can't find any interested testers, let me know and I'll try. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8) restores 2.6.24 interactivity
to the same level as 2.6.23 here with CONFIG_FAIR_USER_SCHED disabled
(my previous report to the contrary was with CONFIG_FAIR_USER_SCHED
enabled because I didn't yet realize the difference it makes), but I
don't know if that's the real fix.
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
struct task_struct *curr = rq-curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = curr-se, *pse = p-se;
- unsigned long gran;
if (unlikely(rt_prio(p-prio))) {
update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
pse = parent_entity(pse);
}
- gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se-load.weight != NICE_0_LOAD))
- gran = calc_delta_fair(gran, se-load);
- if (pse-vruntime + gran se-vruntime)
+ if (pse-vruntime + sysctl_sched_wakeup_granularity se-vruntime)
resched_task(curr);
}
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
41795.173040 631 120 41795.173040 301.572431 24901.348163 -Rcat 4736 41787.850967 0 120 41787.850967 3.696000 0.00 + pbbuttonsd 3878 42001.676760 22659 120 42001.676760 506.463055 52940.745088 +Xorg 4574 42013.220923 15439 119 42013.220923 5168.535269 27513.009418 + zsh 4675 41843.822192 634 120 41843.822192 302.744207 44763.221535 + sh 4734 1362837.967264 2791 139 1362837.967264 19352.99463847.795532 +Rcat 4746 41816.398384 0 120 41816.398384 2.149568 0.00 -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer Sched Debug Version: v0.07, 2.6.24-rc8 #4 now at 224908.343840 msecs .sysctl_sched_latency: 20.00 .sysctl_sched_min_granularity: 4.00 .sysctl_sched_wakeup_granularity : 10.00 .sysctl_sched_batch_wakeup_granularity : 10.00 .sysctl_sched_child_runs_first : 0.01 .sysctl_sched_features : 7 cpu#0 .nr_running: 5 .load : 4364 .nr_switches : 142978 .nr_load_updates : 100239 .nr_uninterruptible: 0 .jiffies : 4294892204 .next_balance : 0.00 .curr-pid : 4746 .clock : 100239.072955 .idle_clock: 0.00 .prev_clock_raw: 224892.259968 .clock_warps : 0 .clock_overflows : 119985 .clock_deep_idle_events: 0 .clock_max_delta : 0.36 .cpu_load[0] : 4364 .cpu_load[1] : 3979 .cpu_load[2] : 3443 .cpu_load[3] : 3331 .cpu_load[4] : 3268 cfs_rq .exec_clock: 80597.780820 .MIN_vruntime : 54813.436178 .min_vruntime : 54813.436178 .max_vruntime : 54818.646546 .spread: 5.210368 .spread0 : 0.00 .nr_running: 3 .load : 4096 .bkl_count : 0 .nr_spread_over: 0 cfs_rq .exec_clock: 19353.983950 .MIN_vruntime : 1362837.967264 .min_vruntime : 54813.436178 .max_vruntime : 1362837.967264 .spread: 0.00 .spread0 : 0.00 .nr_running: 1 .load : 15 .bkl_count : 0 .nr_spread_over: 0 cfs_rq .exec_clock: 9397.906333 .MIN_vruntime : 41843.822192 .min_vruntime : 54813.436178 .max_vruntime : 41843.822192 .spread: 0.00 .spread0 : 0.00 .nr_running: 2 .load : 2048 .bkl_count : 0 .nr_spread_over: 0 cfs_rq .exec_clock: 0.997824 .MIN_vruntime : 0.01 .min_vruntime : 54813.436178 .max_vruntime : 0.01 .spread: 0.00 .spread0 : 0.00 .nr_running: 0 .load : 0 .bkl_count : 0 .nr_spread_over: 0 cfs_rq .exec_clock: 85.106979 .MIN_vruntime : 0.01 .min_vruntime : 54813.436178 .max_vruntime : 0.01 .spread: 0.00 .spread0 : 0.00 .nr_running: 0 .load : 0 .bkl_count : 0 .nr_spread_over: 0 cfs_rq .exec_clock: 94.005568 .MIN_vruntime : 0.01 .min_vruntime : 54813.436178 .max_vruntime : 0.01 .spread: 0.00 .spread0 : 0.00 .nr_running: 0 .load : 0 .bkl_count : 0 .nr_spread_over: 0 cfs_rq .exec_clock: 76.941956 .MIN_vruntime : 0.01 .min_vruntime : 54813.436178 .max_vruntime : 0.01 .spread: 0.00 .spread0 : 0.00 .nr_running
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Fri, 2008-01-25 at 17:54 +1100, Benjamin Herrenschmidt wrote: On Wed, 2008-01-23 at 13:42 +0100, Peter Zijlstra wrote: Another question, do you have: CONFIG_FAIR_GROUP_SCHED=y if so, does flipping that off have any effect? Yes. Here, I do the test of running 4 times the repro-case provided by Michel with nice 19 and a dd eating CPU with nice 0. Without this option, I get the dd at 100% and the nice 19 shells down below it with whatever is left of the CPUs. With this option, dd gets about 50% of one CPU and the niced processes still get most of the time. Hmm, interesting. As I said before, I thought I had tested with this disabled and not seen a difference, but I'll try again to confirm. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Tue, 2008-01-22 at 15:56 +0100, Michel Dänzer wrote:
On Fri, 2008-01-18 at 13:34 +0100, Michel Dänzer wrote:
This is on a PowerBook5,8.
In a nutshell, things seem more sluggish in general than with 2.6.23.
But in particular, processes running at nice levels 0 can get most of
the CPU cycles available, slowing down processes running at nice level
0.
The canonical test case I've come up with is to run an infinite loop
with
sudo -u nobody nice -n 19 sh -c 'while true; do true; done'
This makes my X session (X server running at nice level -1, clients at
0) unusably sluggish (it can even take several seconds to process ctrl-c
to interrupt the infinite loop) with 2.6.24-rc but works as expected
with 2.6.23.
Anybody else seeing this?
I've seen this since .24-rc5 (the first .24-rc I tried), and it's still
there with -rc8. I'd be surprised if this kind of behaviour remained
unfixed for that long if it affected x86, so I presume it's powerpc
specific.
Or maybe not... I've bisected this down to the scheduler changes
between
df3d80f5a5c74168be42788364d13cf6c83c7b9c/23fd50450a34f2558070ceabb0bfebc1c9604af5
and b5869ce7f68b233ceb81465a7644be0d9a5f3dbb .
Finished bisecting now. And the winner is...
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
Author: Peter Zijlstra [EMAIL PROTECTED]
Date: Mon Oct 15 17:00:14 2007 +0200
sched: another wakeup_granularity fix
unit mis-match: wakeup_gran was used against a vruntime
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
:04 04 61242d589b0082a417657807ed6329321340f7f3
bff39e49275324e15f37d2163157733580b7df1a M kernel
Unfortunately, I don't understand how that can cause the misbehaviour
described above, and 2.6.24-rc8
(667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
shows the problem. Any ideas Peter or Ingo (or anyone, really :)?
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
struct task_struct *curr = rq-curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = curr-se, *pse = p-se;
- unsigned long gran;
if (unlikely(rt_prio(p-prio))) {
update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
pse = parent_entity(pse);
}
- gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se-load.weight != NICE_0_LOAD))
- gran = calc_delta_fair(gran, se-load);
- if (pse-vruntime + gran se-vruntime)
+ if (pse-vruntime + sysctl_sched_wakeup_granularity se-vruntime)
resched_task(curr);
}
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Wed, 2008-01-23 at 13:36 +0100, Peter Zijlstra wrote:
On Wed, 2008-01-23 at 13:18 +0100, Michel Dänzer wrote:
810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
Author: Peter Zijlstra [EMAIL PROTECTED]
Date: Mon Oct 15 17:00:14 2007 +0200
sched: another wakeup_granularity fix
unit mis-match: wakeup_gran was used against a vruntime
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
:04 04 61242d589b0082a417657807ed6329321340f7f3
bff39e49275324e15f37d2163157733580b7df1a M kernel
Unfortunately, I don't understand how that can cause the misbehaviour
described above, and 2.6.24-rc8
(667984d9e481e43a930a478c588dced98cb61fea) with the patch below still
shows the problem. Any ideas Peter or Ingo (or anyone, really :)?
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index da7c061..a7cc22a 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -843,7 +843,6 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
struct task_struct *curr = rq-curr;
struct cfs_rq *cfs_rq = task_cfs_rq(curr);
struct sched_entity *se = curr-se, *pse = p-se;
- unsigned long gran;
if (unlikely(rt_prio(p-prio))) {
update_rq_clock(rq);
@@ -866,11 +865,8 @@ static void check_preempt_wakeup(struct rq *rq, struct
task_struct *p)
pse = parent_entity(pse);
}
- gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se-load.weight != NICE_0_LOAD))
- gran = calc_delta_fair(gran, se-load);
- if (pse-vruntime + gran se-vruntime)
+ if (pse-vruntime + sysctl_sched_wakeup_granularity se-vruntime)
resched_task(curr);
}
Most curious; are you sure its not a bisection problem?
Quite sure.
Does ppc32 (or your instance thereof) have a high resolution
sched_clock()?
I'm not sure (FWIW, we did get support for NO_HZ and HIGH_RES_TIMERS in
2.6.24-rc as well, but playing with these config options and even
reverting the code didn't seem to have any effect), can someone from the
linuxppc-dev list answer this?
Another question, do you have:
CONFIG_FAIR_GROUP_SCHED=y
if so, does flipping that off have any effect?
I tried both, no difference that I could tell.
Is there any debugging information I could provide from running the test
on kernels built from at and before the change in question?
Thanks,
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Fri, 2008-01-18 at 13:34 +0100, Michel Dänzer wrote: This is on a PowerBook5,8. In a nutshell, things seem more sluggish in general than with 2.6.23. But in particular, processes running at nice levels 0 can get most of the CPU cycles available, slowing down processes running at nice level 0. The canonical test case I've come up with is to run an infinite loop with sudo -u nobody nice -n 19 sh -c 'while true; do true; done' This makes my X session (X server running at nice level -1, clients at 0) unusably sluggish (it can even take several seconds to process ctrl-c to interrupt the infinite loop) with 2.6.24-rc but works as expected with 2.6.23. Anybody else seeing this? I've seen this since .24-rc5 (the first .24-rc I tried), and it's still there with -rc8. I'd be surprised if this kind of behaviour remained unfixed for that long if it affected x86, so I presume it's powerpc specific. Or maybe not... I've bisected this down to the scheduler changes between df3d80f5a5c74168be42788364d13cf6c83c7b9c/23fd50450a34f2558070ceabb0bfebc1c9604af5 and b5869ce7f68b233ceb81465a7644be0d9a5f3dbb . I'll try and bisect it further, but this is my main work machine, so I can't reboot it too often. I'm CC'ing Ingo in case he has any ideas offhand. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Bug#457294: [powerpc] System time not updated after sleep cycle
Package: linux-2.6 Version: 2.6.23-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After wakeup from sleep, the system time is still the same as it was when going to sleep. I have to restart ntp to get it updated. This problem didn't occur with previous kernels. It persists in 2.6.23-2~snapshot.9949 but is fixed in 2.6.24~rc5-1~experimental.1~snapshot.9974 . I'm CC'ing the linuxppc-dev list on this report in the hope that someone there remembers how this was fixed post 2.6.23 upstream and that the fix can hopefully be backported. - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (102, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 2.6.24-rc5-powerpc Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHa5O1WoGvjmrbsgARAjGpAJ0TaORdhlrDU1kYPDF7dpAvNK0s0ACfU4mX erietOhcqZUjsxn+803CxXo= =I/Op -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Access to PCI Expansion ROMs on PPC
On Mon, 2007-11-26 at 00:59 -0800, Robin H. Johnson wrote: Regarding the sub-thread on x86 emulation, that is totally out of scope for this. The 'AtomBIOS' of the ATI cards, consists of multiple parts (I may have minor errors here, ask airlied if you need more clarification): a) Initialization code (I think arch-specific) b) AtomBIOS script interpreter (I think arch-specific) c) AtomBIOS scripts (card-specific, but not arch-specific) d) Data tables (card-specific, but not arch-specific) The AtomBIOS parts of the various drivers need data from c+d primarily, and provide their own script interpreter, or not using the scripts, just the data tables. Are you sure the X1900 Mac Edition ROM contains any ATOM data structures though? I rather doubt it. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] Add support for Apple aluminum USB keyboards
The following series of two patches adds support for Apple aluminum USB keyboards to the hid and usbhid modules. The first patch contains no functional change but just renames code identifiers, the second patch adds the actual support by reusing and extending the existing quirks for Apple laptop USB keyboards. There's some things I'm not too sure about and would appreciate suggestions for, e.g. * The keycodes generated for the Exposé and Dashboard keys. * Whether F5 and F6 should be subject to the pb_fn_mode option even though they don't have any special engravings. * I only have an ISO keyboard, so the device IDs for the ANSI and JIS variants are guessed from the previous models. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
