Re: [PATCH] fbcon: Increase maximum font width x height to 64 x 64

2024-03-15 Thread Samuel Thibault 
Hello,

Helge Deller, le ven. 15 mars 2024 10:35:40 +0100, a ecrit:
> You should have marked this patch with "v2"...

The actual changes were exactly the same.

> On 3/13/24 17:59, Samuel Thibault wrote:
> > This remains relatively simple by just enlarging integers.
> 
> I like the patch, but I still see some u32...
> drivers/video/fbdev/vt8623fb.c: info->pixmap.blit_x = (bpp == 4) ? (1 
> << (8 - 1)) : (~(u32)0);
> drivers/video/fbdev/arkfb.c:info->pixmap.blit_x = (bpp == 4) ? (1 
> << (8 - 1)) : (~(u32)0);
> drivers/video/fbdev/core/fbmem.c:   fb_info->pixmap.blit_x = 
> ~(u32)0;
> drivers/video/fbdev/s3fb.c: info->pixmap.blit_x = (bpp == 4) ? (1 
> << (8 - 1)) : (~(u32)0);

Oops, I missed including these modifications indeed.

> > It wouldn't be that simple to get to the console's 64x128 maximum, as it 
> > would
> > require 128b integers.
> 
> How realistic are fonts > 64x64 pixels ?

With 4K displays, 64x128 brings 60x16 text console, which is useful for
people with low vision.

> If they are, using the bitmap_xx functions (include/linux/bitmap.h)
> now instead would be better.

Ok, I have now done this in v2. We'll be able to easily increase the
font size when 8K displays get out :)

Samuel

[PATCHv2] fbcon: Increase maximum font width x height to 64 x 128

2024-03-15 Thread Samuel Thibault 
By using bitmaps we actually support whatever size we would want, but the
console currently limits fonts to 64x128 (which gives 60x16 text on 4k
screens), so we don't need more for now, and we can easily increase later.

Signed-off-by: Samuel Thibault 

---
Difference from v1:
- use a bitmap rather than just extending the integer size
- add missing updates in drivers
---
 drivers/firmware/efi/earlycon.c|  2 +-
 drivers/video/fbdev/arkfb.c| 15 +++
 drivers/video/fbdev/core/fbcon.c   | 16 +---
 drivers/video/fbdev/core/fbmem.c   | 12 ++--
 drivers/video/fbdev/core/svgalib.c | 15 +++
 drivers/video/fbdev/s3fb.c | 15 +++
 drivers/video/fbdev/vga16fb.c  |  6 +-
 drivers/video/fbdev/vt8623fb.c | 15 +++
 include/linux/fb.h | 18 --
 include/linux/font.h   |  3 ++-
 lib/fonts/fonts.c  | 15 +--
 11 files changed, 88 insertions(+), 44 deletions(-)

diff --git a/drivers/firmware/efi/earlycon.c b/drivers/firmware/efi/earlycon.c
index f80a9af3d16e..d18a1a5de144 100644
--- a/drivers/firmware/efi/earlycon.c
+++ b/drivers/firmware/efi/earlycon.c
@@ -252,7 +252,7 @@ static int __init efi_earlycon_setup(struct earlycon_device 
*device,
if (si->lfb_depth != 32)
return -ENODEV;
 
-   font = get_default_font(xres, yres, -1, -1);
+   font = get_default_font(xres, yres, NULL, NULL);
if (!font)
return -ENODEV;
 
diff --git a/drivers/video/fbdev/arkfb.c b/drivers/video/fbdev/arkfb.c
index dca9c0325b3f..082501feceb9 100644
--- a/drivers/video/fbdev/arkfb.c
+++ b/drivers/video/fbdev/arkfb.c
@@ -622,8 +622,13 @@ static int arkfb_set_par(struct fb_info *info)
info->tileops = NULL;
 
/* in 4bpp supports 8p wide tiles only, any tiles otherwise */
-   info->pixmap.blit_x = (bpp == 4) ? (1 << (8 - 1)) : (~(u32)0);
-   info->pixmap.blit_y = ~(u32)0;
+   if (bpp == 4) {
+   bitmap_zero(info->pixmap.blit_x, FB_MAX_BLIT_WIDTH);
+   set_bit(8 - 1, info->pixmap.blit_x);
+   } else {
+   bitmap_fill(info->pixmap.blit_x, FB_MAX_BLIT_WIDTH);
+   }
+   bitmap_fill(info->pixmap.blit_y, FB_MAX_BLIT_HEIGHT);
 
offset_value = (info->var.xres_virtual * bpp) / 64;
screen_size = info->var.yres_virtual * info->fix.line_length;
@@ -635,8 +640,10 @@ static int arkfb_set_par(struct fb_info *info)
info->tileops = _tile_ops;
 
/* supports 8x16 tiles only */
-   info->pixmap.blit_x = 1 << (8 - 1);
-   info->pixmap.blit_y = 1 << (16 - 1);
+   bitmap_zero(info->pixmap.blit_x, FB_MAX_BLIT_WIDTH);
+   set_bit(8 - 1, info->pixmap.blit_x);
+   bitmap_zero(info->pixmap.blit_y, FB_MAX_BLIT_HEIGHT);
+   set_bit(16 - 1, info->pixmap.blit_y);
 
offset_value = info->var.xres_virtual / 16;
screen_size = (info->var.xres_virtual * info->var.yres_virtual) 
/ 64;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 46823c2e2ba1..72ff3147a3bf 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2483,12 +2483,12 @@ static int fbcon_set_font(struct vc_data *vc, struct 
console_font *font,
h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
return -EINVAL;
 
-   if (font->width > 32 || font->height > 32)
+   if (font->width > FB_MAX_BLIT_WIDTH || font->height > 
FB_MAX_BLIT_HEIGHT)
return -EINVAL;
 
/* Make sure drawing engine can handle the font */
-   if (!(info->pixmap.blit_x & BIT(font->width - 1)) ||
-   !(info->pixmap.blit_y & BIT(font->height - 1)))
+   if (!test_bit(font->width - 1, info->pixmap.blit_x) ||
+   !test_bit(font->height - 1, info->pixmap.blit_y))
return -EINVAL;
 
/* Make sure driver can handle the font length */
@@ -3082,8 +3082,8 @@ void fbcon_get_requirement(struct fb_info *info,
vc = vc_cons[i].d;
if (vc && vc->vc_mode == KD_TEXT &&
info->node == con2fb_map[i]) {
-   caps->x |= 1 << (vc->vc_font.width - 1);
-   caps->y |= 1 << (vc->vc_font.height - 1);
+   set_bit(vc->vc_font.width - 1, caps->x);
+   set_bit(vc->vc_font.height - 1, caps->y);
charcnt = vc->vc_font.charcount;

Re: [PATCH] fbcon: Increase maximum font width x height to 64 x 64

2024-03-13 Thread Samuel Thibault 
Luca Ceresoli, le mer. 13 mars 2024 17:45:31 +0100, a ecrit:
> This patch is clearly not formatted according to the standard format
> and it does not apply with 'git am'.

(Note: the failure of application was not related to the formatting at
all, but just a little fuzz for the static word in

static struct fb_info *fbcon_registered_fb[FB_MAX];

that git doesn't seem to be able to just cope with)

Samuel

[PATCH] fbcon: Increase maximum font width x height to 64 x 64

2024-03-13 Thread Samuel Thibault 
This remains relatively simple by just enlarging integers.

It wouldn't be that simple to get to the console's 64x128 maximum, as it would
require 128b integers.

Signed-off-by: Samuel Thibault 
---
 drivers/video/fbdev/core/fbcon.c | 17 ++---
 include/linux/fb.h   | 10 +-
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 46823c2e2ba1..849562f92bd5 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -101,6 +101,9 @@ enum {
FBCON_LOGO_DONTSHOW = -3/* do not show the logo */
 };
 
+#define FBCON_MAX_FONT_WIDTH   (sizeof(((struct fb_pixmap *) 0)->blit_x) * 8)
+#define FBCON_MAX_FONT_HEIGHT  (sizeof(((struct fb_pixmap *) 0)->blit_y) * 8)
+
 static struct fbcon_display fb_display[MAX_NR_CONSOLES];
 
 static struct fb_info *fbcon_registered_fb[FB_MAX];
@@ -2483,12 +2486,12 @@ static int fbcon_set_font(struct vc_data *vc, struct 
console_font *font,
h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
return -EINVAL;
 
-   if (font->width > 32 || font->height > 32)
+   if (font->width > FBCON_MAX_FONT_WIDTH || font->height > 
FBCON_MAX_FONT_HEIGHT)
return -EINVAL;
 
/* Make sure drawing engine can handle the font */
-   if (!(info->pixmap.blit_x & BIT(font->width - 1)) ||
-   !(info->pixmap.blit_y & BIT(font->height - 1)))
+   if (!(info->pixmap.blit_x & BIT_ULL(font->width - 1)) ||
+   !(info->pixmap.blit_y & BIT_ULL(font->height - 1)))
return -EINVAL;
 
/* Make sure driver can handle the font length */
@@ -3082,8 +3085,8 @@ void fbcon_get_requirement(struct fb_info *info,
vc = vc_cons[i].d;
if (vc && vc->vc_mode == KD_TEXT &&
info->node == con2fb_map[i]) {
-   caps->x |= 1 << (vc->vc_font.width - 1);
-   caps->y |= 1 << (vc->vc_font.height - 1);
+   caps->x |= 1ULL << (vc->vc_font.width - 1);
+   caps->y |= 1ULL << (vc->vc_font.height - 1);
charcnt = vc->vc_font.charcount;
if (caps->len < charcnt)
caps->len = charcnt;
@@ -3094,8 +3097,8 @@ void fbcon_get_requirement(struct fb_info *info,
 
if (vc && vc->vc_mode == KD_TEXT &&
info->node == con2fb_map[fg_console]) {
-   caps->x = 1 << (vc->vc_font.width - 1);
-   caps->y = 1 << (vc->vc_font.height - 1);
+   caps->x = 1ULL << (vc->vc_font.width - 1);
+   caps->y = 1ULL << (vc->vc_font.height - 1);
caps->len = vc->vc_font.charcount;
}
}
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 05dc9624897d..2bac166cd3f2 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -144,8 +144,8 @@ struct fb_event {
 };
 
 struct fb_blit_caps {
-   u32 x;
-   u32 y;
+   u64 x;
+   u64 y;
u32 len;
u32 flags;
 };
@@ -192,10 +192,10 @@ struct fb_pixmap {
u32 scan_align; /* alignment per scanline   */
u32 access_align;   /* alignment per read/write (bits)  */
u32 flags;  /* see FB_PIXMAP_*  */
-   u32 blit_x; /* supported bit block dimensions (1-32)*/
-   u32 blit_y; /* Format: blit_x = 1 << (width - 1)*/
+   u64 blit_x; /* supported bit block dimensions (1-64)*/
+   u64 blit_y; /* Format: blit_x = 1 << (width - 1)*/
/* blit_y = 1 << (height - 1)   */
-   /* if 0, will be set to 0x (all)*/
+   /* if 0, will be set to ~0ull (all) */
/* access methods */
void (*writeio)(struct fb_info *info, void __iomem *dst, void *src, 
unsigned int size);
void (*readio) (struct fb_info *info, void *dst, void __iomem *src, 
unsigned int size);
-- 
2.39.2

Re: [PATCH] fbcon: Increase maximum font width x height to 64 x 64

2024-03-13 Thread Samuel Thibault 
Luca Ceresoli, le mer. 13 mars 2024 17:45:31 +0100, a ecrit:
> Using 'git format-patch' and 'git send-email' is *very* recommended as
> it will take care of all the formatting for you.

It's quite a pitty that git cannot simply consume the output of diff.

Now I'll have to download 8GB of linux tree only for a simple patch...

Samuel

[PATCH] fbcon: Increase maximum font width x height to 64 x 64

2024-03-12 Thread Samuel Thibault 
This remains relatively simple by just enlarging integers.

It wouldn't be that simple to get to the console's 64x128 maximum, as it would
require 128b integers.

Signed-off-by: Samuel Thibault 

Index: linux-6.4/drivers/video/fbdev/core/fbcon.c
===
--- linux-6.4.orig/drivers/video/fbdev/core/fbcon.c
+++ linux-6.4/drivers/video/fbdev/core/fbcon.c
@@ -101,6 +101,9 @@ enum {
FBCON_LOGO_DONTSHOW = -3/* do not show the logo */
 };
 
+#define FBCON_MAX_FONT_WIDTH   (sizeof(((struct fb_pixmap *) 0)->blit_x) * 8)
+#define FBCON_MAX_FONT_HEIGHT  (sizeof(((struct fb_pixmap *) 0)->blit_y) * 8)
+
 static struct fbcon_display fb_display[MAX_NR_CONSOLES];
 
 struct fb_info *fbcon_registered_fb[FB_MAX];
@@ -2485,12 +2488,12 @@ static int fbcon_set_font(struct vc_data
h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
return -EINVAL;
 
-   if (font->width > 32 || font->height > 32)
+   if (font->width > FBCON_MAX_FONT_WIDTH || font->height > 
FBCON_MAX_FONT_HEIGHT)
return -EINVAL;
 
/* Make sure drawing engine can handle the font */
-   if (!(info->pixmap.blit_x & BIT(font->width - 1)) ||
-   !(info->pixmap.blit_y & BIT(font->height - 1)))
+   if (!(info->pixmap.blit_x & BIT_ULL(font->width - 1)) ||
+   !(info->pixmap.blit_y & BIT_ULL(font->height - 1)))
return -EINVAL;
 
/* Make sure driver can handle the font length */
@@ -3084,8 +3087,8 @@ void fbcon_get_requirement(struct fb_inf
vc = vc_cons[i].d;
if (vc && vc->vc_mode == KD_TEXT &&
info->node == con2fb_map[i]) {
-   caps->x |= 1 << (vc->vc_font.width - 1);
-   caps->y |= 1 << (vc->vc_font.height - 1);
+   caps->x |= 1ULL << (vc->vc_font.width - 1);
+   caps->y |= 1ULL << (vc->vc_font.height - 1);
charcnt = vc->vc_font.charcount;
if (caps->len < charcnt)
caps->len = charcnt;
@@ -3096,8 +3099,8 @@ void fbcon_get_requirement(struct fb_inf
 
if (vc && vc->vc_mode == KD_TEXT &&
info->node == con2fb_map[fg_console]) {
-   caps->x = 1 << (vc->vc_font.width - 1);
-   caps->y = 1 << (vc->vc_font.height - 1);
+   caps->x = 1ULL << (vc->vc_font.width - 1);
+   caps->y = 1ULL << (vc->vc_font.height - 1);
caps->len = vc->vc_font.charcount;
}
}
Index: linux-6.4/include/linux/fb.h
===
--- linux-6.4.orig/include/linux/fb.h
+++ linux-6.4/include/linux/fb.h
@@ -143,8 +143,8 @@ struct fb_event {
 };
 
 struct fb_blit_caps {
-   u32 x;
-   u32 y;
+   u64 x;
+   u64 y;
u32 len;
u32 flags;
 };
@@ -191,10 +191,10 @@ struct fb_pixmap {
u32 scan_align; /* alignment per scanline   */
u32 access_align;   /* alignment per read/write (bits)  */
u32 flags;  /* see FB_PIXMAP_*  */
-   u32 blit_x; /* supported bit block dimensions (1-32)*/
-   u32 blit_y; /* Format: blit_x = 1 << (width - 1)*/
+   u64 blit_x; /* supported bit block dimensions (1-64)*/
+   u64 blit_y; /* Format: blit_x = 1 << (width - 1)*/
/* blit_y = 1 << (height - 1)   */
-   /* if 0, will be set to 0x (all)*/
+   /* if 0, will be set to ~0ull (all) */
/* access methods */
void (*writeio)(struct fb_info *info, void __iomem *dst, void *src, 
unsigned int size);
void (*readio) (struct fb_info *info, void *dst, void __iomem *src, 
unsigned int size);

[PATCH] VT: Protect KD_FONT_OP_GET_TALL from unbound access

2023-03-06 Thread Samuel Thibault 
In ioctl(KD_FONT_OP_GET_TALL), userland tells through op->height which
vpitch should be used to copy over the font. In con_font_get, we were
not checking that it is within the maximum height value, and thus
userland could make the vc->vc_sw->con_font_get(vc, , vpitch);
call possibly overflow the allocated max_font_size bytes, and the
copy_to_user(op->data, font.data, c) call possibly read out of that
allocated buffer.

By checking vpitch against max_font_height, the max_font_size buffer
will always be large enough for the vc->vc_sw->con_font_get(vc, ,
vpitch) call (since we already prevent loading a font larger than that),
and c = (font.width+7)/8 * vpitch * font.charcount will always remain
below max_font_size.

Fixes: 24d69384bcd3 ("VT: Add KD_FONT_OP_SET/GET_TALL operations")
Reported-by: syzbot+3af17071816b61e80...@syzkaller.appspotmail.com
Signed-off-by: Samuel Thibault 
Reviewed-by: Jiri Slaby 

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 57a5c23b51d4..3c2ea9c098f7 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -4545,6 +4545,9 @@ static int con_font_get(struct vc_data *vc, struct 
console_font_op *op)
int c;
unsigned int vpitch = op->op == KD_FONT_OP_GET_TALL ? op->height : 32;
 
+   if (vpitch > max_font_height)
+   return -EINVAL;
+
if (op->data) {
font.data = kvmalloc(max_font_size, GFP_KERNEL);
if (!font.data)

[PATCHv2] fbcon: Check font dimension limits

2023-01-29 Thread Samuel Thibault 
blit_x and blit_y are u32, so fbcon currently cannot support fonts
larger than 32x32.

The 32x32 case also needs shifting an unsigned int, to properly set bit
31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
as reported on:

http://lore.kernel.org/all/ia1pr07mb98308653e259a6f2ce94a4afab...@ia1pr07mb9830.namprd07.prod.outlook.com
Kernel Branch: 6.2.0-rc5-next-20230124
Kernel config: 
https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
Reproducer: 
https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharing

Reported-by: Sanan Hasanov 
Signed-off-by: Samuel Thibault 
Fixes: 2d2699d98492 ("fbcon: font setting should check limitation of driver")
Cc: sta...@vger.kernel.org

---
v1 -> v2:
- Use BIT macro instead of fixing bit test by hand.
- Add Fixes and Cc: stable headers.

Index: linux-6.0/drivers/video/fbdev/core/fbcon.c
===
--- linux-6.0.orig/drivers/video/fbdev/core/fbcon.c
+++ linux-6.0/drivers/video/fbdev/core/fbcon.c
@@ -2489,9 +2489,12 @@ static int fbcon_set_font(struct vc_data
h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
return -EINVAL;
 
+   if (font->width > 32 || font->height > 32)
+   return -EINVAL;
+
/* Make sure drawing engine can handle the font */
-   if (!(info->pixmap.blit_x & (1 << (font->width - 1))) ||
-   !(info->pixmap.blit_y & (1 << (font->height - 1
+   if (!(info->pixmap.blit_x & BIT(font->width - 1)) ||
+   !(info->pixmap.blit_y & BIT(font->height - 1)))
return -EINVAL;
 
/* Make sure driver can handle the font length */

Re: [PATCH] fbcon: Check font dimension limits

2023-01-29 Thread Samuel Thibault 
Jiri Slaby, le jeu. 26 janv. 2023 10:02:55 +0100, a ecrit:
> On 26. 01. 23, 1:49, Samuel Thibault wrote:
> > Index: linux-6.0/drivers/video/fbdev/core/fbcon.c
> > ===
> > --- linux-6.0.orig/drivers/video/fbdev/core/fbcon.c
> > +++ linux-6.0/drivers/video/fbdev/core/fbcon.c
> > @@ -2489,9 +2489,12 @@ static int fbcon_set_font(struct vc_data
> > h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
> > return -EINVAL;
> > +   if (font->width > 32 || font->height > 32)
> > +   return -EINVAL;
> > +
> > /* Make sure drawing engine can handle the font */
> > -   if (!(info->pixmap.blit_x & (1 << (font->width - 1))) ||
> > -   !(info->pixmap.blit_y & (1 << (font->height - 1
> > +   if (!(info->pixmap.blit_x & (1U << (font->width - 1))) ||
> > +   !(info->pixmap.blit_y & (1U << (font->height - 1
> 
> So use BIT() properly then? That should be used in all these shifts anyway.
> Exactly to avoid UB.

Right, I'll use that in next version.

Samuel

Re: [PATCH] fbcon: Check font dimension limits

2023-01-29 Thread Samuel Thibault 
Greg KH, le jeu. 26 janv. 2023 08:43:02 +0100, a ecrit:
> On Thu, Jan 26, 2023 at 01:49:12AM +0100, Samuel Thibault wrote:
> > blit_x and blit_y are uint32_t, so fbcon currently cannot support fonts
> > larger than 32x32.
> 
> "u32" you mean, right?

Right :)

> > The 32x32 case also needs shifting an unsigned int, to properly set bit
> > 31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
> > as reported on
> > 
> > http://lore.kernel.org/all/ia1pr07mb98308653e259a6f2ce94a4afab...@ia1pr07mb9830.namprd07.prod.outlook.com
> 
> Odd blank line?

Not sure what you mean? I found it easier to read to put a blank line
between the text and the references.

> > Kernel Branch: 6.2.0-rc5-next-20230124
> > Kernel config: 
> > https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
> > Reproducer: 
> > https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharing
> 
> What are all of these lines for?

They provide the references that were set in the original report

http://lore.kernel.org/all/ia1pr07mb98308653e259a6f2ce94a4afab...@ia1pr07mb9830.namprd07.prod.outlook.com

Arguably the "branch" and "config" are not that useful since the bug has
been there for more than a dozen years, but notably the "Reproducer" is
useful to provide a userland program that triggers the UB.

> > Reported-by: Sanan Hasanov 
> > Signed-off-by: Samuel Thibault 
> 
> What commit id does this fix?

I though it was there forever, but it seems the check was added in 2007,
so I'll add it in next version.

> Should it go to stable kernels?

Yes. I added stable in Cc of the mail but missed adding it in the text,
I will add it.

> > Index: linux-6.0/drivers/video/fbdev/core/fbcon.c
> > ===
> > --- linux-6.0.orig/drivers/video/fbdev/core/fbcon.c
> > +++ linux-6.0/drivers/video/fbdev/core/fbcon.c
> > @@ -2489,9 +2489,12 @@ static int fbcon_set_font(struct vc_data
> > h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
> > return -EINVAL;
> >  
> > +   if (font->width > 32 || font->height > 32)
> > +   return -EINVAL;
> > +
> > /* Make sure drawing engine can handle the font */
> > -   if (!(info->pixmap.blit_x & (1 << (font->width - 1))) ||
> > -   !(info->pixmap.blit_y & (1 << (font->height - 1
> > +   if (!(info->pixmap.blit_x & (1U << (font->width - 1))) ||
> > +   !(info->pixmap.blit_y & (1U << (font->height - 1
> 
> Are you sure this is still needed with the above check added?  If so,
> why?  What is the difference in the compiled code?

As mentioned by Jiri, yes in the 32 case it's needed otherwise it's UB.

Samuel

[PATCH] fbcon: Check font dimension limits

2023-01-26 Thread Samuel Thibault 
blit_x and blit_y are uint32_t, so fbcon currently cannot support fonts
larger than 32x32.

The 32x32 case also needs shifting an unsigned int, to properly set bit
31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
as reported on

http://lore.kernel.org/all/ia1pr07mb98308653e259a6f2ce94a4afab...@ia1pr07mb9830.namprd07.prod.outlook.com
Kernel Branch: 6.2.0-rc5-next-20230124
Kernel config: 
https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
Reproducer: 
https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharing

Reported-by: Sanan Hasanov 
Signed-off-by: Samuel Thibault 

Index: linux-6.0/drivers/video/fbdev/core/fbcon.c
===
--- linux-6.0.orig/drivers/video/fbdev/core/fbcon.c
+++ linux-6.0/drivers/video/fbdev/core/fbcon.c
@@ -2489,9 +2489,12 @@ static int fbcon_set_font(struct vc_data
h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
return -EINVAL;
 
+   if (font->width > 32 || font->height > 32)
+   return -EINVAL;
+
/* Make sure drawing engine can handle the font */
-   if (!(info->pixmap.blit_x & (1 << (font->width - 1))) ||
-   !(info->pixmap.blit_y & (1 << (font->height - 1
+   if (!(info->pixmap.blit_x & (1U << (font->width - 1))) ||
+   !(info->pixmap.blit_y & (1U << (font->height - 1
return -EINVAL;
 
/* Make sure driver can handle the font length */

Re: [PATCH] fbcon: Check font dimension limits

2023-01-26 Thread Samuel Thibault 
(FYI, the UB was already a problem before my big-font patch submission,
the checks I add here are already making sense in previous versions
anyway)

Samuel Thibault, le jeu. 26 janv. 2023 01:49:12 +0100, a ecrit:
> blit_x and blit_y are uint32_t, so fbcon currently cannot support fonts
> larger than 32x32.
> 
> The 32x32 case also needs shifting an unsigned int, to properly set bit
> 31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
> as reported on
> 
> http://lore.kernel.org/all/ia1pr07mb98308653e259a6f2ce94a4afab...@ia1pr07mb9830.namprd07.prod.outlook.com
> Kernel Branch: 6.2.0-rc5-next-20230124
> Kernel config: 
> https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
> Reproducer: 
> https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharing
> 
> Reported-by: Sanan Hasanov 
> Signed-off-by: Samuel Thibault 
> 
> Index: linux-6.0/drivers/video/fbdev/core/fbcon.c
> ===
> --- linux-6.0.orig/drivers/video/fbdev/core/fbcon.c
> +++ linux-6.0/drivers/video/fbdev/core/fbcon.c
> @@ -2489,9 +2489,12 @@ static int fbcon_set_font(struct vc_data
>   h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
>   return -EINVAL;
>  
> + if (font->width > 32 || font->height > 32)
> + return -EINVAL;
> +
>   /* Make sure drawing engine can handle the font */
> - if (!(info->pixmap.blit_x & (1 << (font->width - 1))) ||
> - !(info->pixmap.blit_y & (1 << (font->height - 1
> + if (!(info->pixmap.blit_x & (1U << (font->width - 1))) ||
> + !(info->pixmap.blit_y & (1U << (font->height - 1
>   return -EINVAL;
>  
>   /* Make sure driver can handle the font length */
> 
>

[i915] assert_device_not_suspended

2015-04-14 Thread Samuel Thibault 
I forgot to mention that this is linux 4.0.0

Samuel

[i915] assert_device_not_suspended

2015-04-14 Thread Samuel Thibault 
Hello,

Yesterday, as usual I ran xlock before the night. In the morning, I
typed a key to wake it up, it didn't. I had to reboot. I could however
read in the logs:

Apr 14 05:00:13 type kernel: [33976.116204] WARNING: CPU: 2 PID: 63 at 
drivers/gpu/drm/i915/intel_uncore.c:69 assert_device_not_suspended+0x45/0x4e 
[i915]()
Apr 14 05:00:13 type kernel: [33976.116206] Device suspended
Apr 14 05:00:13 type kernel: [33976.116206] Modules linked in: tun xt_REDIRECT 
nf_nat_redirect xt_tcpudp ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip_tables 
x_tables binfmt_misc nfsd cpufreq_powersave auth_rpcgss cpufreq_stats 
oid_registry nfs_acl cpufreq_userspace lockd cpufreq_conservative bbswitch(O) 
grace sunrpc joydev hid_generic usbhid hid cdc_mbim cdc_ncm usbnet mii cdc_acm 
cdc_wdm arc4 brcmsmac cordic brcmutil b43 nls_utf8 nls_cp437 mac80211 vfat fat 
cfg80211 x86_pkg_temp_thermal i915 kvm_intel kvm snd_hda_codec_hdmi ssb 
rng_core pcmcia pcmcia_core crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
aesni_intel aes_x86_64 dell_wmi lrw sparse_keymap gf128mul drm_kms_helper 
dell_laptop glue_helper rfkill ablk_helper cryptd drm psmouse dcdbas evdev 
serio_raw bcma i2c_i801 acpi_cpufreq tpm_tis wmi i2c_algo_bit tpm i2c_core 
8250_fintek video ac battery processor button snd_hda_codec_idt 
snd_hda_codec_generic ledtrig_timer ledtrig_oneshot ledtrig_heartbeat 
ledtrig_default_on snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep 
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore coretemp ohci_hcd 
ledtrig_backlight pcspkr i8k firewire_sbp2 firewire_core crc_itu_t loop fuse 
parport_pc ppdev lp parport autofs4 microcode crc32c_intel ehci_pci ehci_hcd 
sdhci_pci sr_mod sdhci cdrom sg mmc_core usbcore e1000e ptp usb_common pps_core 
thermal thermal_sys
Apr 14 05:00:13 type kernel: [33976.116266] CPU: 2 PID: 63 Comm: kswapd0 
Tainted: G   O4.0.0 #87
Apr 14 05:00:13 type kernel: [33976.116267] Hardware name: Dell Inc. Latitude 
E6420/  , BIOS A14 07/11/2012
Apr 14 05:00:13 type kernel: [33976.116268]   0009 
8144544b 8800b1313a88
Apr 14 05:00:13 type kernel: [33976.116270]  8104a9bc 0002 
a0848b37 ea00026dffa0
Apr 14 05:00:13 type kernel: [33976.116272]  8801388b 00100028 
8801388b0068 0010002c
Apr 14 05:00:13 type kernel: [33976.116274] Call Trace:
Apr 14 05:00:13 type kernel: [33976.116280]  [] ? 
dump_stack+0x40/0x50
Apr 14 05:00:13 type kernel: [33976.116284]  [] ? 
warn_slowpath_common+0x98/0xb0
Apr 14 05:00:13 type kernel: [33976.116295]  [] ? 
assert_device_not_suspended+0x45/0x4e [i915]
Apr 14 05:00:13 type kernel: [33976.116297]  [] ? 
warn_slowpath_fmt+0x45/0x4a
Apr 14 05:00:13 type kernel: [33976.116308]  [] ? 
assert_device_not_suspended+0x45/0x4e [i915]
Apr 14 05:00:13 type kernel: [33976.116317]  [] ? 
gen6_write32+0x32/0x83 [i915]
Apr 14 05:00:13 type kernel: [33976.116328]  [] ? 
i915_gem_write_fence+0x270/0x46d [i915]
Apr 14 05:00:13 type kernel: [33976.116337]  [] ? 
i915_gem_object_update_fence+0x40/0xa6 [i915]
Apr 14 05:00:13 type kernel: [33976.116346]  [] ? 
i915_gem_object_put_fence+0xa2/0xac [i915]
Apr 14 05:00:13 type kernel: [33976.116355]  [] ? 
i915_vma_unbind+0xa4/0x1a6 [i915]
Apr 14 05:00:13 type kernel: [33976.116364]  [] ? 
i915_gem_shrink+0x11e/0x178 [i915]
Apr 14 05:00:13 type kernel: [33976.116373]  [] ? 
i915_gem_shrinker_scan+0x60/0x82 [i915]
Apr 14 05:00:13 type kernel: [33976.116376]  [] ? 
shrink_slab.part.53.constprop.71+0x1a6/0x2ac
Apr 14 05:00:13 type kernel: [33976.116379]  [] ? 
shrink_zone+0x6b/0x131
Apr 14 05:00:13 type kernel: [33976.116381]  [] ? 
kswapd+0x57a/0x740
Apr 14 05:00:13 type kernel: [33976.116383]  [] ? 
zone_reclaim+0x1cb/0x1cb
Apr 14 05:00:13 type kernel: [33976.116386]  [] ? 
kthread+0xab/0xb3
Apr 14 05:00:13 type kernel: [33976.116388]  [] ? 
__kthread_parkme+0x5d/0x5d
Apr 14 05:00:13 type kernel: [33976.116389]  [] ? 
ret_from_fork+0x58/0x90
Apr 14 05:00:13 type kernel: [33976.116391]  [] ? 
__kthread_parkme+0x5d/0x5d
Apr 14 05:00:13 type kernel: [33976.116392] ---[ end trace de34697426b2c759 ]---

So it seems it's the reclaiming that triggered an i915 operation while
the graphic card was suspended.

It's probably worth mentioning that I use on my i915 card:

echo auto > /sys/bus/pci/devices/:00:02.0/power/control

In the following days, I'll be trying the attached patch.

Samuel
-- next part --
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5258,6 +5258,11 @@ i915_gem_shrinker_scan(struct shrinker *
if (!i915_gem_shrinker_lock(dev, ))
return SHRINK_STOP;

+   if (HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended)
+   {
+   freed = SHRINK_STOP;
+   goto out;
+   }
freed = i915_gem_shrink(dev_priv,

[REGRESSION FIXED] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2013-01-22 Thread Samuel Thibault 
Hello,

Samuel Thibault, le Thu 05 Jan 2012 10:53:01 +0100, a ?crit :
> Samuel Thibault, le Thu 05 Jan 2012 03:16:46 +0100, a ?crit :
> > Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a ?crit :
> > > Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a ?crit :
> > > > On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault  > > > ens-lyon.org> wrote:
> > > > 
> > > > > At home only. At work, with a different VGA screen, I'm still getting
> > > > > the issue.
> > > > 
> > > > You're still having a problem with the LVDS screen at work with FBC
> > > > disabled?
> > > 
> > > Yes, though it now seems random, sometimes it works, sometimes not.
> > 
> > I have just tried a fresh 3.2 once, without problem. Within a few days,
> > I'll know whether it's luck or magical-fixup.
> 
> It didn't take long. I'm still randomly getting the issue.

I have tried 3.7, I don't have the issue any more (tested for a month
now). Perhaps it was already fixed in 3.6, but not much before.

Samuel

Re: [REGRESSION FIXED] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2013-01-22 Thread Samuel Thibault 
Hello,

Samuel Thibault, le Thu 05 Jan 2012 10:53:01 +0100, a écrit :
 Samuel Thibault, le Thu 05 Jan 2012 03:16:46 +0100, a écrit :
  Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a écrit :
   Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a écrit :
On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault 
samuel.thiba...@ens-lyon.org wrote:

 At home only. At work, with a different VGA screen, I'm still getting
 the issue.

You're still having a problem with the LVDS screen at work with FBC
disabled?
   
   Yes, though it now seems random, sometimes it works, sometimes not.
  
  I have just tried a fresh 3.2 once, without problem. Within a few days,
  I'll know whether it's luck or magical-fixup.
 
 It didn't take long. I'm still randomly getting the issue.

I have tried 3.7, I don't have the issue any more (tested for a month
now). Perhaps it was already fixed in 3.6, but not much before.

Samuel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2012-01-05 Thread Samuel Thibault 
Samuel Thibault, le Thu 05 Jan 2012 03:16:46 +0100, a ?crit :
> Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a ?crit :
> > Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a ?crit :
> > > On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault  > > ens-lyon.org> wrote:
> > > 
> > > > At home only. At work, with a different VGA screen, I'm still getting
> > > > the issue.
> > > 
> > > You're still having a problem with the LVDS screen at work with FBC
> > > disabled?
> > 
> > Yes, though it now seems random, sometimes it works, sometimes not.
> 
> I have just tried a fresh 3.2 once, without problem. Within a few days,
> I'll know whether it's luck or magical-fixup.

It didn't take long. I'm still randomly getting the issue.

Samuel

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2012-01-05 Thread Samuel Thibault 
Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a ?crit :
> Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a ?crit :
> > On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault  > ens-lyon.org> wrote:
> > 
> > > At home only. At work, with a different VGA screen, I'm still getting
> > > the issue.
> > 
> > You're still having a problem with the LVDS screen at work with FBC
> > disabled?
> 
> Yes, though it now seems random, sometimes it works, sometimes not.

I have just tried a fresh 3.2 once, without problem. Within a few days,
I'll know whether it's luck or magical-fixup.

Samuel

Re: [REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2012-01-05 Thread Samuel Thibault 
Samuel Thibault, le Thu 05 Jan 2012 03:16:46 +0100, a écrit :
 Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a écrit :
  Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a écrit :
   On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault 
   samuel.thiba...@ens-lyon.org wrote:
   
At home only. At work, with a different VGA screen, I'm still getting
the issue.
   
   You're still having a problem with the LVDS screen at work with FBC
   disabled?
  
  Yes, though it now seems random, sometimes it works, sometimes not.
 
 I have just tried a fresh 3.2 once, without problem. Within a few days,
 I'll know whether it's luck or magical-fixup.

It didn't take long. I'm still randomly getting the issue.

Samuel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2012-01-04 Thread Samuel Thibault 
Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a écrit :
 Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a écrit :
  On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault 
  samuel.thiba...@ens-lyon.org wrote:
  
   At home only. At work, with a different VGA screen, I'm still getting
   the issue.
  
  You're still having a problem with the LVDS screen at work with FBC
  disabled?
 
 Yes, though it now seems random, sometimes it works, sometimes not.

I have just tried a fresh 3.2 once, without problem. Within a few days,
I'll know whether it's luck or magical-fixup.

Samuel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2011-09-19 Thread Samuel Thibault 
Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a écrit :
 Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a écrit :
  On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault 
  samuel.thiba...@ens-lyon.org wrote:
  
   At home only. At work, with a different VGA screen, I'm still getting
   the issue.
  
  You're still having a problem with the LVDS screen at work with FBC
  disabled?
 
 Yes, though it now seems random, sometimes it works, sometimes not.

Ah, actually home's success was a luck. I'm still getting random
failures at home too.

Samuel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2011-09-16 Thread Samuel Thibault 
Samuel Thibault, le Fri 16 Sep 2011 18:30:50 +0200, a ?crit :
> Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a ?crit :
> > On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault  > ens-lyon.org> wrote:
> > 
> > > At home only. At work, with a different VGA screen, I'm still getting
> > > the issue.
> > 
> > You're still having a problem with the LVDS screen at work with FBC
> > disabled?
> 
> Yes, though it now seems random, sometimes it works, sometimes not.

Ah, actually home's success was a luck. I'm still getting random
failures at home too.

Samuel

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2011-09-16 Thread Samuel Thibault 
Keith Packard, le Thu 15 Sep 2011 09:22:48 -0500, a ?crit :
> On Thu, 15 Sep 2011 10:12:59 +0200, Samuel Thibault  ens-lyon.org> wrote:
> 
> > At home only. At work, with a different VGA screen, I'm still getting
> > the issue.
> 
> You're still having a problem with the LVDS screen at work with FBC
> disabled?

Yes, though it now seems random, sometimes it works, sometimes not.

> Can you send along a kernel log with drm.debug=5?

Here they are.

Samuel
-- next part --
5b, dev 0xe200, auth=1
[   40.384083] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.384093] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.386952] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.386989] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.386999] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.389612] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.389650] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.389662] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.391988] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.392023] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.392033] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.395432] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.395464] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.395473] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.398397] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.398433] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.398444] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.401377] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.401409] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.401419] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.404118] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.404148] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.404158] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.407356] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.407386] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.407397] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.410284] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.410314] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.410324] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.413242] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.413272] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.413282] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.416177] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.416206] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.416216] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.419170] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.419200] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.419210] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.422059] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.422104] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.422116] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.425187] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.425219] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.425229] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.427927] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.427956] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.427967] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.432075] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[   40.432105] [drm:drm_ioctl], pid=4148, cmd=0xc0086457, nr=0x57, dev 0xe200, 
auth=1
[   40.432116] [drm:drm_ioctl], pid=4148, cmd=0x4020645d, nr=0x5d, dev 0xe200, 
auth=1
[   40.434640] [drm:drm_ioctl], pid=4148, cmd=0xc010645b, nr=0x5b, dev 0xe200, 
auth=1
[

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2011-09-15 Thread Samuel Thibault 
Samuel Thibault, le Thu 15 Sep 2011 09:41:06 +0200, a ?crit :
> Keith Packard, le Thu 15 Sep 2011 00:43:36 -0500, a ?crit :
> > On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault  > ens-lyon.org> wrote:
> > Non-text part: multipart/mixed
> > > I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
> > > E6420, but dual head is broken. Here is the scenario:
> > > 
> > > - Turn computer on with VGA1 connected. Both LVDS1 and VGA1 show the
> > >   text console fine.
> > > - Start X. VGA1 shows X fine, but LVDS1 (1600x900 resolution) shows an
> > >   odd screen: completely black on the left part (about 1060x900), sort
> > >   of gray on the right part (about 540x900). Playing with xrandr doesn't
> > >   help, I can at best make it completely black with --off, and not get
> > >   it back again with --auto or anything else.
> > 
> > Can you try disabling frame buffer compression?
> > 
> > i915.i915_enable-fbc=0
> > 
> > I'm about to send a patch to disable this by default; I've gotten two
> > people saying that this helps them already.
> 
> Absolutely. I have no issue any more, and the error messages are gone.

At home only. At work, with a different VGA screen, I'm still getting
the issue.

Samuel
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.1.0-rc6 (samy at type) (gcc version 4.6.1 
(Debian 4.6.1-4) ) #1 SMP Wed Sep 14 19:23:48 CEST 2011
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.1.0-rc6 
root=UUID=38e6e493-2f5f-4a98-b1d6-a9434f0683cc ro i915.i915_enable-fbc=0
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 00091400 (usable)
[0.00]  BIOS-e820: 00091400 - 000a (reserved)
[0.00]  BIOS-e820: 000e - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 2000 (usable)
[0.00]  BIOS-e820: 2000 - 2020 (reserved)
[0.00]  BIOS-e820: 2020 - 4000 (usable)
[0.00]  BIOS-e820: 4000 - 4020 (reserved)
[0.00]  BIOS-e820: 4020 - baa2a000 (usable)
[0.00]  BIOS-e820: baa2a000 - baa6e000 (reserved)
[0.00]  BIOS-e820: baa6e000 - badb7000 (usable)
[0.00]  BIOS-e820: badb7000 - bade7000 (reserved)
[0.00]  BIOS-e820: bade7000 - bafe7000 (ACPI NVS)
[0.00]  BIOS-e820: bafe7000 - bafff000 (ACPI data)
[0.00]  BIOS-e820: bafff000 - bb00 (usable)
[0.00]  BIOS-e820: bb80 - bfa0 (reserved)
[0.00]  BIOS-e820: fed1c000 - fed2 (reserved)
[0.00]  BIOS-e820: ffc0 - ffc2 (reserved)
[0.00]  BIOS-e820: 0001 - 00013e00 (usable)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.6 present.
[0.00] DMI: Dell Inc. Latitude E6420/032T9K, BIOS A05 05/24/2011
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x13e000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 08000 mask FC000 write-back
[0.00]   2 base 0BC00 mask FFC00 uncachable
[0.00]   3 base 0BB00 mask FFF00 uncachable
[0.00]   4 base 1 mask FC000 write-back
[0.00]   5 base 13E00 mask FFE00 uncachable
[0.00]   6 base 0FFC0 mask FFFC0 write-protect
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] last_pfn = 0xbb000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [880f1b60] f1b60
[0.00] initial memory mapped : 0 - 2000
[0.00] Base memory trampoline at [8808c000] 8c000 size 20480
[0.00] init_memory_mapping: -bb00
[0.00]  00 - 00bb00 page 2M
[0.00] kernel direct mapping tables up to bb00 @ badb3000-badb7000
[0.00] init_memory_mapping: 0001-00013e00
[0.00]  01 - 013e0

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2011-09-15 Thread Samuel Thibault 
Keith Packard, le Thu 15 Sep 2011 00:43:36 -0500, a ?crit :
> On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault  ens-lyon.org> wrote:
> Non-text part: multipart/mixed
> > Hello,
> > 
> > I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
> > E6420, but dual head is broken. Here is the scenario:
> > 
> > - Turn computer on with VGA1 connected. Both LVDS1 and VGA1 show the
> >   text console fine.
> > - Start X. VGA1 shows X fine, but LVDS1 (1600x900 resolution) shows an
> >   odd screen: completely black on the left part (about 1060x900), sort
> >   of gray on the right part (about 540x900). Playing with xrandr doesn't
> >   help, I can at best make it completely black with --off, and not get
> >   it back again with --auto or anything else.
> 
> Can you try disabling frame buffer compression?
> 
> i915.i915_enable-fbc=0
> 
> I'm about to send a patch to disable this by default; I've gotten two
> people saying that this helps them already.

Absolutely. I have no issue any more, and the error messages are gone.

Samuel

[REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2011-09-15 Thread Samuel Thibault 
Hello,

I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
E6420, but dual head is broken. Here is the scenario:

- Turn computer on with VGA1 connected. Both LVDS1 and VGA1 show the
  text console fine.
- Start X. VGA1 shows X fine, but LVDS1 (1600x900 resolution) shows an
  odd screen: completely black on the left part (about 1060x900), sort
  of gray on the right part (about 540x900). Playing with xrandr doesn't
  help, I can at best make it completely black with --off, and not get
  it back again with --auto or anything else.

I have attached the corresponding dmesgs and Xorg.0.logs: as you can
see, the Xorg log doesn't change, while the dmesg changes a bit, I'm
getting a few 

[drm:ironlake_update_pch_refclk] *ERROR* enabling SSC on PCH

the rest is the same.

Samuel
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.0.4 (samy at type) (gcc version 4.6.1 (Debian 
4.6.1-4) ) #2 SMP Tue Aug 30 11:04:23 CEST 2011
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.0.4 
root=UUID=38e6e493-2f5f-4a98-b1d6-a9434f0683cc ro
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 00091400 (usable)
[0.00]  BIOS-e820: 00091400 - 000a (reserved)
[0.00]  BIOS-e820: 000e - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 2000 (usable)
[0.00]  BIOS-e820: 2000 - 2020 (reserved)
[0.00]  BIOS-e820: 2020 - 4000 (usable)
[0.00]  BIOS-e820: 4000 - 4020 (reserved)
[0.00]  BIOS-e820: 4020 - baa2a000 (usable)
[0.00]  BIOS-e820: baa2a000 - baa6e000 (reserved)
[0.00]  BIOS-e820: baa6e000 - badb7000 (usable)
[0.00]  BIOS-e820: badb7000 - bade7000 (reserved)
[0.00]  BIOS-e820: bade7000 - bafe7000 (ACPI NVS)
[0.00]  BIOS-e820: bafe7000 - bafff000 (ACPI data)
[0.00]  BIOS-e820: bafff000 - bb00 (usable)
[0.00]  BIOS-e820: bb80 - bfa0 (reserved)
[0.00]  BIOS-e820: fed1c000 - fed2 (reserved)
[0.00]  BIOS-e820: ffc0 - ffc2 (reserved)
[0.00]  BIOS-e820: 0001 - 00013e00 (usable)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.6 present.
[0.00] DMI: Dell Inc. Latitude E6420/032T9K, BIOS A05 05/24/2011
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x13e000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 08000 mask FC000 write-back
[0.00]   2 base 0BC00 mask FFC00 uncachable
[0.00]   3 base 0BB00 mask FFF00 uncachable
[0.00]   4 base 1 mask FC000 write-back
[0.00]   5 base 13E00 mask FFE00 uncachable
[0.00]   6 base 0FFC0 mask FFFC0 write-protect
[0.00]   7 disabled
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] last_pfn = 0xbb000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [880f1b60] f1b60
[0.00] initial memory mapped : 0 - 2000
[0.00] Base memory trampoline at [8808c000] 8c000 size 20480
[0.00] init_memory_mapping: -bb00
[0.00]  00 - 00bb00 page 2M
[0.00] kernel direct mapping tables up to bb00 @ badb3000-badb7000
[0.00] init_memory_mapping: 0001-00013e00
[0.00]  01 - 013e00 page 2M
[0.00] kernel direct mapping tables up to 13e00 @ 
13dffa000-13e00
[0.00] RAMDISK: 2db08000 - 32d7c000
[0.00] ACPI: RSDP 000fe300 00024 (v02 DELL  )
[0.00] ACPI: XSDT baffde18 0007C (v01 DELLCBX306222004 
MSFT 00010013)
[0.00] ACPI: FACP baf87d98 000F4 (v04 DELLCBX306222004 
MSFT 00010013)
[0.00] ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS 
tables! (20110413/tbfadt-369)
[0.00] ACPI Warning: 32/64X FACS address mismatch in FADT - 
0xBAFE4E40/0xBAFE4D40, using 32 (20110413/tbfadt-489)
[

Re: [REGRESSION] i915 KMS dual head broken on DELL latitude E6420 in 3.1-rc*

2011-09-15 Thread Samuel Thibault 
Keith Packard, le Thu 15 Sep 2011 00:43:36 -0500, a écrit :
 On Thu, 15 Sep 2011 01:27:17 +0200, Samuel Thibault 
 samuel.thiba...@ens-lyon.org wrote:
 Non-text part: multipart/mixed
  Hello,
  
  I'm trying to upgrade from 3.0 to 3.1-rcsomething on a DELL latitude
  E6420, but dual head is broken. Here is the scenario:
  
  - Turn computer on with VGA1 connected. Both LVDS1 and VGA1 show the
text console fine.
  - Start X. VGA1 shows X fine, but LVDS1 (1600x900 resolution) shows an
odd screen: completely black on the left part (about 1060x900), sort
of gray on the right part (about 540x900). Playing with xrandr doesn't
help, I can at best make it completely black with --off, and not get
it back again with --auto or anything else.
 
 Can you try disabling frame buffer compression?
 
 i915.i915_enable-fbc=0
 
 I'm about to send a patch to disable this by default; I've gotten two
 people saying that this helps them already.

Absolutely. I have no issue any more, and the error messages are gone.

Samuel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel