Processed: found 838782 in 4.8~rc8-1~exp1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> # Linux c6 4.8.0-rc8-amd64 #1 SMP Debian 4.8~rc8-1~exp1 (2016-09-26) x86_64 
> GNU/Linux
> found 838782 4.8~rc8-1~exp1
Bug #838782 [src:linux] linux-image-4.8.0-rc5-amd64-unsigned: Screen under X 
gets black for 1-2 seconds very often on Intel Skylake with onboard gfx, most 
time while using the mouse's scroll wheel
Marked as found in versions linux/4.8~rc8-1~exp1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
838782: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838782
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#826629: Possible offb unload fix.

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 09:39:12PM +0200, Mathieu Malaterre wrote:
> Here is what I see:
> 
> [   52.270154] bus: 'pci': add driver radeonfb
> [   52.270224] bus: 'pci': driver_probe_device: matched device
> :00:10.0 with driver radeonfb
> [   52.270233] bus: 'pci': really_probe: probing driver radeonfb with
> device :00:10.0
> [   52.270256] devices_kset: Moving :00:10.0 to end of list
> [   52.270264] radeonfb_pci_register BEGIN
> [   52.270267] radeonfb: MM1
> [   52.275001] radeonfb :00:10.0: enabling device (0006 -> 0007)
> [   52.279727] radeonfb: MM2
> [   52.295202] radeonfb: MM3
> [   52.299816] radeonfb: MM4
> [   52.304934] radeonfb: MM0 9800 800 radeonfb
> [   52.309768] checking generic (9c008000 96000) vs hw (9800 800)
> [   52.309776] fb: switching to radeonfb from OFfb ATY,RockHo
> [   52.315075] Console: switching to colour dummy device 80x25
> [   52.315595] device: 'fb0': device_unregister
> [   52.315736] PM: Removing info for No Bus:fb0
> [   52.317348] device: 'fb0': device_create_release
> [   52.317407] radeonfb: MM5 0
> [   52.317447] device: 'vtcon1': device_unregister
> [   52.317500] PM: Removing info for No Bus:vtcon1
> [   52.317565] device: 'vtcon1': device_create_release
> [   52.318992] radeonfb :00:10.0: BAR 0: can't reserve [mem
> 0x9800-0x9fff pref]
> [   52.319029] radeonfb (:00:10.0): cannot request region 0.
> [   52.319066] radeonfb: probe of :00:10.0 failed with error -16

So offb_destroy is NOT called.  Well that explains the problem.

Unfortunately it seems the reason it isn't called is that the
fb->info->count is not zero, because it is still open.  I am not sure
how the ability to unregister a conflicting framebuffer is supposed to
work if it stays active until it is replaced.

The kick out appears to successfully remove offb from being the active
fb, but since the release hasn't been called yet, the resources are not
yet freed, so radeonfb fails when trying to reserve them.  If offb_destroy
had been called the resources would be free and there would almost
certainly not be a problem.

Now the radeon.ko gets away with this because it doesn't try to reserve
the memory and never calls pci_request_region at all.

How about adding this to your patch:

--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -2319,14 +2319,14 @@ static int radeonfb_pci_register(struct pci_dev *pdev,
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 0.\n",
pci_name(rinfo->pdev));
-   goto err_release_fb;
+   //goto err_release_fb;
}
 
ret = pci_request_region(pdev, 2, "radeonfb mmio");
if (ret < 0) {
printk( KERN_ERR "radeonfb (%s): cannot request region 2.\n",
pci_name(rinfo->pdev));
-   goto err_release_pci0;
+   //goto err_release_pci0;
}
 
/* map the regions */

So it will still complain, but it will ignore the fact the memory
reservation failed, and still continue and do the ioremap and try to
use it.

That is how radeon.ko works as far as I can tell.

Of course once that is done, then the changes to offb.c become irrelevant.

-- 
Len Sorensen

Bug#838739: linux-image-amd64: meta depends on image not available

[Ben Hutchings]

On Tue, 2016-10-04 at 22:52 +0200, Vincent Danjean wrote:
> Le 24/09/2016 à 09:05, nutzteil a écrit :
> > 
> > Package: linux-image-amd64
> > Version: 4.6+74~bpo8+1
> > Severity: normal
> > 
> > Hello,
> > current meta-Package linux-image-$ARCH jessie-backports depends on
> > linux-image 4.6,
> >  which is no longer available in jessie-backports.
> > 
> > Same incident for meta-Package linux-headers-$ARCH
> 
>   It seems the problem comes from the migration to signed
> kernel/modules in testing/unstable. The backport of the linux package
> do not revert this part, so only linux-image-*-unsigned packages are
> present in backport. And linux-signed has not been backported.
> 
>   Ben: what it the correct path? Should linux-signed be backported?
[...]

It has; it's waiting in NEW.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, reading IRC for the first
time


signature.asc
Description: This is a digitally signed message part

Bug#838739: linux-image-amd64: meta depends on image not available

[Vincent Danjean]

Le 24/09/2016 à 09:05, nutzteil a écrit :
> Package: linux-image-amd64
> Version: 4.6+74~bpo8+1
> Severity: normal
> 
> Hello,
> current meta-Package linux-image-$ARCH jessie-backports depends on 
> linux-image 4.6,
>  which is no longer available in jessie-backports.
> 
> Same incident for meta-Package linux-headers-$ARCH

  It seems the problem comes from the migration to signed
kernel/modules in testing/unstable. The backport of the linux package
do not revert this part, so only linux-image-*-unsigned packages are
present in backport. And linux-signed has not been backported.

  Ben: what it the correct path? Should linux-signed be backported?
(with other dependencies?) Or should the "-unsigned" part of the
linux package be reverted in the backport suite? Or should the
backport of linux-latest be modified to point to the -unsigned images?

  Regards,
Vincent


> bye
> christian


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
>  wrote:
> > On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> >> € grep bogl_set_palette *
> >> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
> >> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> >> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
> >> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
> >> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
> >> palette[][3]);
> >> bogl-test.c:  bogl_set_palette (0, 16, palette);
> >> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
> >> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
> >> bterm.c:  bogl_set_palette(0, 16, palette);
> >> bterm.c:bogl_set_palette(0, 16, palette);
> >> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
> >>
> >> It looks like bterm always set only colors 0-15.
> >
> > So it does.  Hmm, I will compare the code some more.
> >
> > Has it been confirmed that radeonfb does not have wrong colours while
> > offb on the same machine does?
> >
> > And what video mode does radeonfb run with?  I wish someone had dmesg
> > dumps of both offb and radeonfb, but I am not having much luck finding
> > any with google.
> 
> Attached.

Could you try what offb does if you boot with the kernel option:
video=1680x1050-32

I just wonder if that makes bterm work with right colors.

Of course it might not like it if it doesn't know how to change the mode
on an "Unknown" type of device.

Unfortunately /proc/iomem on powerpc is apparently totally useless.

-- 
Len Sorensen

Bug#826629: Possible offb unload fix.

[Mathieu Malaterre]

On Tue, Oct 4, 2016 at 9:13 PM, Lennart Sorensen
 wrote:
> On Tue, Oct 04, 2016 at 08:41:45PM +0200, Mathieu Malaterre wrote:
>> Hi Len,
>>
>> Here is the release function I am using:
>>
>> static void offb_destroy(struct fb_info *info)
>> {
>> struct offb_par *par = (struct offb_par *) info->par;
>> if (info->screen_base)
>> iounmap(info->screen_base);
>> if (par->cmap_adr != NULL) {
>> iounmap(par->cmap_adr);
>> par->cmap_adr = NULL;
>> }
>> release_mem_region(info->apertures->ranges[0].base,
>> info->apertures->ranges[0].size);
>> framebuffer_release(info);
>> }
>>
>>
>> (you need the cast to avoid warning about deref of void*).
>>
>> And if I do `modprobe radeonfb`:
>>
>> [   72.163546] bus: 'pci': add driver radeonfb
>> [   72.163618] bus: 'pci': driver_probe_device: matched device
>> :00:10.0 with driver radeonfb
>> [   72.163627] bus: 'pci': really_probe: probing driver radeonfb with
>> device :00:10.0
>> [   72.163651] devices_kset: Moving :00:10.0 to end of list
>> [   72.163659] radeonfb_pci_register BEGIN
>> [   72.163680] radeonfb :00:10.0: enabling device (0006 -> 0007)
>> [   72.163721] radeonfb :00:10.0: BAR 0: can't reserve [mem
>> 0x9800-0x9fff pref]
>> [   72.163726] radeonfb (:00:10.0): cannot request region 0.
>> [   72.163746] radeonfb: probe of :00:10.0 failed with error -16
>
> Could you put a print statement in offb_destroy to make sure that is
> actually being called?
>
> And this is radeonfb with code added to actually try to kick out offb,
> right?

Here is what I see:

[   52.270154] bus: 'pci': add driver radeonfb
[   52.270224] bus: 'pci': driver_probe_device: matched device
:00:10.0 with driver radeonfb
[   52.270233] bus: 'pci': really_probe: probing driver radeonfb with
device :00:10.0
[   52.270256] devices_kset: Moving :00:10.0 to end of list
[   52.270264] radeonfb_pci_register BEGIN
[   52.270267] radeonfb: MM1
[   52.275001] radeonfb :00:10.0: enabling device (0006 -> 0007)
[   52.279727] radeonfb: MM2
[   52.295202] radeonfb: MM3
[   52.299816] radeonfb: MM4
[   52.304934] radeonfb: MM0 9800 800 radeonfb
[   52.309768] checking generic (9c008000 96000) vs hw (9800 800)
[   52.309776] fb: switching to radeonfb from OFfb ATY,RockHo
[   52.315075] Console: switching to colour dummy device 80x25
[   52.315595] device: 'fb0': device_unregister
[   52.315736] PM: Removing info for No Bus:fb0
[   52.317348] device: 'fb0': device_create_release
[   52.317407] radeonfb: MM5 0
[   52.317447] device: 'vtcon1': device_unregister
[   52.317500] PM: Removing info for No Bus:vtcon1
[   52.317565] device: 'vtcon1': device_create_release
[   52.318992] radeonfb :00:10.0: BAR 0: can't reserve [mem
0x9800-0x9fff pref]
[   52.319029] radeonfb (:00:10.0): cannot request region 0.
[   52.319066] radeonfb: probe of :00:10.0 failed with error -16

With patch attached.
diff -ru tmp/linux-4.7.5/drivers/video/fbdev/aty/radeon_base.c linux-4.7.5/drivers/video/fbdev/aty/radeon_base.c
--- tmp/linux-4.7.5/drivers/video/fbdev/aty/radeon_base.c	2016-09-24 10:10:18.0 +0200
+++ linux-4.7.5/drivers/video/fbdev/aty/radeon_base.c	2016-10-04 21:17:09.864838492 +0200
@@ -2259,6 +2259,43 @@
 	.read	= radeon_show_edid2,
 };
 
+static int radeon_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+	struct apertures_struct *ap;
+
+	ap = alloc_apertures(1);
+	if (!ap)
+		return -ENOMEM;
+
+	ap->ranges[0].base = pci_resource_start(pdev, 0);
+	ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+		printk(KERN_INFO "radeonfb: MM0 %x %x %s\n", ap->ranges[0].base, ap->ranges[0].size, KBUILD_MODNAME);
+	remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+	//remove_conflicting_framebuffers(ap, KBUILD_MODNAME, true);
+	kfree(ap);
+
+	return 0;
+}
+
+/*static int radeon_kick_out_firmware_fb2(struct pci_dev *pdev)
+{
+	struct apertures_struct *ap;
+
+	ap = alloc_apertures(1);
+	if (!ap)
+		return -ENOMEM;
+
+	ap->ranges[0].base = pci_resource_start(pdev, 0);
+	ap->ranges[0].size = pci_resource_len(pdev, 0);
+
+		printk(KERN_INFO "radeonfb: MM1 %d %d %s\n", ap->ranges[0].base, ap->ranges[0].size, KBUILD_MODNAME);
+	remove_conflicting_framebuffers(ap, KBUILD_MODNAME, false);
+	//remove_conflicting_framebuffers(ap, KBUILD_MODNAME, true);
+	kfree(ap);
+
+	return 0;
+}*/
 
 static int radeonfb_pci_register(struct pci_dev *pdev,
  const struct pci_device_id *ent)
@@ -2270,6 +2307,7 @@
 	int err = 0;
 
 	pr_debug("radeonfb_pci_register BEGIN\n");
+		printk(KERN_INFO "radeonfb: MM1\n");
 	
 	/* Enable device in PCI config */
 	ret = pci_enable_device(pdev);
@@ -2278,6 +2316,7 @@
 		   pci_name(pdev));
 		goto err_out;
 	}
+		printk(KERN_INFO "radeonfb: MM2\n");
 
 	info = framebuffer_alloc(sizeof(struct radeonfb_info), >dev);
 	if (!info) {
@@ -2286,6 +2325,7 @@
 		ret = -ENOMEM;
 		goto err_disable;
 	

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Mathieu Malaterre]

On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
 wrote:
> On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
>> € grep bogl_set_palette *
>> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
>> bogl.c: bogl_set_palette = bogl_fb_set_palette;
>> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
>> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
>> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
>> palette[][3]);
>> bogl-test.c:  bogl_set_palette (0, 16, palette);
>> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
>> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
>> bterm.c:  bogl_set_palette(0, 16, palette);
>> bterm.c:bogl_set_palette(0, 16, palette);
>> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
>>
>> It looks like bterm always set only colors 0-15.
>
> So it does.  Hmm, I will compare the code some more.
>
> Has it been confirmed that radeonfb does not have wrong colours while
> offb on the same machine does?
>
> And what video mode does radeonfb run with?  I wish someone had dmesg
> dumps of both offb and radeonfb, but I am not having much luck finding
> any with google.

Attached.


dmesg.radeonfb.txt.gz
Description: GNU Zip compressed data


fbset.radeonfb.txt.gz
Description: GNU Zip compressed data


iomem.radeonfb.txt.gz
Description: GNU Zip compressed data


dmesg.offb.txt.gz
Description: GNU Zip compressed data


fbset.offb.txt.gz
Description: GNU Zip compressed data


iomem.offb.txt.gz
Description: GNU Zip compressed data

Bug#826629: Possible offb unload fix.

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 08:41:45PM +0200, Mathieu Malaterre wrote:
> Hi Len,
> 
> Here is the release function I am using:
> 
> static void offb_destroy(struct fb_info *info)
> {
> struct offb_par *par = (struct offb_par *) info->par;
> if (info->screen_base)
> iounmap(info->screen_base);
> if (par->cmap_adr != NULL) {
> iounmap(par->cmap_adr);
> par->cmap_adr = NULL;
> }
> release_mem_region(info->apertures->ranges[0].base,
> info->apertures->ranges[0].size);
> framebuffer_release(info);
> }
> 
> 
> (you need the cast to avoid warning about deref of void*).
> 
> And if I do `modprobe radeonfb`:
> 
> [   72.163546] bus: 'pci': add driver radeonfb
> [   72.163618] bus: 'pci': driver_probe_device: matched device
> :00:10.0 with driver radeonfb
> [   72.163627] bus: 'pci': really_probe: probing driver radeonfb with
> device :00:10.0
> [   72.163651] devices_kset: Moving :00:10.0 to end of list
> [   72.163659] radeonfb_pci_register BEGIN
> [   72.163680] radeonfb :00:10.0: enabling device (0006 -> 0007)
> [   72.163721] radeonfb :00:10.0: BAR 0: can't reserve [mem
> 0x9800-0x9fff pref]
> [   72.163726] radeonfb (:00:10.0): cannot request region 0.
> [   72.163746] radeonfb: probe of :00:10.0 failed with error -16

Could you put a print statement in offb_destroy to make sure that is
actually being called?

And this is radeonfb with code added to actually try to kick out offb,
right?

-- 
Len Sorensen

Bug#826629: Possible offb unload fix.

[Mathieu Malaterre]

Hi Len,

Here is the release function I am using:

static void offb_destroy(struct fb_info *info)
{
struct offb_par *par = (struct offb_par *) info->par;
if (info->screen_base)
iounmap(info->screen_base);
if (par->cmap_adr != NULL) {
iounmap(par->cmap_adr);
par->cmap_adr = NULL;
}
release_mem_region(info->apertures->ranges[0].base,
info->apertures->ranges[0].size);
framebuffer_release(info);
}


(you need the cast to avoid warning about deref of void*).

And if I do `modprobe radeonfb`:

[   72.163546] bus: 'pci': add driver radeonfb
[   72.163618] bus: 'pci': driver_probe_device: matched device
:00:10.0 with driver radeonfb
[   72.163627] bus: 'pci': really_probe: probing driver radeonfb with
device :00:10.0
[   72.163651] devices_kset: Moving :00:10.0 to end of list
[   72.163659] radeonfb_pci_register BEGIN
[   72.163680] radeonfb :00:10.0: enabling device (0006 -> 0007)
[   72.163721] radeonfb :00:10.0: BAR 0: can't reserve [mem
0x9800-0x9fff pref]
[   72.163726] radeonfb (:00:10.0): cannot request region 0.
[   72.163746] radeonfb: probe of :00:10.0 failed with error -16

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 08:20:13AM +0200, Mathieu Malaterre wrote:
> Hi,
> 
> > Well it seems ATY,Rockhopper2 (not Rockhopper) in the Mac Mini is in fact
> > a Radeon, and the way the radeonfb driver handles the pallete appears
> > to match the cmap_radeon in offb, so perhaps this would work in offb.c
> 
> I had time to test this patch yesterday night. It did not work using
> `cmap_radeon` codepath. I even tried changing:
> 
> out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));
> 
> into:
> 
> out_le32(par->cmap_adr + 0xb4, (blue << 16 | green << 8 | red));
> 
> I am also thinking we are not looking at the right code.
> 
> I can see my `printk` messages so I know we are entering the
> `cmap_radeon` codepath.

Well radeonfb uses:

OUTREG(PALETTE_INDEX, pindex);
OUTREG(PALETTE_DATA, (red << 16) |
   (green << 8) | blue);

which is :

writel(pindex, (rinfo->mmio_base)+0x00B0)
writel((red << 16) | (green << 8) | blue), 
(rinfo->mmio_base)+0x00B4)

offb in cmap_radeon mode uses:
out_8(par->cmap_adr + 0xb0, regno);
out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));

Not sure if using out_8 for the index versus using a 32 bit write makes
a difference.  I highly doubt it.

The memory being mapped is 0x4000 in size for radeonfb and 0x2000 in offb.
For the colour table that sounds plenty big.

Of course radeonfb is using pci functions to get the memory range while
offb uses OF calls.  The dmesg output I have seen so far seems to indicate
these are both returning the same thing, so that is not likely to be
the problem.

As for radeon driver, it appears to me that it pretty much always runs
32 bit truecolor, which should solve any palette problems by not using
them.

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 04:47:21PM +0200, Mathieu Malaterre wrote:
> Yes. If you re-read my post on debian-powerpc :) But getting `modprobe
> radeonfb` to work does not work as you know very well :)
> So the userland code in bterm is correct (no big endian issue).

Yes I also really doubt this is a bterm problem.

I was hoping my offb patch would solve the modprobe radeonfb problem by
freeing the pallete data memory to allow radeonfb to grab all the memory.

> Will do tonight. I can send the fbset output too.

Great.

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Mathieu Malaterre]

On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
 wrote:
> On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
>> € grep bogl_set_palette *
>> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
>> bogl.c: bogl_set_palette = bogl_fb_set_palette;
>> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
>> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
>> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
>> palette[][3]);
>> bogl-test.c:  bogl_set_palette (0, 16, palette);
>> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
>> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
>> bterm.c:  bogl_set_palette(0, 16, palette);
>> bterm.c:bogl_set_palette(0, 16, palette);
>> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
>>
>> It looks like bterm always set only colors 0-15.
>
> So it does.  Hmm, I will compare the code some more.
>
> Has it been confirmed that radeonfb does not have wrong colours while
> offb on the same machine does?

Yes. If you re-read my post on debian-powerpc :) But getting `modprobe
radeonfb` to work does not work as you know very well :)
So the userland code in bterm is correct (no big endian issue).

> And what video mode does radeonfb run with?  I wish someone had dmesg
> dumps of both offb and radeonfb, but I am not having much luck finding
> any with google.

Will do tonight. I can send the fbset output too.

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
> € grep bogl_set_palette *
> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
> bogl.c: bogl_set_palette = bogl_fb_set_palette;
> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
> bogl.c:   the palette with bogl_set_palette() for this to take effect. */
> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
> palette[][3]);
> bogl-test.c:  bogl_set_palette (0, 16, palette);
> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
> bterm.c:  bogl_set_palette(0, 16, palette);
> bterm.c:bogl_set_palette(0, 16, palette);
> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
> 
> It looks like bterm always set only colors 0-15.

So it does.  Hmm, I will compare the code some more.

Has it been confirmed that radeonfb does not have wrong colours while
offb on the same machine does?

And what video mode does radeonfb run with?  I wish someone had dmesg
dumps of both offb and radeonfb, but I am not having much luck finding
any with google.

-- 
Len Sorensen

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Samuel Thibault]

Lennart Sorensen, on Tue 04 Oct 2016 09:41:34 -0400, wrote:
> while with TERM=bterm
> it might be trying to create custom colours, which puts it into the
> higher range where different handling is done for the pallete and
> cmap_simple no longer works on the radeon.

€ grep bogl_set_palette *
bogl.c:  bogl_set_palette = bogl_fb_set_palette;
bogl.c:   bogl_set_palette = bogl_fb_set_palette;
bogl.c:   bogl_set_palette = bogl_tcfb_set_palette;
bogl.c:   the palette with bogl_set_palette() for this to take effect. */
bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
palette[][3]);
bogl-test.c:  bogl_set_palette (0, 16, palette);
bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) palette);
bterm.c:  bogl_set_palette(0, 16, palette);
bterm.c:  bogl_set_palette(0, 16, palette);
ChangeLog:  * bterm.c (main): Call bogl_set_palette after VT switch.

It looks like bterm always set only colors 0-15.

Samuel

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Tue, Oct 04, 2016 at 08:20:13AM +0200, Mathieu Malaterre wrote:
> I had time to test this patch yesterday night. It did not work using
> `cmap_radeon` codepath. I even tried changing:
> 
> out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));
> 
> into:
> 
> out_le32(par->cmap_adr + 0xb4, (blue << 16 | green << 8 | red));
> 
> I am also thinking we are not looking at the right code.
> 
> I can see my `printk` messages so I know we are entering the
> `cmap_radeon` codepath.

But radeonfb works?

I was comparing the code in radeonfb to offb which is why I thought
using the colour setting code in cmap_radeon should work.

It looks like for the first 16 palette entries, something special is
done that matches cmap_simple, which might explain why the TERM=linux case
works, if it just uses the standard 16 colours, while with TERM=bterm
it might be trying to create custom colours, which puts it into the
higher range where different handling is done for the pallete and
cmap_simple no longer works on the radeon.

It is also likely that if you booted in 24bit or 32bit colour mode
instead of 8 bit, it would work too, since that too is done differently.
Might be interesting to try if there is an easy way to try that.

-- 
Len Sorensen

Bug#839671: linux-image-4.7.0-1-amd64: NEWS should document conntrack policy changes

[Matthew Gabeler-Lee]

On Mon, 3 Oct 2016, Ben Hutchings wrote:


The kernel has warned about reliance on auto-loading conntrack helpers
since 3.5, so this should not be surprising.


How many people do you think really peruse dmesg for low level warnings? 
Esp. considering that the kernel boot messages aren't even printed on 
the console any more.


A warning that isn't displayed anywhere is not much of a warning IMO.

In my case it wasn't even printed during the boot / firewall startup, 
but some four hours later (when I guess the first time a conntrack rule 
failed to operate in the legacy way hit), so even if I checked the logs 
during the firewall startup, when the iptables rules that don't work any 
more were added, it wouldn't have helped me.


--
-Matt
"Reality is that which, when you stop believing in it, doesn't go away".
-- Philip K. Dick
GPG fingerprint: 0061 15DF D282 D4A9 57CE  77C5 16AF 1460 4A3C C4E9

Re: Bug#838919: Swap file

[Philipp Kern]

On 10/04/2016 01:53 AM, Mert Dirik wrote:
> https://wiki.debian.org/Hibernation/Hibernate_Without_Swap_Partition
> 
> Swap files are much more flexible & easier to handle compared to
> messing with partitions and there are only few cases where they don't
> apply. The discussion about predicting swap sizes for hibernation or
> enlarging partitions is completely unnecessary in this context.

It does require that you physically allocate the file (e.g. by writing
zeros, not using truncation/fallocate), which is a little sad on SSDs.
On the other hand a few gigabytes written at install time probably don't
matter much. Also it doesn't work on btrfs. But I do wonder if there are
other real-world drawbacks these days with swap files, given that the
kernel should know the block list on disk and the penalty should hence
be small...

Kind regards and thanks
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Mathieu Malaterre]

Hi,

> Well it seems ATY,Rockhopper2 (not Rockhopper) in the Mac Mini is in fact
> a Radeon, and the way the radeonfb driver handles the pallete appears
> to match the cmap_radeon in offb, so perhaps this would work in offb.c

I had time to test this patch yesterday night. It did not work using
`cmap_radeon` codepath. I even tried changing:

out_le32(par->cmap_adr + 0xb4, (red << 16 | green << 8 | blue));

into:

out_le32(par->cmap_adr + 0xb4, (blue << 16 | green << 8 | red));

I am also thinking we are not looking at the right code.

I can see my `printk` messages so I know we are entering the
`cmap_radeon` codepath.

-M