Bug#825840: linux-image-4.5.0-2-powerpc: radeonfb display inverted red and blue color

[Milan Kupcevic]

On Tue, 31 May 2016 11:54:54 +0100 Ben Hutchings 
wrote:
> On Tue, 2016-05-31 at 07:23 +0200, Geert Stappers wrote:

[...]

> > I don't know what PowerPC hardware is available these days.
> [...]
> 
> Looking at who's participating in OpenPOWER, I think it's mostly
> servers now. (There are still low-end PowerPC chips going into
> embedded systems, but I don't believe Debian has ever supported them.
> We require Open Firmware.) It looks like a lot of those are custom-
> made for large HPC and cloud customers, but Tyan has some that are
> generally available, like this:
> http://www.tyan.com/campaign/openpower/
> 
> There are some PowerPC systems available for remote use by developers:
> http://developers.openpowerfoundation.org/explore
> 


This Tyan development reference platform offer looks interesting.

And still, the most appealing option for an individual Free software
developer to put their hands on a fully functional big-endian machine is
to get a PowerPC Mac, YDL PowerStation or Pegasos II from ebay and
install Debian on it.

IBM Power machines are mostly out of reach to individuals, price-wise
and formal-customer-agreement-requirement-wise.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 12/08/2015 06:30 PM, John Paul Adrian Glaubitz wrote:
> On Fri, Apr 10, 2015 at 05:39:50PM -0400, Milan Kupcevic wrote:
>  > The module landed in sid D-I. It gets loaded automatically as it is not
>> blacklisted in D-I. I've been able to boot and run the installer on an
>> XServe G4 DP, a G4 Mac Mini, and a Pegasos II. All three machines have
>> radeon cards.
>  
> This reddit user got different results which rather support my stance:
> 
>> https://www.reddit.com/r/debian/3vyn0p/
> 


Hi John,

The module in question gets loaded and is used in D-I only. Pay
attention to the case you are pointing at: the graphics does not work on
boot/reboot into an installed system. At this point this module plays no
role because it is blacklisted in the main system. This user is having
some other issues unrelated to this module.

M





signature.asc
Description: OpenPGP digital signature

Bug#741642: mkvmlinuz: How to easily use mkvmlinuz/38 on Jessie?

[Milan Kupcevic]

On 07/22/2015 11:47 AM, intervenant0 gilles charabot wrote:
 
 Dear Maintainer, To avoid the consequences of the bug#741642, I want
 to use mkvmlinuz/38, but it isn't inside Jessie repository and isn't
 yet inside jessie-backports repository and when I tried to download
 the patch with :
 
 # cd /usr/sbin
 
 # wget
 https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;att=1;bug=741642;filename=mkvmlinuz-run-parts-fix.patch

  I have nothing new inside /usr/sbin to apply patch.
 
 If possible can you backports mkvmlinuz/38 to Jessie, so upgrade
 Wheezy to Jessie be more easier for me and others.
 

Hi Gilles,

Watch bug #793556 for progress on inclusion of this bugfix into
Jessie.[0] In the meantime you can download mkvmlinuz[1] version 38 and
install it on your machine before upgrading to Jessie to secure smooth
upgrade.

Milan


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793556
[1]
http://ftp.fr.debian.org/debian/pool/main/m/mkvmlinuz/mkvmlinuz_38_powerpc.deb




signature.asc
Description: OpenPGP digital signature

Re: Bug#793556: jessie-pu: package mkvmlinuz/37+deb8u1

[Milan Kupcevic]

On 07/25/2015 06:38 AM, Adam D. Barratt wrote:
 Control: tags -1 + moreinfo
 
 On Fri, 2015-07-24 at 22:32 -0400, Milan Kupcevic wrote:
 mkvmlinuz/37+deb8u1 is fixing bug #741642 already fixed in sid/testing 
 to allow for smooth upgrade from wheezy to jessie. See attached diff.

  changelog |6 ++
  kernel-image/postinst |2 ++
  kernel-image/postrm   |2 ++
 
 --- mkvmlinuz-37/debian/kernel-image/postinst   2012-06-28 21:01:13.0 
 -0400
 +++ mkvmlinuz-37+deb8u1/debian/kernel-image/postinst2015-07-23 
 22:45:48.0 -0400
 @@ -1,5 +1,7 @@
  #!/bin/sh
  
 +echo 2
 
 Will the mkvmlinuz invocation later in the postinst ever possibly
 produce output on stdout?


The db_get debconf call does communicate with debconf through
stdin/stdout by design. That is why nothing else should use stdin nor
stdout at stake for not to interfere with such communication. The
violation actually comes from 'run-parts --report' itself, not from the
hook.

Wheezy kernel package has been using 'run-parts --verbose' to run the
hooks. This worked fine as run-parts printed out to stderr only. Jessie
kernel package is using 'run-parts --report' instead where output
depends on the behavior of the hook in question. See run-parts manual
for the exact --report run-parts option description.

I'm dealing with this problem by printing out a newline character to
stderr from the hook itself, therefore pushing run-parts to output the
hook's name to stderr, thus causing run-parts to leave the debconf
communication alone.

This fix is as minimalist as you possibly could get for a bug fix in a
stable release.

CC: debian-kernel to get possible input from there


 
 While I can see the intent behind the above (forcing run-parts
 --report to output the script name to stderr rather than stdout), it
 wasn't immediately obvious. The kernel handbook (in
 https://kernel-handbook.alioth.debian.org/ch-update-hooks.html ),
 suggests exec /dev/null 2, which seems much more idiomatic.
 


The kernel-handbook suggestion won't fix this issue because run-parts
interprets debconf communication as hook output and decides that it has
to print out the hook script name to the same place, thus interfering
with debconf communication and causing the error described in bug
reports #791868 and #741642.


Milan





signature.asc
Description: OpenPGP digital signature

Bug#741642: upgrade from wheezy to jessie on a PowerMac G4 Silver

[Milan Kupcevic]

On Sun, 26 Apr 2015 16:35:29 +0200 Holger Levsen hol...@layer-acht.org
wrote:

[...]

 
 I've upgraded my old PowerMac from wheezy to jessie, which failed 
 like shown below.


[...]

 (/boot/initrd.img-3.16.0-4-powerpc) -- doing nothing at 
 /var/lib/dpkg/info/linux-image-3.16.0-4-powerpc.postinst line 263. 
 /etc/kernel/postinst.d/initramfs-tools: update-initramfs: Generating
 /boot/initrd.img-3.16.0-4-powerpc 
 run-parts:
 /etc/kernel/postinst.d/mkvmlinuz exited with return code 20


The run-parts --report option in linux-image-{version}.postinst is
causing run-parts to output a file name to stdout, thus interfere with
an ongoing communication happening between mkvmlinuz and debconf which
is facilitated through stdin/stdout.

The attached mkvmlinuz patch secures a smooth upgrade from wheezy to
jessie by getting run-parts to output to stderr, not to stdout.


diff -Nru ./debian/kernel-image/postinst ../mkvmlinuz-38/debian/kernel-image/postinst
--- ./debian/kernel-image/postinst	2012-06-28 21:01:13.0 -0400
+++ ../mkvmlinuz-38/debian/kernel-image/postinst	2015-07-09 00:00:02.617843623 -0400
@@ -1,5 +1,7 @@
 #!/bin/sh
 
+echo 2
+
 set -e
 
 . /usr/share/debconf/confmodule
diff -Nru ./debian/kernel-image/postrm ../mkvmlinuz-38/debian/kernel-image/postrm
--- ./debian/kernel-image/postrm	2012-06-28 21:01:13.0 -0400
+++ ../mkvmlinuz-38/debian/kernel-image/postrm	2015-07-09 00:00:18.697817011 -0400
@@ -1,5 +1,7 @@
 #!/bin/sh
 
+echo 2
+
 set -e
 
 . /usr/share/debconf/confmodule

Re: Debian 8 on Late 2005 G5, Graphics Issues

[Milan Kupcevic]

On 06/30/2015 05:56 AM, Peter Saisanas wrote:
[...]
 You cant get nouveau working with your current kernel. Period. It 
 doesn't matter what kernel options or module options you pass, 
 nouveau with acceleration just doesn't currently work with a 64kb 
 pagesize kernel.
 
 You are falling back to the openfirmware framebuffer. I have told
 you to disable nouveau because it just wont work with your current
 kernel config for xorg, but for the console it doesnt matter.
[...]

CC: debian-kernel@lists.debian.org

Peter,

Could you please submit a bug report[0] and explain the problem. If
Debian kernel maintainers are not aware of this problem we will have the
same issue in the next Debian release. They might be able to fix it for
Debian 8.2.

Thanks,

Milan

[0] www.debian.org/Bugs/Reporting




signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/09/2015 08:21 AM, Ben Hutchings wrote:
[...]

 
 It isn't reverted.  All I've done is to add radeonfb.ko to the drivers
 that are included *in the installer*.
 
 Neither radeon.ko nor xserver-xorg-video-radeon are included in the
 installer, so how could they possibly be used?  If you though those
 should be used in the installer, you should have told people that
 earlier.
 
 As it is, I think that the installer should be able to work using
 radeonfb.ko and xserver-xorg-video-fbdev, though I'm not sure whether
 radeonfb.ko will be loaded automatically.
 
 Ben.
 

The module landed in sid D-I. It gets loaded automatically as it is not
blacklisted in D-I. I've been able to boot and run the installer on an
XServe G4 DP, a G4 Mac Mini, and a Pegasos II. All three machines have
radeon cards.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/10/2015 06:05 PM, Ben Hutchings wrote:
 On Fri, 2015-04-10 at 17:39 -0400, Milan Kupcevic wrote:
 On 04/09/2015 08:21 AM, Ben Hutchings wrote:
 [...]


 It isn't reverted.  All I've done is to add radeonfb.ko to the drivers
 that are included *in the installer*.

 Neither radeon.ko nor xserver-xorg-video-radeon are included in the
 installer, so how could they possibly be used?  If you though those
 should be used in the installer, you should have told people that
 earlier.

 As it is, I think that the installer should be able to work using
 radeonfb.ko and xserver-xorg-video-fbdev, though I'm not sure whether
 radeonfb.ko will be loaded automatically.

 Ben.


 The module landed in sid D-I. It gets loaded automatically as it is not
 blacklisted in D-I. I've been able to boot and run the installer on an
 XServe G4 DP, a G4 Mac Mini, and a Pegasos II. All three machines have
 radeon cards.
 
 Using the graphical or text-based installer?
 
 Ben.
 

Using text-based installer. I do not remember when I last time saw
graphical installer on PowerPC platform. As far as I know there is no
graphical installer on this platform for very long time. It seems no one
is even trying to make it work.

Milan






signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/09/2015 12:29 PM, Ben Hutchings wrote:
 
 Let's try to keep this civil, please.
 
 Ben.
 


Sorry, my reaction to personal attacks was too harsh. Will stick to
technical issues and ignore any personal slurs from now on.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/09/2015 04:08 AM, John Paul Adrian Glaubitz wrote:
 On 04/09/2015 12:38 AM, Milan Kupcevic wrote:
 Well, yes. As you could see from the bug report you linked above,
  compiling radeonfb into the kernel broke X on basically all
 Radeon cards.

 
 It seems that radeonfb was compiled into the kernel since the dawn
 of time.
 
 On the powerpc Debian kernel, yes, on the other architectures, no.
 radeonfb has been deprecated long time ago and should no longer be
 used.
 
 The only reason it was compiled into the powerpc kernel without anyone
 complaining is the fact that the xf86-video-ati (= Radeon X.Org) driver
 in Wheezy was still old enough [1] to support userland mode-setting
 which was dropped upstream in version 7.0.0 almost three years ago [2].
 
 This is no longer true in Jessie and therefore we have to use radeon,
 not radeonfb. Otherwise you won't get any X display.

What did you do to ensure the radeon module is included in debian installer?

 
 The reason is that the radeon KMS module does not work once
 radoenfb has been loaded once. Even if you unload radeonfb later,
 the radeon module will still refuse to work meaning X will not be
 usable.

 
 This is good to know.
 
 I did thorough testing for the bug report you linked above which is
 why I am a bit surprised you could convince Ben so easily to partly
 revert my change. I think I also explained in the other bug tracker
 that you have to use KMS these days as UMS is being phased out.
 

There is no revert of your change at all. We are just trying to add a
module to debian installer to enable installation on machines with no
native offb support, the machines you have skipped in your thorough
testing. Any input on the best way to achieve this is welcome.

 Well, I think this can be answered straight-forward: radeonfb is
 the wrong solution as radeonfb does not support X which means you
 can use the text-based installer only. But I guess you never
 tested that as you stated in your bug report.


How is that X display in debian installer on PowerPC platform working
for you?

 The proper fix for your problem is not to revert my previous fix
 but to use the proper driver, thus reopening.

 
 There was no my previous fix, just reporting about the state of
 the things in RC1 and RC2. I'm trying to help as I have access to
 more than a few power and powerpc machines.
 
 Sure, but please ask people in the future before you are asking for
 changes which you don't understand. 

Your understanding of the consequences of your changes is trully stellar.

 I also have tons of different
 hardware available here, including several powerpc machines and
 way beyond that (m68k, sh4, mips etc).
 b
 I think you should at least discuss such changes with some more people
 before you ask for them to be integrated. 

Well, I've asked, no one complained until you showed up. The resulting
discussion spreads very interesting scent.

 For anyone who follows X.Org
 and kernel development, it is common knowledge that all the non-KMS
 drivers in the kernel are being deprecated and that you should no
 longer use them. This also applies to X.Org.
 
 It would be nice if you could CC me in the future if you are having
 issues with non-x86 hardware, especially anything that's powerpc,
 Macintosh, or - like in this case - Amiga-related hardware.

Are you sure you want to know about every non-x86 issue I face on daily
basis?


M



signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/08/2015 04:02 PM, John Paul Adrian Glaubitz wrote:
 Control: reopen -1
 
 On 04/08/2015 09:51 PM, Milan Kupcevic wrote:
 In Wheezy and in Jessie RC1 radenfb was compiled in the kernel 
 itself while debian installer worked fine on this machine.
 
 Well, yes. As you could see from the bug report you linked above, 
 compiling radeonfb into the kernel broke X on basically all Radeon 
 cards.
 

It seems that radeonfb was compiled into the kernel since the dawn of time.

 The reason is that the radeon KMS module does not work once radoenfb 
 has been loaded once. Even if you unload radeonfb later, the radeon 
 module will still refuse to work meaning X will not be usable.
 

This is good to know.

 If you want to use X, you **have** to use the radeon KMS driver as 
 the xf86-video-radeon driver does no longer support UMS modesetting 
 which means no matter what you do, you will **never** be able to run 
 X once radeonfb is loaded until next reboot.
 

Okay.

 Neither radeon nor radeonfb driver is included in RC2 debian 
 installer.
 
 Well, yes, we forgot to include radeon, true.
 

[...]

 
 Whether we want to include radeonfb module or radeon KMS module in 
 debian installer is question open to discussion.
 
 Well, I think this can be answered straight-forward: radeonfb is the 
 wrong solution as radeonfb does not support X which means you can use
 the text-based installer only. But I guess you never tested that as
 you stated in your bug report.
 
 The proper fix for your problem is not to revert my previous fix but
  to use the proper driver, thus reopening.
 

There was no my previous fix, just reporting about the state of the
things in RC1 and RC2. I'm trying to help as I have access to more than
a few power and powerpc machines.

As for the proper driver, I'm all for it. We are lucky to have you
around to take care of these issues. I'm looking forward to download and
install final Jessie release on many machines with no problems at all.

Milan





signature.asc
Description: OpenPGP digital signature

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

On 04/08/2015 02:03 PM, John Paul Adrian Glaubitz wrote:
 Hi Milan!
 
 I just stumbled across this bug report and was actually wondering why
 your Pegasos-II board won't work properly with the radeon KMS driver.
 
 As far as I know, the Radeon 9250 found on the Pegasos-II board is fully
 supported by the radeon KMS driver, so I'd expect it to work out-of
 the-box. I always had the opinion that radeonfb was deprecated in
 favor of the KMS driver and therefore the latter is the one you should
 be using.
 
 Maybe it's a good idea to report any issues with the KMS driver to the
 radeon upstream developers?
 

In Wheezy and in Jessie RC1 radenfb was compiled in the kernel itself
while debian installer worked fine on this machine.

Neither radeon nor radeonfb driver is included in RC2 debian installer.
OpenFirmware frame buffer never worked on Pegasos machines so I had to
use serial port to install RC2. After successful installation, the
machine boots up and uses radeon KMS installed on its HD.

Whether we want to include radeonfb module or radeon KMS module in
debian installer is question open to discussion.


Milan


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/552586de.7060...@physics.harvard.edu

Bug#782058: Pegasos II: installer boots up to 'returning from prom_init'

[Milan Kupcevic]

Package: src:linux
Version: 3.16.7-ckt7-1
Severity: important
Tags: d-i jessie


The last line seen on the screen after installer CD boots is 
'returning from prom_init'.  This is a regression introduced in 
d-i rc2 which persist in daily builds.

Connecting serial terminal and booting with 'console=ttyS0,9600' allows 
successful installation of jessie.  (with some hiccups that warrant a 
separate bug report to mkvmlinuz).

I'm aware that fix for bug #748398 actually introduced this regression.
The radeonfb is currently compiled as module which is not included in the 
installer. I hope that including the radeonfb module in the installer will fix 
this issue.

This report was generated on the same machine after successful installation.

Could you please add radeonfb module to debian installer?

Milan


-- Package-specific info:
** Version:
Linux version 3.16.0-4-powerpc (debian-kernel@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.7-ckt7-1 (2015-03-01)

** Command line:
root=/dev/sda2

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
[9.107171] [drm] Connector 0:
[9.107180] [drm]   VGA-1
[9.107193] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[9.107206] [drm]   Encoders:
[9.107216] [drm] CRT1: INTERNAL_DAC1
[9.107227] [drm] Connector 1:
[9.107237] [drm]   DVI-I-1
[9.107246] [drm]   HPD1
[9.107258] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[9.107269] [drm]   Encoders:
[9.107279] [drm] CRT2: INTERNAL_DAC2
[9.107290] [drm] DFP1: INTERNAL_TMDS1
[9.138249] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[9.222863] [drm] fb mappable at 0xC004
[9.222913] [drm] vram apper at 0xC000
[9.222924] [drm] size 5242880
[9.222934] [drm] fb depth is 24
[9.222944] [drm]pitch is 5120
[9.275221] Console: switching to colour frame buffer device 160x64
[9.316086] radeon 0001:01:08.0: fb0: radeondrmfb frame buffer device
[9.316398] radeon 0001:01:08.0: registered panic notifier
[9.320300] [drm] Initialized radeon 2.39.0 20080528 for 0001:01:08.0 on 
minor 0
[9.679644] Adding 3012180k swap on /dev/sda3.  Priority:-1 extents:1 
across:3012180k FS
[9.722815] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[9.732480] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
[9.872623] snd_via82xx_modem: probe of :00:0c.6 failed with error -13
[9.873912] snd_via82xx :00:0c.5: enabling device ( - 0001)
[   10.234992] systemd-journald[133]: Received request to flush runtime journal 
from PID 1
[   10.425400] via-rhine :00:0d.0: enabling device ( - 0003)
[   10.460940] via-rhine :00:0d.0 eth0: VIA Rhine II at 0xf1ffe900, 
00:0b:2f:43:fb:04, IRQ 9
[   10.462200] via-rhine :00:0d.0 eth0: MII PHY found at address 16, status 
0x786d advertising 01e1 Link c5e1
[   10.480763] uhci_hcd :00:0c.2: UHCI Host Controller
[   10.481103] uhci_hcd :00:0c.2: new USB bus registered, assigned bus 
number 1
[   10.481482] uhci_hcd :00:0c.2: detected 2 ports
[   10.481768] uhci_hcd :00:0c.2: irq 9, io base 0x1040
[   10.482306] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[   10.482646] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   10.496172] usb usb1: Product: UHCI Host Controller
[   10.509022] usb usb1: Manufacturer: Linux 3.16.0-4-powerpc uhci_hcd
[   10.521857] usb usb1: SerialNumber: :00:0c.2
[   10.587163] hub 1-0:1.0: USB hub found
[   10.587190] hub 1-0:1.0: 2 ports detected
[   10.587827] ehci-pci :00:05.2: EHCI Host Controller
[   10.587850] ehci-pci :00:05.2: new USB bus registered, assigned bus 
number 2
[   10.588018] ehci-pci :00:05.2: irq 9, io mem 0x80002800
[   10.596335] ehci-pci :00:05.2: USB 2.0 started, EHCI 1.00
[   10.596575] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[   10.596581] usb usb2: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   10.596585] usb usb2: Product: EHCI Host Controller
[   10.596589] usb usb2: Manufacturer: Linux 3.16.0-4-powerpc ehci_hcd
[   10.596593] usb usb2: SerialNumber: :00:05.2
[   10.597535] hub 2-0:1.0: USB hub found
[   10.597685] hub 2-0:1.0: 5 ports detected
[   10.598436] uhci_hcd :00:0c.3: UHCI Host Controller
[   10.598457] uhci_hcd :00:0c.3: new USB bus registered, assigned bus 
number 3
[   10.598473] uhci_hcd :00:0c.3: detected 2 ports
[   10.598522] uhci_hcd :00:0c.3: irq 9, io base 0x1060
[   10.598731] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[   10.598737] usb usb3: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[   10.598741] usb usb3: Product: UHCI Host Controller
[   10.598744] usb usb3: Manufacturer: Linux 3.16.0-4-powerpc uhci_hcd
[   10.598748] usb usb3: SerialNumber: :00:0c.3
[   10.599440] hub 3-0:1.0: USB hub found
[   10.599573] hub 3-0:1.0: 2 ports detected
[   

Bug#781934: XServe G5 all fans run full speed

[Milan Kupcevic]

Package: src:linux
Version: 3.16.7-ckt7-1
Severity: important


Installing jessie makes XServe G5 fans run full speed all the time.



-- Package-specific info:
** Version:
Linux version 3.16.0-4-powerpc64 (debian-kernel@lists.debian.org) (gcc version 
4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)

** Command line:
root=UUID=47e08bf5-e62c-4488-9715-ecc20f04b351 ro 

** Not tainted

** Kernel log:
[6.514122] systemd[1]: Starting system-getty.slice.
[6.534961] systemd[1]: Created slice system-getty.slice.
[6.544965] systemd[1]: Starting Create list of required static device nodes 
for the current kernel...
[6.575941] systemd[1]: Mounting Debug File System...
[6.597499] systemd[1]: Mounting POSIX Message Queue File System...
[6.619313] systemd[1]: Mounting Huge Pages File System...
[6.673770] systemd[1]: Starting Load Kernel Modules...
[6.698216] systemd[1]: Starting udev Coldplug all Devices...
[6.765327] systemd[1]: Started Set Up Additional Binary Formats.
[6.775556] systemd[1]: Starting Journal Service...
[6.807087] systemd[1]: Started Journal Service.
[7.344876] lp: driver loaded but no devices found
[7.621376] systemd-udevd[171]: starting version 215
[8.488202] [drm] Initialized drm 1.1.0 20060810
[8.733873] systemd-udevd[185]: renamed network interface eth0 to eth2
[8.753893] systemd-udevd[186]: renamed network interface eth1 to eth3
[9.000653] [drm] radeon kernel modesetting enabled.
[9.010302] checking generic (9c008000 96000) vs hw (9800 800)
[9.010309] fb: switching to radeondrmfb from OFfb ATY,BlueSt
[9.024617] Console: switching to colour dummy device 80x25
[9.025144] radeon 0001:06:03.0: enabling device (0086 - 0087)
[9.025601] [drm] initializing kernel modesetting (RV100 0x1002:0x5159 
0x1002:0x0908).
[9.026603] [drm] register mmio base: 0x9008
[9.026623] [drm] register mmio size: 65536
[9.163941] [drm] Not an x86 BIOS ROM, not using.
[9.173981] [drm] Using device-tree clock info
[9.174005] radeon 0001:06:03.0: VRAM: 128M 0x9800 - 
0x9FFF (64M used)
[9.174014] radeon 0001:06:03.0: GTT: 512M 0x7800 - 
0x97FF
[9.178774] [drm] Detected VRAM RAM=128M, BAR=128M
[9.178792] [drm] RAM width 64bits DDR
[9.178972] [TTM] Zone  kernel: Available graphics memory: 2040832 kiB
[9.178980] [TTM] Initializing pool allocator
[9.179111] [drm] radeon: 64M of VRAM memory ready
[9.179123] [drm] radeon: 512M of GTT memory ready.
[9.179181] [drm] GART: num cpu pages 8192, num gpu pages 131072
[9.201437] [drm] PCI GART of 512M enabled (table at 0x6218).
[9.201655] radeon 0001:06:03.0: WB disabled
[9.201676] radeon 0001:06:03.0: fence driver on ring 0 use gpu addr 
0x7800 and cpu addr 0xc00164ad
[9.201692] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[9.201697] [drm] Driver supports precise vblank timestamp query.
[9.201765] [drm] radeon: irq initialized.
[9.201809] [drm] Loading R100 Microcode
[9.237575] radeon 0001:06:03.0: firmware: failed to load radeon/R100_cp.bin 
(-2)
[9.237648] [drm:r100_cp_init] *ERROR* Failed to load firmware!
[9.237657] radeon 0001:06:03.0: failed initializing CP (-2).
[9.237664] radeon 0001:06:03.0: Disabling GPU acceleration
[9.237692] [drm] radeon: cp finalized
[9.238134] i2c i2c-5: therm_pm72: attach_adapter method is deprecated
[9.238146] i2c i2c-5: Please use another way to instantiate your i2c_client
[9.238212] i2c i2c-6: therm_pm72: attach_adapter method is deprecated
[9.238219] i2c i2c-6: Please use another way to instantiate your i2c_client
[9.238272] i2c i2c-7: therm_pm72: attach_adapter method is deprecated
[9.238279] i2c i2c-7: Please use another way to instantiate your i2c_client
[9.238334] i2c i2c-8: therm_pm72: attach_adapter method is deprecated
[9.238341] i2c i2c-8: Please use another way to instantiate your i2c_client
[9.246611] [drm] Connector Table: 1 (generic)
[9.246652] [drm] No TMDS info found in BIOS
[9.246663] [drm] No TV DAC info found in BIOS
[9.246944] [drm] Radeon Display Connectors
[9.246950] [drm] Connector 0:
[9.246954] [drm]   DVI-I-1
[9.246958] [drm]   HPD1
[9.246964] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
[9.246968] [drm]   Encoders:
[9.246973] [drm] DFP1: INTERNAL_TMDS1
[9.246977] [drm] CRT2: INTERNAL_DAC2
[9.246982] [drm] Connector 1:
[9.246986] [drm]   VGA-1
[9.246991] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
[9.247004] [drm]   Encoders:
[9.247005] [drm] CRT1: INTERNAL_DAC1
[9.247006] [drm] Connector 2:
[9.247006] [drm]   SVIDEO-1
[9.247007] [drm]   Encoders:
[9.247008] [drm] TV1: INTERNAL_DAC2
[9.345904] [drm] fb mappable at 0x9804
[9.345923] [drm] vram apper at 0x9800
[

Bug#781934: XServe G5: all fans run full speed

[Milan Kupcevic]

The therm_pm72 module is obsolete. It does not do thermal management anymore. 
I've compiled windfarm_rm31 and windfarm_pm72 modules and successfully tested 
on an XServe G5 (RackMac3,1) and a Power Mac G5 (PowerMac7,3). 

Milan


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/5520a08f.3myldcdoutz0fxbc%mi...@physics.harvard.edu

Bug#781935: initramfs-tools: XServe G5 all fans run full speed

[Milan Kupcevic]

tags 781935 + patch
thanks

diff --git a/hooks/thermal b/hooks/thermal
index 93f5100..0b755e0 100755
--- a/hooks/thermal
+++ b/hooks/thermal
@@ -32,8 +32,11 @@ powerpc|ppc64)
 	MODEL=${MODEL##*: }
 
 	case $MODEL in
-	  RackMac3,1|PowerMac7,2|PowerMac7,3)
-	force_load therm_pm72
+	  RackMac3,1)
+	force_load windfarm_rm31
+	;;
+	  PowerMac7,2|PowerMac7,3)
+	force_load windfarm_pm72
 	;;
 	  PowerMac8,1|PowerMac8,2)
 	force_load windfarm_pm81
@@ -60,6 +63,15 @@ powerpc|ppc64)
 	manual_add_modules windfarm_smu_controls
 	manual_add_modules windfarm_smu_sat
 	manual_add_modules windfarm_smu_sensors
+	manual_add_modules windfarm_ad7417_sensor
+	manual_add_modules windfarm_fcu_controls
+	manual_add_modules windfarm_lm87_sensor
+	manual_add_modules windfarm_pm112
+	manual_add_modules windfarm_pm121
+	manual_add_modules windfarm_pm72
+	manual_add_modules windfarm_pm81
+	manual_add_modules windfarm_pm91
+	manual_add_modules windfarm_rm31
 	;;
 i386|amd64|ia64)
 	manual_add_modules fan

Bug#781934: XServe G5: all fans run full speed

[Milan Kupcevic]

tags 781934 + patch
thanks

Index: linux/debian/config/kernelarch-powerpc/config
===
--- linux/debian/config/kernelarch-powerpc/config	(revision 22467)
+++ linux/debian/config/kernelarch-powerpc/config	(working copy)
@@ -389,8 +389,10 @@
 CONFIG_MAC_EMUMOUSEBTN=y
 CONFIG_THERM_WINDTUNNEL=m
 CONFIG_THERM_ADT746X=m
-CONFIG_THERM_PM72=m
+# CONFIG_THERM_PM72 is not set
 CONFIG_WINDFARM=m
+CONFIG_WINDFARM_RM31=m
+CONFIG_WINDFARM_PM72=m
 CONFIG_WINDFARM_PM81=m
 CONFIG_WINDFARM_PM91=m
 CONFIG_WINDFARM_PM112=m
Index: linux/debian/config/kernelarch-powerpc/config-arch-64-be
===
--- linux/debian/config/kernelarch-powerpc/config-arch-64-be	(revision 22467)
+++ linux/debian/config/kernelarch-powerpc/config-arch-64-be	(working copy)
@@ -66,9 +66,12 @@
 ## file: drivers/macintosh/Kconfig
 ##
 CONFIG_WINDFARM=m
+CONFIG_WINDFARM_RM31=m
+CONFIG_WINDFARM_PM72=m
 CONFIG_WINDFARM_PM81=m
 CONFIG_WINDFARM_PM91=m
 CONFIG_WINDFARM_PM112=m
+CONFIG_WINDFARM_PM121=m
 
 ##
 ## file: drivers/net/ethernet/pasemi/Kconfig
Index: linux/debian/installer/powerpc/modules/powerpc-powerpc64/fancontrol-modules
===
--- linux/debian/installer/powerpc/modules/powerpc-powerpc64/fancontrol-modules	(revision 22467)
+++ linux/debian/installer/powerpc/modules/powerpc-powerpc64/fancontrol-modules	(working copy)
@@ -1,5 +1,4 @@
 i2c-powermac ?
-therm_pm72 ?
 windfarm_core ?
 windfarm_cpufreq_clamp ?
 windfarm_lm75_sensor ?
@@ -9,6 +8,12 @@
 windfarm_pm112 ?
 windfarm_pm81 ?
 windfarm_pm91 ?
+windfarm_pm72 ?
+windfarm_rm31 ?
 windfarm_smu_controls ?
 windfarm_smu_sat ?
 windfarm_smu_sensors ?
+windfarm_ad7417_sensor ?
+windfarm_fcu_controls ?
+windfarm_lm87_sensor ?
+windfarm_pid ?

Bug#684265: Still with us

[Milan Kupcevic]

On 09/24/2012 05:04 AM, Rick Thomas wrote:
 
 On Sep 13, 2012, at 2:58 PM, Rick Thomas wrote:
 


 1) It seems likely that adding a udeb for fuse-modules will allow
 os-prober to identify other Linux OS root partitions and get them
 added to the boot-loader config file... But only as long as those
 partitions are not LVM partitions.

 I have not performed definitive experiments to verify either half of
 this assertion, but the evidence so far does point in that direction. 
 When can I expect the udeb for fuse fix to be included in an
 upcoming daily iso?  I'll be happy to test it when it's available.

 
 I tried a test installation with the following:
 
 Debian GNU/Linux testing Wheezy - Official Snapshot amd64 NETINST
  Binary-1 20120923-03:20
 
 which seems to have the necessary module:
 
 $ find /mnt -name '*fuse*' -print
 /mnt/pool/main/f/fuse
 /mnt/pool/main/f/fuse/fuse-udeb_2.9.1-1_amd64.udeb
 /mnt/pool/main/f/fuse/libfuse2_2.9.0-2_amd64.deb
 /mnt/pool/main/f/fuse/libfuse2-udeb_2.9.1-1_amd64.udeb
 /mnt/pool/main/l/linux/fuse-modules-3.2.0-4-amd64-di_3.2.29-1_amd64.udeb
 
 
 However, it still doesn't find the other OS partitions...
 
 They are located in /dev/mapper/monk-root2 and /dev/mapper/monk-root3. 
 The partition being installed to is in /dev/mapper/monk-root.
 
 I'm attaching the (gzipped) installer logs.
 
 Rick
 

Please file a separate debian-installer bug report for problems related
to finding other OS's on LVM partitions.

Milan




signature.asc
Description: OpenPGP digital signature

Bug#684265: Debian Installer 7.0 Beta2 release bug #684265

[Milan Kupcevic]

On 09/13/2012 01:41 AM, Christian PERRIER wrote:
 Quoting Rick Thomas (rbtho...@pobox.com):

 On Sep 12, 2012, at 4:21 PM, Rick Thomas wrote:

 I have not tried running os-prober from the alt-F2 console
 during the install, to see if it gives different results. I'll do
 that and report back.  Any hints of things I should be looking out
 for?

 Here's the stderr/stdout output when os-prober is run in the
 installer environment:

 umount: can't umount /var/lib/os-prober/mount: Invalid argument
 grub-probe: error: no such disk.
 grub-probe: error: no such disk.
 grub-probe: error: no such disk.
 
 Could be something like #686314. Can you try (in the installer) to do
 the workaround found there (loading the fuse module)?
 

Definitely, os-prober needs fuse module to work properly. D-i is trying
to load the fuse module but it is not available in the d-i environment.

Here is d-i log extract:

Sep 11 02:15:31 anna-install: Installing ufs-modules
Sep 11 02:15:31 anna-install: Installing btrfs-modules
Sep 11 02:15:31 anna-install: Installing fuse-modules
Sep 11 02:15:31 os-prober: unknown udeb fuse-modules

When I load the fuse module manually os-prober works fine.

Therefore solution for bug reports 684265, 686314, 686631, 687286 is to
create fuse-modules udeb package. Patch is available here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684265#35

Other problems related to listing other OS's in grub menu, that may or
may not be related to os-prober, are described in bug reports 587397,
603107, 608025, 608219, 609251.

If you see similar problems related to LVM please file a separate bug
report.

Milan




signature.asc
Description: OpenPGP digital signature

Bug#684265: linux: d-i, os-prober need fuse module to detect other OS's

[Milan Kupcevic]

tags 684265 patch
thanks

Debian installer os-prober needs fuse module to look into various
partitions for already installed operating systems.

Patch is attached.

Milan
Index: debian/installer/package-list
===
--- debian/installer/package-list	(revision 19377)
+++ debian/installer/package-list	(working copy)
@@ -332,6 +332,12 @@
  This package contains core modules for the kernel, that will almost 
  always be needed.
 
+Package: fuse-modules
+Depends: kernel-image
+Priority: standard
+Description: FUSE support modules
+ This package contains filesystem in userspace support modules.
+
 Package: acpi-modules
 Depends: kernel-image
 Priority: extra
Index: debian/installer/modules/fuse-modules
===
--- debian/installer/modules/fuse-modules	(revision 0)
+++ debian/installer/modules/fuse-modules	(revision 0)
@@ -0,0 +1 @@
+fuse


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#549681: mkvmlinuz: use xz to compress vmlinuz-boxed initrd

[Milan Kupcevic]

On 07/02/2012 07:07 AM, Touko Korpela wrote:
 On Sun, Jul 01, 2012 at 11:03:02AM -0400, Milan Kupcevic wrote:
 On 07/01/2012 07:05 AM, Touko Korpela wrote:
 ...
 +if test $post_2_6_38; then
 +  XZ=xz --check=crc32 -8
 +else
 +  XZ=false
 +fi

 From xz(1) manual page (you can ignore DecMem):
  Preset   DictSize   CompCPU   CompMem   DecMem
-0 256 KiB   03 MiB1 MiB
-1   1 MiB   19 MiB2 MiB
-2   2 MiB   2   17 MiB3 MiB
-3   4 MiB   3   32 MiB5 MiB
-4   4 MiB   4   48 MiB5 MiB
-5   8 MiB   5   94 MiB9 MiB
-6   8 MiB   6   94 MiB9 MiB
-7  16 MiB   6  186 MiB   17 MiB
-8  32 MiB   6  370 MiB   33 MiB
-9  64 MiB   6  674 MiB   65 MiB

 Better to use default setting -6 that has lower memory requirement.


 Here is timing for re-compression from gzip to xz on Pegasos II with
 Freescale 7447 1GhZ processor and 1Gb RAM:
 
 Use of -8 option isn't a good thing for systems having only 512 Mib or less
 memory. This operation shouldn't force to use slow swap space or OOM.
 

 set   time compressed size
 -91m43.962s9.5MB
 -81m44.824s9.5MB
 -61m35.097s9.6MB
 -31m10.080s10.6MB
 -20m45.609s10.7MB
 -00m19.286s11.1MB

 I've originally decided to go with -8, mainly because the same preset is
 used in mkinitramfs form initramfs-tools package. It may be worth
 hearing arguments about the timing given that all presets currently
 produce vmlinuz smaller than the 12MB limit, but the compression time is
 very different.
 
 Your size numbers show that -8 produces only marginally smaller images.
 If mkinitramfs (initramfs-tools) uses -8 for xz compression, it should be
 changed too.
 

You are right. I just did two more runs with -4 and -5:

set   time compressed size
-51m28.009s9.6MB
-41m12.628s9.8MB

Compression time goes up while compression gain gets insignificant with
presets larger than -4.

It is probably best to go with -4. It is time efficient and needs only
48 MiB for compression. Installer will be able to finish on EFIKA 5200B
boards with 128MB built-in memory.

Milan






signature.asc
Description: OpenPGP digital signature

Bug#549681: mkvmlinuz: use xz to compress vmlinuz-boxed initrd

[Milan Kupcevic]

On 07/01/2012 07:05 AM, Touko Korpela wrote:
 ...
 +if test $post_2_6_38; then
 +  XZ=xz --check=crc32 -8
 +else
 +  XZ=false
 +fi
 
 From xz(1) manual page (you can ignore DecMem):
  Preset   DictSize   CompCPU   CompMem   DecMem
-0 256 KiB   03 MiB1 MiB
-1   1 MiB   19 MiB2 MiB
-2   2 MiB   2   17 MiB3 MiB
-3   4 MiB   3   32 MiB5 MiB
-4   4 MiB   4   48 MiB5 MiB
-5   8 MiB   5   94 MiB9 MiB
-6   8 MiB   6   94 MiB9 MiB
-7  16 MiB   6  186 MiB   17 MiB
-8  32 MiB   6  370 MiB   33 MiB
-9  64 MiB   6  674 MiB   65 MiB
 
 Better to use default setting -6 that has lower memory requirement.
 

Here is timing for re-compression from gzip to xz on Pegasos II with
Freescale 7447 1GhZ processor and 1Gb RAM:

set   time compressed size
-91m43.962s9.5MB
-81m44.824s9.5MB
-61m35.097s9.6MB
-31m10.080s10.6MB
-20m45.609s10.7MB
-00m19.286s11.1MB

I've originally decided to go with -8, mainly because the same preset is
used in mkinitramfs form initramfs-tools package. It may be worth
hearing arguments about the timing given that all presets currently
produce vmlinuz smaller than the 12MB limit, but the compression time is
very different.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#549681: bug#549681: mkvmlinuz: use xz to compress vmlinuz-boxed initrd

[Milan Kupcevic]

On 07/01/2012 12:31 PM, Ben Hutchings wrote:
 On Sat, 2012-06-30 at 23:01 -0400, Milan Kupcevic wrote:
 [...]
 --- mkvmlinuz   (revision 19233)
 +++ mkvmlinuz   (working copy)
 [...]
 @@ -158,6 +153,12 @@
post_2_6_19=
  fi
  
 +if dpkg --compare-versions $release ge 2.6.38  test $arch != prep ; 
 then
 +  post_2_6_38=Yes
 +else
 +  post_2_6_38=
 +fi
 +
 [...]
 
 We should actually check for CONFIG_RD_XZ=y in /boot/config-$release, to
 allow for custom kernels that don't enable it.  And of course the
 variable name should be something like is_xz_supported.
 
 Ben.
 

Updated patch is attached.

Milan
Index: mkvmlinuz
===
--- mkvmlinuz	(revision 19233)
+++ mkvmlinuz	(working copy)
@@ -133,13 +133,10 @@
 # if no release was specified, extract it from the kernel image name
 if test -z $release; then
 release=$(echo $kernel | sed s/.*vmlinux-//)
-if echo $release | grep -q '2\.[46]\.[0-9]*'; then
-	:
-else
-	release=
-fi
 fi
 
+test -z $verbose || echo === Release version seems to be $release.
+
 if dpkg --compare-versions $release ge 2.6.16  test $arch != prep ; then
   post_2_6_16=Yes
 else
@@ -158,7 +155,9 @@
   post_2_6_19=
 fi
 
-test -z $verbose || echo === Release version seems to be $release.
+if grep -q CONFIG_RD_XZ=y /boot/config-$release ; then
+  is_xz_supported=Yes
+fi
 
 # if no object file directory was specified, try to find one
 if test -z $objdir; then
@@ -206,6 +205,11 @@
 test -z $verbose || echo === Doing build in $work.
 
 # utilities
+if test $is_xz_supported; then
+  XZ=xz --check=crc32 -8
+else
+  XZ=false
+fi
 if test $post_2_6_16; then
   ADDNOTE=$objdir/addnote # must be present in mkvmlinuz fallback tools
   if test \! -f $ADDNOTE; then
@@ -291,22 +295,35 @@
 
 # create the compressed initrd image file
 if test -n $initrd; then
-test -z $verbose || echo === Creating compressed initrd image initrd.gz...
+test -z $verbose || echo === Creating compressed initrd image
 if test -z $compressed; then
-# Detect if the file was already compressed by gzip.
-	if test `od -A n -c -N 2 $initrd` =  037 213; then 
-	compressed=Yes
+	if test `xxd -p -l2 $initrd` = 1f8b; then
+	test -z $verbose || echo === $initrd is already gzip compressed
+	do_cmd cp -p $initrd $work/initrd.gz
+	if test -n $is_xz_supported  test $arch != prep; then
+	  test -z $verbose || echo === recompressing to xz
+	  zcat $initrd | $XZ -  $work/initrd.xz
+	fi
+	elif test `xxd -p -l6 $initrd` = fd377a585a00; then 
+	test -z $verbose || echo === $initrd is already xz compressed
+	do_cmd cp -p $initrd $work/initrd.xz
 	else
+	test -z $verbose || echo === assuming $initrd was not compressed
 	compressed=No
 	fi
 fi
 case $compressed in
 	Yes)
 	do_cmd cp -p $initrd $work/initrd.gz
+	do_cmd ln -s $work/initrd.gz $work/initrd.xz
 	;;
 	No)
 	do_cmd cp -p $initrd $work/initrd
-	do_cmd $GZIP $work/initrd
+	if test -n $is_xz_supported  test $arch != prep; then
+	  do_cmd $XZ $work/initrd
+	else
+	  do_cmd $GZIP $work/initrd
+	fi
 	;;
 esac
 fi
@@ -317,7 +334,11 @@
   WRAPPER=$objdir/wrapper
   vmlinuz=$work/vmlinuz.$arch
   if test -n $initrd; then
-INITRD=-i $work/initrd.gz
+if test $is_xz_supported; then
+  INITRD=-i $work/initrd.xz
+else
+  INITRD=-i $work/initrd.gz
+fi
   fi
   $WRAPPER -c -o $vmlinuz -p $arch $INITRD -D $objdir -W $work $kernel
 else 


signature.asc
Description: OpenPGP digital signature

Bug#549681: bug#549681: mkvmlinuz: use xz to compress vmlinuz-boxed initrd

[Milan Kupcevic]

On 07/01/2012 04:13 PM, Geert Stappers wrote:
 
 
 Please use the more readable
 
 test -n $is_xz_supported
 

Have a look at this:


test $string
test -n $string
[ $string ]
[ -n $string ]


They are just four different expressions of exactly the same thing. It
is hard to please everybody's taste.

M



signature.asc
Description: OpenPGP digital signature

Bug#549681: bug#549681: mkvmlinuz: use xz to compress vmlinuz-boxed initrd

[Milan Kupcevic]

 some OpenFirmware implementations, such as the one in the PegasosII,
 have a 12 MB size limit on kernel images, and no initrd loading
 capability. The latter is worked around by merging the initrd into the
 image with the mkvmlinuz tool, however the generated images are
 unbootable if they exceed 12 MB.

The attached patch brings vmlinuz from about 13MB to about 9.5MB, which
is well under the 12MB limit. Downside is that xz compressing is
noticeably slower than currently used gzip, but decompressing speed
difference is not noticeable.

I've tested it on Pegasos II machine, it boots really fast. Updated
mkvmlinuz package is waiting on mentors.debian.net for a willing sponsor
for upload.

Milan
Index: mkvmlinuz
===
--- mkvmlinuz	(revision 19233)
+++ mkvmlinuz	(working copy)
@@ -133,11 +133,6 @@
 # if no release was specified, extract it from the kernel image name
 if test -z $release; then
 release=$(echo $kernel | sed s/.*vmlinux-//)
-if echo $release | grep -q '2\.[46]\.[0-9]*'; then
-	:
-else
-	release=
-fi
 fi
 
 if dpkg --compare-versions $release ge 2.6.16  test $arch != prep ; then
@@ -158,6 +153,12 @@
   post_2_6_19=
 fi
 
+if dpkg --compare-versions $release ge 2.6.38  test $arch != prep ; then
+  post_2_6_38=Yes
+else
+  post_2_6_38=
+fi
+
 test -z $verbose || echo === Release version seems to be $release.
 
 # if no object file directory was specified, try to find one
@@ -206,6 +207,11 @@
 test -z $verbose || echo === Doing build in $work.
 
 # utilities
+if test $post_2_6_38; then
+  XZ=xz --check=crc32 -8
+else
+  XZ=false
+fi
 if test $post_2_6_16; then
   ADDNOTE=$objdir/addnote # must be present in mkvmlinuz fallback tools
   if test \! -f $ADDNOTE; then
@@ -291,22 +297,35 @@
 
 # create the compressed initrd image file
 if test -n $initrd; then
-test -z $verbose || echo === Creating compressed initrd image initrd.gz...
+test -z $verbose || echo === Creating compressed initrd image
 if test -z $compressed; then
-# Detect if the file was already compressed by gzip.
-	if test `od -A n -c -N 2 $initrd` =  037 213; then 
-	compressed=Yes
+	if test `xxd -p -l2 $initrd` = 1f8b; then
+	test -z $verbose || echo === $initrd is already gzip compressed
+	do_cmd cp -p $initrd $work/initrd.gz
+	if test -n $post_2_6_38  test $arch != prep; then
+	  test -z $verbose || echo === recompressing to xz
+	  zcat $initrd | $XZ -  $work/initrd.xz
+	fi
+	elif test `xxd -p -l6 $initrd` = fd377a585a00; then 
+	test -z $verbose || echo === $initrd is already xz compressed
+	do_cmd cp -p $initrd $work/initrd.xz
 	else
+	test -z $verbose || echo === assuming $initrd was not compressed
 	compressed=No
 	fi
 fi
 case $compressed in
 	Yes)
 	do_cmd cp -p $initrd $work/initrd.gz
+	do_cmd ln -s $work/initrd.gz $work/initrd.xz
 	;;
 	No)
 	do_cmd cp -p $initrd $work/initrd
-	do_cmd $GZIP $work/initrd
+	if test -n $post_2_6_38  test $arch != prep; then
+	  do_cmd $XZ $work/initrd
+	else
+	  do_cmd $GZIP $work/initrd
+	fi
 	;;
 esac
 fi
@@ -317,7 +336,11 @@
   WRAPPER=$objdir/wrapper
   vmlinuz=$work/vmlinuz.$arch
   if test -n $initrd; then
-INITRD=-i $work/initrd.gz
+if test $post_2_6_38; then
+  INITRD=-i $work/initrd.xz
+else
+  INITRD=-i $work/initrd.gz
+fi
   fi
   $WRAPPER -c -o $vmlinuz -p $arch $INITRD -D $objdir -W $work $kernel
 else 


signature.asc
Description: OpenPGP digital signature

Bug#666021: swapper/2: page allocation failure: order:1, mode:0x20

[Milan Kupcevic]

found 666021 3.2.18-1
tags 666021 +confirmed
thanks


Linux version 3.2.0-2-powerpc64 (Debian 3.2.18-1) 
(debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-4) ) 
#1 SMP Mon May 21 22:39:59 UTC 2012



While running debmirror I'm getting call trace every few minutes. Call 
trace is attached. The problem completely disappears after issuing:


  sysctl vm.min_free_kbytes=16384


The machine is 2.5GHz Quad PowerMac with 4GB of memory. Processes are 
using about 260MB while the rest gets used by buffers and cache. Free 
memory was floating around 10MB when vm.min_free_kbytes was at 8107 and 
is floating around 20MB after I increased the vm.min_free_kbytes to 16384.


M

Jun  6 21:53:39 power kernel: [17882.998757] swapper/2: page allocation 
failure: order:1, mode:0x20
Jun  6 21:53:39 power kernel: [17883.000968] Call Trace:
Jun  6 21:53:39 power kernel: [17883.002424] [cffe6d10] 
[c001350c] .show_stack+0x80/0x130 (unreliable)
Jun  6 21:53:39 power kernel: [17883.003976] [cffe6dc0] 
[c0119118] .warn_alloc_failed+0xf0/0x108
Jun  6 21:53:39 power kernel: [17883.005544] [cffe6e80] 
[c011c3ec] .__alloc_pages_nodemask+0x700/0x7c4
Jun  6 21:53:39 power kernel: [17883.007152] [cffe7010] 
[c01589d8] .kmem_getpages+0x5c/0x140
Jun  6 21:53:39 power kernel: [17883.008774] [cffe70b0] 
[c0158cfc] .fallback_alloc+0x174/0x200
Jun  6 21:53:39 power kernel: [17883.010420] [cffe7190] 
[c015a6fc] .kmem_cache_alloc+0x104/0x1f8
Jun  6 21:53:39 power kernel: [17883.012088] [cffe7250] 
[c03c3118] .sk_prot_alloc+0x38/0x1c4
Jun  6 21:53:39 power kernel: [17883.013769] [cffe7300] 
[c03c41b4] .sk_clone+0x20/0x2cc
Jun  6 21:53:39 power kernel: [17883.015484] [cffe73a0] 
[c0413378] .inet_csk_clone+0x1c/0x94
Jun  6 21:53:39 power kernel: [17883.017209] [cffe7430] 
[c042c324] .tcp_create_openreq_child+0x24/0x3e8
Jun  6 21:53:39 power kernel: [17883.018998] [cffe74e0] 
[c042a854] .tcp_v4_syn_recv_sock+0x3c/0x31c
Jun  6 21:53:39 power kernel: [17883.020792] [cffe7580] 
[c042c12c] .tcp_check_req+0x350/0x524
Jun  6 21:53:39 power kernel: [17883.022605] [cffe7670] 
[c042966c] .tcp_v4_do_rcv+0x200/0x3c8
Jun  6 21:53:39 power kernel: [17883.024427] [cffe7750] 
[c042b728] .tcp_v4_rcv+0x558/0x940
Jun  6 21:53:39 power kernel: [17883.026246] [cffe7840] 
[c04088f4] .ip_local_deliver_finish+0x1d0/0x2d8
Jun  6 21:53:39 power kernel: [17883.028118] [cffe78e0] 
[c0408704] .ip_rcv_finish+0x374/0x394
Jun  6 21:53:39 power kernel: [17883.030011] [cffe7970] 
[c03d1060] .__netif_receive_skb+0x698/0x6e8
Jun  6 21:53:39 power kernel: [17883.031920] [cffe7a60] 
[c03d26c4] .netif_receive_skb+0x90/0x98
Jun  6 21:53:39 power kernel: [17883.033859] [cffe7b00] 
[c03d51c0] .napi_skb_finish+0x34/0x58
Jun  6 21:53:39 power kernel: [17883.035857] [cffe7b80] 
[d108d4f4] .tg3_poll_work+0x6d8/0xcbc [tg3]
Jun  6 21:53:39 power kernel: [17883.037851] [cffe7cd0] 
[d1093b24] .tg3_poll+0x258/0x448 [tg3]
Jun  6 21:53:39 power kernel: [17883.039854] [cffe7dc0] 
[c03d2924] .net_rx_action+0xd0/0x30c
Jun  6 21:53:39 power kernel: [17883.041893] [cffe7eb0] 
[c008b9ac] .__do_softirq+0x158/0x2a0
Jun  6 21:53:39 power kernel: [17883.043979] [cffe7f90] 
[c001c68c] .call_do_softirq+0x14/0x24
Jun  6 21:53:39 power kernel: [17883.046089] [c0017a84f990] 
[c000edb8] .do_softirq+0x7c/0xec
Jun  6 21:53:39 power kernel: [17883.048202] [c0017a84fa30] 
[c008bd00] .irq_exit+0x4c/0x9c
Jun  6 21:53:39 power kernel: [17883.050346] [c0017a84fab0] 
[c000ec18] .do_IRQ+0x1c4/0x240
Jun  6 21:53:39 power kernel: [17883.052489] [c0017a84fb60] 
[c000553c] hardware_interrupt_entry+0x18/0x1c
Jun  6 21:53:39 power kernel: [17883.054696] --- Exception: 501 at 
.cpu_idle+0x10c/0x1cc
Jun  6 21:53:39 power kernel: [17883.054697] LR = .cpu_idle+0x10c/0x1cc
Jun  6 21:53:39 power kernel: [17883.059158] [c0017a84fe50] 
[c001510c] .cpu_idle+0x64/0x1cc (unreliable)
Jun  6 21:53:39 power kernel: [17883.061470] [c0017a84fee0] 
[c04e5138] .start_secondary+0x33c/0x344
Jun  6 21:53:39 power kernel: [17883.063799] [c0017a84ff90] 
[c00093e8] .start_secondary_prolog+0x10/0x14
Jun  6 21:53:39 power kernel: [17883.066147] Mem-Info:
Jun  6 21:53:39 power kernel: [17883.068475] Node 0 DMA per-cpu:
Jun  6 21:53:39 power kernel: [17883.070832] CPU0: hi:  186, btch:  31 usd: 
110
Jun  6 21:53:39 power kernel: [17883.073241] CPU1: hi:  186, btch:  31 usd: 
164
Jun  6 21:53:39 power kernel: [17883.075656] CPU2: hi:  186, btch:  31 usd: 
157
Jun  6 21:53:39 power kernel: [17883.078065] CPU3: hi:  186, btch:  31 usd: 
 43
Jun  6 21:53:39 power 

Re: Nonexistent modules in Linux kernel-wedge configuration

[Milan Kupcevic]

On 01/29/2012 03:24 PM, Ben Hutchings wrote:
 
 The IDE modules listed here have presumably been replaced by
 libata-based modules, but there might be some cases where neither driver
 is built or neither is included in the installer.
 

IBM Intellistation POWER 275 needs pata_sl82c105 in PowerPC installer. I
have no idea why it got kicked out.

 
 Can anyone explain the others?
 

pata_macio gets compiled in the kernel now, not as a module.


Milan


-- 
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/4f25fe3e.6020...@physics.harvard.edu

Re: State of mkvmlinuz

[Milan Kupcevic]

On 01/27/2012 10:12 AM, Bastian Blank wrote:
 Hi folks
 
 There is a package called mkvmlinuz in the archive. It is maintained by
 the kernel team.
 
 mkvmlinuz is only used on the powerpc architecture.
 
 Does anyone know the current state of mkvmlinuz? Is it still needed?
 
 Bastian
 

It is still used by d-i to create bootable kernel images on Pegasos
machines. As kernel grew over time, mkvmlinuz currently creates
too-large images that firmware has trouble loading [0], but changing
compression from gz to xz fixes the problem.

Milan

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549681


-- 
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/4f22d112.4080...@physics.harvard.edu

Bug#636269: Bug #636269 -- Problem is still with us...

[Milan Kupcevic]

On 09/07/2011 01:47 AM, Rick Thomas wrote:
 
 I tried again today.  I installed Sid from the Sid_d-i PowerPC daily
 businesscard. Same problem.
 


Fixed kernel did not get into d-i, yet.

Milan



-- 
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/4e676a3d.50...@physics.harvard.edu

Bug#636269: ide-pmac - pata_macio transition

[Milan Kupcevic]

On 08/06/2011 07:53 AM, Stephane Louise wrote:
 
 Therefore, the patch should be as trivial as (not tested though):
 
 --- config.old2011-08-06 12:52:46.0 +0200
 +++ config2011-08-06 12:53:43.0 +0200
 @@ -1560,7 +1560,7 @@
  # CONFIG_PATA_IT8213 is not set
  CONFIG_PATA_IT821X=m
  CONFIG_PATA_JMICRON=m
 -# CONFIG_PATA_MACIO is not set
 +CONFIG_PATA_MACIO=m
  CONFIG_PATA_MARVELL=m
  # CONFIG_PATA_NETCELL is not set
  # CONFIG_PATA_NINJA32 is not set
 


It wont work unless ide-pmac is disabled:


--- debian/config/powerpc/config
+++ ../linux-2.6-3.0.0/debian/config/powerpc/config
@@ -78,6 +78,7 @@
 ##
 ## file: drivers/ata/Kconfig
 ##
+CONFIG_PATA_MACIO=m
 CONFIG_PATA_PCMCIA=m

 ##
@@ -294,8 +295,7 @@
 # CONFIG_BLK_DEV_SLC90E66 is not set
 CONFIG_BLK_DEV_TRM290=m
 CONFIG_BLK_DEV_VIA82CXXX=m
-CONFIG_BLK_DEV_IDE_PMAC=y
-CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y
+# CONFIG_BLK_DEV_IDE_PMAC is not set

 ##
 ## file: drivers/input/gameport/Kconfig




-- 
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/4e3df187.4060...@physics.harvard.edu

Bug#607284: linux-base: run /usr/sbin/ybin after yaboot.conf upgrade

[Milan Kupcevic]

On upgrade from lenny to squeeze linux-base package changes content of
/etc/yaboot.conf but does not run /usr/sbin/ybin to actually apply the
changes on the bootloader. Machines with drive enumeration problems and
drive naming changes introduced in new kernels will be non-(re)bootable.

Milan



signature.asc
Description: OpenPGP digital signature

Bug#603981: initramfs-tools: Load PowerMac G5 thermal modules

[Milan Kupcevic]

On 11/19/2010 04:09 AM, maximilian attems wrote:

 oh fun, thought that linux-2.6 was fixed to autoload those modules.

Only i2c_powermac gets included/loaded without manual intervention. I
removed it from this hook.


 -if [ -e /sys/bus/ps3_system_bus/ ]; then
 -exit 0
 -fi
 why do you remove the ps3 check??

No need to exit here on PS3 because this patch includes/loads therm_pm72
and windfarm_* modules on G5 Mac machines only.

 
 -manual_add_modules therm_pm72
 +
 +# Only PowerMac G5 machines need these modules
 +
 +MODEL=`grep model /proc/cpuinfo 2/dev/null`; MODEL=${MODEL##*: }
 please 2 lines and a check that /proc/cpuinfo is readable

OK. Fixed.

 +
 +case $MODEL in
 +  RackMac3,1|PowerMac7,2|PowerMac7,3)
 +force_load therm_pm72
 +;;
 +  PowerMac8,1|PowerMac8,2)
 +force_load windfarm_pm81
 +;;
 +  PowerMac9,1)
 +force_load windfarm_pm91
 +;;
 +  PowerMac11,2)
 +force_load windfarm_pm112
 +;;
 +  PowerMac12,1)
 +force_load windfarm_pm121
 +;;
 +  *)
 +exit 0
 hmm why this exit, seems bad for any other box?

Every G5 Mac model [1] is covered. We can safely exit here because no
other box is using windfarm_* modules.

 +;;
 +esac
  manual_add_modules windfarm_core
  manual_add_modules windfarm_cpufreq_clamp
  manual_add_modules windfarm_lm75_sensor
  manual_add_modules windfarm_max6690_sensor
  manual_add_modules windfarm_pid
 -manual_add_modules windfarm_pm121
 -manual_add_modules windfarm_pm112
 -manual_add_modules windfarm_pm81
 -manual_add_modules windfarm_pm91
  manual_add_modules windfarm_smu_controls
  manual_add_modules windfarm_smu_sat
  manual_add_modules windfarm_smu_sensors
 
 otherwise this looks like a good workaround for this kernel bug.
 please repost fixed patch.

New patch is attached.


[1]
http://www.everymac.com/systems/by_capability/mac-specs-by-machine-model-machine-id.html
diff -Nru ./hooks/thermal ../initramfs-tools-0.98.5/hooks/thermal
--- ./hooks/thermal	2010-09-23 14:43:51.0 -0400
+++ ../initramfs-tools-0.98.5/hooks/thermal	2010-11-19 16:08:33.0 -0500
@@ -22,23 +22,44 @@
 case $DPKG_ARCH in
 # copy the right modules
 powerpc|ppc64)
-	if [ -e /sys/bus/ps3_system_bus/ ]; then
-		exit 0
-	fi
-	manual_add_modules therm_pm72
+
+	# Only G5 Mac machines need to load 
+	# therm_pm72 or one of the windfarm_pm* modules.
+
+	[ -r /proc/cpuinfo ] || exit 0
+
+	MODEL=`grep model /proc/cpuinfo`
+	MODEL=${MODEL##*: }
+
+	case $MODEL in
+	  RackMac3,1|PowerMac7,2|PowerMac7,3)
+	force_load therm_pm72
+	;;
+	  PowerMac8,1|PowerMac8,2)
+	force_load windfarm_pm81
+	;;
+	  PowerMac9,1)
+	force_load windfarm_pm91
+	;;
+	  PowerMac11,2)
+	force_load windfarm_pm112
+	;;
+	  PowerMac12,1)
+	force_load windfarm_pm121
+	;;
+	  *)
+	# No other machine needs windfarm_* modules on initrd.
+	exit 0
+	;;
+	esac
 	manual_add_modules windfarm_core
 	manual_add_modules windfarm_cpufreq_clamp
 	manual_add_modules windfarm_lm75_sensor
 	manual_add_modules windfarm_max6690_sensor
 	manual_add_modules windfarm_pid
-	manual_add_modules windfarm_pm121
-	manual_add_modules windfarm_pm112
-	manual_add_modules windfarm_pm81
-	manual_add_modules windfarm_pm91
 	manual_add_modules windfarm_smu_controls
 	manual_add_modules windfarm_smu_sat
 	manual_add_modules windfarm_smu_sensors
-	manual_add_modules i2c-powermac
 	;;
 i386|amd64|ia64)
 	manual_add_modules fan


signature.asc
Description: OpenPGP digital signature

Bug#603981: initramfs-tools: Load PowerMac G5 thermal modules

[Milan Kupcevic]

Package: initramfs-tools
Version: 0.98.5
Severity: important
Tags: patch

On iMac and PowerMac G5 machines, about a minute after boot, fans run at
full speed producing jet engine noise. Thermal modules do not get loaded
as they were in Lenny.
diff -Nru ./hooks/thermal ../initramfs-tools-0.98.5/hooks/thermal
--- ./hooks/thermal	2010-09-23 14:43:51.0 -0400
+++ ../initramfs-tools-0.98.5/hooks/thermal	2010-11-18 10:55:47.0 -0500
@@ -22,19 +22,33 @@
 case $DPKG_ARCH in
 # copy the right modules
 powerpc|ppc64)
-	if [ -e /sys/bus/ps3_system_bus/ ]; then
-		exit 0
-	fi
-	manual_add_modules therm_pm72
+
+	# Only PowerMac G5 machines need these modules
+
+	MODEL=`grep model /proc/cpuinfo 2/dev/null`; MODEL=${MODEL##*: }
+
+	case $MODEL in
+	  RackMac3,1|PowerMac7,2|PowerMac7,3)
+	force_load therm_pm72
+	;;
+	  PowerMac8,1|PowerMac8,2)
+	force_load windfarm_pm81
+	;;
+	  PowerMac11,2)
+	force_load windfarm_pm112
+	;;
+	  PowerMac12,1)
+	force_load windfarm_pm121
+	;;
+	  *)
+	exit 0
+	;;
+	esac
 	manual_add_modules windfarm_core
 	manual_add_modules windfarm_cpufreq_clamp
 	manual_add_modules windfarm_lm75_sensor
 	manual_add_modules windfarm_max6690_sensor
 	manual_add_modules windfarm_pid
-	manual_add_modules windfarm_pm121
-	manual_add_modules windfarm_pm112
-	manual_add_modules windfarm_pm81
-	manual_add_modules windfarm_pm91
 	manual_add_modules windfarm_smu_controls
 	manual_add_modules windfarm_smu_sat
 	manual_add_modules windfarm_smu_sensors


signature.asc
Description: OpenPGP digital signature

Bug#603981: initramfs-tools: Load PowerMac G5 thermal modules

[Milan Kupcevic]

The first patch did not include PowerMac9,1. Corrected patch is attached
to this message.

Thanks,

Milan
diff -Nru ./hooks/thermal ../initramfs-tools-0.98.5/hooks/thermal
--- ./hooks/thermal	2010-09-23 14:43:51.0 -0400
+++ ../initramfs-tools-0.98.5/hooks/thermal	2010-11-18 21:54:21.0 -0500
@@ -22,19 +22,36 @@
 case $DPKG_ARCH in
 # copy the right modules
 powerpc|ppc64)
-	if [ -e /sys/bus/ps3_system_bus/ ]; then
-		exit 0
-	fi
-	manual_add_modules therm_pm72
+
+	# Only PowerMac G5 machines need these modules
+
+	MODEL=`grep model /proc/cpuinfo 2/dev/null`; MODEL=${MODEL##*: }
+
+	case $MODEL in
+	  RackMac3,1|PowerMac7,2|PowerMac7,3)
+	force_load therm_pm72
+	;;
+	  PowerMac8,1|PowerMac8,2)
+	force_load windfarm_pm81
+	;;
+	  PowerMac9,1)
+	force_load windfarm_pm91
+	;;
+	  PowerMac11,2)
+	force_load windfarm_pm112
+	;;
+	  PowerMac12,1)
+	force_load windfarm_pm121
+	;;
+	  *)
+	exit 0
+	;;
+	esac
 	manual_add_modules windfarm_core
 	manual_add_modules windfarm_cpufreq_clamp
 	manual_add_modules windfarm_lm75_sensor
 	manual_add_modules windfarm_max6690_sensor
 	manual_add_modules windfarm_pid
-	manual_add_modules windfarm_pm121
-	manual_add_modules windfarm_pm112
-	manual_add_modules windfarm_pm81
-	manual_add_modules windfarm_pm91
 	manual_add_modules windfarm_smu_controls
 	manual_add_modules windfarm_smu_sat
 	manual_add_modules windfarm_smu_sensors


signature.asc
Description: OpenPGP digital signature