Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Rick Thomas]

> Pushed a fix to git:
> 
> https://salsa.debian.org/kernel-team/linux/-/commit/f952b94621847732b3ed96a74babb89b6a1862f6

Wow!  Thanks!  At least I now know I'm not crazy...  Any idea how long it will 
be before the fix is in something I can download and install with?

Enjoy!
Rick

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Rick Thomas]

On Tue, Jun 1, 2021, at 11:06 PM, Vagrant Cascadian wrote:
> On 2021-06-01, Rick Thomas wrote:
> > Is there any estimate of when the assumed fix (linux/5.10.40-1) will
> > show up in the installer at [1] ?  I'd love to test it!
> ...
> > [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
> 
> It should already be there kernel version 5.10.38-1 had it, 5.10.40-1
> should also have it.
> 
> I only tested it outside of debian-installer (e.g. upgrading kernel on
> an already installed system), so it is also possible that more modules
> are needed in one of the kernel udebs used by the installer, or that
> you're experiencing a different issue from the one that was fixed. I'll
> try to test debian-installer on Cubox-i4pro to see if I still have an
> issue.

Hmmm... Here's a log from the serial console while trying to use the above card 
image.  Best way to read it is with "less -r".
It does appear that the 5.10.40-1 kernel is being used by the installer.  But 
it still has the problem... 

Hope it helps!
Let me know if there's anything else I can provide that might help!

Rick


screenlog
Description: Binary data

Bug#982270: Re Bug#982270 (installer can not find an ehternet driver for CuBox-i4Pro)

[Rick Thomas]

Hi!
Is there any estimate of when the assumed fix (linux/5.10.40-1) will show up in 
the installer at [1] ?  I'd love to test it!
Failing that, is there some other place I can get an installer SDcard image 
with that fix?

Thanks!   Rick

[1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/

Bug#785419: Bug#855203: hwclock-set: Synchronize from hwclock despite systemd presence

[Rick Thomas]

On Sat, May 8, 2021, at 12:02 PM, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi,
> 
> Ist this still an issue or has been fixed in meanwhile? I'm going
> through some older src:linux associated buts and noticed that it was
> considered here to reassign it to util-linux.
> 
> Is the problem still present?
> 
> Further:
> 
> On Fri, Mar 17, 2017 at 07:55:31PM +0100, Lukas Wunner wrote:
> [...]
> > @Rick Thomas: Could you verify if the attached patch solves this issue
> > for you?
> 
> Were you able to test the proposed patch?
> 
> Regards,
> Salvatore

Thanks for following up on this!

No, I got side-tracked by a family medical issue (now all resolved and OK) and 
never was able to test the patches.  Sorry!

Nevertheless, I can verify that the problem _is_ still with us.  I'm running

rbthomas@cube:~$ uname -a
Linux cube 4.19.0-16-armmp #1 SMP Debian 4.19.181-1 (2021-03-19) armv7l 
GNU/Linux
rbthomas@cube:~$ cat /etc/debian_version 
10.9

on a Cubox-i4Pro.   It still shows as having two RealTime clocks.  The one 
named /dev/rtc0 still looses it's time when I unplug/replug the device, while 
/dev/rtc1 still does manage to carry-over.  Unfortunately, the kernel still 
uses rtc0 to set system time when rebooting.

The workaround I use (such as it is) is to run ntpsec with the "-g" option, 
which allows the first system clock adjustment to be more than 1000 seconds. ( 
I also have to remember to reset rtc0 after a power outage.)

Along the same lines, I recently got a Raspberry Pi4B 4GB, and was somewhat 
surprised to find that it did not have a RT clock at all unless you buy an 
add-on hat for it.  So we not only have to deal with devices with two RT 
clocks, but also devices with zero RT clocks.

I'm not much of a software developer, so if you want me to test something, 
please provide it in the form of a ".deb" that I can install,  rather than a 
set of patches I have to apply.

Thanks!
Rick

Bug#741663: G4 MDD report (finally) Re: Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

Here's the data from the G4 MDD.  Sorry for the delay getting it out!

rbthomas@macswell:~$ cat /proc/cpuinfo 
processor   : 0
cpu : 7455, altivec supported
clock   : 1416.61MHz
revision: 3.3 (pvr 8001 0303)
bogomips: 83.31

processor   : 1
cpu : 7455, altivec supported
clock   : 1416.61MHz
revision: 3.3 (pvr 8001 0303)
bogomips: 83.31

total bogomips  : 166.63
timebase: 41659125
platform: PowerMac
model   : PowerMac3,6
machine : PowerMac3,6
motherboard : PowerMac3,6 MacRISC3 Power Macintosh
detected as : 129 (PowerMac G4 Windtunnel)
pmac flags  : 0010
L2 cache: 256K unified
pmac-generation : NewWorld
Memory  : 2048 MB

rbthomas@macswell:~$ cat /proc/version 
Linux version 5.10.0-6-powerpc-smp (debian-kernel@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.28-1 (2021-04-09)

rbthomas@macswell:~$ lsmod | grep wind
therm_windtunnel7229  0

The fans come on at low speed when I give the CPU a short workout.  I haven't 
tried a long-term CPU intensive task yet.

Hope this helps!
Rick

On Tue, Apr 27, 2021, at 3:55 PM, Rick Thomas wrote:
> 
> 
> On Tue, Apr 27, 2021, at 12:15 AM, John Paul Adrian Glaubitz wrote:> 
> > On 4/27/21 8:54 AM, Rick Thomas wrote:
> > > I'll look around and see if I have any MDD (mirror drive door -- the type 
> > > in the
> > > original bugreport) machines.  If so, I'll try to find some time to 
> > > install Adrian's
> > > latest and report back.
> > 
> > OK, thank you. Maybe someone else with a machine that previously had 
> > this issue can also
> > comment so that we can be sure the issue has been fixed.
> > 
> > Rick, maybe you can check whether the windfarm module(s) get(s) loaded 
> > on your machine?
> > 
> > # lsmod |grep windfarm
> 
> On the G4 (which is _not_ the MDD) I get nothing from that
> 
> On the G5 I get:
> 
> rbthomas@kmac:~$ lsmod | grep wind
> windfarm_smu_sat8626  0
> windfarm_ad7417_sensor 7755  0
> windfarm_fcu_controls12227  0
> windfarm_cpufreq_clamp 3881  0
> windfarm_pm72  14329  0
> windfarm_pid3256  1 windfarm_pm72
> windfarm_lm75_sensor 5350  0
> windfarm_max6690_sensor 4600  0
> windfarm_core  11920  7 
> windfarm_cpufreq_clamp,windfarm_fcu_controls,windfarm_max6690_sensor,windfarm_smu_sat,windfarm_ad7417_sensor,windfarm_pm72,windfarm_lm75_sensor
> 
> Hope that helps.
> Rick
> 
> PS: I do have a MDD, but I haven't yet tried Adrian's latest on it.  
> Maybe later today, maybe it'll have to wait for the weekend.
> 

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

Hi William!

On Thu, Apr 29, 2021, at 11:05 AM, William Bonnet wrote:
> > The PowerMac G5 users on this list are kindly asked to confirm the bug
> > has been fixed. Until then, I'll reopen it.
> 
> I am running the latest version (5.10.0-6-sparc64-smp #1 SMP Debian
> 5.10.28-1 (2021-04-09) sparc64) from the ports repo and it runs ok on two 
> G5

Thanks for the report.

Can you run this: "lsmod | grep wind" (without the quotes) on one or both of 
the G5s, and report the results back here?

Thanks!
Rick

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

On Tue, Apr 27, 2021, at 12:15 AM, John Paul Adrian Glaubitz wrote:> 
> On 4/27/21 8:54 AM, Rick Thomas wrote:
> > I'll look around and see if I have any MDD (mirror drive door -- the type 
> > in the
> > original bugreport) machines.  If so, I'll try to find some time to install 
> > Adrian's
> > latest and report back.
> 
> OK, thank you. Maybe someone else with a machine that previously had 
> this issue can also
> comment so that we can be sure the issue has been fixed.
> 
> Rick, maybe you can check whether the windfarm module(s) get(s) loaded 
> on your machine?
> 
> # lsmod |grep windfarm

On the G4 (which is _not_ the MDD) I get nothing from that

On the G5 I get:

rbthomas@kmac:~$ lsmod | grep wind
windfarm_smu_sat8626  0
windfarm_ad7417_sensor 7755  0
windfarm_fcu_controls12227  0
windfarm_cpufreq_clamp 3881  0
windfarm_pm72  14329  0
windfarm_pid3256  1 windfarm_pm72
windfarm_lm75_sensor 5350  0
windfarm_max6690_sensor 4600  0
windfarm_core  11920  7 
windfarm_cpufreq_clamp,windfarm_fcu_controls,windfarm_max6690_sensor,windfarm_smu_sat,windfarm_ad7417_sensor,windfarm_pm72,windfarm_lm75_sensor

Hope that helps.
Rick

PS: I do have a MDD, but I haven't yet tried Adrian's latest on it.  Maybe 
later today, maybe it'll have to wait for the weekend.

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

On Mon, Apr 26, 2021, at 10:45 PM, John Paul Adrian Glaubitz wrote:
> On 4/27/21 2:07 AM, Rick Thomas wrote:
> > I've got the latest (Apr 17) running on my G5 right now.  No problems.
> 
> Rick, you should just confirm that this particular problem is fixed but I 
> assume
> that this is the case?

I've got a PowerMac G5 running the latest install from Adrian.  It does not 
have any problem with fans running at high speed for prolonged time.

rbthomas@kmac:~$ cat /proc/version ; cat /proc/cpuinfo
Linux version 5.10.0-6-powerpc64 (debian-kernel@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.28-1 (2021-04-09)
processor   : 0
cpu : PPC970FX, altivec supported
clock   : 2000.00MHz
revision: 3.0 (pvr 003c 0300)

processor   : 1
cpu : PPC970FX, altivec supported
clock   : 2000.00MHz
revision: 3.0 (pvr 003c 0300)

timebase: 
platform: PowerMac
model   : PowerMac7,3
machine : PowerMac7,3
motherboard : PowerMac7,3 MacRISC4 Power Macintosh 
detected as : 336 (PowerMac G5)
pmac flags  : 
L2 cache: 512K unified
pmac-generation : NewWorld

Looking at the original bugreport, this in not the type of machine about which 
the report was filed.

I also have a PowerMac G4 Silver running the 32-bit install from Feb  2, 2021 
from Adrian.  It also does not have any problem with fans running at high speed.

rbthomas@dillserver:~$ cat /proc/version ; cat /proc/cpuinfo
Linux version 5.10.0-6-powerpc (debian-kernel@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 Debian 
5.10.28-1 (2021-04-09)
processor   : 0
cpu : 7410, altivec supported
temperature : 38-40 C (uncalibrated)
clock   : 533.32MHz
revision: 1.3 (pvr 800c 1103)
bogomips: 66.58

timebase: 33290001
platform: PowerMac
model   : PowerMac3,4
machine : PowerMac3,4
motherboard : PowerMac3,4 MacRISC2 MacRISC Power Macintosh
detected as : 69 (PowerMac G4 Silver)
pmac flags  : 0010
L2 cache: 1024K unified
pmac-generation : NewWorld
Memory  : 1536 MB

Unfortunately, this is also not the type of machine from the original 
bugreport. 

I'll look around and see if I have any MDD (mirror drive door -- the type in 
the original bugreport) machines.  If so, I'll try to find some time to install 
Adrian's latest and report back.

Rick

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

I've got the latest (Apr 17) running on my G5 right now.  No problems.

Rick

rbthomas@kmac:~$ cat /proc/version 
Linux version 5.10.0-6-powerpc64 (debian-kernel@lists.debian.org) (gcc-10 
(Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 
SMP Debian 5.10.28-1 (2021-04-09)

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

On Sep 9, 2018, at 1:59 AM, Wolfram Sang  wrote:

> On Sat, Sep 08, 2018 at 02:48:01PM -0700, Rick Thomas wrote:
>> Thanks!  Yes, I’ll give it a try.
> 
> Note: You can either build the v4.19-rc1 tar ball which has the patch
> already included. Or you can take your Debian kernel and add this patch:
> 
> http://patchwork.ozlabs.org/patch/960488/
> 
> You can download it as mbox there which gives you a file to apply.

Thank you!

Please remember, I’ve never done this before…  so I’ve still got a couple of 
questions:

How do I get a copy of the v4.19-rc1 tar ball, if I decide to go that way?  And 
once I’ve got it, which section of the kernel handbook do I look in for 
instructions to build it?

And supposing I decide to go the other way and add the patch to my current 
kernel (4.18.0-1-powerpc64) how do I get the patch in a form that I can add it 
to the kernel?  I’m assuming that section 4.2.2 “Simple patching and building” 
is where I go for instructions once I’ve got the patch?

Thanks, and really sorry for my ignorance!  
Rick

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

Thanks!  Yes, I’ll give it a try.

On Sep 8, 2018, at 6:51 AM, Salvatore Bonaccorso  wrote:

> Hi,
> 
> On Mon, Sep 03, 2018 at 11:38:32PM -0700, Rick Thomas wrote:
>> Hi Mathieu,
>> 
>> I’m sorry that I don’t have the expertise to apply a patch and build
>> a kernel.  However, if someone who does have that expertise can
>> build a “.deb’ file and tell me where to download it, I’ll be happy
>> to test and provide detailed feedback.
>> 
>> Another possibility, of course, would be for someone to provide me
>> with step-by-step instructions for building a ‘.deb’ and stand by to
>> answer the inevitable questions.
> 
> The kernel-handbook contains a section on simple patching and
> building, for the case of testing an extra patch, cf.
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
> .
> 
> Does this helps you on this?
> 
> Regards,
> Salvatore

Bug#741663: linux-image-3.13-1-powerpc-smp: therm_windtunnel does not load correctly

[Rick Thomas]

Hi Mathieu,

I’m sorry that I don’t have the expertise to apply a patch and build a kernel.  
However, if someone who does have that expertise can build a “.deb’ file and 
tell me where to download it, I’ll be happy to test and provide detailed 
feedback.

Another possibility, of course, would be for someone to provide me with 
step-by-step instructions for building a ‘.deb’ and stand by to answer the 
inevitable questions.

Thanks!
Rick

On Sep 3, 2018, at 1:40 AM, Mathieu Malaterre  wrote:

> Hi Rick,
> 
> On Tue, Apr 12, 2016 at 12:08 PM Mathieu Malaterre  wrote:
>> 
>> Dear all,
>> 
>> I am looking for testers for the following patch:
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741663#20
>> 
>> Wolfram (CC here) is looking for feedback from users for this patch.
> 
> Wolfram is still looking for feedback from user on the patch applied
> recently upstream:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/macintosh/therm_windtunnel.c?id=3e7bed52719de4b5b5fb900869e293eae0bc3f3e
> 
> Could you give it a try ?
> 
> Thanks

Re: armel/marvell kernel size

[Rick Thomas]

On Mar 28, 2018, at 2:22 AM, Rick Thomas <rbtho...@pobox.com> wrote:

>> What filesystems do you use? Do you use any (para)virtualization? What
>> about addon hardware that you have? Any USB dongles? Anything that you
>> can think of? Sound?
>> 
>> Do you use NFS? (I do) What kind of compressed ramdisk do you use? The
>> loaded modules that you have with lsmod would be nice to know.
> 

Filesystems:  ext2 and ext4

Vitrualization: Nope.  These are way too small for anything fancy like that.

Addon hardware:
USB2 ports useful for disk and/or flash drives and other stuff (I don’t 
do the “other stuff” myself but I suppose there are folks who might).
They have 1000BaseT ports.  Two ports on the OpenRD Client, one on the 
SheevaPlug.
They each have a mini-USB serial port that they use for serial console.
The Client has a headphone jack.  I’ve used it in the past for 
listening to streaming radio.  The SheevaPlug has no audio i/o.
Both machines have SD-card slots that can be used in booting or as aux 
data storage.
Both get their uboot from mtd, not mmc, so updating uboot requires 
re-flashing.
The Client has 512MB RAM.  The SheevaPlug has the same.

CPU info for SheevaPlug —
> root@sheeva:~# cat /proc/cpuinfo
> processor : 0
> model name: Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS  : 1185.79
> Features  : swp half thumb fastmult edsp 
> CPU implementer   : 0x56
> CPU architecture: 5TE
> CPU variant   : 0x2
> CPU part  : 0x131
> CPU revision  : 1
> 
> Hardware  : Marvell Kirkwood (Flattened Device Tree)
> Revision  : 
> Serial: 

CPU info for OpenRD Client —
> rbthomas@client:~$ cat /proc/cpuinfo 

> processor : 0
> model name: Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS  : 1191.93
> Features  : swp half thumb fastmult edsp 
> CPU implementer   : 0x56
> CPU architecture: 5TE
> CPU variant   : 0x2
> CPU part  : 0x131
> CPU revision  : 1
> 
> Hardware  : Marvell Kirkwood (Flattened Device Tree)
> Revision  : 
> Serial: 

Uboot details on SheevaPlug —
> U-Boot 2016.01-rc3+dfsg1-3 (Jan 02 2016 - 23:19:11 +)
> Marvell-Sheevaplug
> 
> SoC:   Kirkwood 88F6281_A0
> DRAM:  512 MiB (ECC not enabled)
> WARNING: Caches not enabled
> NAND:  512 MiB
> MMC:   MVEBU_MMC: 0
> In:serial
> Out:   serial
> Err:   serial
> Net:   egiga0

and on OpenRD Client —
> U-Boot 2016.11+dfsg1-4~20170308~1 (Mar 09 2017 - 01:27:49 +)
> OpenRD-Client
> 
> SoC:   Kirkwood 88F6281_A0
> DRAM:  512 MiB
> WARNING: Caches not enabled
> NAND:  512 MiB
> MMC:   MVEBU_MMC: 0
> In:serial
> Out:   serial
> Err:   serial
> Net:   egiga0, egiga1
> 


I use the SheevaPlug as a backup DHCP/DNS server for my home network.  The 
Client is reserved for experimenting.

I don’t currently use NFS on either, but I have in the past.

I’m not sure what you mean by “What kind of compressed ramdisk do you use?”.  
As a stab in the dark —

> rbthomas@client:~$ file /boot/initrd.img-4.9.0-6-marvell
> /boot/initrd.img-4.9.0-6-marvell: gzip compressed data, last modified: Sun 
> Mar  4 14:29:43 2018, from Unix

and

> root@sheeva:~# file /boot/initrd.img-4.9.0-6-marvell
> /boot/initrd.img-4.9.0-6-marvell: gzip compressed data, last modified: Sat 
> Mar 10 10:12:39 2018, from Unix

In other words, nothing fancy!

Does that help?
Rick

Re: armel/marvell kernel size

[Rick Thomas]

On Mar 27, 2018, at 2:08 PM, Rogério Brito <rbr...@ime.usp.br> wrote:

> On 2018-03-27 17:29, Rick Thomas wrote:
>> On Mar 27, 2018, at 1:04 PM, Rogério Brito <rbr...@ime.usp.br> wrote:
>>> As a related subject, I could compile a more stripped down version of
>>> the armel kernel, put it for people to download and ask people to
>>> comment if it works for them, so that we can gauge what people actually
>>> need from such a kernel...
>> 
>> Please do!  I have an OpenRD box and a SheevaPlug that I’ll be happy to test 
>> on.
> 
> You're welcome. I don't know much about the OpenRD nor about the
> SheevaPlug, but are they able to run the -marvell kernels? What was the
> last version of the kernel that worked for you?
> 
> What filesystems do you use? Do you use any (para)virtualization? What
> about addon hardware that you have? Any USB dongles? Anything that you
> can think of? Sound?
> 
> Do you use NFS? (I do) What kind of compressed ramdisk do you use? The
> loaded modules that you have with lsmod would be nice to know.

A lot of questions…  I’ll do my best to answer them as best I can sometime this 
weekend (There are an equally large lot of things on my to-do list this week!  
/-: )

In the mean time here’s a start:

OpenRD Client
> rbthomas@client:~$ uname -a
> Linux client 4.9.0-6-marvell #1 Debian 4.9.82-1+deb9u3 (2018-03-02) armv5tel 
> GNU/Linux

SheevaPlug
> rbthomas@sheeva:~$ uname -a
> Linux sheeva 4.9.0-6-marvell #1 Debian 4.9.82-1+deb9u3 (2018-03-02) armv5tel 
> GNU/Linux

Both are running the latest Stretch.

Rick

Re: armel/marvell kernel size

[Rick Thomas]

On Mar 27, 2018, at 1:04 PM, Rogério Brito  wrote:
> As a related subject, I could compile a more stripped down version of
> the armel kernel, put it for people to download and ask people to
> comment if it works for them, so that we can gauge what people actually
> need from such a kernel...

Please do!  I have an OpenRD box and a SheevaPlug that I’ll be happy to test on.

Thanks for keeping these old boxes alive!
Rick

Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Rick Thomas]

On Wed, 24 Feb 2016 15:06:27 -0800 Vagrant Cascadian  wrote:
> On 2016-02-24, Vagrant Cascadian wrote:
> > On 2016-02-04, Ben Hutchings wrote:
> >> Oh, so the MODULES=most case is bust and we need to list more host
> >> controller drivers (or include all modules under drivers/usb/host/).
> >> How about MODULES=dep; does that work now?
> >
> > MODULES=dep appears to pull in the necessary drivers on a recent stretch
> > install on a wandboard solo, using initramfs-tools 0.123, but
> > MODULES=most still requires manually including them in
> > /etc/initramfs-tools/modules.
> 
> And, FWIW, MODULES=dep appears to also workaround the issue on the wandboard 
> dual
> with initramfs-tools 0.120.
> 
> 
> live well,
>   vagrant

would it make sense to ensure that MODULES=most is always a superset of 
MODULES=dep?  Could this be done by running MODULES=dep first, then running 
MODULES=most and delivering the union of the two sets?

Thanks!
Rick

Re: Kernel version for stretch

[Rick Thomas]

On Feb 2, 2016, at 11:28 PM, Karsten Merker  wrote:

> On Tue, Feb 02, 2016 at 02:23:06PM +0100, Cyril Brulebois wrote:
>> Niels Thykier  (2016-02-02):
>>> @Kernel+d-i - What is your take on the following:
>>> 
>>> * How long will it take to have the new release ready?
>>>   - That is, the latency between the 22nd and us having it in unstable.
>>>   - How certain are we on the 22nd being the actual release date?
>>>   - [d-i]: How long will it take to have a d-i using the new linux
>>> ready?
>> 
>> Once the new ABI reaches unstable, d-i can be patched to use it instead of 
>> the
>> old one. That's a one-liner patch. In case udebs are modified we might need 
>> to
>> also update a few lists accordingly, but as usual that can be done 
>> proactively
>> if the kernel team tells us that this or that udeb is getting dropped or 
>> added.
>> 
>> Having people around to test d-i daily builds until the kernel reaches 
>> testing
>> would be nice, so that we don't wait until the d-i upload (and maybe d-i 
>> image
>> builds) using testing's kernel to get some feedback.
> 
> I can offer to do that for a number of armhf platforms.
> 
> Regards,
> Karsten

And I can offer to do that for old Macintosh PowerPC (G4, G5) and armel 
(SheevaPlug, OpenRD) hardware.

Enjoy!
Rick

Bug#811351: additional request...

[Rick Thomas]

> On Jan 20, 2016, at 2:54 PM, Aaro Koskinen  wrote:
> 
> I can add more verbose comments to mainline kernel .dts on how to
> enable serial port, and how to select between rs232/485. Andrew, do
> you want me to resend the current patches, or can it be done with an
> incremental patch?
> 
> However, Debian probably needs to provide its own documentation how to
> modify the .dtb (probably some example how to convert the dtb to source
> with dtc, then how to do the modifications, and compile the source back
> to dtb).
> 
> A.

Andrew (I think it was) suggested that the instructions for doing that could go 
on Martin’s web page, which anyone who wants to use Debian on OpenRD will need 
to reference anyway.

Martin, are you willing to do that?

I can (and will gladly) test any changes and help with debuging (if such is 
necessary) .

Rick

Bug#811351: additional request...

[Rick Thomas]

Hi Aaro,

Andrew wrote
> On Sun, Jan 17, 2016 at 11:55:19PM -0800, Rick Thomas wrote:
>> 
>> On Jan 17, 2016, at 2:42 PM, Martin Michlmayr <t...@cyrius.com> wrote:
>>> * Andrew Lunn <and...@lunn.ch> [2016-01-10 16:38]:
>>>> Please can you try the following patch. If this works, i can add it to
>>>> mainline. The issue we might run into is that somebody else wants
>>>> serial not MMC
>> 
>> Is it possible to make this depend on a DTB setting?  e.g. the
>> mainline kernel supports either serial or mmc, but which one depends
>> on which one is configured in the DTB?
> 
> Hi Rick
> 
> Device tree is not particularly good for dynamic hardware. We would
> probably have to have two device tree blobs, one for MMC and one for
> RS232. I don't remember if this is just an issue for Base, or if
> Client and Ultimate have the same muxing. If so, we would want two DT
> blobs for those as well...
> 
> If there is demand, we can do it, but i would prefer to avoid this if
> possible.
> 
>   Andrew

Andrew wrote:
> On Mon, Jan 18, 2016 at 02:49:50PM -0800, Martin Michlmayr wrote:
>> * Rick Thomas <rbtho...@pobox.com> [2016-01-18 14:45]:
>>> Would it be reasonable to put a note in the release docs (or in 
>>> /usr/share/doc/??? ) describing how to modify the released dtb for personal 
>>> use?
>> 
>> Oh, right, I was going to make that comment but I forgot.
>> 
>> Andrew: maybe instead of removing the code from the base DTB, you
>> should comment it out and add a comment about this.  This way, people
>> can easily edit the DTS and recompile the DTB if needed.
> 
> I was going to take Aaro Koskinen patches, since they have Tested-by:
> etc.
> 
> How about you ask Aaro to add the comment?
> 
> Thanks
>Andrew

As per the above discussion, would it be possible to have the patch comment the 
code, rather than delete it, so that people with a need for the serial port 
could activate it?  Maybe also add a note in the /usr/share/doc/ as to how to 
perform the activation.

As long as both are possible, my own preference would be to have the MMC be 
default and the serial port be optional. But YMMV.

I'll be more than happy to test any changes...

Thanks!

Rick

Bug#811351: linux-image-4.3.0-0.bpo.1-kirkwood: MMC does not work on OpenRD Client / fix pending

[Rick Thomas]

Package: src:linux
Version: 4.3.3-5~bpo8+1
Severity: normal

Dear Maintainer,

The 4.3.0.0 kernel on an "OpenRD Client" fails to recognize the SD card -- 
there is no mmc device shown by lsblk.

This is fixed by using a modified DTB file provided by Aaro Koskinen.
Fix tested by Rick Thomas.
Martin Michlmayr has the details.


-- Package-specific info:
** Version:
Linux version 4.3.0-0.bpo.1-kirkwood (debian-kernel@lists.debian.org) (gcc 
version 4.9.2 (Debian 4.9.2-10) ) #1 Debian 4.3.3-5~bpo8+1 (2016-01-07)

** Command line:
console=ttyS0,115200

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[7.702388] NET: Registered protocol family 10
[7.707889] systemd[1]: Inserted module 'ipv6'
[7.714743] systemd[1]: Set hostname to .
[8.185269] systemd[1]: Cannot add dependency job for unit 
display-manager.service, ignoring: Unit display-manager.service failed to load: 
No such file or directory.
[8.203342] systemd[1]: Starting Forward Password Requests to Wall Directory 
Watch.
[8.211470] systemd[1]: Started Forward Password Requests to Wall Directory 
Watch.
[8.219225] systemd[1]: Expecting device dev-ttyS0.device...
[8.236795] systemd[1]: Starting Remote File Systems (Pre).
[8.252761] systemd[1]: Reached target Remote File Systems (Pre).
[8.259054] systemd[1]: Starting Dispatch Password Requests to Console 
Directory Watch.
[8.267366] systemd[1]: Started Dispatch Password Requests to Console 
Directory Watch.
[8.275428] systemd[1]: Starting Paths.
[8.288760] systemd[1]: Reached target Paths.
[8.293257] systemd[1]: Starting Encrypted Volumes.
[8.308756] systemd[1]: Reached target Encrypted Volumes.
[8.314360] systemd[1]: Starting Arbitrary Executable File Formats File 
System Automount Point.
[8.336767] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[8.346341] systemd[1]: Expecting device 
dev-disk-by\x2duuid-d5b98715\x2df529\x2d4170\x2d8559\x2d6f9fae4ac1e9.device...
[8.368782] systemd[1]: Expecting device 
dev-disk-by\x2duuid-806d1dac\x2d2026\x2d4b31\x2d977d\x2df47f0f9b7207.device...
[8.392770] systemd[1]: Starting Root Slice.
[8.404756] systemd[1]: Created slice Root Slice.
[8.409591] systemd[1]: Starting User and Session Slice.
[8.424758] systemd[1]: Created slice User and Session Slice.
[8.430643] systemd[1]: Starting Delayed Shutdown Socket.
[8.444761] systemd[1]: Listening on Delayed Shutdown Socket.
[8.450649] systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[8.468761] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[8.475867] systemd[1]: Starting Journal Socket (/dev/log).
[8.492758] systemd[1]: Listening on Journal Socket (/dev/log).
[8.498852] systemd[1]: Starting udev Control Socket.
[8.512762] systemd[1]: Listening on udev Control Socket.
[8.518332] systemd[1]: Starting udev Kernel Socket.
[8.532758] systemd[1]: Listening on udev Kernel Socket.
[8.538225] systemd[1]: Starting Journal Socket.
[8.552759] systemd[1]: Listening on Journal Socket.
[8.557930] systemd[1]: Starting System Slice.
[8.572760] systemd[1]: Created slice System Slice.
[8.577823] systemd[1]: Started File System Check on Root Device.
[8.584037] systemd[1]: Starting system-systemd\x2dfsck.slice.
[8.600764] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[8.607171] systemd[1]: Starting system-getty.slice.
[8.624758] systemd[1]: Created slice system-getty.slice.
[8.630294] systemd[1]: Starting system-serial\x2dgetty.slice.
[8.648761] systemd[1]: Created slice system-serial\x2dgetty.slice.
[8.655241] systemd[1]: Starting Increase datagram queue length...
[8.675792] systemd[1]: Starting Create list of required static device nodes 
for the current kernel...
[8.703721] systemd[1]: Starting udev Coldplug all Devices...
[8.734742] systemd[1]: Started Set Up Additional Binary Formats.
[8.746369] systemd[1]: Starting Load Kernel Modules...
[8.771856] systemd[1]: Mounted Huge Pages File System.
[8.792795] systemd[1]: Mounting POSIX Message Queue File System...
[8.819522] systemd[1]: Mounting Debug File System...
[8.843315] systemd[1]: Starting Slices.
[8.868822] systemd[1]: Reached target Slices.
[8.875562] systemd[1]: Starting Remount Root and Kernel File Systems...
[8.908840] systemd[1]: Mounted Debug File System.
[8.926006] EXT4-fs (sdb2): re-mounted. Opts: errors=remount-ro
[8.932879] systemd[1]: Mounted POSIX Message Queue File System.
[8.956788] systemd[1]: Started Increase datagram queue length.
[8.976779] systemd[1]: Started Create list of required static device nodes 
for the current kernel.
[8.996885] systemd[1]: Started Load Kernel Modules.
[9.016818] systemd[1]: Started Remount Root and Kernel File Systems.
[9.084783] systemd[1]: Started udev Coldplug a

Bug#783381: upgrade from wheezy to jessie on a PowerMac G4 Silver/Confirmation

[Rick Thomas]

Try adding 
append=“ nomodeset
to the end of the main stanza in /etc/yaboot.conf.  Then (as root) execute 
“ybin” to propagate the change to the bootstrap routines.

This will set the kernel command line to inhibit the kernel from trying to use 
hardware acceleration for your video.

The result will be (hopefully) two-fold: (1) slower video (but not much slower 
as long as you’re not using 3D features) and (2) better control over the color 
and layout of your screen.

I’ve found it’s the only thing that works for my G5 PowerMac.

Hope it helps you too!
Rick

On Jun 8, 2015, at 1:56 PM, Alois Zoitl aloiszo...@gmail.com wrote:

 Hi,
 
 thanks. Looks like there is no Gnome for non Intel platforms. With XFCE and 
 lightdm I got graphics partly working. Still rad and blue is exchanged. 
 
 But I don't want to hijack this bug for the graphics problems ;-)
 
 Regards,
 Alois
 
 On Sat, Jun 6, 2015 at 1:57 PM, Manfred Stock 
 manfred.stock+deb...@gmail.com wrote:
 Package: upgrade-reports, linux-image-3.16.0-4-powerpc
 Followup-For: Bug #783381
 
 Hi,
 
  And now to the graphics problems :-(
 
 on my system, I could improve the situation by replacing GDM3 with Lightdm, 
 and
 Gnome3 with the Awesome or Fluxbox window manager (since they actually started
 and displayed something, which was not the case with GDM or Gnome, they just
 displayed an error along the lines of something went wrong, with a logout
 button). However, I then got some kind of crash/lockup when I executed eg.
 dmesg in an xterm (mouse pointer still visible/movable, but otherwise, nothing
 changed, and restarting X iirc just got me a black screen with mouse pointer).
 I could improve that by adding
 append=radeon.agpmode=-1
 to the yaboot config of the kernel I'm booting, which disables AGP mode, but 
 so
 far seems to result in a stable system (I have the feeling that it feels 
 slower
 on certain UI updates though, but I'm not sure about his). So far, I've found
 some bug reports [1,2,3] which might be related to these issues, but haven't
 tried anything further.
 
 Still don't have working suspend to disk/ram though, but that could actually 
 be
 related to the graphics issues and/or my workaround.
 
 Kind regards
 Manfred
 
 [1] https://bugs.debian.org/762047
 [2] https://bugs.debian.org/782066
 [3] https://bugs.debian.org/683796
 
 
 -- System Information:
 Debian Release: 8.0
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
 Architecture: powerpc (ppc)
 
 Kernel: Linux 3.16.0-4-powerpc
 Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/bash
 Init: systemd (via /run/systemd/system)
 
 --
 To unsubscribe, send mail to 783381-unsubscr...@bugs.debian.org.
 


--
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/faca15c0-22b7-4805-9445-627f672d7...@pobox.com

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

On May 16, 2015, at 12:58 PM, Rick Thomas rbtho...@pobox.com wrote:

 
 On May 16, 2015, at 6:02 AM, Ben Hutchings b...@decadent.org.uk wrote:
 
 This is not implemented directly by the init system.  util-linux
 installs the script/lib/udev/hwclock-set and a udev rule that runs it
 for each RTC device.  However, the hwclock-set script does nothing if
 systemd is running.
 
 curiouser and curiouser…
 
 Looking at the code in /lib/udev/hwclock-set, I can’t see that it would would 
 ever do anything useful (except by chance) in the case like mine where there 
 are two rtc devices, only one of which should actually be used to set system 
 time at boot.
 
 In particular, it goes to some effort to source /etc/default/rcS and 
 /etc/default/hwclock, but it pays no attention to the HCTOSYS_DEVICE 
 parameter.
 
 It appears to set the system time from each RTC device in turn as it 
 discovers them.  So system time ends up set by the last RTC to be discovered. 
  If the right one happens to be last, that’s good.  But that’s not guaranteed.

Looking further, I find that what I said is not quite true.  hwclock-set only 
gets called for /dev/rtc0, i.e. the *first* one to be discovered.  This happens 
in /lib/udev/rules.d/85-hwclock.rules.  There is provision in 
/lib/udev/rules.d/50-udev-default.rules to swing the /dev/rtc symlink to the 
device that has ATTR{hctosys}==“1”, but that doesn’t fix the problem at hand, 
because the symlink is not used anywhere in hwclock-set.

Fascinating!
Rick

--
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/c4618e4b-58a9-4f5d-8cbd-7967f1a9c...@pobox.com

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

On May 16, 2015, at 6:02 AM, Ben Hutchings b...@decadent.org.uk wrote:

 If that’s correct, I’m not sure if even sysvinit
 with /etc/default/hwclock could have done the right thing in my case.
 
 This is not implemented directly by the init system.  util-linux
 installs the script /lib/udev/hwclock-set and a udev rule that runs it
 for each RTC device.  However, the hwclock-set script does nothing if
 systemd is running.

Thank you Ben.  As usual, your clear explanation has helped me to better 
understand my problem and pointed me in new directions.

Why does it do that?  Is there some systemd feature that should make setting 
the system time unnecessary?  If so, it’s not working.

Thanks!
Rick

--
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/6a59d631-3182-4419-aab8-41ea2e2a3...@pobox.com

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

On May 16, 2015, at 6:02 AM, Ben Hutchings b...@decadent.org.uk wrote:

 This is not implemented directly by the init system.  util-linux
 installs the script/lib/udev/hwclock-set and a udev rule that runs it
 for each RTC device.  However, the hwclock-set script does nothing if
 systemd is running.

curiouser and curiouser…

Looking at the code in /lib/udev/hwclock-set, I can’t see that it would would 
ever do anything useful (except by chance) in the case like mine where there 
are two rtc devices, only one of which should actually be used to set system 
time at boot.

In particular, it goes to some effort to source /etc/default/rcS and 
/etc/default/hwclock, but it pays no attention to the HCTOSYS_DEVICE parameter.

It appears to set the system time from each RTC device in turn as it discovers 
them.  So system time ends up set by the last RTC to be discovered.  If the 
right one happens to be last, that’s good.  But that’s not guaranteed.

Enjoy!
Rick

--
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/c5140f9d-0a22-415a-8a0e-9b77b2da2...@pobox.com

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

On May 16, 2015, at 3:13 AM, Ian Campbell i...@debian.org wrote:

 On Fri, 2015-05-15 at 17:55 -0700, Rick Thomas wrote:
 [...]
 There does not seem to be any way to over-ride this.  There's code in 
 /etc/default/hwclock
 that would do part of the work in a sysvinit setup, but it seems to be 
 ignored under systemd.
 [...]
 Presumably, there is systemd magic that could do the same thing as was 
 available under
 sysvinit.  Is there anybody out there with enough systemd foo to tell me how 
 to do that?
 
 I think that if systemd is not supporting /etc/default/hwclock and the
 replacement mechanism is not apparent after some searching of the docs
 etc then this should be considered a systemd bug (either in the docs if
 not an actual code bug or missing feature).
 
 Perhaps someone on the pkg-systemd-maintainers@alioth list will be
 better able to advise on if/how systemd solves this problem?
 
 Ian.

Thanks, Ian, for the prompt response.  I’ve submitted a separate bug to systemd 
asking for a fix.  However, it may not be possible to do this with systemd…  
Looking at the dmesg output, it looks like the decision to use /dev/rtc0 is 
being made at the kernel level, before systemd even gets started.  If that’s 
correct, I’m not sure if even sysvinit with /etc/default/hwclock could have 
done the right thing in my case.

Do you happen to know why the patch I came across never made it into the kernel?

Thanks, again!
Rick


--
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/80f682f1-e5b8-4195-b6bb-be1e1c2af...@pobox.com

Bug#785419: linux-image-4.0.0-1-armmp: with 2 RTC devices -- need way to chose which one sets system clock on boot

[Rick Thomas]

Package: src:linux
Version: 4.0.2-1
Severity: normal
Tags: upstream


My cubox-i4pro armhf device has two real-time-clocks.  One, snvs, is not 
battery backed,
hence is not useful for setting the system clock on boot after a power failure.
The other, pcf8523, does have battery backup.

Unfortunately, the snvs is recognzed first, so it become /dev/rtc0 (the pcf8523 
becomes /dev/rtc1)
and the kernel at boot time uses /dev/rtc0 by default to set the system time 
from.

There does not seem to be any way to over-ride this.  There's code in 
/etc/default/hwclock
that would do part of the work in a sysvinit setup, but it seems to be ignored 
under systemd.

In googling about, I stumbled across a proposed patch that would add a kernel 
command line
parameter, hctosys=rtc#' that would over-ride the default, but it seems not
to have ever been implemented ( 
http://lkml.iu.edu/hypermail/linux/kernel/1407.0/03989.html )

Presumably, there is systemd magic that could do the same thing as was 
available under
sysvinit.  Is there anybody out there with enough systemd foo to tell me how to 
do that?

Other ways to attack this problem may involve something with udev rules, but 
I'm not savvy
enough to figure that out for myself, either.

Personally, I kind of like the kernel command line parameter, but others may 
have other
ideas.

Thanks for your consideration!
Rick 


-- Package-specific info:
** Version:
Linux version 4.0.0-1-armmp (debian-kernel@lists.debian.org) (gcc version 4.9.2 
(Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11)

** Command line:
hctosys=rtc1 console=ttymxc0,115200 quiet

** Not tainted

** extracts from dmesg
rbthomas@cube:~$ dmesg | egrep 'rtc|clock' | grep -v crtc
[0.00] Kernel command line: hctosys=rtc1 console=ttymxc0,115200 quiet
[0.00] L2C-310 dynamic clock gating enabled, standby mode enabled
[0.07] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 
1431655765682ns
[0.114449] PTP clock support registered
[0.115986] Switched to clocksource mxc_timer1
[1.303721] snvs_rtc 20cc034.snvs-rtc-lp: rtc core: registered 
20cc034.snvs-rtc-lp as rtc0
[1.311100] snvs_rtc 20cc034.snvs-rtc-lp: setting system clock to 2015-05-15 
23:43:56 UTC (1431733436)
[5.634623] rtc-pcf8523 2-0068: rtc core: registered rtc-pcf8523 as rtc1


** Kernel log:
[7.857815] usb-storage 1-1.4.2:1.0: USB Mass Storage device detected
[7.858173] scsi host6: usb-storage 1-1.4.2:1.0
[7.865466] scsi 1:0:0:0: Direct-Access Generic  STORAGE DEVICE   0272 
PQ: 0 ANSI: 0
[7.866779] sd 1:0:0:0: Attached scsi generic sg1 type 0
[7.873156] scsi 2:0:0:0: Direct-Access SanDisk  Cruzer Fit   1.27 
PQ: 0 ANSI: 6
[7.873790] scsi 3:0:0:0: Direct-Access SanDisk  Cruzer Fit   1.27 
PQ: 0 ANSI: 6
[7.874380] sd 2:0:0:0: Attached scsi generic sg2 type 0
[7.875645] sd 3:0:0:0: Attached scsi generic sg3 type 0
[7.876241] sd 2:0:0:0: [sdc] 61056064 512-byte logical blocks: (31.2 
GB/29.1 GiB)
[7.876886] sd 3:0:0:0: [sdd] 61056064 512-byte logical blocks: (31.2 
GB/29.1 GiB)
[7.877015] sd 2:0:0:0: [sdc] Write Protect is off
[7.877033] sd 2:0:0:0: [sdc] Mode Sense: 43 00 00 00
[7.877632] sd 3:0:0:0: [sdd] Write Protect is off
[7.877651] sd 3:0:0:0: [sdd] Mode Sense: 43 00 00 00
[7.877881] sd 2:0:0:0: [sdc] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
[7.878766] sd 3:0:0:0: [sdd] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
[7.892636] sd 3:0:0:0: [sdd] Attached SCSI removable disk
[7.896288] sd 2:0:0:0: [sdc] Attached SCSI removable disk
[7.927904] md: bindsdd
[7.938387] md: bindsdc
[8.068936] scsi 4:0:0:0: Direct-Access SanDisk  Cruzer Fit   1.27 
PQ: 0 ANSI: 6
[8.070109] sd 4:0:0:0: Attached scsi generic sg4 type 0
[8.070636] sd 4:0:0:0: [sde] 61056064 512-byte logical blocks: (31.2 
GB/29.1 GiB)
[8.071369] sd 4:0:0:0: [sde] Write Protect is off
[8.071386] sd 4:0:0:0: [sde] Mode Sense: 43 00 00 00
[8.072145] sd 4:0:0:0: [sde] Write cache: disabled, read cache: enabled, 
doesn't support DPO or FUA
[8.082631] sd 4:0:0:0: [sde] Attached SCSI removable disk
[8.119009] md: bindsde
[8.122659] sd 1:0:0:0: [sdb] 122519552 512-byte logical blocks: (62.7 
GB/58.4 GiB)
[8.123764] sd 1:0:0:0: [sdb] Write Protect is off
[8.123780] sd 1:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[8.125874] sd 1:0:0:0: [sdb] No Caching mode page found
[8.125892] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[8.136889]  sdb: sdb1 sdb2 sdb3  sdb5 sdb6 sdb7 
[8.142922] sd 1:0:0:0: [sdb] Attached SCSI removable disk
[8.661076] scsi 5:0:0:0: Direct-Access SanDisk  Cruzer Fit   1.27 
PQ: 0 ANSI: 6
[8.662322] sd 5:0:0:0: Attached scsi generic sg5 type 0
[8.663763] sd 5:0:0:0: [sdf] 61056064 512-byte logical blocks: (31.2 
GB/29.1 GiB)
[8.665357] sd 5:0:0:0: [sdf] Write Protect is off
[   

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

On May 6, 2015, at 3:35 AM, Rick Thomas rbtho...@pobox.com wrote:

 
 On May 6, 2015, at 3:27 AM, Ian Campbell i...@debian.org wrote:
 
 It would be preferable to test the thing in Sid before the upload to
 jessie-proposed-updates
 
 I’ll keep an eye out for it.
 
 But I don’t have one of the cubox models without the battery-backed RTC, so I 
 won’t be able to test that case.   Is there anyone out there in debian-arm 
 land with an appropriate test box?
 
 Enjoy!
 Rick

Am I looking in the wrong place?  I would have expected to see something show 
up in sid by now.

Is there a particular linux-image….deb I should download from somewhere to test 
this?

Thanks for all your help!
Rick

--
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/47e9fe80-96c8-4d91-b161-53a61a8a5...@pobox.com

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

On May 12, 2015, at 2:11 AM, Ian Campbell i...@debian.org wrote:

 On Tue, 2015-05-12 at 01:33 -0700, Rick Thomas wrote:
 On May 6, 2015, at 3:35 AM, Rick Thomas rbtho...@pobox.com wrote:
 
 
 On May 6, 2015, at 3:27 AM, Ian Campbell i...@debian.org wrote:
 
 It would be preferable to test the thing in Sid before the upload to
 jessie-proposed-updates
 
 I’ll keep an eye out for it.
 
 But I don’t have one of the cubox models without the battery-backed
 RTC, so I won’t be able to test that case.   Is there anyone out there
 in debian-arm land with an appropriate test box?
 
 Enjoy!
 Rick

It arrived this morning.  I’ve got two RTC entries now in /dev.  But I’m a bit 
confused…

Looking at the boot log with journalctl (see attachment), it appears that the 
snvs RTC (i.e. the one without a battery backup) is being found first, and the 
_kernel_ is setting system time from it — ignoring /etc/init.d/hwclock.sh 
completely.

The pcf8523 RTC (the one with battery backup) is being discovered later, and is 
not being used to set the system time at all.

This is exactly the opposite of the behavior I was hoping for.

Well… I thought I was prepared for that by planning to use parameters in 
/etc/default/hwclock to tell it which RTC to use when shutting-down or 
booting-up.  But it appears that those parameters are being ignored.

Looking in /lib/systemd/system/hwclock-save.service (the systemd equivalent of 
/etc/init.d/hwclock), I find “ExecStart=/sbin/hwclock -D —systohc” which is 
interesting because (1) it invokes a “-D” option which is not documented in 
“man hwclock”, (2) it ignores the /etc/default parameters, and (3) it’s only 
being done on shutdown/halt/reboot; there’s no corresponding service that gets 
run at boot time…  Is the RTC driver itself supposed to be doing that, so 
there’s no need for sysvinit or systemd to worry about it???  The “setting 
system clock” log entry would seem to substantiate that.

So what to do now?

Any constructive suggestions will appreciated.

Rick

root@cube:~# journalctl | egrep 'rtc|clock|date|time'
May 12 20:54:53 cube systemd-journal[167]: Runtime journal is using 5.0M (max 
allowed 40.3M, trying to leave 60.5M free of 398.5M available → current limit 
40.3M).
May 12 20:54:53 cube systemd-journal[167]: Runtime journal is using 5.0M (max 
allowed 40.3M, trying to leave 60.5M free of 398.5M available → current limit 
40.3M).
May 12 20:54:53 cube kernel: L2C-310 dynamic clock gating enabled, standby mode 
enabled
May 12 20:54:53 cube kernel: Switching to timer-based delay loop, resolution 
333ns
May 12 20:54:53 cube kernel: sched_clock: 32 bits at 3000kHz, resolution 333ns, 
wraps every 1431655765682ns
May 12 20:54:53 cube kernel: Calibrating delay loop (skipped), value calculated 
using timer frequency.. 6.00 BogoMIPS (lpj=12000)
May 12 20:54:53 cube kernel: AppArmor: AppArmor disabled by boot time parameter
May 12 20:54:53 cube kernel: PTP clock support registered
May 12 20:54:53 cube kernel: Switched to clocksource mxc_timer1
May 12 20:54:53 cube kernel: snvs_rtc 20cc034.snvs-rtc-lp: rtc core: registered 
20cc034.snvs-rtc-lp as rtc0
May 12 20:54:53 cube kernel: snvs_rtc 20cc034.snvs-rtc-lp: setting system clock 
to 2015-05-13 03:54:49 UTC (1431489289)
May 12 20:54:53 cube kernel: imx2-wdt 20bc000.wdog: timeout 60 sec (nowayout=0)
May 12 20:54:53 cube kernel: rtc-pcf8523 2-0068: rtc core: registered 
rtc-pcf8523 as rtc1
May 12 20:54:54 cube kernel: [drm] Supports vblank timestamp caching Rev 2 
(21.10.2013).
May 12 20:54:54 cube kernel: [drm] No driver support for vblank timestamp query.
May 12 20:54:54 cube kernel: imx-drm display-subsystem: bound imx-ipuv3-crtc.0 
(ops ipu_drm_driver_exit [imx_ipuv3_crtc])
May 12 20:54:54 cube kernel: imx-drm display-subsystem: bound imx-ipuv3-crtc.1 
(ops ipu_drm_driver_exit [imx_ipuv3_crtc])
May 12 20:54:54 cube kernel: imx-drm display-subsystem: bound imx-ipuv3-crtc.4 
(ops ipu_drm_driver_exit [imx_ipuv3_crtc])
May 12 20:54:54 cube kernel: imx-drm display-subsystem: bound imx-ipuv3-crtc.5 
(ops ipu_drm_driver_exit [imx_ipuv3_crtc])
May 12 20:54:54 cube kernel: [drm] Cannot find any crtc or sizes - going 
1024x768
May 12 20:55:56 cube systemd-journal[167]: Runtime journal is using 5.0M (max 
allowed 40.3M, trying to leave 60.5M free of 398.3M available → current limit 
40.3M).
May 12 20:55:56 cube adjtimex[356]: Regulating system clock...done.
May 12 20:55:59 cube ntpd[481]: Listening on routing socket on fd #20 for 
interface updates
May 12 20:56:03 cube colord[833]: Cannot adopt OID in UCD-SNMP-MIB: 
versionUpdateConfig ::= { version 11 }
May 12 20:56:06 cube ntpd[918]: Listening on routing socket on fd #23 for 
interface updates
May 12 21:23:02 cube CRON[1236]: (rbthomas) CMD (bash bin/check_cmos_ctime)

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

OK, How will I identify the upload when I see it?  The box is running 
Debian/Sid and I do regular updates.  So presumably, I’ll see a 
“linux-image-3.16.0-4-armmp” package go by sometime soon?  And I’ll know I’ve 
got it when I see two /dev/rtc* devices?

As for “rbtho...@cube.rcthomas.org” — I’m afraid it’s bogus.  I had exim4 
configured wrong when I submitted the original bugreport  /-:.  I’m subscribed 
to the bugreport with my proper address (“rbtho...@pobox.com”) now; so you can 
either just send stuff for me to the bugreport directly or to the “@pobox.com” 
address, and delete (or simply ignore) “rbtho...@cube.rcthomas.org” whenever it 
raises its head.

Thanks!  This has been an interesting and educational discussion!
Rick


On May 6, 2015, at 1:01 AM, Ian Campbell i...@debian.org wrote:

 On Sat, 2015-05-02 at 17:21 +0100, Ian Campbell wrote:
 We typically build RTCs statically (for this sort of reason) so it seems
 like the right thing for us to do here is to build both in.
 
 Which I've now done in SVN. Rick, please test the next upload.
 
 Also, Rick, I'm getting messages from my MTA about not being able to
 deliver to rbtho...@cube.rcthomas.org, it's been queuing/retrying since
 the weekend and says I shouldn't worry, but I thought I'd mention it
 since I was here. Exim logs say:
 
 2015-05-06 06:48:50 1YoZqj-0002JC-G0 == rbtho...@cube.rcthomas.org 
 R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host
 
 Hopefully you will see this via some other route.
 
 Ian.
 
 -- 
 To unsubscribe, send mail to 782364-unsubscr...@bugs.debian.org.
 


--
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/64a51823-c50b-48d5-8180-cbc44f691...@pobox.com

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

On May 6, 2015, at 3:27 AM, Ian Campbell i...@debian.org wrote:

 It would be preferable to test the thing in Sid before the upload to
 jessie-proposed-updates

I’ll keep an eye out for it.

But I don’t have one of the cubox models without the battery-backed RTC, so I 
won’t be able to test that case.   Is there anyone out there in debian-arm land 
with an appropriate test box?

Enjoy!
Rick

--
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/1250b1d0-ebaa-404c-b0f2-686de9e4d...@pobox.com

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

On Apr 28, 2015, at 8:02 PM, Fabio Estevam feste...@gmail.com wrote:

 On Fri, Apr 10, 2015 at 9:08 PM, Ben Hutchings b...@decadent.org.uk wrote:
 
 Whenever I reset my cubox-i4Pro by disconnecting the power plug, the 
 hardware real-time-clock gets
 reset to midnight UTC, Dec 31, 1970.
 Even though the SolidRun literature says that the i4Pro has a battery 
 backed RTC.
 
 If this RTC is not battery backed, it seems like it ought to be disabled
 in this board's device tree.
 
 Agreed. Just sent a patch for this.
 
 # CONFIG_RTC_DRV_PCF8523 is not set
 
 and
 
 CONFIG_RTC_DRV_SNVS=y
 
 And also a patch for turning on this option as well.
 
 Regards,
 
 Fabio Estevam

Cool… Thanks!  Any idea when we’ll see it in the kernel from Sid/Unstable 
repo’s?

Rick

--
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/b77ed00a-c66e-4ed8-b10d-6b5e8a885...@pobox.com

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

On Apr 28, 2015, at 8:02 PM, Fabio Estevam feste...@gmail.com wrote:

 On Fri, Apr 10, 2015 at 9:08 PM, Ben Hutchings b...@decadent.org.uk wrote:
 
 Whenever I reset my cubox-i4Pro by disconnecting the power plug, the 
 hardware real-time-clock gets
 reset to midnight UTC, Dec 31, 1970.
 Even though the SolidRun literature says that the i4Pro has a battery 
 backed RTC.
 
 If this RTC is not battery backed, it seems like it ought to be disabled
 in this board's device tree.
 
 Agreed. Just sent a patch for this.
 
 # CONFIG_RTC_DRV_PCF8523 is not set
 
 and
 
 CONFIG_RTC_DRV_SNVS=y
 
 And also a patch for turning on this option as well.
 
 Regards,
 
 Fabio Estevam

I don’t know if this makes any difference, but please remember that this box 
comes in several flavors.  Only the i4pro flavor has the battery-backed clock 
turned on in the hardware.

--
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/74d54565-f9ae-4be5-b48d-ffc8903ce...@pobox.com

Bug#782364: Actually, it makes some sense to keep both clocks

[Rick Thomas]

Ben Hutchings indicates that his preference would be to disable the 
non-battery-backed RTC and enable the battery-backed RTC in the kernel for the 
Cubox-i4pro.

I’m not a kernel hacker, so what I’m about to say may be off the mark, but:

If I’m not mistaken, this kernel is intended to be used on the entire Cubox 
line of computers.  Only the i4Pro model has the battery-backed RTC available.  
The other models do not enable that hardware feature.  So disabling the 
non-battery-backed RTC would break those models.

I don’t know if it’s possible (without modifications to other packages) to have 
the battery-backed clock be the one pointed to by /dev/rtc (though that would 
be nice…).  However, if that’s not possible, I’m willing to configure 
/etc/default/hwclock as a workaround.

I don’t know whether the two RTCs on the Cubox-i4Pro differ in their properties 
other than battery-backed-ness — e.g. accuracy, precision, etc… But if they do, 
that would be an argument in favor of providing both in the kernel.  One may be 
good for some uses, the other for other uses.

Thanks!
Rick

--
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/f59ad9fa-47db-4a9a-a764-199fbd068...@pobox.com

Bug#782364: Actually, it makes some sense to keep both clocks

[Rick Thomas]

On Apr 12, 2015, at 6:10 AM, Ben Hutchings b...@decadent.org.uk wrote:

 On Sun, 2015-04-12 at 01:37 -0700, Rick Thomas wrote:
 Ben Hutchings indicates that his preference would be to disable the
 non-battery-backed RTC and enable the battery-backed RTC in the kernel
 for the Cubox-i4pro.
 
 I’m not a kernel hacker, so what I’m about to say may be off the mark,
 but:
 
 If I’m not mistaken, this kernel is intended to be used on the entire
 Cubox line of computers.  Only the i4Pro model has the battery-backed
 RTC available.  The other models do not enable that hardware feature. 
 [...]
 
 Are you saying that a single device tree is used for multiple models?
 That should not be the case.
 
 But it looks like there are only two device trees defined for Cubox, one
 for those with the i.MX6DL and one for the i.MX6Q.  Both of which enable
 both RTCs!
 
 So you're right, we can't just disable the non-battery-backed RTC for
 this one model.

Thanks for clarifying what I was trying to get at.

Looking forward to help test this!


 Ben.
 
 -- 
 Ben Hutchings
 compatible: Gracefully accepts erroneous data from any source

Rick

--
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/08e8c208-9ea1-4796-b9fc-8b44f83cc...@pobox.com

Bug#782364: linux-image-3.16.0-4-armmp: please configure drivers for both Cubox i4pro real time clocks

[Rick Thomas]

Package: src:linux
Version: 3.16.7-ckt7-1
Severity: wishlist
Tags: newcomer

Whenever I reset my cubox-i4Pro by disconnecting the power plug, the hardware 
real-time-clock gets
reset to midnight UTC, Dec 31, 1970.
Even though the SolidRun literature says that the i4Pro has a battery backed 
RTC.

A bit of googling reveals that this is related to the following fact (Quoted 
from the SolidRun forums)

There are two RTC inside CuBox-i 
1. One connected to the SNVS rail (internal i.MX6) which is not battery backed 
and typically goes to /dev/rtc0
2. Second is NXP PFC8523 based and that one has battery backup (/dev/rtc1)
SolidRun Engineering
user rabeeh in #cubox on Freenode IRC
by rabeeh » Sat Jan 25, 2014 7:04 pm 

It's a standard non rechargeable lithium 3.3v coin cell.
Available only on the models that has RTC.
SolidRun Engineering
user rabeeh in #cubox on Freenode IRC

Curiously, when I look at the Debian Jessie system running on the box, I find 
that there is only one /dev/rtc* device,
and that seems to be associated with the SNVS clock.  The PFC8523 clock is not 
available…

Checking /boot/config-3.16.0-4-armmp, I see what I think is an explanation, 
because

# CONFIG_RTC_DRV_PCF8523 is not set

and

CONFIG_RTC_DRV_SNVS=y

Other Linux systems (e.g. Arch) appear (according to the above mentioned 
googling) to have their kernel compiled so as to
provide both /dev/rtc0 attached to the SNVS clock, and /dev/rtc1 attached to 
the PFC8523 clock.

Would it be possible to configure the default Debian Jessie kernel to do the 
same?

Ideally, the PFC8523 clock should show up as /dev/rtc0, linked to /dev/rtc,
so that the battery backed clock is used by default to set the system clock at 
boot-time.
Failing that, it may be possible to address this by setting HCTOSYS_DEVICE in 
/etc/default/hwclock appropriately.
Or maybe one could tweak a rule in /etc/udev ?

Karsten Merker commented via email:

Yes, that should just need enabling the appropriate module.
The device-tree instantiates the pcf8523 clock chip:

i2c3 {
   pinctrl-names = default;
   pinctrl-0 = pinctrl_cubox_i_i2c3;

   status = okay;

   rtc: pcf8523@68 {
   compatible = nxp,pcf8523;
   reg = 0x68;
   };
};

So if the module is available, it should be loaded automatically.

Please file a wishlist bug against Source: linux, Version: 
3.16.7-ckt9-1 so that the kernel maintainers can enable the
module for the next kernel upload.


-- Package-specific info:
** Version:
Linux version 3.16.0-4-armmp (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:
console=ttymxc0,115200 quiet

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[3.659929] IR RC5(x) protocol handler initialized
[3.661235] IR SANYO protocol handler initialized
[3.682273] [drm] Initialized drm 1.1.0 20060810
[3.684385] ipu_smfc_init: ioremap 0x0265 - f05a8000
[3.685339] imx-ipuv3 240.ipu: IPUv3H probed
[3.685411] lirc_dev: IR Remote Control driver registered, major 243 
[3.685844] ipu_smfc_init: ioremap 0x02a5 - f05c2000
[3.685851] leds_pwm pwmleds: unable to request PWM for imx6:red:front: -517
[3.685879] platform pwmleds: Driver leds_pwm requests probe deferral
[3.694394] imx-ipuv3 280.ipu: IPUv3H probed
[3.722182] i2c i2c-1: IMX I2C adapter registered
[3.726369] rc rc0: lirc_dev: driver ir-lirc-codec (gpio-rc-recv) registered 
at minor = 0
[3.726389] IR LIRC bridge handler initialized
[3.735281] i2c i2c-2: IMX I2C adapter registered
[3.764961] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[3.768187] imxdrm: module is from the staging directory, the quality is 
unknown, you have been warned.
[3.769810] imxdrm: module is from the staging directory, the quality is 
unknown, you have been warned.
[3.775554] imx_hdmi: module is from the staging directory, the quality is 
unknown, you have been warned.
[3.794884] imx_ipuv3_crtc: module is from the staging directory, the 
quality is unknown, you have been warned.
[3.794888] imx_ipuv3_crtc: module is from the staging directory, the 
quality is unknown, you have been warned.
[3.794893] imx_ipuv3_crtc: module is from the staging directory, the 
quality is unknown, you have been warned.
[3.796261] imx_ipuv3_crtc: module is from the staging directory, the 
quality is unknown, you have been warned.
[3.799664] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.799677] [drm] No driver support for vblank timestamp query.
[3.799852] imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops .LANCHOR0 
[imx_ipuv3_crtc])
[3.799942] imx-drm display-subsystem: bound imx-ipuv3-crtc.1 (ops .LANCHOR0 
[imx_ipuv3_crtc])
[3.800053] imx-drm display-subsystem: bound imx-ipuv3-crtc.4 (ops .LANCHOR0 
[imx_ipuv3_crtc])
[3.800140] imx-drm display-subsystem: bound 

Bug#713943: Not fixed for me

[Rick Thomas]

H...

I'm planning to try it on my G5 soon.  I'll let you know what I find out.

It may be that we need a parameter on the module load line?

Rick

On Apr 22, 2014, at 1:10 AM, Bertrand Dekoninck bdekoni...@free.fr wrote:

 Hi Rick, for you so much for your quick answer.
 I had tried the same in /etc/modules. I've just removed it and tried your 
 local.conf setting. No success.
 I have still the same message in dmesg  :
 
 
 [0.961200] PowerMac i2c bus pmu 2 registered
 [0.961236] PowerMac i2c bus pmu 1 registered
 [0.961272] PowerMac i2c bus mac-io 0 registered
 [0.961667] PowerMac i2c bus u3 1 registered
 [0.961725] i2c i2c-3: i2c-powermac: modalias failure on 
 /u3@0,f800/i2c@f8001000/cereal@1c0
 [0.961764] PowerMac i2c bus u3 0 registered
 
 
 and
 
 
 [1.361462] Detected fan controls:
 [1.361467]   0: PWM fan, id 1, location: BACKSIDE,SYS CTRLR FAN
 [1.361472]   1: RPM fan, id 2, location: DRIVE BAY
 [1.361477]   2: PWM fan, id 2, location: SLOT,PCI FAN
 [1.361482]   3: RPM fan, id 3, location: CPU A INTAKE
 [1.361488]   4: RPM fan, id 4, location: CPU A EXHAUST
 [1.361493]   5: RPM fan, id 5, location: CPU B INTAKE
 [1.361498]   6: RPM fan, id 6, location: CPU B EXHAUST
 [1.361538] i2c i2c-0: therm_pm72: attach_adapter method is deprecated
 [1.361545] i2c i2c-0: Please use another way to instantiate your 
 i2c_client
 [1.361553] i2c i2c-1: therm_pm72: attach_adapter method is deprecated
 [1.361558] i2c i2c-1: Please use another way to instantiate your 
 i2c_client
 [1.361566] i2c i2c-2: therm_pm72: attach_adapter method is deprecated
 [1.361572] i2c i2c-2: Please use another way to instantiate your 
 i2c_client
 [1.361580] i2c i2c-3: therm_pm72: attach_adapter method is deprecated
 [1.361585] i2c i2c-3: Please use another way to instantiate your 
 i2c_client
 [1.361596] i2c i2c-3: Failed to register i2c client therm_pm72 at 0x2f 
 (-16)
 [1.361602] therm_pm72: Failed to attach to i2c ID 0x15e
 [1.361609] i2c i2c-4: therm_pm72: attach_adapter method is deprecated
 [1.361615] i2c i2c-4: Please use another way to instantiate your 
 i2c_client
 [1.361671] i2c i2c-4: Failed to register i2c client therm_pm72 at 0x2c 
 (-16)
 [1.361677] therm_pm72: Failed to attach to i2c ID 0x58
 
 
 Not all fans seem to be registered.
 
 I also have random kernel panics, but i think it is unrelated  to this bug : 
 something about radeon-kms (and I only have a software rasterizer for opengl, 
 even if I boot with the video=offb:off video=radeonfb:off  kernel 
 argument.).
 
 Thank you again.
 
 Le 22/04/2014 05:18, Rick Thomas a écrit :
 On Apr 21, 2014, at 1:49 PM, Bertrand Dekoninck bdekoni...@free.fr wrote:
 
 I've installed jessie with linux-3.13.7-1 last night on my powermac7,3 
 (2x2.0 ghz). The fans are still crazy, even if i2c-powermac is build-in 
 (and not a module anymore).
 Hi Bertrand,
 
 Have you tried
 echo 'i2c-powermac'  /etc/modules-load.d/local.conf
 then reboot?
 
 I know it's supposed to be compiled-in with this version of the kernel, but 
 maybe it just needs a little push?
 
 Rick
 
 
 
 -- 
 To unsubscribe, send mail to 713943-unsubscr...@bugs.debian.org.
 


--
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/5bd7be0f-2181-4414-85c9-dd2ee35a8...@pobox.com

Bug#713943: Not fixed for me

[Rick Thomas]

On Apr 21, 2014, at 1:49 PM, Bertrand Dekoninck bdekoni...@free.fr wrote:

 I've installed jessie with linux-3.13.7-1 last night on my powermac7,3 (2x2.0 
 ghz). The fans are still crazy, even if i2c-powermac is build-in (and not a 
 module anymore).

Hi Bertrand,

Have you tried
echo 'i2c-powermac'  /etc/modules-load.d/local.conf
then reboot?

I know it's supposed to be compiled-in with this version of the kernel, but 
maybe it just needs a little push?

Rick


--
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/92734fe9-9af3-455d-be5e-753e040fa...@pobox.com

Bug#713943: Lack of i2c_powermac module may be the cause

[Rick Thomas]

On Feb 22, 2014, at 12:23 AM, Erik de Castro Lopo er...@mega-nerd.com wrote:

 Hi,
 
 I run debian testing on a dual G5 powermac.
 
 Just upgraded from linux-image-3.4-trunk-powerpc64 to
 linux-image-3.12-1-powerpc64 and found the same issue. The windfarm
 modules are loading but the about 30 seconds to a couple of minutes
 after booting to 3.12-1-powerpc64 the fans speed up to full speed.
 
 lsmod says the windfarm modules are being loaded, and its the same
 modules being loaded under the 3.4 kernel.
 
 I have however found a difference. On 3.12 I get:
 
 dmesg | grep windfarm 
[4.358299] windfarm: initializing for dual-core desktop G5
 
 whereas on 3.4 I get:
 
 dmesg | grep windfarm 
[4.791589] windfarm: initializing for dual-core desktop G5
[9.077416] windfarm: CPUs control loops started.
[   12.440957] windfarm: Backside control loop started.
[   12.491701] windfarm: Slots control loop started.
[   12.592933] windfarm: Drive bay control loop started.
 
 Definitely something wonky there.
 
 Erik

 Erik de Castro Lopo wrote:
 
 Hi,
 
 A previous message in this bug suggested that the i2c_powermac module 
 may be involved.
 
 I can confirm that this module is missing completely for the 3.12 kernel
 (there is no module of that name in the /lib/modules/3.12-1-powerpc64/
 tree) whereas for the 3.4 kernel this module is available and is being
 auto-loaded.
 
 It seems that the i2c_powermac module from 3.4 is now called i2c-powermac
 (underscore replaced with a minux sign).
 
 Manually loading the i2c-powermac module results in fans that run at the
 normal. expected low speed. I will be adding this to /etc/modules as a
 workaround for this issue.
 
 A question about kernel modules, can one module (eg windfarm_core) be
 made to depend on and auto-load another (eg i2c-powermac)?
 
 Erik
 -- 
 --
 Erik de Castro Lopo
 http://www.mega-nerd.com/
 
 -- 
 To unsubscribe, send mail to 713943-unsubscr...@bugs.debian.org.
 


I'm forwarding this to the debian-powerpc list, incase someone there can help!

Rick


--
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/d1fd7102-6925-4f1a-a04d-24a6cba0e...@pobox.com

Bug#713943: Lack of i2c_powermac module may be the cause

[Rick Thomas]

I have a single processor MacPro G5 PowerMac7,3 running Jessie.

model   : PowerMac7,3
machine : PowerMac7,3
motherboard : PowerMac7,3 MacRISC4 Power Macintosh 
detected as : 336 (PowerMac G5)



I also have a dual core G5 PowerMac11,2 but it's running MacOS-X.

The 7,3 has exactly the problem described.  Adding the line i2c-powermac to 
/etc/modules is enough to fix the problem.  As for the windfarm driver on that 
machine, 

$ lsmod | grep -i wind | wc -l
0

Sometime soon, I'll put a spare disk into the 11,2 and install Jessie on it.  
I'll give results and CC this bugreport.

Rick


On Feb 22, 2014, at 7:28 AM, Erik de Castro Lopo er...@mega-nerd.com wrote:

 David Gosselin wrote:
 
 Are you testing on a PowerMac G5 7,3?  Should be in /proc/cpuinfo.
 I have a 7,3 model and cannot load the windfarm driver.  It appears
 that the hardware on the 7,3 is not supported.  I’ve been working to
 update the therm_pm72 driver to use the probe interface instead of the
 attach_adapter interface.  Maybe you’re hitting this issue?
 
 Nope, seems to be 11,2:
 
 
platform: PowerMac
model   : PowerMac11,2
machine : PowerMac11,2
motherboard : PowerMac11,2 MacRISC4 Power Macintosh 
detected as : 337 (PowerMac G5 Dual Core)
 
 
 Erik
 -- 
 --
 Erik de Castro Lopo
 http://www.mega-nerd.com/
 
 
 -- 
 To UNSUBSCRIBE, email to debian-powerpc-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/20140223022840.de1c11b823017c14f79d2...@mega-nerd.com
 
 


--
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/5ce3db0a-4116-45e9-af61-bc4bb5e08...@pobox.com

Bug#713943: linux-image-3.9-1-powerpc64: windfarm module is not working any more

[Rick Thomas]

On Aug 30, 2013, at 8:01 AM, Vladimir Berezenko qmaster2...@gmail.com wrote:

 Seems that there's another one problem.
 From time to time cursor in X become garbage and after some time kernel goes 
 panicking.
 Last update seems not causing panick, but cursor garbage stayed.
 The 3.2 kernel works OK with all the same libs/env so it's a kernel 3.10 bug.


On Sep 23, 2013, at 10:30 AM, Douglas Mencken dougmenc...@gmail.com wrote:

 Yep, it happens everytime. GNU/Linux is totally unusable in its current state.
 
 P.S. But X.org mouse pointer issue doesn't have anything with kernel.


On Sep 23, 2013, at 1:40 PM, Vladimir Berezenko qmaster2...@gmail.com wrote:

 I think that it has. The 3.2 kernel is not causing this garbage to come and 
 didnt panick. All other env is completely the same. The latest update didn't 
 fix the problem. I've just rebooted back to 3.2 because of a cursor garbage. 

With the 3.12 kernel (Jessie), my G5 PowerMac7,3 crashes and freezes when 
trying o reboot, but ONLY if I am running X when I attempt to reboot.

Also, the X graphics is crappy compared to the same machine running the 3.2 
kernel (Wheezy)

I'm working on getting netconsole setup so I can get a transcript of the 
crash/hang to submit as a bugreport.  Is this bug (Bug#713943) a good place to 
send it, if I can get it?

Thanks!

Rick

--
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/1894f3d7-1a73-4af3-bc7a-b0112d985...@pobox.com

Bug#736130: Mac64 - wrong colors and other problems

[Rick Thomas]

On Jan 24, 2014, at 11:10 AM, Vladimir Berezenko qmaster2...@gmail.com wrote:

 В письме от 24 января 2014 11:07:51 пользователь Michel Dänzer написал:
 
 The mach64 DRM driver never made it into the mainline kernel, so I'm
 afraid getting DRI working is hopeless (unless you want to revive the
 mach64 DRM driver and get it merged :).
 
 DRI in 32bit is not working on nvidia and ati cards also.
 And for me the latest 3.12 kernel panics sometimes in X.
 -- 
 WBR, Vladimir Berezenko.

I'm seeing this (bad color in X and crashes) also, on my G5 MacPro with [AMD] 
nee ATI RV350 AP [Radeon 9600] video.

Interestingly enough, everything works fine in Wheezy (3.2 kernel); the 
problems only show up in Jessie (3.12 kernel).

Crashes reported in bug#736130

Rick


--
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/17c6a7f4-2224-47cb-b00f-a30bce60e...@pobox.com

Bug#736130: linux-image-3.12-1-powerpc64 crashes during shutdown of PowerPC G5 Mac. But PowerPC g4 Mac (23-bit) works OK.

[Rick Thomas]

Package: src:linux
Version: 3.12.6-2
Severity: important



-- Package-specific info:
** Version:
Linux version 3.12-1-powerpc64 (debian-kernel@lists.debian.org) (gcc version 
4.8.2 (Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29)

** Command line:
root=UUID=22825ec8-11c9-4041-8bb3-d74fabacf3f5 ro 

** Not tainted

** Kernel log:
[5.429923] hid-generic 0003:0461:4D15.0006: input,hidraw5: USB HID v1.11 
Mouse [USB Optical Mouse] on usb-0001:05:0b.0-2.3/input0
[5.536358] PM: Starting manual resume from disk
[5.551346] PM: Hibernation image partition 8:4 present
[5.551348] PM: Looking for hibernation image.
[5.559934] PM: Image not found (code -22)
[5.559939] PM: Hibernation image not present or could not be loaded.
[5.605217] EXT4-fs (sda3): INFO: recovery required on readonly filesystem
[5.620377] EXT4-fs (sda3): write access will be enabled during recovery
[6.438475] EXT4-fs (sda3): recovery complete
[6.463378] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: 
(null)
[7.603515] systemd-udevd[328]: starting version 204
[8.366144] cfg80211: Calling CRDA to update world regulatory domain
[8.668627] b43-phy0: Broadcom 4306 WLAN found (core revision 5)
[8.704610] b43-phy0: Found PHY: Analog 2, Type 2 (G), Revision 2
[8.744678] Broadcom 43xx driver loaded [ Features: PMNLS ]
[8.770468] b43 ssb0:0: firmware: failed to load b43/ucode5.fw (-2)
[8.786018] b43 ssb0:0: firmware: failed to load b43/ucode5.fw (-2)
[8.801573] b43 ssb0:0: firmware: failed to load b43-open/ucode5.fw (-2)
[8.816913] b43 ssb0:0: firmware: failed to load b43-open/ucode5.fw (-2)
[8.831975] b43-phy0 ERROR: You must go to 
http://wireless.kernel.org/en/users/Drivers/b43#devicefirmware and download the 
correct firmware for this driver version. Please carefully read all 
instructions on this website.
[9.418309] cfg80211: World regulatory domain updated:
[9.434184] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp)
[9.450012] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[9.465849] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[9.481576] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (300 mBi, 
2000 mBm)
[9.497178] cfg80211:   (517 KHz - 525 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[9.512730] cfg80211:   (5735000 KHz - 5835000 KHz @ 4 KHz), (300 mBi, 
2000 mBm)
[   12.327388] Adding 5868160k swap on /dev/sda4.  Priority:-1 extents:1 
across:5868160k 
[   12.441652] EXT4-fs (sda3): re-mounted. Opts: (null)
[   12.799691] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro
[   13.946910] snd-powermac no longer handles any machines with a layout-id 
property in the device-tree, use snd-aoa.
[   13.995345] i2c i2c-4: therm_pm72: attach_adapter method is deprecated
[   14.005929] i2c i2c-4: Please use another way to instantiate your i2c_client
[   14.016452] PowerMac i2c bus pmu 2 registered
[   14.028733] i2c i2c-5: therm_pm72: attach_adapter method is deprecated
[   14.039319] i2c i2c-5: Please use another way to instantiate your i2c_client
[   14.049877] PowerMac i2c bus pmu 1 registered
[   14.060367] i2c i2c-6: therm_pm72: attach_adapter method is deprecated
[   14.070900] i2c i2c-6: Please use another way to instantiate your i2c_client
[   14.081481] PowerMac i2c bus mac-io 0 registered
[   14.092515] i2c i2c-7: therm_pm72: attach_adapter method is deprecated
[   14.103201] i2c i2c-7: Please use another way to instantiate your i2c_client
[   14.113822] PowerMac i2c bus u3 1 registered
[   14.124225] i2c i2c-7: Failed to register i2c client MAC,fcu at 0x2f (-16)
[   14.134693] i2c i2c-7: i2c-powermac: Failure to register 
/u3@0,f800/i2c@f8001000/fan@15e
[   14.145113] i2c i2c-7: i2c-powermac: modalias failure on 
/u3@0,f800/i2c@f8001000/cereal@1c0
[   14.155365] i2c i2c-8: therm_pm72: attach_adapter method is deprecated
[   14.165586] i2c i2c-8: Please use another way to instantiate your i2c_client
[   14.176228] PowerMac i2c bus u3 0 registered
[   14.190309] FCU Initialized, RPM fan shift is 3
[   14.191367] i2c i2c-8: Failed to register i2c client MAC,ds1775 at 0x4a (-16)
[   14.201881] i2c i2c-8: i2c-powermac: Failure to register 
/u3@0,f800/i2c@f8001000/temp-monitor@94
[   14.212545] i2c i2c-8: Failed to register i2c client MAC,max6690 at 0x4c 
(-16)
[   14.223332] i2c i2c-8: i2c-powermac: Failure to register 
/u3@0,f800/i2c@f8001000/temp-monitor@98
[   14.234119] i2c i2c-8: Failed to register i2c client MAC,ad7417 at 0x2c (-16)
[   14.244524] i2c i2c-8: i2c-powermac: Failure to register 
/u3@0,f800/i2c@f8001000/supply-monitor@58
[   14.256115] i2c i2c-8: Failed to register i2c client MAC,ad7417 at 0x2d (-16)
[   14.266651] i2c i2c-8: i2c-powermac: Failure to register 
/u3@0,f800/i2c@f8001000/supply-monitor@5a
[   14.325096] fuse init (API version 7.22)
[   14.384786] EXT4-fs (sda5): mounted 

Bug#736130: linux-image-3.12-1-powerpc64 crashes during shutdown of PowerPC G5 Mac. But PowerPC g4 Mac (23-bit) works OK.

[Rick Thomas]

Thanks, Ben, for the very quick response!

I'd love to do that.  But I don't have a serial console for this machine (no 
serial port -- it's a PowerMac MacPro G5, 64-bit CPU) and the messages logged 
at crash time scroll off the screen too fast for me to copy them down (or even 
photograph).

I'll make a photograph of the last screen's worth of messages and send that to 
the bug, if you think that will help.

Do you know of any way to get more information than that?  I'd really like to 
help get this bug fixed (I've got plans for this machine but I can't go forward 
with them until I can reboot it reliably)

Does it help any that the G4 (32-bit CPU) sitting right beside it, running an 
identical software setup, reboots just fine?

Rick

On Jan 19, 2014, at 7:13 PM, Ben Hutchings b...@decadent.org.uk wrote:

 Control: tag -1 moreinfo
 
 You forgot to include the messages logged at shutdown.
 
 Ben.
 
 -- 
 Ben Hutchings
 One of the nice things about standards is that there are so many of them.


--
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/63f5cf1b-4eed-4d09-9fb5-46d9c8bf7...@pobox.com

Bug#736130: linux-image-3.12-1-powerpc64 crashes during shutdown of PowerPC G5 Mac. But PowerPC g4 Mac (23-bit) works OK.

[Rick Thomas]

One additional bit of information that may help -- Wheezey ( the 3.2 ppc64 
kernel ) doesn't have this problem on this machine.

Rick

On Jan 19, 2014, at 7:23 PM, Rick Thomas rbtho...@pobox.com wrote:

 Thanks, Ben, for the very quick response!
 
 I'd love to do that.  But I don't have a serial console for this machine (no 
 serial port -- it's a PowerMac MacPro G5, 64-bit CPU) and the messages 
 logged at crash time scroll off the screen too fast for me to copy them down 
 (or even photograph).
 
 I'll make a photograph of the last screen's worth of messages and send that 
 to the bug, if you think that will help.
 
 Do you know of any way to get more information than that?  I'd really like to 
 help get this bug fixed (I've got plans for this machine but I can't go 
 forward with them until I can reboot it reliably)
 
 Does it help any that the G4 (32-bit CPU) sitting right beside it, running an 
 identical software setup, reboots just fine?
 
 Rick
 
 On Jan 19, 2014, at 7:13 PM, Ben Hutchings b...@decadent.org.uk wrote:
 
 Control: tag -1 moreinfo
 
 You forgot to include the messages logged at shutdown.
 
 Ben.
 
 -- 
 Ben Hutchings
 One of the nice things about standards is that there are so many of them.
 
 


--
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/ca50ba1a-006d-4ade-b6cf-60e365f24...@pobox.com

Bug#736130: linux-image-3.12-1-powerpc64 crashes during shutdown of PowerPC G5 Mac. But PowerPC g4 Mac (23-bit) works OK.

[Rick Thomas]

On Jan 19, 2014, at 7:41 PM, Ben Hutchings b...@decadent.org.uk wrote:

 On Sun, 2014-01-19 at 19:23 -0800, Rick Thomas wrote:
 Thanks, Ben, for the very quick response!
 
 I'd love to do that.  But I don't have a serial console for this
 machine (no serial port -- it's a PowerMac MacPro G5, 64-bit CPU)
 and the messages logged at crash time scroll off the screen too fast
 for me to copy them down (or even photograph).
 
 I'll make a photograph of the last screen's worth of messages and send
 that to the bug, if you think that will help.
 
 It might do.

OK.  That's worth a try then.

 
 Do you know of any way to get more information than that?  I'd really
 like to help get this bug fixed (I've got plans for this machine but I
 can't go forward with them until I can reboot it reliably)
 
 You might also be able to use netconsole
 https://www.kernel.org/doc/Documentation/networking/netconsole.txt.

I'll read up and see if I can make it work for this case.

 
 Does it help any that the G4 (32-bit CPU) sitting right beside it,
 running an identical software setup, reboots just fine?
 
 I have no idea what the differences could be.  Unfortunately there are
 no kernel maintainers for powerpc in Debian so all I can do is prompt
 for useful information and then refer you upstream.

Thanks! for helping any way you can…

 Ben.

Rick

 
 -- 
 Ben Hutchings
 One of the nice things about standards is that there are so many of them.

Words to live by!


--
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/f8d1414d-d553-46d6-8c73-3ceaa86b2...@pobox.com

Bug#728936: Seems to be fixed in PowerPC Netinst from Jan 8th

[Rick Thomas]

This bug seems to be fixed in

Debian GNU/Linux testing Jessie - Official Snapshot powerpc NETINST
   Binary-1 20140108-22:14

However, that netinst image installs a system that refuses to boot on PowerPC64 
-- works fine on powerpc (32-bit) though!

I'll be submitting a separate bug-report on that one…

Rick

--
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/0a0bfea4-a1cb-496d-bb2e-0a88db403...@pobox.com

Bug#728936: Seems to be fixed in powerpc netinst from Jan 8

[Rick Thomas]

This bug seems to be fixed in

Debian GNU/Linux testing Jessie - Official Snapshot powerpc NETINST
   Binary-1 20140108-22:14

However, that netinst image installs a system that refuses to boot on PowerPC64 
-- works fine on powerpc (32-bit) though!

I'll be submitting a separate bug-report on that one…

Rick

--
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/87262085-7f40-44ab-80ce-170032963...@pobox.com

Bug#728936: Is there a way to ssh into the debian installation process?

[Rick Thomas]

Hi Gary,
Thanks for your interest.

This is in pursuit of Bug#728936 (and related bugs #715408 and 731939)  wherein 
the USB keyboard and mouse are not recognized by the installer, thus making it 
impossible to specify any options past the bootloader.

The idea is to pressed the installer to auto-answer all debian-installer 
questions up-to and including loading the ssh server and network console, 
thus giving me an alternate way to get in and poke-around in the installation.  
 Hopefully, with this I can find out why the USB keyboard and mouse are not 
being recognized, and propose a fix.

Do you have any experience making a pre seeded bootable CD for powerpc?  If so, 
could you share it with us?

Rick



On Jan 5, 2014, at 9:48 AM, Gary Driggs gdri...@gmail.com wrote:

 On Jan 5, 2014, at 1:22 AM, Rick Thomas wrote:
 So I think I could do the same thing on a PowerPC Mac if I knew the ppc 
 equivalents of isolinux.cfg as used by you for i386 -- and the ppc 
 equivalent of the genisoimage magic you use to make the bootable image.
 
 I thought that any advanced installation would give you a menu option to turn 
 on SSH to finish the installation. Or does this config turn it on much 
 earlier in the process?
 
 -Gary


--
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/4403cf26-6110-4135-a2f0-a073e0a68...@pobox.com

Re: Bug#728936: Bug#731939: debian-installer: USB input not functioning during install

[Rick Thomas]

Manfred and Jason,

It would help a lot if each of you please reply-all to this with the output of 
(as root -- and with the USB keyboard and mouse plugged in to the machine)
 lsusb -v
and
 lsmod

That may help tell what USB/HCI driver is needed for your devices.

Thanks!

Rick

On Dec 12, 2013, at 10:57 AM, Ben Hutchings b...@decadent.org.uk wrote:

 On Thu, Dec 12, 2013 at 06:11:12PM +0100, Andreas Cadhalpun wrote:
 Hi,
 
 I noticed one difference between my and Manfred's setup to Jason's:
 It seems USB input works now on Intel hardware (hadn't worked in the
 past), but not on AMD hardware (and also not on PowerPC).
 
 Can someone else with AMD and/or Intel hardware test this hypothesis?
 
 I seriously doubt that this is the important difference.  These bugs
 are probably duplicates of #730789: the OHCI driver (ohci-pci,
 previously called ohci-hcd) is missing.  I believe that breaks:
 
 - All devices in USB 1.x ports (except in systems with UHCI)
 - Low speed and full speed devices in USB 2.0 ports
 
 But these should still work:
 
 - High speed devices in USB 2.0 ports (handled by ehci-pci)
 - All devices in USB 3.0 ports (handled by xhci)
 
 Keyboards and mice are generally low speed or full speed, but a
 keyboard with a built-in hub might be high speed.



--
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/b4017918-e347-426f-b170-962f592eb...@pobox.com

Re: Bug#731939: debian-installer: USB input not functioning during install

[Rick Thomas]

On Dec 11, 2013, at 5:06 AM, Cyril Brulebois k...@debian.org wrote:

 Jason Young doom...@gmail.com (2013-12-11):
 Package: debian-installer
 Severity: normal
 
 Dear Maintainer,
 I booted the amd64 netinstall disc for debian jessie, and at first I
 thought that it was frozen because neither the keyboard and mouse,
 which are usb, were lit up or would respond. I discovered this was not
 the case when, on a hunch, I attached a keyboard with a ps2 port.
 
 I think I read something about ohci-pci on #-kernel lately, which might
 explain the issue you're seeing.
 
 Cc-ing -kernel to make sure they're aware of your report.


Hmmm…

We're seeing the same problem with the PowerPC Jessie daily build netinst CDs.  
See Bug#715408 and Bug#728936 for details.

In the discussion regarding those two, it seems that (at least sometimes) amd64 
doesn't have this problem.  So what's different about Jason's setup?

Curiouser and Curiouser! cried Alice.

Rick

--
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/081b8ebc-f675-4fe5-9492-709e57ed0...@pobox.com

Bug#713943: Fwd: Sound and BCM4318 wireless no longer working in Wheezy on late 2005 G5

[Rick Thomas]

This may have some relevance to bug#713943

Begin forwarded message from Debian PowerPC list:


Resent-From: debian-powe...@lists.debian.org
From: Chris Wareham ch...@chriswareham.net
Date: August 5, 2013 12:27:06 PM PDT
To: debian-powe...@lists.debian.org
Subject: Re: Sound and BCM4318 wireless no longer working in Wheezy  
on late 2005 G5


Michel Dänzer said on 05/08/13 10:15:

On Son, 2013-08-04 at 22:20 +, Chris Wareham wrote:


I've been tracking Debian Wheezy on my late 2005 dual G5 Powermac  
the

middle of last year. Everything has worked fine (Bluetooth / BCM4318
wireless combo card, sound, etc) until around the time of the 7.1
release. The first thing that went wrong was the fans switching to  
full

power, which has already been noted on this list.


For the fans, make sure the i2c_powermac module is loaded. Not sure
about your other problems though.




Hi Michel,

The i2c_powermac module wasn't loaded - now that it is, the problem  
with the fans running at full blast is solved. As for the other  
issues, I notice in the dmesg output there's a message saying that  
the snd-powermac module shouldn't be loaded. Removing it doesn't  
change things though.


Regards,

Chris



--
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/c2a99612-2540-41f1-8a9b-866042cfe...@pobox.com

Bug#684265: Bug#690515: Still with us -- still in Beta3

[Rick Thomas]

On Oct 14, 2012, at 11:55 PM, Rick Thomas wrote:



On Sep 24, 2012, at 6:26 AM, Milan Kupcevic wrote:

Please file a separate debian-installer bug report for problems  
related

to finding other OS's on LVM partitions.

Milan


OK, here it is: Bug#690515

I hope it's an easy fix.  It would be a shame to see it get into  
beta3...


Rick



Well... The bug made it into Beta3.  [)-:]

I just tested it with the Beta3 AMD64 DVD-1 (no repository servers --  
to make sure I got just Beta3 and not the latest updates.)


On my machine with three Debian root LVM partitions, it only found one  
(the one I was installing to).


After finishing installing and rebooting into the installed system,  
update-grub does find the other partitions and it does the right  
thing.


I'm happy to help by testing anything you suggest.  That's what I keep  
this machine for.


If you think it's a missing module, as it was with 684265, please  
point me to the module, and I'll test it.


Thanks!

Rick


--
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/b1566131-1c92-442d-8c04-91b7eef49...@pobox.com

Bug#684265: Still with us

[Rick Thomas]

On Sep 24, 2012, at 6:26 AM, Milan Kupcevic wrote:

Please file a separate debian-installer bug report for problems  
related

to finding other OS's on LVM partitions.

Milan


OK, here it is: Bug#690515

I hope it's an easy fix.  It would be a shame to see it get into  
beta3...


Rick


--
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/9c33fca4-9d2d-408d-aa3a-f7fddcb87...@pobox.com

Bug#684265: Still with us

[Rick Thomas]

On Sep 24, 2012, at 6:26 AM, Milan Kupcevic wrote:



Please file a separate debian-installer bug report for problems  
related

to finding other OS's on LVM partitions.

Milan


Well... I tried it on a machine that was not using LVM, and got the  
same results.


So the bug isn't fixed yet.

Rick


--
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/803060d4-01ca-410d-b797-10ebe8216...@pobox.com

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

[Rick Thomas]

On Sep 15, 2012, at 8:36 PM, Ben Hutchings wrote:


On Thu, 2012-09-13 at 14:58 -0700, 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.

[...]

Will be included in the next linux upload to unstable, hopefully this
weekend.  I don't know how long that will take to get into a daily
installer.


Thanks, Ben!  I'll be on the lookout for it.  Please let me know if  
you see it appear before I do.


Rick


--
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/28548ade-6395-4b62-999d-c4617edb6...@pobox.com

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

[Rick Thomas]

On Sep 12, 2012, at 10:41 PM, 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)?


It certainly does sound like it!

I'll try the workaround and report back.

Thanks for caring!

Rick


--
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/43be9a58-959e-4b5a-956f-5a257d071...@pobox.com

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

[Rick Thomas]

On 09/12/12 23:22, Rick Thomas wrote:


On Sep 12, 2012, at 10:41 PM, 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)?


I'll try the workaround and report back.


Sadly, that didn't solve the problem.

The umount: can't umount... error message went away, but the three 'no 
such disk' messages remained.  And grub install still objected because 
there was only one OS...


I've attached the relevant section of /var/log/installer/syslog

Hope it helps...

Thanks!

Rick
Sep 13 07:15:48 anna-install: Installing os-prober-udeb
Sep 13 07:15:48 os-prober: File descriptor 3 (pipe:[1755]) leaked on lvs 
invocation. Parent PID 15811: log-output
Sep 13 07:15:48 os-prober: File descriptor 4 (/dev/pts/0) leaked on lvs 
invocation. Parent PID 15811: log-output
Sep 13 07:15:48 os-prober: File descriptor 5 (/dev/pts/0) leaked on lvs 
invocation. Parent PID 15811: log-output
Sep 13 07:15:48 os-prober: File descriptor 6 (/dev/pts/0) leaked on lvs 
invocation. Parent PID 15811: log-output
Sep 13 07:15:48 os-prober: debug: running /usr/lib/os-probes/50mounted-tests on 
/dev/sda1
Sep 13 07:15:48 50mounted-tests: debug: mounted using GRUB ext2 filesystem 
driver
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/10freedos
Sep 13 07:15:48 10freedos: debug: /dev/sda1 is not a FAT partition: exiting
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/10qnx
Sep 13 07:15:48 10qnx: debug: /dev/sda1 is not a QNX4 partition: exiting
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/20macosx
Sep 13 07:15:48 macosx-prober: debug: /dev/sda1 is not an HFS+ partition: 
exiting
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/20microsoft
Sep 13 07:15:48 20microsoft: debug: /dev/sda1 is not a MS partition: exiting
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/30utility
Sep 13 07:15:48 30utility: debug: /dev/sda1 is not a FAT partition: exiting
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/40lsb
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/70hurd
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/80minix
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/83haiku
Sep 13 07:15:48 83haiku: debug: /dev/sda1 is not a BeFS partition: exiting
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/90linux-distro
Sep 13 07:15:48 50mounted-tests: debug: running subtest 
/usr/lib/os-probes/mounted/90solaris
Sep 13 07:15:48 finish-install: rmdir: '/var/lib/os-prober/mount': Device or 
resource busy
Sep 13 07:15:48 os-prober: debug: running /usr/lib/os-probes/50mounted-tests on 
/dev/sda2
Sep 13 07:15:48 50mounted-tests: debug: /dev/sda2 type not recognised; skipping
Sep 13 07:15:48 os-prober: debug: os detected by 
/usr/lib/os-probes/50mounted-tests
Sep 13 07:15:48 os-prober: debug: running /usr/lib/os-probes/50mounted-tests on 
/dev/sda5
Sep 13 07:15:48 finish-install: rmdir: '/var/lib/os-prober/mount': Device or 
resource busy
Sep 13 07:15:48 os-prober: debug: /dev/sdb1: part of software raid array
Sep 13 07:15:48 os-prober: debug: /dev/sdc1: part of software raid array
Sep 13 07:15:48 os-prober: debug: running /usr/lib/os-probes/mounted/10freedos 
on mounted /dev/sdd1
Sep 13 07:15:48 10freedos: debug: /dev/sdd1 is not a FAT partition: exiting
Sep 13 07:15:48 os-prober: debug: running /usr/lib/os-probes/mounted/10qnx on 
mounted /dev/sdd1
Sep 13 07:15:48 10qnx: debug: /dev/sdd1 is not a QNX4 partition: exiting
Sep 13 07:15:48 os-prober: debug: running /usr/lib/os-probes/mounted/20macosx 
on mounted /dev/sdd1
Sep 13 07:15:48 macosx-prober: debug: /dev/sdd1 is not an HFS+ partition: 
exiting
Sep 13 07:15:48 os-prober: debug: running 
/usr/lib/os-probes/mounted/20microsoft on mounted /dev/sdd1
Sep 13 07:15:48 20microsoft: debug: /dev/sdd1 is not a MS partition: exiting
Sep 13 07:15:48 os-prober: debug: running /usr/lib/os-probes/mounted/30utility 
on mounted /dev/sdd1
Sep 13 07:15:48 30utility: debug: /dev/sdd1 is not a FAT partition: exiting
Sep 13 07:15:48 os-prober: debug: running /usr/lib/os-probes/mounted/40lsb on 
mounted /dev/sdd1
Sep 13 07:15:48 os-prober: debug: running /usr

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

[Rick Thomas]

On 09/13/12 01:15, Rick Thomas wrote:


The umount: can't umount... error message went away, but the three 'no
such disk' messages remained. And grub install still objected because
there was only one OS...

I've attached the relevant section of /var/log/installer/syslog


It may be worth noting these error messages in syslog:

  Sep 13 07:15:49 os-prober: debug: running 
/usr/lib/os-probes/50mounted-tests on /dev/mapper/monk-root

  Sep 13 07:15:49 finish-install: grub-probe: error: no such disk.
  Sep 13 07:15:49 os-prober: debug: running 
/usr/lib/os-probes/50mounted-tests on /dev/mapper/monk-root2

  Sep 13 07:15:50 finish-install: grub-probe: error: no such disk.

It seems to be claiming that /dev/mapper/monk-root and 
/dev/mapper/monk-root2 don't exist.  Those are the two partitions that 
have the other Linux installed in them -- the two I would have expected 
os-prober to find.


Interestingly, it finds /dev/mapper/monk-home just fine.  One difference 
between the two root partitions and the home partition is that I 
told the partitioner to mount the home partition on /home, but I never 
mentioned the two root partitions at all in the partitioner.


I wonder if I gave them mount points and told the partitioner to mount 
them, would os-prober be able to find them?


Rick


--
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/50519b3c.7050...@pobox.com

Bug#684265: Debian Installer 7.0 Beta2 release bug #684265 -- partial success

[Rick Thomas]

On 09/13/12 01:15, Rick Thomas wrote:



On 09/12/12 23:22, Rick Thomas wrote:


On Sep 12, 2012, at 10:41 PM, 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)?


I'll try the workaround and report back.


Sadly, that didn't solve the problem.


On the amd64 (with LVM) the fuse workaround wasn't enough...

*But*... when I tried it on the PowerPC (Mac G4) machine, where all the 
relevant partitions are real partitions, no LVM stuff involved, the 
workaround (insmod ... fuse.ko) *did* fix the problem.


I wonder if there's another module that's missing on the LVM machine?

Hope this helps!
Rick


--
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/5051bdc1.2010...@pobox.com

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

[Rick Thomas]

On Sep 13, 2012, at 5:49 AM, Milan Kupcevic wrote:


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


We seem to have solved about a third of the problems uncovered in  
investigating this bug:



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.


2) We have not yet identified the ingredient that makes the boot- 
loader installer unable to handle Linux OS root on LVM partitions  
correctly.  I'm willing to pursue the issue thru to its conclusion, if  
someone who knows the installer internals better will guide me.


3) It would be nice if all boot-loader installers were as vigilant as  
the current grub installer.  The grub installer warns the user if it  
finds only one OS partition (the one it's installing for) and asks if  
she wants to go ahead with a process that may have to be re-done after  
the install completes, due to having missed other OS roots.


From my own personal perspective, the one particular boot-loader  
installer I would like this extra vigilant feature for is the  
powerpc yaboot installer.  I would file a wishlist bugreport on this  
issue if I only knew which package to file it against.  Can anyone  
suggest a good candidate?



Thanks!

Rick


--
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/5ace1ff1-0cce-4602-ba71-d3974deea...@pobox.com

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

[Rick Thomas]

On Sep 10, 2012, at 10:16 PM, Christian PERRIER wrote:


Quoting Rick Thomas (rbtho...@pobox.com):


I'll be happy to provide installation log files to anyone who wants
them.

I'd also be happy to look at the relevant code and see if I can
figure out what's wrong, but I don't know where to look.  I don't
have any experience with the insides of the installer.  If somebody
is willing to mentor me a little I might be able to help.



It's likely to be in os-prober.


When I run os-prober on the installed system, I get exactly what I  
expect:


/dev/mapper/monk-root:Debian GNU/Linux (6.0.5):Debian:linux
/dev/mapper/monk-root2:Debian GNU/Linux (wheezy/sid):Debian1:linux

There are three root partitions monk-root, monk-root2, and monk- 
root3.  The last is the active root at the time os-prober was run, so  
I don't expect it to show.  It does find the other two, though.


The PowerPC system that shows the bug is not using LVM.  On that  
machine the extra Linux root partitions are real physical partitions.   
On that machine I also get the expected results from running os-prober  
in the installed system.


So if the problem is in os-prober, it's not in the part of os-prober  
that gets used in the installed system, it must be in the parts that  
are unique to the installation system.


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?


Thanks!

Rick


--
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/ab8a19e3-f995-437d-88dc-c820921d6...@pobox.com

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

[Rick Thomas]

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.


I've attached the installer syslog part from when I ran os-prober  
manually.


Hope this helps!


Rick



os-prober-syslog.out
Description: Binary data

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

[Rick Thomas]

I tried again today.  I installed Sid from the Sid_d-i PowerPC daily 
businesscard. Same problem.


Here's what I installed:

Daily build #1 for powerpc, using installer build from sid
...
This build finished at Wed Aug 10 03:24:48 UTC 2011.
...
debian-testing-powerpc-businesscard.iso   10-Aug-2011 05:23   80M

Using this URL:
http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/arch-latest/powerpc/iso-cd/

Full logs are available upon request...

Rick



--
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/4e4213fa.1070...@pobox.com

Bug#614221: Things that make you go hmmmm....

[Rick Thomas]

Joey Hess said:


Rick Thomas wrote:

Well, in the mean-time, there's no way to test new d-i businesscard
or netinst CDs beyond the disk partition step.  Or, to put it more
bluntly: Testing grinds to a halt until this is fixed.


Use http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/



On Mar 10, 2011, at 2:18 AM, Risto Suominen wrote:


It's probably because of the frame buffer problem that's been
discussed in bug #614221.

As a workaround, try: install video=ofonly.

Risto



Well, installing with that iso and using video=ofonly works a treat.

Rick




--
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/2a456f06-fc04-4968-9476-45bbd587c...@pobox.com

Bug#587290: initramfs-tools: malformed yaboot.conf created when alternate partitions use UUID= in fstab

[Rick Thomas]

On 06/27/10 08:19, Ben Hutchings wrote:

Please send the files /etc/fstab, /etc/yaboot.conf.old and
/etc/yaboot.conf from your system.

Ben.



OK.  Here they are:

/etc/yaboot.conf from the hda6 partition (see note [1])


## yaboot.conf generated by debian-installer
##
## run: man yaboot.conf for details. Do not make changes until you have!!
## see also: /usr/share/doc/yaboot/examples for example configurations.
##
## For a dual-boot menu, add one or more of:
## bsd=/dev/hdaX, macos=/dev/hdaY, macosx=/dev/hdaZ


# boot = /dev/hda2
boot = /dev/disk/by-label/bootstrap

device=/p...@f200/mac...@17/at...@1f000/d...@0:
partition=6

# root = /dev/hda6
root = UUID=88a47bea-8c36-4a09-b418-747e2396feb2

timeout=100
install=/usr/lib/yaboot/yaboot
magicboot=/usr/lib/yaboot/ofboot
enablecdboot

image=/boot/vmlinux
label=Linux
read-only
initrd=/boot/initrd.img

image=/boot/vmlinux.old
label=old
read-only
initrd=/boot/initrd.img.old

# This entry automatically added by the Debian installer for an existing
# Linux installation on /dev/hda4.
image=/p...@f200/mac...@17/at...@1f000/d...@0:4,/boot/vmlinux
label=hda4-Linux
root=/p...@f200/mac...@17/at...@1f000/d...@0:4
append=root=/dev/hda4 ro
initrd=/p...@f200/mac...@17/at...@1f000/d...@0:4,/boot/initrd.img

# This entry added by Rick for an existing
# Linux installation on /dev/hda5.
image=/p...@f200/mac...@17/at...@1f000/d...@0:5,/boot/vmlinux-2.6.27-1.ydl61.5
label=hda5-Linux
read-only
root=/p...@f200/mac...@17/at...@1f000/d...@0:5
append=rhgb quiet root=/dev/hda5

initrd=/p...@f200/mac...@17/at...@1f000/d...@0:5,/boot/initrd-2.6.27-1.ydl61.5.img



/etc/fstab from hda6 [1]


# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# file system   mount point   type  options   
dump  pass
proc  /proc   procdefaults  
0   0
# / was on /dev/hda6 during installation
UUID=88a47bea-8c36-4a09-b418-747e2396feb2 /   ext3
errors=remount-ro 0   1
# /home was on /dev/md127 during installation
# UUID=fa18ea9a-bf45-42c6-9eb5-9d67aa80eeb9 /home ext3defaults  
0   2
/dev/md127/home   ext3defaults  
0   3
# swap was on /dev/hda3 during installation
# /dev/hda3   noneswapsw
0   0
LABEL=SWAP-hda3   noneswapsw
0   0
# /dev/hdc/media/cdrom0   udf,iso9660 
user,noauto   0   0
/dev/cdrom/media/cdrom0   udf,iso9660 
user,noauto   0   0



/etc/fstab from hda4 [2]


# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# file system mount point   type  options   dump  pass
proc/proc   procdefaults0   0
# / was on /dev/hda4 during installation
UUID=2494caa7-fb49-4cbe-81ee-b594788f4d85 /   ext3
errors=remount-ro 0   1
# swap was on /dev/hda3 during installation
UUID=e672ba0d-2c2e-4b03-9e4e-7a71f39c44b9 noneswapsw
  0   0
/dev/hdc/media/cdrom0   udf,iso9660 user,noauto 0   0




/etc/yaboot.conf from hda4 [2]


## yaboot.conf generated by debian-installer
##
## run: man yaboot.conf for details. Do not make changes until you have!!
## see also: /usr/share/doc/yaboot/examples for example configurations.
##
## For a dual-boot menu, add one or more of:
## bsd=/dev/hdaX, macos=/dev/hdaY, macosx=/dev/hdaZ

boot=/dev/hda2
device=/p...@f200/mac...@17/at...@1f000/d...@0:
partition=4
root=/dev/hda4
timeout=100
install=/usr/lib/yaboot/yaboot
magicboot=/usr/lib/yaboot/ofboot
enablecdboot

image=/boot/vmlinux
label=Linux
read-only
initrd=/boot/initrd.img

image=/boot/vmlinux.old
label=old
read-only
initrd=/boot/initrd.img.old

# This entry automatically added by the Debian installer for an existing
# Linux installation on /dev/hda5.
image=/p...@f200/mac...@17/at...@1f000/d...@0:5,/boot/vmlinux-2.6.27-1.ydl61.5
label=hda5-linux
root=/p...@f200/mac...@17/at...@1f000/d...@0:5
append=ro rhgb quiet root=LABEL=/

initrd=/p...@f200/mac...@17/at...@1f000/d...@0:5,/boot/initrd-2.6.27-1.ydl61.5.img

# This entry automatically added by the Debian installer for an existing
# Linux installation on /dev/hda6.

Bug#587290: initramfs-tools: malformed yaboot.conf created when alternate partitions use UUID= in fstab

[Rick Thomas]

Package: initramfs-tools
Version: 0.97
Severity: important


The generated /etc/yaboot.conf contains lines
append=root=UUID ro
for partitions that have their /etc/fstab root line using UUID=...  .

This makes it impossible to boot into those partitions:
  the boot progresses to the point of trying to mount the root
  filesystem and dies with
Begin: Running /scripts/local-premount ... done
Mount: mounting UUID on /root failed: No such directory
  then a few more errors obviously caused by not having a mounted root
  and eventually dropping into the (initrd) BusyBox shell.

When I went back and changed the offending line to
append=root=/dev/hda6 ro
and reran ybin, everything was fine.

See bug # 580455 for another aspect of the switch to UUID naming being
broken on powerPC.



-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 9.8M Jun 26 23:48 /boot/initrd.img-2.6.32-5-powerpc
-rw-r--r-- 1 root root 9.9M Jun 27 00:06 /boot/initrd.img-2.6.32-5-powerpc-smp
-- /proc/cmdline
root=/p...@f200/mac...@17/at...@1f000/d...@0:4 root=/dev/hda4 ro 

-- resume
RESUME=UUID=e672ba0d-2c2e-4b03-9e4e-7a71f39c44b9
-- /proc/filesystems
ext3

-- lsmod
Module  Size  Used by
uinput 10475  2 
loop   16273  0 
firewire_sbp2  16232  0 
snd_aoa_codec_tas  13079  2 
snd_aoa_fabric_layout12091  0 
snd_aoa15620  2 snd_aoa_codec_tas,snd_aoa_fabric_layout
snd_aoa_i2sbus 20933  1 
snd_pcm67233  1 snd_aoa_i2sbus
snd_timer  21510  1 snd_pcm
snd_page_alloc  9053  1 snd_pcm
snd53564  6 
snd_aoa_codec_tas,snd_aoa_fabric_layout,snd_aoa,snd_aoa_i2sbus,snd_pcm,snd_timer
soundcore   8335  1 snd
snd_aoa_soundbus6669  2 snd_aoa_fabric_layout,snd_aoa_i2sbus
evdev  12021  12 
ext3  126551  1 
jbd46110  1 ext3
mbcache 8870  1 ext3
usbhid 40424  0 
hid68369  1 usbhid
raid1  24559  1 
md_mod 89657  1 raid1
ata_generic 5947  0 
libata143752  1 ata_generic
scsi_mod  128326  2 firewire_sbp2,libata
ide_pci_generic 5580  0 
ohci_hcd   35644  0 
firewire_ohci  26292  0 
ehci_hcd   43274  0 
ide_cd_mod 28609  0 
sungem 31621  0 
firewire_core  44766  2 firewire_sbp2,firewire_ohci
cdrom  36707  1 ide_cd_mod
sungem_phy 12982  1 sungem
crc_itu_t   4495  1 firewire_core
usbcore   133556  4 usbhid,ohci_hcd,ehci_hcd
i2c_powermac6651  0 
nls_base8937  1 usbcore
siimage 9538  2 

-- /etc/kernel-img.conf
# Kernel image management overrides
# See kernel-img.conf(5) for details
do_symlinks = yes
do_bootloader = no
do_initrd = yes
link_in_boot = yes

-- /etc/initramfs-tools/initramfs.conf
MODULES=most
BUSYBOX=y
KEYMAP=n
COMPRESS=gzip
BOOT=local
DEVICE=
NFSROOT=auto

-- /etc/initramfs-tools/update-initramfs.conf
update_initramfs=yes
backup_initramfs=no

-- /proc/mdstat
Personalities : [raid1] 
md127 : active (auto-read-only) raid1 hdg2[0] hdi2[1]
  244198464 blocks [2/2] [UU]
  
unused devices: none


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.32-5-powerpc-smp (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages initramfs-tools depends on:
ii  cpio 2.11-4  GNU cpio -- a program to manage ar
ii  findutils4.4.2-1 utilities for finding files--find,
ii  klibc-utils  1.5.18-1small utilities built with klibc f
ii  module-init-tools3.12~pre2-3 tools for managing Linux kernel mo
ii  udev 157-1   /dev/ and hotplug management daemo

Versions of packages initramfs-tools recommends:
ii  busybox   1:1.15.3-1 Tiny utilities for small and embed

Versions of packages initramfs-tools suggests:
ii  bash-completion   1:1.2-2programmable completion for the ba

-- no debconf information



-- 
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/20100627050240.2777.29149.report...@dillserver.rcthomas.org

Re: Removal of cramfs support

[Rick Thomas]

On Dec 5, 2009, at 10:47 AM, Bastian Blank wrote:


Hi folks

I intent to remove the cramfs support from the kernel and the
cramfsprogs package. Current kernels supports squashfs, which is a far
more advanced replacement.

It is currently in use by the debian-installer for mips and the  
powerpc

floppies.

Bastian


Ambiguous pronoun: Which fs is currently in use for mips and powerpc  
floppies? cramfs or squashfs?


If cramfs, won't removing it (cramfs) make those two installation  
modes unusable?


Rick


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#519028: linux-image-powerpc has the same broken dependency...

[Rick Thomas]

This bug prevents an expert mode install from properly installing  
Sid unless you chose a non-default kernel.


Instead of depending on linux-image-2.6.26-2-powerpc, in Sid, it  
should depend on linux-image-2.6.29-1-powerpc, because 2.6.26-2  
doesn't exist in Sid.


The 2.6.26 version may (I haven't checked) exist in squeeze.  But,  
unless you have both sid and squeeze repos in your sources.list, it's  
not available on a Sid system.


Is there some way this sort of thing could be automated?  So that when  
a new latest linux-image package is put in the repository, the  
packages that should depend on it get automatically updated?


Rick



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#369760: Video problems installing etch on oldworld PowerPC Mac (beige G3)

[Rick Thomas]

On Dec 25, 2008, at 5:22 PM, Moritz Muehlenhoff wrote:


On Thu, Jun 01, 2006 at 03:00:47AM -0400, Rick Thomas wrote:

Package: debian-installer
Severity: Important

I've been trying to test install the etch daily netinst CD on an
oldworld Mac (beige G3) and I can't get off first base because I  
can't

get the video to co-operate.

I'm using the BootX bootloader under MacOS-9.2.2

Before I begin describing my problems, let me state that I was  
able to

install sarge using just about any of the available combinations of
video setting in BootX (Force video settings checkbox on or off,  
No
video driver checkbox on or off, and any one of three settings  
for More

kernel arguments: -- video=ofonly, , and
video=atyfb:vmode:17,cmode:8) (Does anybody know what the two video
checkboxes translate into in terms of kernel arguments???)

The problem is that, no matter what I set for video options in BootX,
using the debian-testing-powerpc-netinst.iso CD image from

http://cdimage.debian.org/daily-builds/arch-latest/powerpc/iso_cd/

I get unreadable stuff on the screen during the part that should be
kernel messages and evenutally it hangs.  I never get to the language
chooser screen at all.

In some cases I get tiny unreadable green text which is duplicated
between the left and right halves of the screen, followed by readable
characters in white saying:

Preparing boot params...
Preparing BAT...
pmac_init(): exit
id mach(): done
MMU: enter
MMU: hw init
hash: enter
hash: find piece
hash: done
MMU: mapin
MMU: setio
MMU: exit

then it hangs.

In other cases (in particular with none of the BootX video checkboxes
set and with kernel args set to video=ofonly) I get a seemingly  
random

collection of white dots on a black screen (nothing recognizable as
potential kernel messages) and it hangs.


Is the ATI video driver compiled into the kernel on this CD?


Does this error still occur with more recent kernel versions?

Cheers,
Moritz


Trying it with the RC1 CD, this problem did not occur.

I believe you can close the bug report now.

Thanks!

Rick





--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#375422: Boot failure with kernel 2.6.15 on G4

[Rick Thomas]

Sorry to take so long to get back on this.

I just did an install on this machine, and all went well.  I used the  
Lenny RC1 netinst CD.  Everything worked according to specs.  I was  
even able to install X11 and Gnome at full 1280x1024 resolution --  
it's not blindingly fast, but it works OK.


I think you can close this bugreport.

Enjoy!

Rick
On Nov 27, 2008, at 6:12 PM, Moritz Muehlenhoff wrote:


On Sun, Jun 25, 2006 at 05:50:17PM -0400, Rick Thomas wrote:

Package: debian-installer


I just attempted to install the debian powerpc daily businesscard iso
from June 24 on my OldWorld beige G3 test machine, and got the same
error.

There's been some discussion of a set of patches that prevented  
this but
got dropped from the 2.6.15 kernel.  Is anybody looking at  
retrofitting

them back in?


With regard to http://bugs.debian.org/cgi-bin/bugreport.cgi? 
bug=375422 :


Does this error still occur with the final Etch kernel?

Cheers,
Moritz





--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#499231: updated initramfs-tools now kernel oops during boot sequence - sorta fixed?

[Rick Thomas]

On Sep 18, 2008, at 3:55 AM, maximilian attems wrote:


On Wed, Sep 17, 2008 at 11:54:01PM -0400, Rick Thomas wrote:

Well...

I did another dist-upgrade tonite, and the problem went away.  Go
figure...

Some one of the following list of upgrades (extracted from /var/log/
dpkg.log) fixed it.

2008-09-17 22:57:42 upgrade initramfs-tools 0.92k 0.92l


please post the output of
find /etc/kernel -type f

and if it contains a file the content of that script.

thanks

--
maks



[EMAIL PROTECTED]:~$ find /etc/kernel -type f -print
/etc/kernel/postinst.d/mkvmlinuz
/etc/kernel/postrm.d/mkvmlinuz
[EMAIL PROTECTED]:~$

[EMAIL PROTECTED]:~$ cat /etc/kernel/postrm.d/mkvmlinuz
#!/bin/sh

set -e

. /usr/share/debconf/confmodule

db_get mkvmlinuz/bootloaders
bootloader=$RET

# Let's erase the kernel created by mkvmlinuz too.
if [ $bootloader = mkvmlinuz ]; then
vmlinuz=`echo $2 | sed -e 's/vmlinux/vmlinuz/'`
rm -f $vmlinuz
if [ -e $vmlinuz.old ]; then
mv $vmlinuz.old $vmlinuz
fi
fi
[EMAIL PROTECTED]:~$

[EMAIL PROTECTED]:~$ cat /etc/kernel/postinst.d/mkvmlinuz
#!/bin/sh

set -e

. /usr/share/debconf/confmodule

db_get mkvmlinuz/bootloaders
bootloader=$RET

if [ $bootloader = mkvmlinuz ]; then
/usr/sbin/mkvmlinuz $1 $2
fi
[EMAIL PROTECTED]:~$


Hope this helps!


Rick




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#499231: updated initramfs-tools now kernel oops during boot sequence

[Rick Thomas]

On Sep 17, 2008, at 4:02 AM, Rick Thomas wrote:

I have another system running Sid.  I haven't done a dist-upgrade  
on it yet.  So I'll see what happens there.



I did the dist-upgrade on my other G4 running Sid, and the oops  
doesn't happen.


Looking at the syslog extracts, it seems that the failing machine  
oops-es when it's trying to initialize its Radeon video driver.  The  
machine that doesn't oops has an ATI Rage video card.  The traceback  
also mentions radeon.  So that's probably where the problem lies.


Do others with Radeon cards have this problem?

Here's the relevant part of lspci -v for each of the machines,  
incase it's useful:



:00:10.0 VGA compatible controller: ATI Technologies Inc Radeon  
RV200 QW [Radeon 7500]

Subsystem: ATI Technologies Inc Radeon RV200 QW [Radeon 7500]
Flags: bus master, stepping, 66MHz, medium devsel, latency  
255, IRQ 48

Memory at 9800 (32-bit, prefetchable) [size=128M]
I/O ports at 0400 [size=256]
Memory at 9000 (32-bit, non-prefetchable) [size=64K]
Expansion ROM at f100 [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
Kernel driver in use: radeonfb


:00:10.0 VGA compatible controller: ATI Technologies Inc Rage 128  
PF/PRO AGP 4x TMDS

Flags: bus master, stepping, 66MHz, medium devsel, latency 255, IRQ 48
Memory at 9400 (32-bit, prefetchable) [size=64M]
I/O ports at 0400 [size=256]
Memory at 9000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at f100 [disabled] [size=128K]
Capabilities: [50] AGP version 2.0
Capabilities: [5c] Power Management version 2
Kernel driver in use: aty128fb


Any help will be appreciated...

Rick



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#499231: updated initramfs-tools now kernel oops during boot sequence - sorta fixed?

[Rick Thomas]

Well...

I did another dist-upgrade tonite, and the problem went away.  Go  
figure...


Some one of the following list of upgrades (extracted from /var/log/ 
dpkg.log) fixed it.


2008-09-17 22:57:17 upgrade ncurses-bin 5.6+20080907-1 5.6+20080913-1
2008-09-17 22:57:23 upgrade libncurses5 5.6+20080907-1 5.6+20080913-1
2008-09-17 22:57:27 upgrade libselinux1 2.0.65-4 2.0.65-5
2008-09-17 22:57:32 upgrade libncursesw5 5.6+20080907-1 5.6+20080913-1
2008-09-17 22:57:33 upgrade net-tools 1.60-19 1.60-20
2008-09-17 22:57:33 upgrade exim4-base 4.69-6 4.69-7
2008-09-17 22:57:36 upgrade exim4-daemon-light 4.69-6 4.69-7
2008-09-17 22:57:37 upgrade libidn11 1.9-1 1.10-2
2008-09-17 22:57:37 upgrade fastjar 2:0.95-2 2:0.95-3
2008-09-17 22:57:38 upgrade gparted 0.3.8-1+b1 0.3.9-1
2008-09-17 22:57:40 upgrade htdig 1:3.2.0b6-6 1:3.2.0b6-7
2008-09-17 22:57:42 upgrade initramfs-tools 0.92k 0.92l
2008-09-17 22:57:42 upgrade libcdparanoia0 3.10.0+debian-1 3.10.2 
+debian-1

2008-09-17 22:57:43 upgrade libjack0 0.109.2-3 0.109.2-4
2008-09-17 22:57:43 upgrade libnautilus-extension1 2.20.0-6 2.20.0-7
2008-09-17 22:57:43 upgrade nautilus 2.20.0-6 2.20.0-7


Rick



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#429449: aptitude says kernel-image-2.6-powerpc version 102sarge2 depends on non-existent kernel version

[Rick Thomas]

Package: kernel-image-2.6-powerpc
Version: 102sarge1
Severity: important


aptitude dist-upgrade says:

  The following packages have been kept back:
kernel-image-2.6-powerpc 
  0 packages upgraded, 0 newly installed, 0 to remove and 1 not
  upgraded.
  Need to get 0B of archives. After unpacking 0B will be used.

Further investigation shows that the current version of kernel-image-2.6-powerpc
is 102sarge2 which depends on kernel-image-2.6-4-powerpc which is
unsatisfied. 

Any idea why?

my sources.list is included below...


*** /etc/apt/sources.list
# deb file:///cdrom/ sarge main 
# deb http://debian.rutgers.edu/ sarge main 

# deb http://debian.rutgers.edu/ sarge main non-free contrib 
# deb-src http://debian.rutgers.edu/ sarge main non-free contrib 

deb http://security.debian.org/ sarge/updates main non-free contrib 

deb http://ike.egr.msu.edu/debian/ sarge main non-free contrib 

# deb http://ftp.us.debian.org/debian/ sarge main non-free contrib 

## # ftp.us.debian.org
## deb http://mirrors1.kernel.org/debian/ sarge main non-free contrib 
## deb-src http://mirrors1.kernel.org/debian/ sarge main non-free contrib 

# deb http://archive.progeny.com/debian/ sarge main non-free contrib 
# deb-src http://archive.progeny.com/debian/ sarge main non-free contrib 

deb http://debian.lcs.mit.edu/debian/ sarge main non-free contrib
deb-src http://debian.lcs.mit.edu/debian/ sarge main non-free contrib

deb http://volatile.debian.net/debian-volatile sarge/volatile main contrib 
non-free

# For instructions on getting stuff from backports see
#   http://www.backports.org/dokuwiki/doku.php?id=instructions
deb http://www.backports.org/debian sarge-backports main contrib non-free


-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.8-3-powerpc
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages kernel-image-2.6-powerpc depends on:
ii  kernel-image-2.6.8-3-powe 2.6.8-12sarge6 Linux kernel image for 2.6.8-3-pow

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#410845: [powerpc] The PCILynx firewire driver is broken on PPC machines, and should be disabled.

[Rick Thomas]

Package: linux-2.6

When I boot Debian (Etch or Sarge)  on my BlueWhite PowerMac, with  
the old TI PCILynx firewire chip on the motherboard, the pcilynx  
driver crashes consistently.  If I blacklist pcilynx, the crash goes  
away, but I have no firewire capability.




https://lists.sourceforge.net/lists/listinfo/linux1394-devel


Looking at the archives of the Linux1394 developers mailinglist, it  
appears that pcilynx on PPC hardware has been horribly broken for a  
long time (at least since 2004).  Furthermore, it looks like support  
for pcilynx may be dropped entirely from the next generation of  
ieee1394 drivers, regardless of CPU type.


I'd like to suggest that pcilynx be disabled in the Debian PPC  
kernels, and a note to that effect be put in the release documents,  
encouraging users who need firewire to avail themselves of one of the  
cheap OHCI1394 cards.


Rick


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#369760: Similar symptoms using miboot ofonlyboot floppy

[Rick Thomas]

Interestingly enough, I get similar results when booting from the  
miboot ofonlyboot floppy.


Even more interesting, when I use the miboot boot floppy the video  
is slightly strange (some columns flicker) but usable for installation.


Rick



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]