up to them. I would
think that the path of least resistance would be to maintain the status
quo, but if they want to remove lilo from the Debian installer menu
that's their call, as far as I am concerned. I just don't want to see
lilo removed from the distribution.
--
.''`. Stephen Powell
the bootloader. See also, for example,
linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
on line 38. This really is an open and shut case, if only I can the kernel
people to actually look at it! Please look at it!
--
.''`. Stephen Powell
someone on the kernel team actually has
to fix it.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
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
Initial reply from upstream:
- Forwarded Message -
From: Heiko Carstens h.carst...@de.ibm.com
To: Stefan Haberland1 stefan.haberl...@de.ibm.com, Stefan Weinhuber
w...@de.ibm.com
Cc: Martin Schwidefsky martin.schwidef...@de.ibm.com, Susanne Wintenberger
swin...@de.ibm.com, Stephen Powell
-mail to
linux...@de.ibm.com to report the bug and see what happens.
In the meantime, my patch is available for users who want to build
a custom kernel with my patch applied to fix the problem.
Wish me luck!
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email
in the Debian bug log.
Please copy 582...@bugs.debian.org on correspondence.
Respectfully submitted,
Stephen Powell
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
this? Do you (the Debian Kernel Team)
want to function as an intermediary between me and upstream?
Or would you prefer that I report the problem to upstream myself?
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
as a problem
log.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
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/409713699.268027.1274293120373.javamail.r
devices names to s390 device numbers as follows:
Device
0200 /dev/dasda
0201 /dev/dasdb
0202 /dev/dasdc
0203 /dev/dasdd
and (2) it specifies the device driver used for each disk as follows:
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE
drivers if this file is not present?
A new kernel, linux-image-2.6.32-5-s390x, was also included in the upgrade;
so perhaps this is part of the problem as well. Previously, I was using
linux-image-2.6.32-3-s390x.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE
boot either.
So this is not related to the kernel. It is definitely related to the
new version of initramfs-tools.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
is bootable again, now that I've made
the changes indicated above.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http
On 2010-01-04 at 14:52:19 -0800, Greg KH wrote:
On Mon, Dec 21, 2009 at 10:26:38AM -0500, Stephen Powell wrote:
Hello upstream kernel team!
A fix was recently published for drivers/s390/block/dasd_diag.c to fix a
problem
with an inability to get read-only minidisks online to Linux via
Hello upstream kernel team!
A fix was recently published for drivers/s390/block/dasd_diag.c to fix a problem
with an inability to get read-only minidisks online to Linux via the dasd_diag
driver. This fix was published for kernel release 2.6.33. (See
An official fix has now been published for this problem by upstream
development for kernel 2.6.33. See
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=22825ab7693fd29769518a0d25ba43c01a50092a
Please consider backporting it to 2.6.32 so that when Squeeze freezes,
I'm afraid that's beyond my area of recent experience. The last time I built
an out-of-tree module was back in the days when the ALSA drivers were
not part of the kernel source tree, and I was using Woody, I think,
with a 2.4 kernel. But make-pkpg could do that back then, and I would hope
I would like to suggest addressing the building of out-of-tree modules
as well. This is kind of a moving target, as Debian does not currently
offer a way to build deb packages from out-of-tree modules which have
been (prematurely, IMO) converted to DKMS.
I'm afraid that's beyond my area of
first of all you shall build your linux-2.6 in ~/src/
no compellent reason to do it in /usr/src
second you shall use make deb-pkg no need to use kernel-package
on a recent linux-2.6 tarball (= 2.6.31). it will just produce
the linux-image.
Thank you for your feedback. In response to your
here the pointer to the historic mail from linus, quite dated already
http://lkml.indiana.edu/hypermail/linux/kernel/0007.3/0587.html
Thanks. I have read the e-mail. I am not a C programmer, despite managing
to hack out a kernel patch for dasd_diag.c. But I do know other programming
Maybe I'm re-inventing the wheel here, but I have recently collected and
organized
my notes on custom kernel building in Debian and have put them on the web at the
following URL: http://www.wowway.com/~zlinuxman/Kernel.htm
Maybe it will be useful to somebody. If there is anything incorrect on
On Mon, Nov 16 2009, Manoj Srivastava wrote:
I like that, and would like to be able to incorporate this HOWTO
in the kernel-package package. What license are you distributing the
document under? If it is a free license, I would like it to be in the
kernel-package docs for Squeeze.
I'm
However ...
This fix also creates (or more likely exposes) another problem. When this fix
is on, devices which are manually taken offline immediately come online again!
I had this problem once before in an earlier kernel, but the problem
eventually
went away with maintenance.
False
I have come up with a patch that seems to solve my problem.
The mdsk_init_io internal subroutine of drivers/s390/block/dasd_diag.c
currently looks like this:
--
/* Initialize block I/O to DIAG device using the specified blocksize and
* block offset. On success, return zero and set
Package: linux-image-2.6.26-2-s390x
Version: 2.6.26-19
X-Debbugs-CC: debian-s...@lists.debian.org
This bug report applies to the s390 and s390x Linux kernel architectures only.
I am reasonably certain that this is not a Debian-specific bug but
applies to all distributions. Nevertheless, since I
I issued the mkinitramfs command with the exact options you specified,
then re-ran zipl, then rebooted. No change in results. But the
custom kernel built with kernel-package works just fine. Could this be
some kind of cross-compilation problem, perhaps? Do you build your
s390 kernels on an
I notice that the fix for this bug (div64.c) has finally made it into the
official
Debian kernel source code. However, the latest stock kernel, 2.6.26-2-s390,
revision
2.6.26-17, still won't boot in my virtual machine under z/VM 5.4.0, running in
an IFL LPAR
on a z/890. I still have to build
When I closed this bug report, it appeared that my Compaq Netelligent
10/100 PC Card Ethernet adapter WOULD work with Ethernet cables which
have no soft plastic boot protecting the hard plastic hook, but WOULD
NOT work with cables which have boots. Subsequent testing, however,
has disproved this.
perhaps this means the severity should be lowered
I can't speak to that. I'm not a member of the Debian kernel team. I'm just
an ordinary
end user who happened to notice a reference to the same kind of sound chip that
I have
and thought I might be able to help.
The problem, as I see it, is
Dear Mr. Hansen,
I am not a member of the Debian Kernel Team, or any other team for that matter.
I am just an ordinary end user. But I noticed the message
Clocksource tsc unstable (delta = -244351700 ns)
in the kernel log file and wondered if that might be part of your problem.
You yourself
Yes, 15lenny2 was a security update. This fix is queued for 2.6.26-16
which should be included in Debian 5.0.2.
Well, I guess that makes sense; since the kernel that is packaged with
the Debian installer needs to be replaced too. Even s390x kernels,
which are not affected by this bug, are
I had a similar problem installing Lenny on an IBM ThinkPad 600 Model 2645-51U,
which also has a built-in Crystal Semiconductor CS4237B sound chip. You
might want to check out my web site, http://www.wowway.com/~zlinuxman/tp600.htm,
to see how I handled the problem. One thing in particular that
In the process of collecting additional supporting data, I have
stumbled upon the problem. As mentioned
earlier, there are two laptops involved here. One runs
Etch (kernel 2.6.18) and the other runs Lenny (kernel 2.6.26).
The Compaq Netelligent 10/100 PC Card adapter works in the Etch
machine
The latest kernel update, revision 2.6.26-15lenny2, still does not
contain the fix for this problem.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
If you need more information on my system and how it is set up, please
see http://www.wowway.com/~zlinuxman/tp600.htm.
I tried installing linux-image-2.6.29-bpo.2-686 from lenny-backports to
see if the latest linux kernel would fix the problem, but it does not.
The symptom is the same. The card is recognized and configured,
but I/O does not work. Therefore, DHCP configuration fails.
Here is the output of
Package: linux-image-2.6.26-2-686
Version: 2.6.26-15
Severity: normal
I have two laptops. One is an IBM ThinkPad 390E running Debian Etch
(kernel linux-image-2.6.18-6-686). The other is an IBM ThinkPad 600
running Debian Lenny (kernel linux-image-2.6.26-2-686).
I have a 16-bit PC Card 10/100
Actually, I decided to go ahead and do the plan I had outlined, just for grins,
while I was waiting on an answer.
If it didn't work, and Frans said yes, do that, I could then say it didn't
work right away and save time.
But it did work!
Here is what I did, as close as I can remember it. I was
Correction. The s390 server did not have two virtual CPUs. It had a *LIMIT*
of two virtual CPUs. In other words, its CP directory entry contained
MACH XA 2
This statement creates only one virtual CPU, but allows a second one to be
defined, if desired, by means of the
CP DEFINE CPU
Could http://bugs.debian.org/511334 be related to your problem? There's a
link to patch in one of the last messages.
See especially messages #57 and #65.
It's possible that they may be related. The difference, though, is that the user
in problem number 511334 was running in a virtual machine
Can you boot the old kernel and unpack the initramfs to see if the
needed modules got added? See the DEBUG section of initramfs-tools(8)
for a command to do the unpacking.
As you know, the initial RAM file system is not included with the kernel
image package but is built dynamically during
I just tried re-building the initial RAM file system for the 2.6.26-1-s390
kernel image, rerunning zipl, and rebooting.
It came up fine. It does not appear to be a problem with the build process for
the initial RAM file system.
If it is, it is a build problem which is specific to the new kernel
By the way, I have another server that runs the 64-bit version of the kernel
image (linux-image-2.6.26-2-s390x), and it works fine.
Either the bug affects only the 31-bit version of the kernel, or there is an
environmental difference of some kind.
I have found an environmental difference between the two servers, one of which
runs linux-image-2.6.26-2-s390x (and will boot)
and the other of which runs linux-image-2.6.26-2-s390 (and will not boot). The
s390x server has only one virtual CPU.
The s390 server has two virtual CPUs. I changed
Package: linux-image-2.6.26-2-s390
Version: 2.6.26-15
Severity: critical
This particular Linux kernel image will not boot on a virtual machine in ESA
mode under z/VM. I have not tried other platforms (LPAR, for example).
Here is the boot log:
--
Booting default (debian)...
[
Hello Debian kernel team.
I am an IBM mainframe systems programmer. I support
and maintain the z/VM operating system at my
installation which provides the virtualization that
allows multiple virtual Linux servers to share the
same LPAR (mainframe partition). I would like to make
an appeal for
It is enabled in the current Debian kernel images
for
2.6.24 and above.
However it is not enabled in the Etch 2.6.18. 2.6.24
is currently in
proposed-updates and will reach stable in the next
days (hopefully).
Thanks!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject
101 - 146 of 146 matches
Mail list logo
