From: David Miller <davem@xxxxxxxxxxxxx>
Date: Tue, 24 Oct 2006 16:32:59 -0700 (PDT)
> From: Per Øyvind Karlsen <pkarlsen@xxxxxxxxxxxx>
> Date: Wed, 25 Oct 2006 01:31:23 +0200
>
> > So, did we get to any conclusion on this one?
> >
> > Should I dig through changes between -rc3 & -rc4 to exactly pinpoint the
> > breakage, or do you have enough info on the matter to work with?
>
> I have enough info to look into this.
Well, I just did a diff between 2.6.17-rc3 and 2.6.17-rc4, which is
where you say the breakage got introduced, and there is nothing that
even remotely could cause atyfb breaking.
All sparc64 changes are:
1) Changes to arguments passed to audit_syscall_{entry,exit}()
Cannot possibly effect framebuffer operation.
2) Add support for vmsplice() system call, again cannot possibly
break your framebuffer.
3) Add preempt() protection around flush_tlb_pending(), again cannot
possible break your framebuffer.
4) Remove prototype for a function whose implementation got deleted
years ago. Cannot possibly break anything.
All PCI layer changes are:
1) MSI layer memory leak fix, sparc64 does not turn on CONFIG_MSI
and thus can't even execute this code.
2) printk message change in quirk layer, can't break anything.
All framebuffer layer changes are:
1) Help text added to FB_ASILIANT kernel config option, cannot
break atyfb.
2) Changes to au1200fb.c driver, not used by sparc64 nor every built
into the sparc64 kernel image.
3) SYSFS changes for framebuffer, wrt. cmap writes to /sys filesystem
files after boot. Cannot break the atyfb framebuffer on bootup.
4) Minor changes to the Makefile rule that builds the video
framebuffer logo image file, cannot break atyfb.
So there is absolutely nothing for me to work with.
Does the kernel in 2.6.17-rc4 say anything interesting if you
boot with the "-p" option on the kernel boot command line?
Do you get an OOPS or some other kind of crash message?
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
