Created attachment 434027 [details] Screenshot Description of problem: Remote console display on 34.x kernels is broken. Remote console in IBM BladeCenter H Advanced Management Module Version-Release number of selected component (if applicable): Any 34.x series we currently have in koji. How reproducible: Always Steps to Reproduce: 1. Start remote console in the IBM BladeCenter H Advanced Management Module 2. Boot or just switch to the blade running the 34.x kernel 3. Actual results: See attached picture Expected results: Display being a OK Additional info: Works fine with any 33.x kernels we have.
Created attachment 434028 [details] /var/log/messages
You could try pci=nocrs: Jul 23 18:01:56 snotra kernel: PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
Adding pci=nocrs did not change anything
Font corruption with matroxfb was mentioned on LKML recently: http://permalink.gmane.org/gmane.linux.kernel/1015771
You should be able to blacklist matroxfb and use vesa or vga modes. We may just have to disable building the matroxfb driver entirely unless someone can figure out why it broke.
Fix, from: http://marc.info/?l=linux-kernel&m=128086050905521&q=raw Fix incorrect use of memcpy_toio() in matroxfb that broke in 2.6.34. Signed-off-by: Ondrej Zary <linux> --- linux-2.6.35-rc2/drivers/video/matrox/matroxfb_base.h +++ linux-2.6.35-rc3/drivers/video/matrox/matroxfb_base.h @@ -151,13 +151,13 @@ static inline void mga_writel(vaddr_t va static inline void mga_memcpy_toio(vaddr_t va, const void* src, int len) { #if defined(__alpha__) || defined(__i386__) || defined(__x86_64__) /* - * memcpy_toio works for us if: + * iowrite32_rep works for us if: * (1) Copies data as 32bit quantities, not byte after byte, * (2) Performs LE ordered stores, and * (3) It copes with unaligned source (destination is guaranteed to be page * aligned and length is guaranteed to be multiple of 4). */ - memcpy_toio(va.vaddr, src, len); + iowrite32_rep(va.vaddr, src, len >> 2); #else u_int32_t __iomem* addr = va.vaddr;
Fix will be in 2.6.34.2-33
Confirmed fixed with 2.6.34.2-33 great work everyone....
This bug never hit a released kernel, so closing it now.