On Sat, 2006-04-15 at 07:29 +0800, Antonino A. Daplas wrote:
> Richard Purdie wrote:
> > Ignoring whether this is a good idea or not, under 2.6.15 you could run
> >
> > dd if=/dev/zero of=/dev/fb0
> >
> > which would clear the framebuffer. It would end up saying "dd: /dev/fb0:
> > No space left on device".
> >
> > Under 2.6.16 (and a recent git kernel), the same command clears the
> > screen but then hangs. Was the change in behaviour intentional?
> >
> > I've noticed this on a couple of ARM based Zaurus handhelds under both
> > w100fb and pxafb.
> >
>
> There is a change in behavior of fb_read and fb_write committed Jan 2006.
> They return the number of bytes read or written if the requested size
> is bigger than the remaining space. Previously, they returned -ENOSPC.
>
> But I haven't experienced hangs...
The change in question is:
@@ -661,19 +664,19 @@ fb_write(struct file *file, const char _
return info->fbops->fb_write(file, buf, count, ppos);
total_size = info->screen_size;
+
if (total_size == 0)
total_size = info->fix.smem_len;
if (p > total_size)
- return -ENOSPC;
+ return 0;
+
if (count >= total_size)
- count = total_size;
- err = 0;
- if (count + p > total_size) {
- count = total_size - p;
- err = -ENOSPC;
- }
- cnt = 0;
+ count = total_size;
+
+ if (count + p > total_size)
+ count = total_size - p;
+
buffer = kmalloc((count > PAGE_SIZE) ? PAGE_SIZE : count,
GFP_KERNEL);
if (!buffer)
I agree with the latter part of this but not the change for the "if (p >
total_size)" case. If we return zero here, the writer will just keep
retrying to write to the device indefinitely and therefore hang. Would
it make sense to revert that part of the change?:
If we reach the end of the framebuffer, we should return an out of space
error, not zero. Returning zero implies we might be able to write
further bytes at some future time which isn't true.
Signed-off-by: Richard Purdie <[email protected]>
Index: git/drivers/video/fbmem.c
===================================================================
--- git.orig/drivers/video/fbmem.c 2006-04-13 00:22:28.000000000 +0100
+++ git/drivers/video/fbmem.c 2006-04-15 01:04:37.000000000 +0100
@@ -674,7 +674,7 @@
total_size = info->fix.smem_len;
if (p > total_size)
- return 0;
+ return -ENOSPC;
if (count >= total_size)
count = total_size;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
