Bug#279370: does not boot: 'CLAIM FAILED' error on IBM 7043-260.
Hi, Alessandro Amici writes: Severity: important [...] nice black magic trick: Well, I'm not sure if a bit of editing the kernel binary qualifies as major effect on the usability or black magic, but anyway. As long as you don't make it RC. - with an hexeditor look for the values '00 0c 00 00' and '00 00 40 00' You mean '00 c0 00 00'. Both values are coming into the compressed kernel from the note file, which is created by mknote, which is built from arch/ppc/boot/utils/mknote.c, which is shipped with the upstream kernel source and has these values hardcoded. in the first few bytes of the vmlinuz.initrd file and change both them of them to 'ff ff ff ff'. We could add a patch that hardcodes these values instead, meaning real-base and load-base will be unspecified in the kernel, just like all the other OF variables. This affects CHRP only, since it is the only subarch that uses the note in the first place, so it would be great to hear people who actually have the hardware... leighbb knows more than me ... like Leigh and Sven. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#279491: No disk detected on an IBM RS6000 7043-260 (sym53c8xx driver)
reassign 279370 kernel-patch-powerpc-2.6.8 reassign 279491 kernel-patch-powerpc-2.6.8 thanks Hi, Alessandro Amici writes: - the SCSI driver (sym53c8xx) Which chip exactly? [...] it looks like an irq problem, the fact that the d-i uses a 32bit kernel on a 64bit can well be to be the trigger, A similar problem was fixed for PReP systems a while ago. Before that, I worked around it by setting CONFIG_SCSI_SYM53C8XX_IOMAPPED. so i am currently trying to re-compile the debian kernel without the drivers-scsi-sym53c8xx_revert.dpatch.bz2 patch and/or try a ppc64 cross-build. but tha machine is not easily reachable and i need to integrate the kernel in the d-i enviroment (not easy for me!) If you are recompiling the Debian kernel, you only need to exchange the sym53c8xx driver itself. This can even be done on the fly, if you manage to get a shell from d-i (for example by starting in expert mode). Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#279491: No disk detected on an IBM RS6000 7043-260 (sym53c8xx driver)
Hi, Alessandro Amici writes: you have only a few seconds between the unpacking of scsi-modules udeb and the fatal modprobe. If you run the installation in expert mode (by passing the parameter DEBCONF_PRIORITY=low at the kernel command line) you should be able to avoid this. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#278957: kernel-image-2.6.8-9-amd64-k8-smp: Driver aic79xx for Adaptec AIC-7902B U320 SCSI controller fails to load
tags 278957 +pending thanks Hi, Frederik Schueler writes: I just uploaded the i386 kernel packages to http://users.idf.de/~fs/debian-kernel/i386/ I tried those, and my problem is indeed fixed. Thanks a bunch, please consider uploading to unstable asap. I'm setting the appropriate tag on this bug report. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#275246: kernel-image-2.6.7-powerpc: Oops starting hald
Hi, Andrea Bedini writes: Package: kernel-image-2.6.7-powerpc Version: 2.6.7-5 Severity: normal this is the oops. it happens at boot when hald starts. Could you please do three things to provide more information: 1. Try the latest revision of kernel-image-2.6.8-powerpc and see whether the bug persists. 2. Disable hal and see what happens. 3. Run the oops through ksymoops. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#274939: How can editing a binary kernel be suggested?
Hi, How can this be suggested on an official packaged kernel? Because the only alternative is to recompile. Asking an end user to binary-edit a kernel is mindless, from my point of view. The most likely explanation for this point of view of yours is that you don't really know what you're talking about. I'd be happy to help you change this, please tell me where to start. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#273673: please enable CONFIG_SCSI_MULTI_LUN
tags 273673 +pending thanks Hi, Maks Attems writes: ppc is build without CONFIG_SCSI_MULTI_LUN that makes a lot of card readers not available for ppc folks. it's enabled on i386, amd, ia64 and even alpha. Thanks for pointing this out. Will go into the next upload. hch I think we even agreed to kill the config option in mainline IRC is next door ;) Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Bug#271310: eth0 not identified
Hi, Joshua Kwan writes: I fear that using NEWS.Debian won't be obvious enough. You may be right, given my experience with the NEWS.Debian file in the PowerPC kernel-image packages. Then again, nobody knows how many people read that file, paused to think, upgraded without major problems and therefore never showed up in the BTS and on the mailing lists. I have no idea how to integrate [a debconf note] into the kernel image package. In order to display a debconf note, you have to replace the postinst from kernel-package with our own version. The debian/rules file of kernel-patch-powerpc shows how this can be done: After building a dummy kernel-image package with make-kpkg, we unpack its contents with 'dpkg -x' and its control structure with 'dpkg -e'. Everything can then be mangled to our hearts' delight, and finally be re-packaged into the kernel-image package we actually ship. But. The more we change the official kernel-image packages after they are created by kernel-package, the bigger the divide between official and user-generated kernel-image packages becomes. This is a bad thing in itself, so changing the scripts included with kernel-package seems like a better way of doing it. But this is obviously for post-sarge. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
CONFIG_SCSI_SYM53C8XX_IOMAPPED
Hi, I recently encountered a machine (a Thinkpad 860) with a NCR 53C810 SCSI controller that would not work properly unless the config option CONFIG_SCSI_SYM53C8XX_IOMAPPED was set. Under these circumstances, installation was a royal pain in the ass, and therefore, I am inclined to trade performance for wider support and enable this in the PowerPC kernel image packages. Any comments? Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: CONFIG_SCSI_SYM53C8XX_IOMAPPED
Hi, Matthew Wilcox writes: It outputs a can't map PCI MMIO region and does nothing at all. Interesting. This can only happen if ioremap() returns NULL. Sorry. I got the message completely wrong. I really was: | PCI: Enabling device :00:0c.0 ( - 0003) | sym.0.12.0: MMIO base address disabled. lspci -v of that device would be interesting to see. | :00:0c.0 SCSI storage controller: LSI Logic / Symbios Logic 53c810 (rev 02) | Flags: bus master, medium devsel, latency 128, IRQ 13 | I/O ports at 1000 [size=256] | [virtual] Memory at c000 (32-bit, non-prefetchable) [size=256] CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 # CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set Those are good config options. So I used them for a test kernel, built from kernel-source-2.6.8 and your little debugging patch applied. What happened is this: | map 0xc400 length 128 returned 0xf400 and the kernel initialized the SCSI controller correctly - as I could verify, this is due to the backported patch from 2.6.9-rc2 that Hollis Blanchard sent here earlier in Bug#271852. So that problem will be solved in the next revision. Thanks for your time and help. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: CONFIG_SCSI_SYM53C8XX_IOMAPPED
Hi, Matthew Wilcox writes: Urm. I don't understand. You said that you encountered the problem in a Thinkpad 860, but bug 271852 refers to a powerpc-specific problem. That's exactly what the Thinkpad 8xx series are - RS/6000 systems with PowerPC 603e processors. See: korgan:~# cat /proc/cpuinfo processor : 0 cpu : 603ev clock : 166MHz revision: 2.0 (pvr 0007 0200) bogomips: 110.33 machine : PReP IBM Thinkpad 850/860 upgrade cpu : not present scsi fuse : ok simms : 0:32MiB l2 cache: 256KiB look-aside direct-mapped write-back 60x bus : 66MHz pci bus : 33MHz Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270630: kernel-image-2.6.8-powerpc: iBook keyboard generates bad keyboard scancode for Menu key
Hi, Frank Murphy writes: I imagine there aren't many ADB keyboards that have a Menu key. :) It can be quite surprising to see the variety of ADB hardware out there. I tried sending this upstream, but it seems there's a problem with the list. Thanks for the patch. Did you try sending it to linuxppc-dev or to linux-kernel? Can you try again? Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: keyboard problems with 2.6.8-5
Hi, Peter Spuhler writes: Wondering if anyone besides myself has had their usb keyboard stop working or working very sluggishly after upgrading to 2.6.8-5 powerpc-smp ? I can't figure out why this is happening, but it affects the console and X. USB trackball is working fine BTW. The previous iteration of 2.6.8 didn't have this issue. I haven't. What is more, I haven't noticed any changes in the kernel-source that could possibly have affected USB. I'm cc'ing and redirecting this to debian-kernel, maybe someone there has an insight. I also noticed that for some odd reason my X is running on console F2 instead of the normal console F7, not sure that this would have anything to do with the first problem or why this is the case. Your display manager is probably starting the Xserver without explicitly putting it on a specific virtual console. The Xserver then grabs the first virtual console it finds unoccupied, and this may be one of the first six if for some reason the gettys are starting very slowly. You can prevent this by starting the Xserver with the option vt7; here, /etc/X11/wdm/Xservers contains the line :0 local /usr/bin/X11/X :0 vt7 -nolisten tcp Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Any progress on the root filesystem thing?
Hi, any further information on bugs 270321 and 270326? I installed two PReP systems in the last few days, and put the root filesystem on /dev/sda3. After that, both booting with root=/dev/sda3 and with no root option at all worked. Therefore, I am inclined to change the option from sda2 to sda3 (leaving *something* in so it is easy to set /dev/ram0 for the installer, or something different altogether) and close both bug reports. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#271852: kernel-image-2.6.8-powerpc: VGA console broken on PReP
Hi, Thanks for the patch. If nobody objects, I will check it into kernel-source and enable the VGA console in kernel-patch-powerpc, so the problem should be fixed in the next build. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#271541: kernel-image-2.6.8-powerpc: USB/Ethernet support not enabled? Modules package?
Hi, Francis Reyes writes: Package: kernel-image-2.6.8-powerpc Version: 2.6.8-4 Severity: normal I just installed kernel-image-2.6.8-powerpc as well as added the initrd.img to my yaboot, but upon booting no devices such as ethernet/usb are installed? The drivers for those devices are all built as modules in the 2.6 packages. You need to make sure they are loaded - either by loading them manually with modprobe, naming them explicitly in /etc/modules so they are always loaded at boot, or installing an agent such as hotplug or discover that will detect most of the hardware for you. The last method is the recommended one, and installing both packages doesn't hurt either. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#271088: Please enable IKCONFIG
Hi, Michel Dänzer writes: Does this really make the difference between fitting on a miBoot floppy or not? The floppy I created yesterday has about 30k free. The compressed config would take about 10k, i.e. a substantial amount of it. PS: Next time please make sure the submitter gets the mail closing the bug, e.g. by sending it to -done. Sorry. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#256073: kernel-image-2.6.7-powerpc: kernel is too big to fit on a miboot floppy)
close 256073 thanks Hi, Sven Luther writes: That said, i believe that nobody really looked into miboot since ages, so ... In any case, I managed to build a working miBoot floppy from the miBoot.img included with BootX_1.2.2.sit, and successfully started the latest kernel vmlinux-2.6.8-powerpc on a beige G3 and a 7200/90. The necessary zImage was created with a fixed version of mkvmlinuz that has just been uploaded. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#271088: Please enable IKCONFIG
close 271088 thanks Hi, Sven Luther writes: Since the config is with the kernel in the package, there should be no doubt really. Also, as said, the aim was to fit the kernel on a miboot floppy, so any space gained is precious. Precisely. I am backing out your change in svn again. Especially since I managed to build a working miBoot floppy this afternoon from vmlinux-2.6.8-powerpc, miBoot.img included in BootX_1.2.2.sit, and mkvmlinuz-10. I am now closing this bug. If anybody feels it should stay open, reopen it and add a wontfix tag. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#271088: Please enable IKCONFIG
Hi, Michel Dänzer writes: How about /boot/config-2.6.7-powerpc? Doesn't help when the kernel has been upgraded since booted. Leaving the kernel running for an extended period of time after an upgrade is not recommended for a number of reasons, and in fact the kernel-image postinst script spews out a big fat warning containing some of them. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#256073: kernel-image-2.6.7-powerpc: kernel is too big to fit on a miboot floppy)
reassign 256073 kernel-patch-powerpc-2.6.8 thanks Hi, Sven Luther writes: Jens, can you let this open Sure. I thought this had been fixed for good. until we found out why miboot doesn't like objcopy -O binary, not using the miboot.image target ? So this is really a mkvmlinuz bug? And, since mkvmlinuz copies the output from the kernel Makefiles line by line, it also affects upstream? Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#256073: kernel-image-2.6.7-powerpc: kernel is too big to fit on a miboot floppy)
Hi, Sven Luther writes: miboot [...] is not yet in debian, and needs OS 9 and some older codewarrior version, How old? Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#256818: Bug #256818: pbbuttonsd: Kernel 2.6.7 oops when suspending
Hi, I have found, thanks to Warren A. Layton (zeevon at debian dot org) from the debian-powerpc list, the solution of the problem. The kernel config parameter CONFIG_SERIAL_PMACZILOG has to be deselected. It seems it's a bug from the kernel which is not yet solved as of 2.6.7. Can you please check whether the bug persists in the latest revision 2.6.8-4 of the PowerPC kernel-image packages? Thanks and best regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#256073: kernel-image-2.6.7-powerpc: kernel is too big to fit on a miboot floppy
close 256073 thanks Hi, $ mkvmlinuz -a miboot -k boot/vmlinux-2.6.8-powerpc -d usr/lib/kernel-image-2.6.8-powerpc -a miboot -o vmlinuz $ ls -o vmlinuz -rw-r--r-- 1 jens 1250126 Sep 10 10:52 vmlinuz Nuff said. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#256071: kernel-image should work out of the box on CHRP
reassign 256071 kernel-package severity 256071 wishlist thanks Hi, in a nutshell, the bug submitter wants something along the lines of 'apt-get install kernel-image-powerpc reboot' to work on the CHRP subarchitecture. Since this must be done in the postinst, and the postinst should be the one created by make-kpkg, I am reassigning this bug. If I understand the current situation correctly, some manual interaction is required to create a bootable kernel and get it in place; this is a minor inconvenience and therefore I am adjusting the severity. I'm not sure whether this bug has been fixed already. If this is the case, please close it. If not, I will look into this again when I have both time and hardware. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270321: kernel-image-2.6.8-powerpc: PReP boot failure
Hi, Hollis Blanchard writes: pivot_root: No sKernel panic: Attempted to kill init! uch file or dire ctory /sbin/ini0Rebooting in 180 seconds..t: 426: cannot open dev/console: No such file What kernel command line did you use? Try passing a root option there, set to wherever you keep your root file system. This should do the trick. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270743: radeonfb cannot detect display panel size and breaks
Hi, Nikolaus Schulz writes: I'm not sure if I understand you correctly: file a bug against the xserver because it requires the kernel's radeonfb? Precisely. This is not supposed to happen (for instance, the nv driver for nVidia cards works just fine regardless of the underlying framebuffer), and should be reported even though the bug report itself won't achieve much. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270743: radeonfb cannot detect display panel size and breaks
tags 270743 +unreproducible tags 270743 +patch thanks Hi, Nikolaus Schulz writes: booting kernel 2.6.8 on my iBook 2.2 with a Radeon Mobility M7, the radeonfb driver fails to detect the display panel size, resulting in a blank screen. This is very strange, since the Mobility M7 in the iBook is supposed to work perfectly. Can you rule out hardware issues? Did you by any chance run that little hack that enables true dual-head in Mac OS and Mac OS X? AFAIK radeonfb is required to run X on the iBook, right? Unfortunately, yes. You could file a bug report against the Xserver about this and contact upstream as well. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270326: kernel-image-2.6.8-powerpc: bad commandline default: root=/dev/sda2
Hi, Sven Luther writes: Jens, i would greatly appreciate if you could investigate a bit (and explain) what is going on on that box of yours, What is going on is quite simple. If I omit the root option from the kernel command line, the system panics. If I set the option correctly (/dev/sda2 for the installed system, /dev/ram0 for d-i), everything works fine. Why this is happening is beyond my comprehension. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270326: kernel-image-2.6.8-powerpc: bad commandline default: root=/dev/sda2
Hi,
Sven Luther writes:
Can you provide a full serial log output ?
Sure. It's attached.
Is the panic in question one happening because it doesn't find the
initrd, or something else ?
It doesn't find the root filesystem if I omit the root option from the
kernel command line.
How do you boot, and with what ? Where do you create the initrd ? On
the same box or somewhere else ? what is the size of the initrd ?
Could you try setting the initrd options to MODULES=most or
something such ?
I don't believe any of this is related to the problem. Anyway. The
setup is exactly the same that Hollis described in his original
report. The only thing I do manually after installing a new kernel
image package is to dd the vmlinuz file onto the PReP boot partition.
Yeah, but let's find out why this happens.
Please keep in mind that *my* PReP system is running fine now, after
numerous bugs that I reported have been fixed. I'd rather just set
that root option, the ideal way being the bootargs patch, and then
move on to more worthwhile things.
Such as getting my recently acquired R50 and the Thinkpad 860 running :)
Regards, Jens.
loaded at: 00480410 0079F004
relocated to: 0080 00B1EBF4
zimage at: 00805A3C 0093743B
initrd at: 00938000 00B142FF
avail ram: 0040 0080
Linux/PPC load: console=ttyS0 root=/dev/sda2
Uncompressing Linux...done.
Now booting the kernel
Total memory = 64MB; using 128kB for hash table (at c02e)
Linux version 2.6.8-powerpc ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian
1:3.3.4-9)) #1 Fri Aug 27 18:02:26 CEST 2004
PReP architecture
IBM planar ID: 00f5
Built 1 zonelists
Kernel command line: console=ttyS0
PID hash table entries: 512 (order 9: 4096 bytes)
time_init: decrementer frequency = 16.66 MHz
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 59824k available (1720k kernel code, 1056k data, 164k init, 0k highmem)
Calibrating delay loop... 331.77 BogoMIPS
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1904k freed
NET: Registered protocol family 16
PCI: Probing PCI hardware
NCR 53c810 rev 1 detected, setting PCI class.
Setting PCI interrupts for a IBM 7248, PowerSeries 830/850 (Carolina)
PCI: Cannot allocate resource region 0 of device :00:0c.0
PCI: Cannot allocate resource region 0 of device :00:10.0
PCI: Cannot allocate resource region 0 of device :00:16.0
Thermal assist unit not available
audit: initializing netlink socket (disabled)
audit(1094627149.008:0): initialized
devfs: 2004-01-31 Richard Gooch ([EMAIL PROTECTED])
devfs: boot_options: 0x0
Initializing Cryptographic API
Generic RTC Driver v1.07
Macintosh non-volatile memory driver v1.1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
pmac_zilog: 0.6 (Benjamin Herrenschmidt [EMAIL PROTECTED])
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
input: Macintosh mouse button emulation
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
RAMDISK: Compressed image found at block 0
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 164k init 60k pmac 4k chrp 8k openfirmware
initrd-tools: 0.1.73
NET: Registered protocol family 1
SCSI subsystem initialized
PCI: Enabling device :00:10.0 ( - 0003)
sym0: 810 rev 0x1 at pci :00:10.0 irq 15
sym0: No NVRAM, ID 7, Fast-10, SE, parity checking
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18j
Using anticipatory io scheduler
Vendor: IBM Model: CDRM00203 !K Rev: BZ26
Type: CD-ROM ANSI SCSI revision: 02
scsi(0:0:3:0): Beginning Domain Validation
sym0:3: FAST-10 SCSI 5.0 MB/s ST (200.0 ns, offset 8)
scsi(0:0:3:0): Domain Validation skipping write tests
scsi(0:0:3:0): Ending Domain Validation
sym0:6: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 8)
Vendor: IBM Model: DFHSS2F !d Rev: 1717
Type: Direct-Access ANSI SCSI revision: 02
sym0:6:0: tagged command queuing enabled, command queue depth 16.
scsi(0:0:6:0): Beginning Domain Validation
sym0:6: asynchronous.
sym0:6: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 8)
scsi(0:0:6:0): Domain Validation skipping write tests
scsi(0:0:6:0): Ending Domain Validation
SCSI device sda: 4404489 512-byte hdwr sectors (2255 MB)
SCSI device sda: drive cache:
Bug#270326: kernel-image-2.6.8-powerpc: bad commandline default: root=/dev/sda2
Hi, Sven Luther writes: Can you check with giving the root device explicitly with : -r root when creating the initrd ? Same thing. This is because the -r flag is only used for figuring out the necessary modules. Also, if the same problems happens in d-i when you don't specifify root=/dev/ram0, and you don't have root=/dev/sda2 as default command line, then it is also a bug in d-i. #268986, to be precise. Yeah, and you probably broke all other boxes out there who don't mirror *your* PReP box setup, I like to think of it as having fixed all PReP boxen that do have the root filesystem on the second partition of the first SCSI disk. As well as having provided a clue to unsuspecting users what that prompt is for in the first place. not to speak the unexplored repercussion on pmac/chrp boxes, now that i have fixed the chrp default command line handling. Then maybe you should back out your patch and explore its implications. The right thing is to fix mkinitrd and not to break everyones capacity of booting without root= argument. AFAICT, this capacity wasn't there in the first place. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Don't fix it if it ain't broken (was: Bug#270326: kernel-image-2.6.8-powerpc: bad commandline default: root=/dev/sda2)
Hi, Sven Luther writes: Well, no, why ? The patch is a correct fix, which makes the default command line work, do you seriously think it is better to have a broken default commandline on chrp/pmac, I know for sure that the default command line is not needed for PowerMacs, as one can use a bootloader or Open Firmware to set the command line. I suspect that it's not needed for CHRP machines either. As things stand, your patch is unnecessary at best. I'm taking this off the bug report, because it's in no way related to the submitter's problem. Also, I'm setting a fitting subject. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Don't fix it if it ain't broken
Hi, Sven Luther writes: Yeah, well, it may be needed in a self compiled kernel from the kernel-source-2.6.8, where the user like to set it, don't you think ? In fact, I don't. So, you advocate shipping a broken command line support on chrp/pmac because you are too lazy or uninterested to pursue the proper fix to your prep issue. I have stated quite clearly what I advocate. Also, I have - several times, in fact - asked for help with forward porting the assembler chunks of the bootargs patch [1], which is all that is missing for that proper fix. Until I get a response, or find the time to dig it myself, I'll just let the issue rest. Regards, Jens. [1] URL:http://www.solinno.co.uk/7043-140/files/2.4.22/010-boot-args.diff -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Don't fix it if it ain't broken
Hi, Sven Luther writes: Yeah, i personally feel that the bootargs patch may not be the best solution though, and that a recompilation of the incriminated object file in mkvmlinuz, I already told you this is not acceptable because it requires at least a complete toolchain on every system, and the kernel headers into the bargain. or an elf manipulation of it maybe, This is exactly what preptool does, and the bootargs patch makes sure it is done safely. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270326: kernel-image-2.6.8-powerpc: bad commandline default: root=/dev/sda2
Hi, Hollis Blanchard writes: perl -pi -e s+/dev/sda2+/dev/foo7+ vmlinuz Sounds like that perl command being run by mkvmlinuz, supplying the current partition mounted on / . That shouldn't be too hard right? As I said, it would be nicer to forward port the bootargs patch by Leigh Brown. Do you happen to know PowerPC assembler? But I'll try to cook up something. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270326: kernel-image-2.6.8-powerpc: bad commandline default: root=/dev/sda2
Hi, Sven Luther writes: if the kernel is able to figure out the correct root device, AFAICT, it isn't. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270321: kernel-image-2.6.8-powerpc: PReP boot failure
Hi, Hollis Blanchard writes: Does this mean the ramdisk is bad? Could well be. You can check its contents with 'fsck.cramfs -v /initrd.img'. Any way I can get some debug output from it? On the serial console? Put console=ttyS0 last in the kernel command line. Then /dev/console will point to the serial console, and you will get all console output, not only the kernel messages. This machine has 64M of RAM, perhaps that's relevent... how much memory does your 43P-100 have? Dunno, but I'll look it up the next time I boot her. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270321: kernel-image-2.6.8-powerpc: PReP boot failure
Hi, Hollis Blanchard writes: Steps to reproduce: 1. install kernel-image-2.6.8-powerpc 2. run mkvmlinuz with do_initrd = Yes in kernel-img.cnf 3. boot the resulting vmlinuz-2.6.8-powerpc on PReP [...] Setting PCI interrupts for a IBM 7248, PowerSeries 830/850 (Carolina) [...] Kernel panic: Attempted to kill init! 0Rebooting in 180 Strange. I also have a Carolina (a 43P-100, to be precise), and it works very well with the exact same setup. Can you try a non-initrd kernel built from Debian sources? Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#270321: kernel-image-2.6.8-powerpc: PReP boot failure
Hi, Hollis Blanchard writes: Can you try a non-initrd kernel built from Debian sources? Kernel panic: VFS: Unable to mount root fs on unknown-block(3,3) 0Rebooting in 180 seconds.. It's missing some drivers that I assume would be present on the initrd... This is bound to happen if you just run the Debian kernel without an initrd. I probably wasn't clear. What I meant is, can you install kernel-source-2.6.8, configure all drivers needed for bringing up your root filesystem into the kernel, build that kernel, and boot it. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Revision 2.6.8-3 of kernel-source-2.6.8 won't build
Hi, It seems that the above-mentioned revision of kernel-source, which is currently in incoming, won't build at all (see below). Unless I'm completely mistaken, the missing values should be 0x8f for VERIFY_16 and 0x5d for GPCMD_SEND_CUE_SHEET, is it safe to just slam them into include/scsi/scsi.h? Regards, Jens. $ make EXTRAVERSION=-power3 ARCH=ppc vmlinux make[1]: `arch/ppc/kernel/asm-offsets.s' is up to date. CHK include/linux/compile.h CC drivers/block/scsi_ioctl.o drivers/block/scsi_ioctl.c: In function `verify_command': drivers/block/scsi_ioctl.c: In function `verify_command': drivers/block/scsi_ioctl.c:131: error: `VERIFY_16' undeclared (first use in this function) drivers/block/scsi_ioctl.c:131: error: (Each undeclared identifier is reported only once drivers/block/scsi_ioctl.c:131: error: for each function it appears in.) drivers/block/scsi_ioctl.c:181: error: `GPCMD_SEND_CUE_SHEET' undeclared (first use in this function) drivers/block/scsi_ioctl.c:181: error: (Each undeclared identifier is reported only once drivers/block/scsi_ioctl.c:181: error: for each function it appears in.) drivers/block/scsi_ioctl.c:181: error: nonconstant array index in initializer drivers/block/scsi_ioctl.c:181: error: (near initialization for `cmd_type') make[2]: *** [drivers/block/scsi_ioctl.o] Error 1 make[1]: *** [drivers/block] Error 2 make: *** [drivers] Error 2 -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-image 2.4 i386 update
Hi, Horms writes: I would like to upload kernel-latest-2.4-i386 to d.o shortly. If there are any objections now would be a most excellent time to make them. I still think the meta packages should be created by the current source package, and sent a message with my main two points of concern. If you feel they are outweighed by the benefits of the separate package, go ahead. That said, I am comfortable with a single package for all architectures if that is what other people want. For the time being, I'd rather keep the powerpc meta packages in kernel-patch-powerpc. The main issue being that there is just *one* list of flavours now, namely debian/flavours, while a separate source package for meta packages would require an identical copy - come to think of it, that's a third synchronization issue. Anyway, the package has a debian/control generator at the end of debian/rules that makes it very easy to change the entries for all flavours in an identical way (by changing debian/control.stub or debian/control-image.m4 and running the command debian/rules debian/control). Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-image 2.4 i386 update
Hi, Sven Luther writes: BTW, I believe that the only reason this works for you is because you don't make uploads of older packages. The meta packages are right now provided by both 2.6.7-5 and 2.6.8-1, and the latest are being used because they where uploaded last. If you reuploaded a 2.6.7-6 kernel, it would be those holding the metapackage. Then the meta packages must be removed before the 2.7.6-6 upload. Shall I check this in before we forget? This is also a synchronization issue Not really, because the packages will never make it into the archive in the first place. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-package Help
Hi, Sven Luther writes: The solution to this is to create a kernel-image-meta or whatever source package, which provides the kernel-image-arch and the kernel-image-arch-2.[46] packages. A separate source package raises synchronization issues. So those meta packages should just be removed from older kernel-image source packages. This would be fully independent from the real kernel-image packages, and hold the default kernels per arch for both 2.4 and 2.6 and general. Do you mean depend on when you say hold above? Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-package Help
Hi, Horms writes: A separate source package raises synchronization issues. So those meta packages should just be removed from older kernel-image source packages. Could you elaborate on what synchronisation issues you forsee? The two scenarios that spring to my mind immediately are: The processing delay of an updated real package in the new queue leads to the corresponding meta package being uninstallable. This can be minimised with careful fine-tuning of the upload of the meta package, but cannot be avoided at all. Forgetting to update the meta package leads to the user being stuck with an old revision of the real package. This can be avoided, but will happen according to Murphy's Law. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#259354: kernel-image-2.6.7-powerpc: falls into coma when trying to sleep (powerbook)
tags 259354 +upstream thanks Hi, Bernhard Reiter writes: However blacklisting does not seem to be the best solution as I need the USB ports. Of course not. Removing the module should not be necessary at all, it is just a kludge until the bug is properly fixed. This bug is not there with kernel-image-2.6.6-powerpc, so maybe it is an upstream bug? Definitely. I already reported it, but didn't set the tag for some reason. Can you please try again with 2.6.8-1 and see if the bug has gone away? Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-patch-debian-2.6.8 and pristine linux 2.6.8 kernel
Hi, Shaul Karl writes: The description of kernel-patch-debian-2.6.8 claims that they should be applied to a pristine linux 2.6.8 kernel. Yet I get: No version.Debian file, assuming pristine Linux 2.6.8 Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] 2 out of 2 hunks ignored -- saving rejects to file fs/nfs/file.c.rej What am I missing? That particular reject is part of the upstream patch-2.6.8.1 as well. You are probably using 2.6.8.1 instead of 2.6.8. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#267391: Does not apply against kernel-source-2.4.26 2.4.26-6
Package: kernel-patch-powerpc-2.4.26 Version: 2.4.26-1 Severity: important Hi, subject says it all. More precisely: $ /usr/src/kernel-patches/powerpc/debian-powerpc.diff.gz gunzip | patch -p1 -f -s --dry-run 1 out of 2 hunks FAILED -- saving rejects to file arch/ppc/platforms/Makefile.rej Patch attempted to create file drivers/scsi/ata_piix.c, which already exists. 1 out of 1 hunk FAILED -- saving rejects to file drivers/scsi/ata_piix.c.rej What's more, the build of the official kernel-image packages just rolls over these errors. I haven't investigated what this actually means for the resulting kernels, though. Regards, Jens. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.7-sleipnir Locale: LANG=C, LC_CTYPE=C -- no debconf information -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-patch-debian-2.6.8 and pristine linux 2.6.8 kernel
Hi, Christoph Hellwig writes: Talk to the firmware-removal zealots. Talk to whoever went and just shuffled the tg3 related code in prune-non-free around instead of activating it properly. Because just like in 2.6.7, readd-tg3.dpatch is the only firmware related patch that fails against vanilla. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: New kernel-source-2.6.7 upload ?
Hi, Goswin von Brederlow writes: I don't see where such a strict Depends would reduce usefullness. Now, users of kernel-tree have to download the upstream source once per upstream release and the Debian patch once per Debian revision. With a versioned dependency of kernel-tree on kernel-source, they would have to download the upstream source for every Debian revision. So this gains nothing over just installing kernel-source in the first place, and kernel-tree and kernel-patch-debian could be dropped altogether. People who install kernel-tree-2.6 should be prepared for lots of downloads of new debian patches and new upstream sources. Think security updates. Think users who get CDs and update over slow lines. Think people who pay for their traffic per volume. The sizes of kernel-source and kernel-patch-debian differ by two orders of magnitude, so keeping the existing kernel-tree in good shape is well worth it. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: New kernel-source-2.6.7 upload ?
Hi, Sven Luther writes: i think it warrants an upload. So do I. Stuff is here and here and here: http://www.theorie.physik.uni-muenchen.de/~jens/kernel-source/ http://www.theorie.physik.uni-muenchen.de/~jens/kernel-patch-powerpc/ http://www.theorie.physik.uni-muenchen.de/~jens/mol-modules/ Apart from Sven's changes, the packages contain an IDE fix for the Xserve G4 and more fixes for the new binutils. I'll upload the whole shebang in a few hours, if nobody objects. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: New kernel-source-2.6.7 upload ?
Hi, Sven Luther writes: Still, the kernel-patch package should be able to make the upgrade, since it contains the patchset betweem the version of kernel-source the user has, and the last one. That's exactly how it's done. More precisely, the apply script in kernel-patch-debian does this work. He needs to unapply the veersion he has, and reapply the latest one, right ? No, it uses the list-patches script to figure out which patches it has to apply in which order and in which direction. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: New kernel-source-2.6.7 upload ?
Hi, Sven Luther writes: So, i still don't understand what is broken. Consider a patch that creates a single file containing a single line: +foo You publish this as the first revision, resulting in the patchset: patch-1: +foo You realize you should have applied a different patch: +bar So you want to publish a second revision containing the patchset: patch-1: +foo patch-2: -foo +bar If you just replace the patch, you will break the path between the first and the second revision, because you get: patch-1: +bar patch-2: +bar Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#263169: loadmodules incomplete
Hi, Harald Dunkel writes: the patch [...] looks into /proc/modules (the user space interface for module management) to get a list of loaded modules. This only works if you are building an initrd for a kernel with the exact same module configuration. On the other side, the current mkinitrd searches for entries in /proc/scsi and uses 45 lines sed (hardwired into mkinitrd!) to do a mapping to module names. mkinitrd is far from perfect. Nevertheless, it works nicely on a great many systems. I doubt that /proc/scsi is the right way to guess which modules are loaded. It is, since it contains information about the installed SCSI hardware, not about the loaded drivers. At least for sata_sil and sata_sis it doesn't work, as it seems. Patch the sed script, then. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: r973 - in trunk/kernel/source/kernel-source-2.6.7-2.6.7/debian: . patches
Hi, Sven Luther writes: Modified: trunk/kernel/source/kernel-source-2.6.7-2.6.7/debian/patch es/marvell-pegasos.dpatch Let me re-iterate: You must never, ever change dpatch files that have already made it into uploads. Otherwise, you will certainly break kernel-tree. See debian/README.NMU, step 3. Anyway. If you want this and kernel-patch-powerpc built and uploaded, drop me an email and I'll do it tonight. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: r973 - in trunk/kernel/source/kernel-source-2.6.7-2.6.7/debian: . patches
Hi, Sven Luther writes: Yeah, thanks, i had forgotten about this, will fix it later today. It's already fixed. Let's wait one more day to be sure that other things don't come up. Fair enough. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: New kernel-source-2.6.7 upload ?
Hi, Sven Luther writes: So what is the problem ? The problem arises when stuff gets out of sync, i.e. applying the latest revision of kernel-patch-debian to an older revision of kernel-source doesn't result in the latest revision of kernel-source. This was demonstrated nicely by the 2.4 build failure that I fixed. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: New kernel-source-2.6.7 upload ?
Hi, Sven Luther writes: Could this not be solved by simply making the kernel-source kernel-tree kernel-patch-debian dependency strict ? This is equivalent to dropping kernel-tree and kernel-patch-debian altogether. After all, there is almost zero chance to have the patches in separate states, since they are built from the same package. In the archive, yes. But a user may choose to put a new kernel-source package on hold once it's installed and upgrade to further revisions using kernel-tree, saving a hell of a lot of download volume. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#263058: CONFIG_PDC202XX_FORCE=y
tags 263058 pending thanks Hi, Troy Benjegerdes writes: I've confirmed that setting CONFIG_PDC202XX_FORCE=y resolves the problem. Thanks for investigating this. I've checked the change into svn. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Bug#263057: binutils: Unrecognized opcode: dssall on powerpc
tags 263057 pending thanks Hi, Ingo Juergensmann writes: cp'ed that patch to ppc-patch: Obviously, the list archive interface ate a number of vital spaces. Please supply a working patch file It's in svn now. I have no idea how to construct those nifty URLs that you can click on, anyway it's patches/binutils.diff in kernel-patch-powerpc-2.6.7-2.6.7. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Bug#263057: binutils: Unrecognized opcode: dssall on powerpc
Hi, Jens Schmalzing: I have no idea how to construct those nifty URLs that you can click on, Got it :) URL:http://svn.debian.org/viewcvs/kernel/trunk/kernel/powerpc/kernel- patch-powerpc-2.6.7-2.6.7/patches/binutils.diff?view=auto Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Bug#263057: binutils: Unrecognized opcode: dssall on powerpc
Hi, Ingo Juergensmann writes: Anyway, regarding to other mails regarding to this bugreport, I think you can now close this bug. It's tagged as pending and will be closed on the next upload of kernel-patch-powerpc. If anybody feels the need for it, feel free to reassign to that package, or kernel-source or kernel. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: CAN-2004-0554 is not fixed
Hi, Norbert Tretkowski writes: I just discovered that CAN-2004-0554 is still valid, at least for kernel-image-2.4.26-1-686 2.4.26-4 from unstable. I tested it on two machines, and both machines crashed when running crash.c. This is related to Bug#262540. In fact, patch-2.4.26-3 has not been applied to the tarball that shipped in revision 2.4.26-4 of kernel-source-2.4.26. Just great. I have already cleaned up the patches -3 and -4 (which didn't apply cleanly) and am currently preparing a new revision of the package. In the meantime, please file your discovery as a bug against kernel-image-2.4.26 and use the appropriate severity. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#262540: kernel-source-2.4.26: apply/unapply scripts don't work
Hi, Horms writes: Thanks, I have you resolved this or do you want me to look into it? Please take care of this. I haven't looked at the patches at all, just worked around the bug locally by disabling the scripts altogether. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#262390: kernel-image-2.6.7-powerpc: firewire broken (sbp2 module does not see ipod)
close 262390 thanks Hi, Troy Benjegerdes writes: This can be closed. Okay, thanks. Does the iPod work when you load the modules manually? If I load sbp2 manually, its fine FYI, when you plug firewire disks in, and sbp2 loads, how do you tell sbp2 to 'log out' of a firewire disk so it can be safely unplugged? Sorry, no idea. I usually plug in one disk at a time and just unload everything manually before I unplug disks. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: preparations for 2.6.7-3
Hi, Sven Luther writes: Jens, will you upload powerpc 2.6.7-3 too ? -2 will not be buildable because of the asfs patch move i believe ? That's okay, the asfs patch moved in 2.6.7-2 already. I need to hear some info about possibly creating a new powerpc-small config for 2.6 oldworld miboot based d-i in the near future. Bad idea. please propose an alternate solution with a reasonable timeframe. 2.4 base miboot floppies are working nicely. until there is a proper solution for the issues with 2.6, just stick with those. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: PReP support for mkvmlinuz kernel-image 2.6
Hi, Sven Luther writes: since there is a filename conflict between the openfirmware and prep objs files, i moved them both into subdirectories, which means that the future 2.6.7-3 will conflict with mkvmlinuz = 6. As far as I can see, the only conflicting file is misc.o. By installing simple/misc.o as misc-simple.o, we could preserve backwards compatibility. I'll check that out. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-patch-amd64
[Cc trimmed, Reply-To trimmed further] Hi, Troy Benjegerdes writes: Do we have a mechanism for dropping patches as we move from unstable-testing-stable ? Not really. When a certain revision of a package is uploaded into unstable, it leaves the maintainer's hands. The passage from unstable into testing is almost completely automatic, the passage from testing into stable involves the large and complicated release process. Or a way to mark a package as unstable only ? There is experimental for that kind of thing, and unofficial repositories. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Bug#258043: kernel-patch-debian-2.6.7: doesn't list which patches are incorporated: kernel-patch-debian-2.6.7, kernel-image-2.6.7: doesn't list which patches are incorporated
Hi, Kilian Krause writes: Just some place i can check the list *BEFORE* downloading some 30MB off the net The .diff.gz, containing all the patches complete with accurate descriptions, is less than 500kB. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: preparations for 2.6.7-3
Hi, Andres Salomon writes: I would like to get kernel-source-2.6.7-3 out tomorrow, if possible. Go ahead. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Open a discussion about bug 253324
Hi, Bluefuture writes: The low techie people I came across think that anything beside graphics are old computing or recovery broken things... so a bootsplash help they to trust the operating system (the computer as whole object from their point of view). I'm totally agree on this point. In my experience of installing debian to many different kind of people this is a very diffuse user cases and not only for low tech people also for avg tech people. It's a little psicological problem against debian that a small and tested kernel patch could solve. Psychology aside, there are two technical reasons for not integrating this kernel patch. One: It works exclusively with vesafb and this sucks. But let's assume for the moment that we all have nothing but i386 hardware and continue to Two: The official Debian kernel is modularized to a great extent. On i386, all framebuffer drivers and framebuffer console support itself are built as modules. Therefore, the console stays pitch black until those drivers are loaded, which happens exactly here: # head -2 /initrd/loadmodules modprobe -k vesafb /dev/null 21 modprobe -k fbcon 2 /dev/null Nothing stops you from loading pretty pictures at this point (or not load the drivers at all, then XFree86 will be the first thing you see), but as Herbert rightly said, this can be done from userspace. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-patch-amd64
Hi, [EMAIL PROTECTED] writes: [..] prepare kernel-patch-amd64-2.6.7 packages Bad idea. Split the patch and get as much as possible merged upstream. Of course, sorry for omitting it. Still, a kernel-patch package should be prepared. Thing is, the kernel-patch source package for powerpc that I mentioned as an example also creates the kernel-image binary packages. So even if the patch was completely empty, the package would still serve a very valid purpose. BTW, hppa does it in a different way, having separate source packages kernel-patch-hppa and kernel-image-hppa. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-patch-amd64
Hi, [EMAIL PROTECTED] writes: Me Og. Og wget. Og package. Og upload. Og no read. Og maintainer. YMMD :) Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: 2.4 2.6 kernels, should sarge be 2.6 only at least for powerpc ?
Hi, Sven Luther writes: Jens [...] is comaintainer of the 2.4 kernels. Nope. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: 2.6.7
Hi, Christian Heim writes: But I've tested [the vesafb patch] now for you. Doesn't compile at all. Where did you get the kernel source tree from? The build Works very well here, using kernel-source-2.6.7_2.6.7-2. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-patch-amd64
Hi, Frederik Schueler writes: Since the debian kernel packages now are being maintained by the debian-kernel maintainers team, what is going to happen to these inofficial packages once amd64 will enter sid? Do I have to ITP kernel-patch-amd64 and/or kernel-image-amd64? I would suggest that you subscribe to debian-kernel, prepare kernel-patch-amd64-2.6.7 packages based on the example of the other 2.6 kernel-patch packages (right now, this means the powerpc patches, so please let me know if you find a better way of doing it) , and upload them as soon as amd64 enters sid. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: ASFS fs-patch, new version: 1.0beta7
Hi, Marek Szyprowskiwrites: I've prepared a new version of my ASFS driver. Old 1.0beta4 or even 1.0beta3 I found in kernel-patch packages should be replaced by the new one as soon as possible Thanks for letting us know. The latest version of the Debian kernel packages use 1.0beta6, how about that? Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: initrd on installed kernels
Hi, Thibaut Varene writes: The main difference (the only one _really_ noticeable) stands at very early stage, when lilo loads the kernel (and the initrd now). The Loading Linux... dot-bar progress message that used to last a couple of seconds is now taking tens of secs. This is very strange and probably a lilo bug or setup problem. Since I myself use grub for booting i386 systems, I haven't seen anything like this, but I vaguely remember one of my users reporting the same problem. It may have to do with the compact option in lilo.conf, try and toggle it. I have some boxes which I really enjoyed switching to NetBSD _from_ Debian (really old tiny hardware, [EMAIL PROTECTED], 36M RAM) ;) Gee, NetBSD/mac68k. My very first Un*x box was (and still is) a Mac IIci with this. btw, what does _that_ mean ? ;) It's a quote from a bande dessinée by Enki Bilal, namely Froid Équateur. Judging from your email adress, you should be able to go and see his latest film Immortel, which is vaguely based on that. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-source 2.6.7 packages pending upload
Hi, William Lee Irwin III writes: Shouldn't we disable swsusp instead? The code is flakey at least and eats quite a bit of memory that seems to be scare on the boot floppies. I'd be in favor of that also. Ah, too bad. I'm just uploading a new build that fixes kernel-tree (most important), fixes a few other glitches (less important), and moves the asfs filesystem from kernel-patch-powerpc into kernel-source (mostly cosmetical). I could have dropped the modular-swsusp patch if I had seen your message earlier. Anyway, if you decide to fix modular-swsusp.dpatch, please leave the old version in place, make changes to a copy, and put that copy in debian/patches/00list-3. Otherwise the building of the monolithic patches will fail horribly. I'll update the documentation for that as soon as possible. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: [jblache@debian.org: Re: [PATCH 2.6] Add back beep support to snd-powermac]
Dear Sven, How about including this patch ? I'd say the author (Derrick? Julien?) should try to get it included upstream. Beep is not a very high priority. BTW, i added both a new uhci fix Ok. and the marvell driver to the svn repo, It's *huge*. Any reason why it should be powerpc-only? as well as started the practice of marking the new changelog as UNRELEASED, please change it back before making the build for the next release. Please don't do this, it's too easy to forget. Also, maybe we should start using the same convention as the debian-installer packages is using, that is, have each changelog entry marked by the person doing it : * Sven - Stuff 1 - Stuff 2 * Jens - Stuff 3 - Stuff 4 And so on ? This doesn't work well in emacs and is not chronological, I would prefer the way we did it for kernel-source: * Stuff 1 (Sven Luther). * Stuff 2 (Jens Schmalzing). * Stuff 3 (Jens Schmalzing). * Stuff 4 (Sven Luther). Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Marvell Discovery II Ethernet driver
Hi, Sven Luther writes: i added [..] the marvell driver to the svn repo, Time for a subject change. We are talking about the following patch: URL:http://www.theorie.physik.uni-muenchen.de/~jens/kernel-patch-powe rpc/kernel-patch-powerpc-2.6.7-2.6.7/patches/marvell-gigabit.diff Could someone please take a look at this driver and tell me where it belongs? I have the feeling that it is out of place in the PowerPC patch, but who am I to tell. Also, Sven, if you have to add new drivers, please make sure they don't break the package. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Add back beep support to snd-powermac]
Hi, Sven Luther writes: How about including this patch ? This patch, by Julien Blache, can be found here: URL:http://www.theorie.physik.uni-muenchen.de/~jens/kernel-patch-powe rpc/kernel-patch-powerpc-2.6.7-2.6.7/patches/powermac-beep.diff I don't see the missing console beep as an extremely pressing problem, but why not. Still, could someone review the patch, please? Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: [jblache@debian.org: Re: [PATCH 2.6] Add back beep support to snd-powermac]
Hi, Sven Luther writes: Huge ? Yes, huge. Twice the size of the other patches combined. Twenty times if you omit the asfs patch from the others. Talking about the asfs patch, any progress getting it accepted upstream? Any reason why it should not be promoted to kernel-source in the meantime? It is a full gigabit ethernet driver, what did you expect ? In any case I did not expect to see a full gigabit ethernet driver appear in an arch specific patch. Well, it should be powerpc mips only, Then it definitely belongs in kernel-source until it is accepted upstream. Well, ok, the idea behind it is to not upload a package by mistake while it has not yet been blessed. As you wish. I don't really care. Either way, it's hard to upload something by mistake if it takes more than an hour to build. [...] You are supposed o use dch -a anyway to add a new entry, which would set also the last modification entry correctly and such. I will definitely continue using emacs for editing changelogs. But maybe we should discuss this more broadely. [...] No we shouldn't. It's not worth it. Just add whatever changelog entries you like, but do mark them with your name (which you didn't). BTW, where you able to boot kernels whose image was generated with version 3.1-pre2-1 of module-init-tools (the one in unstable) installed ? No, but I submitted a patch to the BTS that made it into 3.1-pre2-2. It fails here because of missing /etc/modprobe.conf. That message is spurious, I also submitted a patch for that, but it's pending upload. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Add back beep support to snd-powermac]
Hi, Christoph Hellwig writes: 404 Oops. Fixed. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
PReP support (was: powerpc kernel-patch 2.6.6-5 in incoming since over a month !!!)
Hi, Sven Luther writes: unbootable kernels on non pmac systems, Speaking of which. Anybody got a PReP system they don't need and could throw at me? As I said, I got a bunch of RS/6000 boxen recently, only to find out they're MCA. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Marvell Discovery II Ethernet driver
Hi, Christoph Hellwig writes: On the junkjard. Done. Andrew Morton's -mm tree has a much better driver for the same hardware (and it's about a third the size) This should definitely go into kernel-source then. First because it's already in -mm, second because it's a chance of getting out a new Debian revision fixing kernel-tree. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: PReP support
Hi, Sven Luther writes: BTW, could you add a mkvmlinuz calling script to the next version of mkvmlinuz ? A calling script for a shell script? Something like : #!/bin/sh mkvmlinuz -k $2 -o /boot/vmlinuz-$1 Should do just fine. This is already there, right in mkvmlinuz itself. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: PReP support
Hi, Sven Luther writes: Do you mean that by doing : mkvmlinuz /boot/vmlinux-2.6.7-powerpc 2.6.7-powerpc The right thing will happen, and that is creation of a /boot/vmlinuz-2.6.7-powerpc ? Yes, provided /etc/mkvmlinuz/output sets the variable output to /boot/vmlinuz-$release. Nope, it doesn't work : === Building for sub-architecture chrp. === Using kernel image file 2.6.7-powerpc. === Using initrd image file . === Release version seems to be /boot/vmlinux-2.6.7-powerpc. === Using object files from /home/sven. Please specify an output file. There must be some misunderstanding going on then. Or failure to read the documentation. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: initrd on installed kernels
Hi, Thibaut Varene writes: I didn't pay much attention to that at that time, knowing it was the new default for debian kernels. But, I started giggling when I realized the total boot time (time before first login prompt) of the box was almost tripled (that's a P2 400). How big is the initrd you generated? I've found that it helps to strip it down as much as possible, by setting MODULES=dep in mkinitrd.conf for example, and getting all unnecessary filesystem drivers out. I was wondering why are we using initd on installed debian kernels. Even if you only consider booting from a harddisk partitions, a generic kernel without an initrd needs basically all low-level IDE and SCSI drivers built in in order to access the harddisk, and a good many filesystem drivers on top of that. So everybody is forced to load lots and lots of drivers they will never need. On the other hand, with an initrd kernel you only have the bare minimum in the kernel and use the initrd to load precisely the drivers you need to get your root filesystem running. my question about proper 2.6 packaging still holds, I'd suggest you just look at the existing 2.6 kernel-image and kernel-patch packages of other archs and pick what you like best. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: kernel-source 2.6.7 packages pending upload
Hi, Frederik Schueler writes: I was updating the kernel packages for amd64, and encountered this error: No debian/revision file, assuming pristine Linux 2.6.7 Ah crap. This file was called version.Debian before, and I cleverly renamed it to debian/revision, forgetting that it wouldn't get packaged into the kernel-source-2.6.7.tar.bz2 tarball. This will be fixed in the next revision. For the time being, just comment the line in your debian/rules file that tries to apply the Debian patch. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: preliminary kernel-source 2.6.7 packages available
Hi, Kenshi Muto writes: I tried to compile for i386 from this source, but it was aborted by error: kernel/power/swsusp-core.c:48:20: swsusp.h: No such file or directory kernel/power/swsusp-core.c: In function `mark_swapfiles': ... Sorry 'bout that. I vaguely remember seeing a fix for this on the list a few days ago. So I must have used an old version of the split patches. I just checked Christoph's tarball again, and it has nothing new, so I'll wait for him. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: preliminary kernel-source 2.6.7 packages available
Hi,
Christoph Hellwig writes:
- I have done some more work on the split patches, especially added
lots of .dpatch commentary. I'll re-merged that with your
changes tomorrow
- the changelog should be much more detailed, e.g. mentioning which
changes we've dropped that didn't go upstream. I'll write
something up on that.
Very nice. I was kind of wondering what to do about the identical
dpatch comments and default author addresses.
I enclose a new version of modular-swsusp.dpatch. The header file
that Kenshi's system complained about was simply missing from the
patch. Just adding it from 2.6.6 looks alright to me.
Regards, Jens.
#! /bin/sh -e
## PATCHNAME.dpatch by [EMAIL PROTECTED]
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Makefiles, configure scripts and other build stuff adapted for
## DP: debian package creation
. $(dirname $0)/DPATCH
* Partially modularised software suspend
--- 1.3/arch/i386/power/Makefile2003-09-09 22:52:20 +02:00
+++ edited/arch/i386/power/Makefile 2004-06-16 15:29:58 +02:00
@@ -1,3 +1,8 @@
+swsusp-arch-y += swsusp_syms.o swsusp.o
+
obj-$(CONFIG_PM) += cpu.o
obj-$(CONFIG_PM_DISK) += pmdisk.o
-obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
+
+ifneq ($(CONFIG_SOFTWARE_SUSPEND),)
+obj-y += swsusp-arch.o
+endif
--- 1.14/arch/i386/power/pmdisk.S 2004-05-25 11:53:07 +02:00
+++ edited/arch/i386/power/pmdisk.S 2004-06-16 15:29:58 +02:00
@@ -25,8 +25,9 @@
movl %ecx,%cr3
movlpm_pagedir_nosave,%ebx
- xorl%eax, %eax
- xorl%edx, %edx
+ movlpmdisk_pages, %eax
+ leal-1(%eax), %edx
+ sall$4, %edx
.p2align 4,,7
.L1455:
movl4(%ebx,%edx),%edi
@@ -36,13 +37,11 @@
rep
movsl
- movl%cr3, %ecx;
- movl%ecx, %cr3; # flush TLB
+ movl%cr3, %eax;
+ movl%eax, %cr3; # flush TLB
- incl%eax
- addl$16, %edx
- cmplpmdisk_pages,%eax
- jb .L1455
+ subl$16, %edx
+ jge .L1455
.p2align 4,,7
.L1453:
movl saved_context_esp, %esp
--- 1.14/arch/i386/power/swsusp.S 2004-05-25 11:53:07 +02:00
+++ edited/arch/i386/power/swsusp.S 2004-06-16 15:29:59 +02:00
@@ -40,8 +40,9 @@
movl %ecx,%cr3
call do_magic_resume_1
- movl $0,loop
- cmpl $0,nr_copy_pages
+ movl nr_copy_pages,%eax
+ movl %eax,loop
+ cmpl $0,%eax
je .L1453
.p2align 4,,7
.L1455:
@@ -52,8 +53,8 @@
movl loop,%eax
movl loop2,%edx
sall $4,%eax
- movl 4(%ecx,%eax),%ebx
- movl (%ecx,%eax),%eax
+ movl -12(%ecx,%eax),%ebx
+ movl -16(%ecx,%eax),%eax
movb (%edx,%eax),%al
movb %al,(%edx,%ebx)
movl %cr3, %eax;
@@ -66,11 +67,11 @@
cmpl $4095,%eax
jbe .L1459
movl loop,%eax
- leal 1(%eax),%edx
+ leal -1(%eax),%edx
movl %edx,loop
movl %edx,%eax
- cmpl nr_copy_pages,%eax
- jb .L1455
+ cmpl $0,%eax
+ jne .L1455
.p2align 4,,7
.L1453:
movl $__USER_DS,%eax
--- 1.36/arch/x86_64/kernel/Makefile2004-05-10 12:25:59 +02:00
+++ edited/arch/x86_64/kernel/Makefile 2004-06-16 15:29:59 +02:00
@@ -19,7 +19,9 @@
obj-$(CONFIG_X86_LOCAL_APIC) += apic.o nmi.o
obj-$(CONFIG_X86_IO_APIC) += io_apic.o mpparse.o
obj-$(CONFIG_PM) += suspend.o
-obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend_asm.o
+ifneq ($(CONFIG_SOFTWARE_SUSPEND),)
+obj-y += swsusp-arch.o
+endif
obj-$(CONFIG_CPU_FREQ) += cpufreq/
obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
obj-$(CONFIG_GART_IOMMU) += pci-gart.o aperture.o
@@ -36,3 +38,4 @@
topology-y += ../../i386/mach-default/topology.o
swiotlb-$(CONFIG_SWIOTLB) += ../../ia64/lib/swiotlb.o
microcode-$(subst m,y,$(CONFIG_MICROCODE)) += ../../i386/kernel/microcode.o
+swsusp-arch-y += swsusp_syms.o suspend_asm.o
--- 1.10/drivers/acpi/sleep/proc.c 2004-03-31 15:32:27 +02:00
+++ edited/drivers/acpi/sleep/proc.c2004-06-16 15:30:00 +02:00
@@ -2,6 +2,7 @@
#include linux/seq_file.h
#include linux/suspend.h
#include linux/bcd.h
+#include linux/module.h
#include asm/uaccess.h
#include acpi/acpi_bus.h
@@ -67,12 +68,17 @@
goto Done;
}
state = simple_strtoul(str, NULL, 0);
-#ifdef CONFIG_SOFTWARE_SUSPEND
if (state == 4) {
- software_suspend();
- goto Done;
+ down(software_suspend_sem);
+ if (software_suspend_module
+ try_module_get(software_suspend_module)) {
+ up(software_suspend_sem);
+ software_suspend_hook();
+ module_put(software_suspend_module);
+
Re: preliminary kernel-source 2.6.7 packages available
Hi, Christoph Hellwig writes: now that we're working with three people on this, we really need the SVN repo up. I'd rather say, we really need to upload a usable kernel-source package to unstable. A svn repo would greatly help this, but we can probably do without this one more time - can we meet on IRC for coordination? Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
kernel-source 2.6.7 packages pending upload
Hi, we had a very productive session in #debian-kernel today, and as a result, kernel-source packages are ready for upload to unstable. At least that's what I think, having built them from source and tested them by using them as a base for the PowerPC kernel-image packages. Before I upload to unstable, I would like to have William's blessing, as he did the upload before. This will give everybody else time to look at the packages and let me know of problems that have escaped . So, William, is it alright if I upload the following to unstable? URL:http://www.theorie.physik.uni-muenchen.de/~jens/kernel-source/ Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: mkvmlinuz, boot-loaders and powerpc kernels.
Dear Sven, Jens, in your discussion with Manoj about this, where would the generic-powerpc or whatever script reside ? in my proposal, 'generic' or 'official' would be a separate PowerPC subarch that a) packages the kernel as an uncompressed ELF image file in /boot/vmlinux-revision-flavour and nothing else, b) packages the bootloading glue for pmac, chrp and prep into the directory /usr/lib/kernel-image-revision-flavour, c) takes provisions to apply the correct glue in the postinst. Right now, a) and b) are implemented in the debian/rules file of kernel-patch-powerpc, by building an intermediate pmac kernel-image package, unpacking it, and making the necessary changes. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: Proposition: latest kernel source dependency package
Hi, Goswin von Brederlow writes: Better would be Kernel-tree-2.6 analog to kernel-tree-2.6.6. I'm working on the kernel-source-2.6.7 package anyway, I'll add a kernel-tree metapackage. kernel-tree because IMHO sticking with a certain minor version is against the spirit of a tracker package. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
preliminary kernel-source 2.6.7 packages available
Hi, I've created preliminary kernel-source packages based on the 2.6.7 split patches created by Christoph. They can be found at deb http://www.theorie.physik.uni-muenchen.de/~jens/kernel-source ./ Please check them out and provide feedback. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: powerpc kernel-patch 2.6.6-5 in incoming since over a month !!!
Hi, Sven Luther writes: how would mkvmlinuz act if there were no vmlinux installed, but only a vmlinuz ? It exits with a non-zero exit status. Since the postinst comes from kernel-package, you need to sort this out with Manoj. Well, that would be a possibility. The other possibility would be to depend on mkvmlinuz, [...] Is installing mkvmlinuz such a problem, especially if you have a subarch aware debconfified postinst ? On many systems, it is perfectly reasonable to not install mkvmlinuz. Therefore, Depends is definitely too strong. IMHO Suggests is just about right. If I had filed a grave bug every time I hosed one of my systems because I didn't know something, we'd be approaching #30 now. But debian would be a more stable and usable system by now too. Maybe. Or maybe more bugs would be closed immediately with nothing but an RTFM. Who knows. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: powerpc kernel-patch 2.6.6-5 in incoming since over a month !!!
Hi, Sven Luther writes: how would mkvmlinuz act if there were no vmlinux installed, but only a vmlinuz ? It exits with a non-zero exit status. Which would kill dpkg, right ? Have you actually tried this? If not, please do so. If it does not work as expected, try again with the following patch applied: --- mkvmlinuz.orig Mon Jun 7 15:07:35 2004 +++ mkvmlinuz Sat Jun 19 11:08:43 2004 @@ -86,7 +86,7 @@ # we couldn't find a kernel, and therefore give up if test -z $kernel; then echo Could not find a kernel image file, please specify one. - exit 1 + exit 0 fi # sanitize the location of the kernel Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: powerpc kernel-patch 2.6.6-5 in incoming since over a month !!!
Hi, Sven Luther writes: Please tell me what you gain by not having a depends there ? what is the benefit in _NOT_ installing it ? No cruft on the many systems where it is not needed at all. If you are really going to insist in doing it this way, i would insist that we create at least a package containing a special non-modular pegasos friendly config, in chrp friendly format. Again, we have reached a point where further discussion is fruitless. The question whether mkvmlinuz is Depends or Recommends or Suggests is secondary. First, it has to be integrated properly into the kernel-image postinst, the postinst_hook is only a temporary solution after all. Since Manoj wrote that postinst and you have the hardware to test it, the two of you should sort this out. If you come up with a patch that Manoj doesn't want to merge, send it to me and I'll put it into the official kernel-image packages. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Re: powerpc kernel-patch 2.6.6-5 in incoming since over a month !!!
Hi, Sven Luther writes: Please tell me exactly in how far you feel that this would be so much of a hindrance compared to the benefit of having kernel-image installation work out of the box on non-pmac subarches ? mkvmlinuz serves the purpose of making some systems bootable given an uncompressed kernel and optionally an initrd. For other systems, the packages yaboot and quik serve the same purpose. Yet other systems use programs that are not packaged at all, such as BootX or a diskless setup or whatever. While you seem to care mostly for your Pegasos board, I want PowerPC kernel-image packages that work equally well on all subarchs. Following your logic, the way to achieve this would be to automatically pull in all packages mentioned above and let the postinst pick and configure the correct one. This has bloat written all over it, and is unacceptable. So I am suggesting to let the installation system and the user take care of a reasonable setup. If you think the postinst should fail on CHRP if it doesn't detect one, fine with me. Go implement it. If you would have told me that the real problem is that mkvmlinuz pulls in binutils, which is 6.6Mo or something such, then that would be a real argument It's not an argument at all. Have you forgotten that one could do without binutils and create very small wrapper scripts if size was an issue? Well, you were the one proposing to use the postinst_hook, where you not ? As a workaround, pending a real solution in kernel-package. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
