Re: [PATCH] hvc_vio: Do not override preferred console set by kernel parameter
On Thu, 2013-09-26 at 14:22 -0700, Greg Kroah-Hartman wrote: So, I shouldn't apply this patch? We should do something to fix this, if Debian has to drag this patch on for 5 years, that's an indication that this might be one solution we should use, right? Ah sorry, dropped the ball on that one. Yes the patch is an acceptable band-aid but somebody should work on a better solution :-) Cheers, Ben. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1380232830.28561.71.camel@pasglop
Re: [PATCH] hvc_vio: Do not override preferred console set by kernel parameter
On Sun, 2013-09-01 at 17:24 +0100, Ben Hutchings wrote: The original version of this was done by Bastian Blank, who wrote: The problem is the following: - Architecture specific code sets preferred console to something bogus. - Command line handling tries to set preferred console but is overruled by the old setting. The udbg0 console is a boot console and independant. References: http://bugs.debian.org/492703 Signed-off-by: Ben Hutchings b...@decadent.org.uk --- We've been carrying this in Debian for 5 years now, so it's about time it got reviewed. I'm not convinced strstr() is the right way to check the command line (what if there's also a 'netconsole='?). Also I think the problem should be solved elsewhere :-) In the end, what that code is trying to do (as are all the other similar instances) is to set this is a good default in case nothing is specified *or* what is specified doesn't actually exist. Of course doesn't exist is tricky since the console could be provided by a module loaded god knows when ... but in that case, maybe it does make sense to stick to one of the known good defaults. After all, init will fail without a tty ... So I'm thinking we should in kernel/printk.c keep track of all those arch defaults when console= is specified as latent consoles, and right before starting init, if the specified one didn't work out (we have no console with an associated tty), then go through those latent ones and pick one that works. Cheers, Ben. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1378079740.3978.13.camel@pasglop
Re: Stable update of linux-2.6
On Mon, 2011-04-04 at 16:10 -0600, dann frazier wrote: I'm just reporting this as a build-time regression in stable as it caused an issue when we merged recent stable updates into the Debian tree. I've never personally tried to configure kdump on powerpc. fwiw, a quick test shows that kexec doesn't work on my test box: dannf@macmini:~$ sudo kexec -l /boot/vmlinux-2.6.32-5-powerpc --append=root=/dev/hda3 ro --initrd=/boot/initrd.img-2.6.32-5-powerpc get_memory_ranges(): Unsupported platform Could not get memory layout Yes, we've never added support for kexec on macs, I suppose that shouldn't be too hard to do tho... Cheers, Ben. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301956312.2549.94.camel@pasglop
Re: Stable update of linux-2.6
On Sun, 2011-04-03 at 00:10 +0530, Kamalesh Babulal wrote: * dann frazier da...@dannf.org [2011-04-02 11:23:03]: 2.6.32.36 also fails to build on powerpc/SMP: CC arch/powerpc/kernel/crash.o arch/powerpc/kernel/crash.c: In function 'crash_kexec_wait_realmode': arch/powerpc/kernel/crash.c:176: error: 'paca' undeclared (first use in this function) arch/powerpc/kernel/crash.c:176: error: (Each undeclared identifier is reported only once arch/powerpc/kernel/crash.c:176: error: for each function it appears in.) make[1]: *** [arch/powerpc/kernel/crash.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 This build is not reproducible locally, can you please send the .config file. Smells to me like a 32-bit build... Current upstream has the function crash_kexec_wait_realmode() protected by: #ifdef CONFIG_PPC_STD_MMU_64 Maybe that is missing in .32.36 ? You can disable CONFIG_CRASH_DUMP as a workaround. Is it that useful anyways on 32-bit ? (Does it even work ?) Cheers, Ben -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301780019.2549.31.camel@pasglop
Bug#614221: iMac-G3 fails to boot with 2.6.37-1-powerpc (Bug#614221)
On Tue, 2011-03-08 at 13:00 +0100, Michel Dänzer wrote:
On Die, 2011-03-08 at 07:30 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2011-03-07 at 10:45 +0100, Michel Dänzer wrote:
I've been using radeon KMS on my PowerBook ever since I got it working
initially about 1.5 years ago and fixing issues as time permits.
The major outstanding issues I'm aware of are:
* The uninorth AGP driver doesn't allow AGP transfer rates beyond
1x to work reliably with KMS. Benjamin Herrenschmidt (CC'd) was
working on a fix for this, any progress Ben?
I have hacks.
FWIW, I've been using the hack at the end of this mail for AGP 1x.
.../...
Ok I'll try to give it another go here one of these days, I think I
still have some of my old hacks too.
Cheers,
Ben.
But I never got it working reliably. In fact, on the laptop I have
here, even with PCI GART, it's still unstable if I use KMS/DRI2.
I know your PowerBook was affected by the problem fixed by commit
b7d8cce5b558e0c0aa6898c9865356481598b46d ('drm/radeon/kms: MC vram map
needs to be = pci aperture size'), which went into 2.6.37. Still no
better with that?
* Come to think of it, the OFfb handover probably only works for
me thanks to a patch drm/radeon: Add early unregister of
firmware fb's by BenH. Ben/Dave, what's the status of that?
Dave ? Was this ever merged ?
Apparently it went into 2.6.37, I didn't notice because it went into
different places in the code compared to the patch I had from you.
* Various endianness issues in the Mesa drivers.
Right, and the later aren't getting any better :-( It's busted even
without KMS nowadays.
Unfortunately, I have about 0 time to spend on that at the moment.
I recommend that distros stick to radeonfb + UMS for the time being on
ppc32.
One problem being that the classic Mesa r300 driver is essentially
unmaintained, and evidently rotting
commit 9a86d7fa5bb0b4fe228becf9ed9831bac985702c
Author: Michel Dänzer daen...@vmware.com
Date: Thu Jan 6 18:34:28 2011 +0100
agp/uninorth: Fix lockups with radeon KMS and 1x.
diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
index f845a8f..a32c492 100644
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@ -80,7 +80,7 @@ static void uninorth_tlbflush(struct agp_memory *mem)
ctrl | UNI_N_CFG_GART_INVAL);
pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL, ctrl);
- if (uninorth_rev = 0x30) {
+ if (!mem uninorth_rev = 0x30) {
pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
ctrl | UNI_N_CFG_GART_2xRESET);
pci_write_config_dword(agp_bridge-dev, UNI_N_CFG_GART_CTRL,
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1299623992.22236.40.camel@pasglop
Bug#614221: iMac-G3 fails to boot with 2.6.37-1-powerpc (Bug#614221)
On Mon, 2011-03-07 at 10:45 +0100, Michel Dänzer wrote: I've been using radeon KMS on my PowerBook ever since I got it working initially about 1.5 years ago and fixing issues as time permits. The major outstanding issues I'm aware of are: * The uninorth AGP driver doesn't allow AGP transfer rates beyond 1x to work reliably with KMS. Benjamin Herrenschmidt (CC'd) was working on a fix for this, any progress Ben? I have hacks. But I never got it working reliably. In fact, on the laptop I have here, even with PCI GART, it's still unstable if I use KMS/DRI2. * Come to think of it, the OFfb handover probably only works for me thanks to a patch drm/radeon: Add early unregister of firmware fb's by BenH. Ben/Dave, what's the status of that? Dave ? Was this ever merged ? * LVDS backlight control was only added for 2.6.38, and some concerns were raised about the prerequisite backlight infrastructure changes, so I'm not sure if it's staying in for 2.6.38 final. * No suspend to RAM support yet. Suspend to disk seems to work though without AGP, I have some hackish fixes for it to work with AGP as well that I need to clean up and submit. * Various endianness issues in the Mesa drivers. Right, and the later aren't getting any better :-( It's busted even without KMS nowadays. Unfortunately, I have about 0 time to spend on that at the moment. I recommend that distros stick to radeonfb + UMS for the time being on ppc32. Cheers, Ben. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1299529827.9759.19.camel@pasglop
Bug#506964: [PATCH] suspend/resume for ATI Mobility Radeon RV350
On Thu, 2009-01-08 at 21:57 +0100, Wolfgang Kroener wrote:
Hi,
On Wed, Oct 01, 2008 at 08:10:10, Benjamin Herrenschmidt wrote:
Can you resend it with a proper Signed-off-by: line ? Thanks !
I think the mail (http://lkml.org/lkml/2008/10/1/134) got lost
somewhere, so I try again:
Fell through the cracks along with some of my own radeonfb patches :-)
Thanks for reminding.
Cheers,
Ben.
radeonfb suspend/resume for Acer Travelmate 29X
This patch adds suspend/resume for the Acer Travelmate 290D/292LMi with
the following graphic-chip:
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350
[Mobility Radeon 9600 M10] [1002:4e50] (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] TravelMate 290 [1025:005a]
Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 10
Memory at a800 (32-bit, prefetchable) [size=128M]
I/O ports at c100 [size=256]
Memory at e001 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at a000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
Kernel driver in use: radeonfb
Kernel modules: radeonfb
Signed-off-by: Wolfgang Kroener l...@azog.de
---
drivers/video/aty/radeon_pm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/video/aty/radeon_pm.c b/drivers/video/aty/radeon_pm.c
index 675abda..5e4b2da 100644
--- a/drivers/video/aty/radeon_pm.c
+++ b/drivers/video/aty/radeon_pm.c
@@ -89,6 +89,9 @@ static struct radeon_device_id radeon_workaround_list[] = {
BUGFIX(Acer Aspire 2010,
PCI_VENDOR_ID_AI, 0x0061,
radeon_pm_off, radeon_reinitialize_M10),
+ BUGFIX(Acer Travelmate 290D/292LMi,
+PCI_VENDOR_ID_AI, 0x005a,
+radeon_pm_off, radeon_reinitialize_M10),
{ .ident = NULL }
};
--
1.5.6.5
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#435226: log's incomplete
The log is incomplete... looks like the bcm43xx driver is so verbose, it kicked useful things out. Thus I can't see the output from the video driver which is the interesting bit... Also, is it nvidiafb or rivafb ? Cheers, Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433236: Subject: linux-image-2.6.21-2-powerpc: radeonfb broken with Apple Cinema Display, connected via DVI
On Mon, 2007-07-30 at 20:41 +0200, Stephane Louise wrote: Bonjour Ben, merci pour le suivit. Benjamin Herrenschmidt a écrit : Does this happen also without radeonfb and with X alone using the X radeon driver ? Yes, unless I misunderstand you. I tried several options at the yaboot prompt (nofb or video=of), and speaking of Xorg, I don't use the UseFBDev for X11 since it rarely works with LCD panels (same with the Apple 20 and the Samsung 206, most of the valid resolutions don't work with UseFBDev). Just to make sure I understand properly: with video=ofonly and X with the config below, you still get a black screen ? It looks like the monitor powers off right ? I saw that with issues with Apple doing non-kosher things with the DDC line but we had that fixed long ago... Ben. Here are my device and monitor sections of xorg.conf: Section Device Identifier ATI Technologies, Inc. RV280 [Radeon 9200] Driver radeon BusID PCI:0:16:0 Option UseFBDev false Option AGPMode 4 Option AGPFastWrite true Option ReverseDDCtrue Option PanelSize 1680x1050 Option AccelMethod XAA Option AccelDFS on Option EnablePageFliptrue Option ColorTiling on Option EnableDepthMoves true Option RenderAccel true Option DRI true Option XAANoOffscreenPixmaps true EndSection Section Monitor Identifier Apple Cinema Display 20 Option MonitorLayout TMDS,NONE Option DPMS HorizSync 28-68 VertRefresh 60 DisplaySize 434 270 Option DPMS ModeLine 1680x1050 119.06 1680 1728 1760 1840 1050 1053 1059 1080 +HSync -VSync Modeline 1280x800 67.26 1280 1312 1560 1592 800 817 824 841 Modeline 1024x640 51.90 1024 1056 1248 1280 640 653 660 673 Modeline 800x500 30.98 800 832 944 976 500 510 515 526 EndSection Tell me if I can do something else to help.
Bug#433236: Subject: linux-image-2.6.21-2-powerpc: radeonfb broken with Apple Cinema Display, connected via DVI
On Sat, 2007-07-21 at 23:19 +0200, Stephane Louise wrote: Hi, I can confirm this bug. I have also a Mac Mini G4/1.5GHz with a 20 Apple Cinema Display (DVI model), and the kernel starts fine but the monitor switches off in the early phase of the boot process. Otherwise, it is fine, and I can connect through ssh to the machine, or login blindly. Here are some parts of the dmesg log that could be relevant: Does this happen also without radeonfb and with X alone using the X radeon driver ? Ben. Kernel command line: root=/dev/hda3 ro mpic: Setting up MPIC MPIC 1version 1.2 at 8004, max 4 CPUs mpic: ISU size: 64, shift: 6, mask: 3f mpic: Initializing for 64 sources PID hash table entries: 2048 (order: 11, 8192 bytes) GMT Delta read from XPRAM: 0 minutes, DST: off time_init: decrementer frequency = 41.600571 MHz time_init: processor frequency = 1499.94 MHz Console: colour dummy device 80x25 serial8250_console_init: nothing to do on PowerMac Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) High memory: 0k Memory: 508288k/524288k available (3272k kernel code, 15512k reserved, 124k data, 189k bss, 188k init) Calibrating delay loop... 82.94 BogoMIPS (lpj=165888) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 device-tree: Duplicate name in /cpus/PowerPC,[EMAIL PROTECTED], renamed to l2-cache#1 NET: Registered protocol family 16 KeyWest i2c @0xf8001003 irq 42 /[EMAIL PROTECTED]/[EMAIL PROTECTED] channel 0 bus multibus channel 1 bus multibus KeyWest i2c @0x80018000 irq 26 /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] channel 0 bus multibus PMU i2c /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/pmu-i2c channel 1 bus multibus channel 2 bus multibus ... PCI: Enabling device :00:10.0 (0006 - 0007) radeonfb (:00:10.0): Invalid ROM signature 0 should be 0xaa55 radeonfb: Retrieved PLL infos from Open Firmware radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=190.00 Mhz, System=250.00 MHz radeonfb: PLL min 12000 max 35000 i2c_adapter i2c-2: unable to read EDID block. i2c_adapter i2c-2: unable to read EDID block. i2c_adapter i2c-2: unable to read EDID block. radeonfb: Monitor 1 type DFP found radeonfb: EDID probed radeonfb: Monitor 2 type DFP found radeonfb: EDID probed Console: switching to colour frame buffer device 210x65 radeonfb (:00:10.0): ATI Radeon Yb Generic RTC Driver v1.07 Macintosh non-volatile memory driver v1.1 serial8250_init: nothing to do on PowerMac pmac_zilog: 0.6 (Benjamin Herrenschmidt [EMAIL PROTECTED]) ttyS0 at MMIO 0x80013020 (irq = 22) is a Z85c30 ESCC - Serial port ttyS1 at MMIO 0x80013000 (irq = 23) is a Z85c30 ESCC - Serial port ... PowerMac i2c bus pmu 2 registered PowerMac i2c bus pmu 1 registered PowerMac i2c bus mac-io 0 registered PowerMac i2c bus uni-n 1 registered PowerMac i2c bus uni-n 0 registered ... [drm] Initialized drm 1.1.0 20060810 [drm] Initialized radeon 1.25.0 20060524 on minor 0 agpgart: Putting AGP V2 device at :00:0b.0 into 4x mode agpgart: Putting AGP V2 device at :00:10.0 into 4x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode [drm] writeback test succeeded in 1 usecs ~$ cat /proc/cpuinfo processor : 0 cpu : 7447A, altivec supported clock : 1499.94MHz revision: 0.5 (pvr 8003 0105) bogomips: 82.94 timebase: 41600571 platform: PowerMac machine : PowerMac10,2 motherboard : PowerMac10,2 MacRISC3 Power Macintosh detected as : 287 (Unknown Intrepid-based) pmac flags : L2 cache: 512K unified pmac-generation : NewWorld ~$ cat /proc/version Linux version 2.6.21-2-powerpc (Debian 2.6.21-6) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070629 (prerelease) (Debian 4.1.2-13)) #1 Tue Jul 10 19:09:48 CEST 2007 ~$ cat /proc/dri/0/name radeon :00:10.0 pci::00:10.0 And from /var/log/Xorg.0.log ... (II) RADEON(0): Page flipping enabled (II) RADEON(0): Will try to use DMA for Xv image transfers (II) RADEON(0): Generation 2 PCI interface, using max accessible memory (II) RADEON(0): Detected total video RAM=65536K, accessible=131072K (PCI BAR=131072K) (--) RADEON(0): Mapped VideoRAM: 65536 kByte (64 bit DDR SDRAM) (II) RADEON(0): Color tiling enabled by default (II) Loading sub module ddc (II) LoadModule: ddc(II) Module already built-in (II) Loading sub module i2c (II) LoadModule: i2c(II) Module already built-in (II) RADEON(0): I2C bus DDC initialized. (II) Attempted to read BIOS 64KB from /sys/bus/pci/devices/:00:10.0/rom: got 0KB (WW) RADEON(0): Video BIOS not detected in PCI space! (WW) RADEON(0): Attempting to read Video BIOS from legacy ISA space! (WW) RADEON(0): Unrecognized BIOS signature
Bug#407671: kernel 2.6.18: Confusion about Macintosh backlight configuration
On Mon, 2007-01-22 at 16:05 +0100, Matthias Grimm wrote: On Mon, 22 Jan 2007 14:33:35 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: Which solution you prefer is up to you but I would be glad if at least solution #1 could be realised. For now, at least, what prevents you from having all enabled and have pbbuttonsd still call PMU_IOC_GRAB_BACKLIGHT ? Nothing. Pbbuttonsd does so by now but this wouldn't help if someone set CONFIG_PMAC_BACKLIGHT_LEGACY to off. I check this out with debian, hoping you will find a smart solution for this in the future. I think the debian people getting aware of this backwards compatibility problem now and there is hope they will fix it for etch. Yes, debian should keep CONFIG_PMAC_BACKLIGHT_LEGACY enabled. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407671: kernel 2.6.18: Confusion about Macintosh backlight configuration
This will allow modern systems to be compiled only with CONFIG_PMAC_BACKLIGHT and a user space daemon does the rest. I hope my point could be seen. I would really appreciate if the configuration could be cleaned up. Other solutions could be: 2. If the sysfs backlight driver is opened switch kernel backlight keys handling off by calling PMU_IOC_GRAB_BACKLIGHT for machines that support the sysfs backlight interface. 3. Remove the kernel backlight keys control code from the kernel. Which solution you prefer is up to you but I would be glad if at least solution #1 could be realised. For now, at least, what prevents you from having all enabled and have pbbuttonsd still call PMU_IOC_GRAB_BACKLIGHT ? In the long run, we might want something smarter indeed, not sure what the best solution is... I like having the kernel control work always when no daemon is there. Among others, because we have this never solved problem where occasionally, the internal flat panel doesn't sync properly and the only way to get it back is to turn the backlight all the way down and back up a few times until it kicks in. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397942: g5 imacs now silent?
On Thu, 2006-11-30 at 23:04 +0100, Étienne Bersac wrote: Hi, Beware not to confuse iMac G5 rev AB and rev C (among PowerMac G5). iMac G5 rev C (chip PowerMac 12,1) do not have yet their windfarm driver. Benh told that he began the work on this driver but has difficulties to get access to de device. Benh, can you confirm ? Yes, I did some initial work to dig as much info as I could from darwin, but it seems that apple, once again, changed everything and thus I'm not confident writing and releasing a driver without physical access to the HW to verify by myself that the fans are behaving properly. I haven't managed to get access to that machine yet. Ben.
Re: Boot failure with kernel 2.6.15 on G4
This message is generally a sign that something else went wrong. Magnus, the best way on this would be to file a bug report against initramfs-tools about this second problem, and if possible provide the whole log. Benjamin, BTW, there seems to be some issue about pmac_zilog and the normal serial controller, that if both are builtin the kernel, then the PC serial controller will take priority over pmac_zilog, and this second one will not work. Any hint on how to workaround that ? None currently. It's an old issue. The new serial core cannot deal with 2 drivers wanting to share the same major device. The only solution would be to allocate a new major for pmac_zilog (or steal one that is only used by a non-ppc arch, doesn't sparc has a separate major for zilog ? we could re-use that ) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The powerpc port should be removed from etch release candidates ...
Hey, cool. so ARCH=ppc will work both for apus and prep, and the rest should go with ARCH=powerpc. This is the case both for 2.6.16 and the upcoming 2.6.17, right ? I don't remember when he fixed it precisely but I think 2.6.16 got it yes. So, the basic plan is to have a -prep ARCH=ppc flavour in addition of the -powerpc one. I will add this over this WE. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The powerpc port should be removed from etch release candidates ...
On Thu, 2006-05-04 at 08:41 +0200, Sven Luther wrote: On Thu, May 04, 2006 at 04:38:07PM +1000, Benjamin Herrenschmidt wrote: Hey, cool. so ARCH=ppc will work both for apus and prep, and the rest should go with ARCH=powerpc. This is the case both for 2.6.16 and the upcoming 2.6.17, right ? I don't remember when he fixed it precisely but I think 2.6.16 got it yes. Do you know if there are SMP PReP machines around ? I think i will do only a UP -prep flavour. I think there is Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Two 32bit power3/4 build-failure patches ...
On Sun, 2005-10-16 at 12:28 +0200, Sven Luther wrote: Hello, I have here two 32bit power[34] build failure patches that the debian kernels has been using for some time, and which i think i did post here in the past, but it doesn't seem to be applied. Well, those are 32 bit issues, and debian doesn't build anymore 32bit kernels of those flavours, but i guess it may be possible that some random user wants to build them, so it would be nice if they could be included upstream. I think we'll be dropping 64 bits CPU support for 32 bits kernel anyway. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge kernel frozen (2.4.27 and 2.6.8), and plans for post-sarge powerpc kernels.
On Mon, 2005-04-04 at 09:58 +0200, Gabriel Paubert wrote: As I said above, some embedded CPU really need different mm handling. BookE is an abomination, and fun with the 64 bit BookE implemetations if they come one day: they use different instruction encoding than standard PPC64. I think the whole idea of 64 bits bookE was trashed ... at least I hope so, I remember hearing something around those lines though. As said above, I might try to push upstream patches to merge PreP, PowerPlus and MVME5100. But these are not really embedded boards, except for memory size (I have to run in 16MB, root on NFS, no disk, no swap, serial console only). I'm starting this week to resurrect my old bootloader which included an x86 emulator to initialize VGA boards by running their BIOS code. Good :) However, I'll still compile my kernels. So I don't care very much about what you put in the package. Regards, Gabriel -- Benjamin Herrenschmidt [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#268352: 2.6.* radeonfb regression
On Sat, 2004-09-25 at 23:51, Francesco Paolo Lovergine wrote: On Sat, Sep 18, 2004 at 02:42:10PM +1000, Benjamin Herrenschmidt wrote: Sorry for the delay, I've been kept very busy with other things. Can you send me dmesg logs after enabling radeonfb verbose debug of the boot that leads to incorrect detection ? Also tell me what the real resolution should be in both cases, and send me also the XFree log. Also, make sure you are testing with the lastest 2.6 possible as there have been a fix for such an issue recently. Ben. Sorry for the long delay. I'm enclosing the output of radeonfb for the first 1400x1050 Radeon Mobility M6 LY chip and the XFree86 log too. radeonfb seem to detect it properly... weird. I don't know what's up at this point. Ben. Sep 25 15:44:22 localhost kernel: radeonfb_pci_register BEGIN Sep 25 15:44:22 localhost kernel: ACPI: PCI interrupt :01:00.0[A] - GSI 9 (level, low) - IRQ 9 Sep 25 15:44:22 localhost kernel: radeonfb: probed DDR SGRAM 32768k videoram Sep 25 15:44:23 localhost kernel: radeonfb: mapped 16384k videoram Sep 25 15:44:23 localhost kernel: radeonfb: Retreived PLL infos from BIOS Sep 25 15:44:23 localhost kernel: radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=166.00 Mhz, System=143.00 MHz Sep 25 15:44:23 localhost kernel: 1 chips in connector info Sep 25 15:44:23 localhost kernel: - chip 1 has 1 connectors Sep 25 15:44:23 localhost kernel: * connector 0 of type 2 (CRT) : 2300 Sep 25 15:44:23 localhost kernel: Starting monitor auto detection... Sep 25 15:44:23 localhost kernel: radeonfb: I2C (port 1) ... not found Sep 25 15:44:23 localhost kernel: radeonfb: I2C (port 2) ... not found Sep 25 15:44:24 localhost kernel: radeonfb: I2C (port 3) ... not found Sep 25 15:44:24 localhost kernel: radeonfb: I2C (port 4) ... found LVDS panel Sep 25 15:44:24 localhost kernel: radeonfb: I2C (port 2) ... not found Sep 25 15:44:24 localhost kernel: radeonfb: I2C (port 4) ... found LVDS panel Sep 25 15:44:25 localhost kernel: radeonfb: I2C (port 3) ... not found Sep 25 15:44:25 localhost kernel: radeonfb: Monitor 1 type LCD found Sep 25 15:44:25 localhost kernel: radeonfb: EDID probed Sep 25 15:44:25 localhost kernel: radeonfb: Monitor 2 type no found Sep 25 15:44:25 localhost kernel: radeonfb: panel ID string: Samsung LTN150P1-L02 Sep 25 15:44:25 localhost kernel: radeonfb: detected LVDS panel size from BIOS: 1400x1050 Sep 25 15:44:25 localhost kernel: BIOS provided panel power delay: 1000 Sep 25 15:44:25 localhost kernel: radeondb: BIOS provided dividers will be used Sep 25 15:44:25 localhost kernel: ref_divider = 2 Sep 25 15:44:25 localhost kernel: post_divider = 4 Sep 25 15:44:25 localhost kernel: fbk_divider = 18 Sep 25 15:44:25 localhost kernel: Scanning BIOS table ... Sep 25 15:44:25 localhost kernel: 320 x 350 Sep 25 15:44:25 localhost kernel: 320 x 400 Sep 25 15:44:25 localhost kernel: 320 x 400 Sep 25 15:44:25 localhost kernel: 320 x 480 Sep 25 15:44:25 localhost kernel: 400 x 600 Sep 25 15:44:25 localhost kernel: 512 x 384 Sep 25 15:44:25 localhost kernel: 640 x 350 Sep 25 15:44:25 localhost kernel: 640 x 400 Sep 25 15:44:25 localhost kernel: 640 x 475 Sep 25 15:44:25 localhost kernel: 640 x 480 Sep 25 15:44:25 localhost kernel: 720 x 480 Sep 25 15:44:25 localhost kernel: 720 x 576 Sep 25 15:44:25 localhost kernel: 800 x 600 Sep 25 15:44:25 localhost kernel: 848 x 480 Sep 25 15:44:25 localhost kernel: 1024 x 768 Sep 25 15:44:25 localhost kernel: 1152 x 864 Sep 25 15:44:25 localhost kernel: 1280 x 1024 Sep 25 15:44:25 localhost kernel: 1400 x 1050 Sep 25 15:44:25 localhost kernel: Found panel in BIOS table: Sep 25 15:44:25 localhost kernel: hblank: 288 Sep 25 15:44:25 localhost kernel: hOver_plus: 40 Sep 25 15:44:25 localhost kernel: hSync_width: 112 Sep 25 15:44:25 localhost kernel: vblank: 13 Sep 25 15:44:25 localhost kernel: vOver_plus: 0 Sep 25 15:44:25 localhost kernel: vSync_width: 3 Sep 25 15:44:25 localhost kernel: clock: 10800 Sep 25 15:44:25 localhost kernel: Setting up default mode based on panel info Sep 25 15:44:25 localhost kernel: radeonfb: Power Management enabled for Mobility chipsets Sep 25 15:44:25 localhost kernel: radeonfb: ATI Radeon LY DDR SGRAM 32 MB Sep 25 15:44:25 localhost kernel: radeonfb_pci_register END This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-7 20040906103015 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.26 i686 [ELF] Build Date: 06 September 2004 Before reporting problems, check http
Bug#268352: 2.6.* radeonfb regression
On Fri, 2004-10-01 at 17:39, Francesco P. Lovergine wrote: Could you suggest any hook point in the code where I can augment verbosity level to see what's going on? In the meantime is there any possibility to add the old radeonfb module along with the new one? That code is anyway there and can be built apparently under 2.6. Any issues about? The any reason the old worked is, I think, because it didn't know about the flat panel at all and didn't program any FP register, so you got whatever your firmware had previously programmed... Your problem might be related to the way the driver plays with LVDS_GEN_CNTL, you can try hacking around this... Ben.
Re: 2.4 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Benjamin Herrenschmidt [EMAIL PROTECTED]
Re: 2.4 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
Well... That isn't really what I said ;) What I said is that I don't have time to actively maintain the PowerMac support in 2.4, that is make it evolve support newer machines. That doesn't mean that PPC will be going away from 2.4 ;) I think the exact quote was that you are not going to support G5 on 2.4 forever. But anyway, a move to 2.6 should be salutable if all the linuxppc developers have much more interest for 2.6 trhan 2.4, and we will be saddled with this for the next 2 years probably, so ... Oh yes, G5 is another matter, it's not supported at all in 2.4 ;) The fact that there is a very minimal support in 2.4 was done to help some distro who had 2.4-only installers at one point, and definitely not meant to be used after the install stage. Also, I don't intend to support the 32 bits kernel on them for long neither, G5s should really run a 64 bits kernel even with a 32 bits userland. Ben.
Re: Add back beep support to snd-powermac]
Christoph, i am not really sure i care all that much for this please let's it included upstream first philosophy. It let the control over what we will have or not in the debian kernel totally out of our hand, which is not something i am 100% confortable with. This is also the way other distro works except in critical release situations which isn't the case for a patch like that. Get it upstream first. Ben.
Re: Problems with SATA and 15 partitions
On Sun, 2004-05-30 at 22:36, Christoph Hellwig wrote: On Sun, May 30, 2004 at 01:11:30PM +0200, Goswin von Brederlow wrote: As for 3 this is a general problem of scsi disks. Wouldn't it be possible for the code that scans partitions to allocate device nodes dynamically for partitions 15 so that users with devfs or udev active would get additional device nodes created? Alternatively a userspace program could scan the partition block and create devices with the device mapper coresponding to each partition. Both aproaches would allow for 15 partition. No, theres lots of code in kernelspace that assumes a partitioned disk has a block of minors. Use a volume manager instead of traditional partitions if you need more than 15 subdivions of a disk. Not that this is beeing a problem for G5s too. Apple partition maps traditionally have lots of partitions, because of small driver ones used by MacOS, among others. We regulary cross the 15 partitions limit. On IDE, it's ok, with SATA or SCSI, it's a problem.
Re: NFSroot Power4 (was Re: Debian non-x86 kernel arches)
Yeah, but until we have a ppc64 toolchain, that is all we have got, and furthermore, the actual testing will go into the infrastructure around the kernel, the mkvmlinuz needed to create the zImage.chrp-rs6k from the vmlinux and the creation of the initrd, which altough it works well on pmac, fails on my pegasos (and probably also on your pseries). Also the config needs testing. This part of the testing will mostly be the same for the ppc32 and ppc64 kernels, and it is good we need feedback on those. Note that I also don't maintain nor support ppc32 for the g5 neither. It works, but I will do no special effort on it. We really need to kick the ppc64 effort into life asap, though that requires at least a more recent gcc and a more recent glibc, which seems to be yet another can of worms with debian... Personally, I'd be happy with completely depracating the -power3 and -power4 kernels until we have a 64 bit biarch compiler package. Nope, first we need to get the biarch toolchain, and then we can deprecate the power3 and power4 kernels. This is how things work in debian. Friendly, Svne Luther -- Benjamin Herrenschmidt [EMAIL PROTECTED]
Re: Debian non-x86 kernel arches
And x86 could have:
static inline no_isa_blind_probe() { return 0;}
That sounds nice.
Just a note: beware with the 8250 driver, it may still be useful on pmac
for people using a pcmcia modem. There is currently a problem in that you
cannot have both pmac_zilog and 8250 since the new serial core doesn't do
dynamic allocation of minor devices and doesn't have the old offset kludge
we had in serial.c/macserial.c in 2.4
Ben.
Re: Debian non-x86 kernel arches
On Mon, 2004-05-24 at 18:03, Christoph Hellwig wrote: On Mon, May 24, 2004 at 10:06:58AM +0200, Sven Luther wrote: Is there any ppc machine we still need floppy support on? Can floppy be made a module only? All old world pmacs (that is those prior to the bluewhite G3, but not the nubus ones which we don't support) have and need the floppy disk, as this is the only way to do the initial boot on those, with miboot. They're not using the PC floppy driver, though. Indeed, they use swim3 (which is a nightmare as well if you ask me ;) Ben.
