Bug#1012506: AW: Bug#1012506: Fix for 64bit big-endian systems
Hello David, I can confirm that this patch works fine for the s390x architecture. I have a setup with postfix and two opendkim instances for RSA and ED25519 dual signing running bullseye on a IBM system z15 (in fact it's the same host where zelenka and zandonai are hosted on). I've not tested this patch on x86 yet. If you want, I can build a test system for x86. But maybe you already have a system to give it a try? I've split the patch in a fix for s390x and a cleanup patch on purpose to keep things separated. Feel free to ignore the cleanup patch. From my understanding upstream opendkim seams pretty much dead, so I've little hope to get those fixes upstream. Ciao Martin Von: David Bürgin Gesendet: Freitag, 18. November 2022 18:19 An: Martin Grimm; 1012...@bugs.debian.org Betreff: Re: Bug#1012506: Fix for 64bit big-endian systems Hello Martin, thank you for the patches. Martin Grimm: > Building opendkim with --with-gnutls disables support for ed25519, so I've > taken a closer look at the problematic code and found the culprit code. > > The error comes from the call to the openssl function RSA_sign in > libopendkim/dkim.c:3945: > > RSA_sign takes as fifth argument a reference to an unsigned int (4 byte) > variable to return the length of the signature. > The opendkim-code uses a reference to the variable l of type size_t (unsigned > long, 8 bytes on s390x) casted as (signed) int reference for this. > This is fatal for a big endian system. > > I've attached to patches: > 1.) fix-RSA_sign-call.patch: fixes the call to RSA_sign by using a temporary > variable ui_l of the correct type unsigned int to get back the length from > RSA_sign and savely assigns the returned value to l after the call. > 2.) fix-printf-types.patch: fixes several calls of printf in dkim.c that use > the signed int specifier "%d" to print size_t arguments. For C99-code "%zu" > should be used for size_t variables. Regarding patch 1: I don’t have access to an s390x machine and I don’t want to spend too much time assessing this patch. I can apply it, but please confirm that you have verified that this is the right fix and that it does not impact the current working build. If someone else can try it and report back, that would be useful, too. Regarding patch 2: There are lots of compiler warnings today (eg also for our current use of OpenSSL APIs). I can apply the patch, but generally code cleanup is something I prefer done upstream (yeah, I know …) instead of maintained as Debian patches. Ciao, David
Bug#1012506: Fix for 64bit big-endian systems
Dear maintainer and Waldemar,
Building opendkim with --with-gnutls disables support for ed25519, so I've
taken a closer look at the problematic code and found the culprit code.
The error comes from the call to the openssl function RSA_sign in
libopendkim/dkim.c:3945:
RSA_sign takes as fifth argument a reference to an unsigned int (4 byte)
variable to return the length of the signature.
The opendkim-code uses a reference to the variable l of type size_t (unsigned
long, 8 bytes on s390x) casted as (signed) int reference for this.
This is fatal for a big endian system.
I've attached to patches:
1.) fix-RSA_sign-call.patch: fixes the call to RSA_sign by using a temporary
variable ui_l of the correct type unsigned int to get back the length from
RSA_sign and savely assigns the returned value to l after the call.
2.) fix-printf-types.patch: fixes several calls of printf in dkim.c that use
the signed int specifier "%d" to print size_t arguments. For C99-code "%zu"
should be used for size_t variables.
best regards,
Martin--- a/libopendkim/dkim.c
+++ b/libopendkim/dkim.c
@@ -440,7 +440,7 @@ dkim_add_plist(DKIM *dkim, DKIM_SET *set
plist = (DKIM_PLIST *) DKIM_MALLOC(dkim, sizeof(DKIM_PLIST));
if (plist == NULL)
{
- dkim_error(dkim, "unable to allocate %d byte(s)",
+ dkim_error(dkim, "unable to allocate %zu byte(s)",
sizeof(DKIM_PLIST));
return -1;
}
@@ -504,7 +504,7 @@ dkim_process_set(DKIM *dkim, dkim_set_t
hcopy = (u_char *) DKIM_MALLOC(dkim, len + 1);
if (hcopy == NULL)
{
- dkim_error(dkim, "unable to allocate %d byte(s)", len + 1);
+ dkim_error(dkim, "unable to allocate %zu byte(s)", len + 1);
return DKIM_STAT_INTERNAL;
}
strlcpy((char *) hcopy, (char *) str, len + 1);
@@ -513,7 +513,7 @@ dkim_process_set(DKIM *dkim, dkim_set_t
if (set == NULL)
{
DKIM_FREE(dkim, hcopy);
- dkim_error(dkim, "unable to allocate %d byte(s)",
+ dkim_error(dkim, "unable to allocate %zu byte(s)",
sizeof(DKIM_SET));
return DKIM_STAT_INTERNAL;
}
@@ -1146,7 +1146,7 @@ dkim_privkey_load(DKIM *dkim)
crypto = DKIM_MALLOC(dkim, sizeof(struct dkim_crypto));
if (crypto == NULL)
{
- dkim_error(dkim, "unable to allocate %d byte(s)",
+ dkim_error(dkim, "unable to allocate %zu byte(s)",
sizeof(struct dkim_crypto));
return DKIM_STAT_NORESOURCE;
}
@@ -1939,7 +1939,7 @@ dkim_siglist_setup(DKIM *dkim)
dkim->dkim_siglist = DKIM_MALLOC(dkim, len);
if (dkim->dkim_siglist == NULL)
{
- dkim_error(dkim, "unable to allocate %d byte(s)", len);
+ dkim_error(dkim, "unable to allocate %zu byte(s)", len);
return DKIM_STAT_NORESOURCE;
}
@@ -1953,7 +1953,7 @@ dkim_siglist_setup(DKIM *dkim)
int n;
dkim_error(dkim,
- "unable to allocate %d byte(s)",
+ "unable to allocate %zu byte(s)",
sizeof(DKIM_SIGINFO));
for (n = 0; n < c; n++)
DKIM_FREE(dkim, dkim->dkim_siglist[n]);
@@ -2337,7 +2337,7 @@ dkim_siglist_setup(DKIM *dkim)
if (dkim->dkim_siglist[c]->sig_sig == NULL)
{
dkim_error(dkim,
- "unable to allocate %d byte(s)",
+ "unable to allocate %zu byte(s)",
b64siglen);
return DKIM_STAT_NORESOURCE;
}
@@ -2904,7 +2904,7 @@ dkim_get_key(DKIM *dkim, DKIM_SIGINFO *s
if (sig->sig_key == NULL)
{
dkim_error(dkim,
- "unable to allocate %d byte(s)",
+ "unable to allocate %zu byte(s)",
osig->sig_b64keylen);
return DKIM_STAT_NORESOURCE;
}
@@ -3086,7 +3086,7 @@ dkim_get_key(DKIM *dkim, DKIM_SIGINFO *s
sig->sig_key = DKIM_MALLOC(dkim, sig->sig_b64keylen);
if (sig->sig_key == NULL)
{
- dkim_error(dkim, "unable to allocate %d byte(s)",
+ dkim_error(dkim, "unable to allocate %zu byte(s)",
sig->sig_b64keylen);
return DKIM_STAT_NORESOURCE;
}
@@ -3368,7 +3368,7 @@ dkim_eoh_sign(DKIM *dkim)
dkim->dkim_siglist = DKIM_MALLOC(dkim, sizeof(DKIM_SIGINFO **));
if (dkim->dkim_siglist == NULL)
{
- dkim_error(dkim, "failed to allocate %d byte(s)",
+ dkim_error(dkim, "failed to allocate %zu byte(s)",
sizeof(DKIM_SIGINFO *));
return DKIM_STAT_NORESOURCE;
}
@@ -3377,7 +3377,7 @@ dkim_eoh_sign(DKIM *dkim)
sizeof(struct dkim_siginfo));
if (dkim->dkim_siglist[0] == NULL)
{
- dkim_error(dkim, "failed to allocate %d byte(s)",
+ dkim_error(dkim, "failed to allocate %zu byte(s)",
sizeof(struct dkim_siginfo));
return DKIM_STAT_NORESOURCE;
}
@@ -3810,7 +3810,7 @@ dkim_eom_sign(DKIM *dkim)
{
sig->sig_error = DKIM_SIGERROR_KEYTOOSMALL;
dkim_error(dkim,
- "private key too small (%d bits, need at least %d)",
+ "private key too small (%u bits, need at least %u)",
sig->sig_keybits,
dkim->dkim_libhandle->dkiml_minkeybits);
return DKIM_STAT_SIGGEN;
@@ -3898,6 +3898,7 @@ dkim_eom_sign(DKIM *dkim)
Bug#728705: gdb fails on s390x with Couldn't write registers: Invalid argument
I can confirm this problem on s390x and s390 wheezy systems. gdb 7.0.1-2+b1 runs fine on s390 squeeze. Greetings, Martin Am 04.11.2013 14:35, schrieb Thibaut Paumard: Package: gdb Version: 7.6.1-1 Severity: important X-Debbugs-CC: debian-s...@lists.debian.org Dear Maintainer, gdb seems to be completely useless on s390x. I tried running it against various executables (both buggy and sane). gdb seems to launch the executable, however the subprocess doesn't seem to be doing anything. gdb just gives a message, but it does not even seem to consider the situation fatal and just seats there, apparently considering that the subprocess is running faultlessly. Example session on echo foo, notice how foo is not echoed: GDB SESSION ___ (sid_s390x-dchroot)thibaut@zelenka:~$ gdb --args echo foo GNU gdb (GDB) 7.6.1 (Debian 7.6.1-1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as s390x-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /bin/echo...(no debugging symbols found)...done. (gdb) run Starting program: /bin/echo foo Couldn't write registers: Invalid argument. (gdb) bt Target is executing. (gdb) quit A debugging session is active. Inferior 1 [process 18228] will be killed. Quit anyway? (y or n) y (sid_s390x-dchroot)thibaut@zelenka:~$ END GDB SESSION _ Kind regards, Thibaut. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: s390x Kernel: Linux 3.2.0-4-s390x (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages gdb depends on: ii gdbserver 7.6.1-1 ii libc6 2.17-93 ii libexpat1 2.1.0-4 ii liblzma5 5.1.1alpha+20120614-2 ii libncurses5 5.9+20130608-1 ii libpython2.7 2.7.5-8 ii libreadline6 6.2+dfsg-0.1 ii libtinfo5 5.9+20130608-1 ii zlib1g1:1.2.8.dfsg-1 Versions of packages gdb recommends: pn libc-dbg none Versions of packages gdb suggests: pn gdb-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725743: procps 1:3.3.8-2 FTBFS on ia64 and s390x
Am 09.10.2013 10:17, schrieb Craig Small: I've got most of these problems sorted out for the s390 (and the ia64 but you probably don't care about that). I'm stuck at with one of the more obscure ps flags. FAIL: ps SCHED_BATCH scheduler See [1] So.. what does this test do? It compiles [2] Runs the binary as test-schedbatch 18 Runs ps --no-header -o comm,cls,nice -a Expects the output to be test-schedbatch B 18 Most of my programs have TS instead of B. On my amd64 I see B it looks like this: COMMAND CLS NI bash TS 0 test-schedbatch B 18 ps TS 0 So.. what does an s390 see? I tried compiling this small program and got a screenful of error messages so I'm stuck. 1: https://buildd.debian.org/status/fetch.php?pkg=procpsarch=s390xver=1%3A3.3.8-2stamp=1370603323 2: https://gitorious.org/procps/procps/source/e6a78f2745ca6c7ceed4406d3ce5397e77518b11:testsuite/ps.test/test-schedbatch.c Sorry Craig, but I can't reproduce your problem here: I've built procps 3.3.8-2 from sid successfully on a wheezy s390x system (unpacking orig source + patch and then running debuild) Here the snippet from the build output: --8- === ps tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using ./config/unix.exp as tool-and-target-specific interface file. Running ./ps.test/ps_output.exp ... Running ./ps.test/ps_personality.exp ... Running ./ps.test/ps_sched_batch.exp ... === ps Summary === # of expected passes9 # of untested testcases 1 WARNING: Couldn't find tool init file Test Run By mgrimm on Wed Oct 9 11:21:42 2013 Native configuration is s390x-ibm-linux-gnu --8- Manual test seems fine, too: mgrimm@build:procps-ng-3.3.8 debian/procps/bin/ps -V procps-ng version 3.3.8 mgrimm@build:procps-ng-3.3.8 ./testsuite/test-schedbatch 18 ! mgrimm@build:procps-ng-3.3.8 debian/procps/bin/ps --no-header -o comm,cls,nice -a test-schedbatch B 18 ps TS 0 Greetings Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#723739: resource-agents: send_arp sends incorrect arp packets on big endian machines with 64bit wide u_long datatype.
Package: resource-agents
Version: 1:3.9.2-5+deb7u1
Severity: important
Tags: upstream patch
Dear Maintainer,
The send_arp binary (libnet-version) doesn't work on big endian systems
that use 64bit for datatype u_long. In our case this means that
heartbeat with VIPs doesn't work because the needed ARP broadcast on IP
failover is broken.
Network traces showed that instead of the ip given on commandline 0.0.0.0
was used in all packets.
The problem is caused by incorrect use of u_long as return value of
libnet_name2addr4 (libnet1.1 version returns u_int32_t). This variable
is casted to u_char* and given to libnet_build_arp, which copies the
first 4 bytes to the arp packet. On big endian systems with 64bit wide
long datatype these 4 bytes are 0x00 and the ip is in byte 5 to 8.
Attached patch changes the type of the variable ip to u_int32_t for
libnet1.1-code.
The problem seems to be fixed in latest upstream version. The fix in
upstream can be seen here:
https://github.com/ClusterLabs/resource-agents/commit/1eea8a6cb3b6a58908276b23e66ce282b1733c9e
Greetings,
Martin
-- System Information:
Debian Release: 7.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: s390x
Kernel: Linux 3.2.0-4zivit1-s390x (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages resource-agents depends on:
ii cluster-glue 1.0.9+hg2665-1
ii libc6 2.13-38
ii libglib2.0-0 2.33.12+really2.32.4-5
ii libnet1 1.1.4-2.1
ii libplumb2 1.0.9+hg2665-1
ii libplumbgpl2 1.0.9+hg2665-1
ii python2.7.3-4
resource-agents recommends no packages.
resource-agents suggests no packages.
-- no debconf information
--- a/tools/send_arp.libnet.c 2011-06-29 14:51:48.0 +0200
+++ b/tools/send_arp.libnet.c 2013-09-19 09:45:44.691470508 +0200
@@ -49,15 +49,17 @@
#ifdef HAVE_LIBNET_1_0_API
# define LTYPE struct libnet_link_int
+# define IPTYPE u_long
#endif
#ifdef HAVE_LIBNET_1_1_API
# define LTYPE libnet_t
+# define IPTYPE u_int32_t
#endif
#define PIDDIR HA_VARRUNDIR / PACKAGE
#define PIDFILE_BASE PIDDIR /send_arp-
-static int send_arp(LTYPE* l, u_long ip, u_char *device, u_char mac[6]
+static int send_arp(LTYPE* l, IPTYPE ip, u_char *device, u_char mac[6]
, u_char *broadcast, u_char *netmask, u_short arptype);
static char print_usage[]={
@@ -133,7 +135,7 @@
char* macaddr;
char* broadcast;
char* netmask;
- u_long ip;
+ IPTYPE ip;
u_char src_mac[6];
LTYPE* l;
int repeatcount = 1;
@@ -388,7 +390,7 @@
#ifdef HAVE_LIBNET_1_0_API
int
-send_arp(struct libnet_link_int *l, u_long ip, u_char *device, u_char *macaddr, u_char *broadcast, u_char *netmask, u_short arptype)
+send_arp(struct libnet_link_int *l, IPTYPE ip, u_char *device, u_char *macaddr, u_char *broadcast, u_char *netmask, u_short arptype)
{
int n;
u_char *buf;
@@ -465,7 +467,7 @@
#ifdef HAVE_LIBNET_1_1_API
int
-send_arp(libnet_t* lntag, u_long ip, u_char *device, u_char macaddr[6], u_char *broadcast, u_char *netmask, u_short arptype)
+send_arp(libnet_t* lntag, IPTYPE ip, u_char *device, u_char macaddr[6], u_char *broadcast, u_char *netmask, u_short arptype)
{
int n;
u_char *target_mac;
Bug#719993: linux-image-3.2.0-4-s390x: hangs hard after a few hours
I wan't to confirm this problem. We have several wheezy installations (s390 and s390x) running unter z/VM 5.4 on IBM System z 196 EC and all suffer from this problem. Some systems started to hang after few minutes, others kept running for days or weeks before the problem occured. In PerfKit the hanging systems are shown to go high on CPU usage. There is no I/O activity to devices. Memory usage is normal, so OOM can't be the cause of the problem. I've build custom kernels with Aurelien's patch applied and installed them on all our wheezy systems two days ago. No hangs so far. Greetings Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671238: linux-image-2.6.32-5-s390x: no CMM with z/VM Resource Manager possible
Am 03.05.2012 09:06 schrieb Bastian Blank: severity 671238 important thanks On Wed, May 02, 2012 at 07:12:45PM +0200, Martin Grimm wrote: CMM (Cooperative Memory Management) can't be controlled from z/VM Resource Manager because the core component (cmm) is builtin and the needed communication module (smsgiucv) is build as a module. Loading the module smsgiucv doesn't help. Which versions are affected? I believe both Squeeze (2.6.32) and Wheezy (3.2). Bastian Yes, I can confirm the problem for both versions. Martin -- Martin Grimm Zentrum für Informationsverarbeitung und Informationstechnik Dienstsitz Bonn An der Küppe 2 53225 Bonn Tel.: +49 228 99 680 5298 e-mail: extern.martin.gr...@zivit.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671238: linux-image-2.6.32-5-s390x: no CMM with z/VM Resource Manager possible
Package: linux-2.6 Version: 2.6.32-41 Severity: normal CMM (Cooperative Memory Management) can't be controlled from z/VM Resource Manager because the core component (cmm) is builtin and the needed communication module (smsgiucv) is build as a module. Loading the module smsgiucv doesn't help. Building the kernel with cmm as a module an loading it autoloads smsgiucv before and controlling cmm via z/VM works fine. Greetings Martin -- Package-specific info: ** Version: Linux version 2.6.32-5-s390x (Debian 2.6.32-41) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan 16 15:10:12 UTC 2012 ** Command line: ro dasd=200-21f vmpoff=LOGOFF root=/dev/dasdb1 elevator=deadline BOOT_IMAGE=0 ** Not tainted ** Kernel log: [0.00] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) [0.00] Memory: 1013884k/1048576k available (3475k kernel code, 0k reserved, 1844k data, 220k init) [0.00] Write protected kernel read-only data: 0x12000 - 0x4dcfff [0.00] SLUB: Genslabs=13, HWalign=256, Order=0-3, MinObjects=0, CPUs=32, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] console [ttyS0] enabled [0.102661] Calibrating delay loop (skipped)... 7668.00 BogoMIPS preset [0.102706] Security Framework initialized [0.102720] SELinux: Disabled at boot. [0.102747] Mount-cache hash table entries: 256 [0.103105] Initializing cgroup subsys ns [0.103537] Initializing cgroup subsys cpuacct [0.103551] Initializing cgroup subsys devices [0.103556] Initializing cgroup subsys freezer [0.103561] Initializing cgroup subsys net_cls [0.103867] cpu: 4 configured CPUs, 0 standby CPUs [0.104060] cpu: Processor 0 started, address 0, identification 06A18A [0.105039] cpu: Processor 1 started, address 0, identification 06A18A [0.105317] cpu: Processor 2 started, address 0, identification 06A18A [0.105519] cpu: Processor 3 started, address 0, identification 06A18A [0.105546] Brought up 4 CPUs [0.105569] CPU0 attaching sched-domain: [0.105574] domain 0: span 0-3 level MC [0.105577] groups: group 01e3d218 cpus 0 group 01e4d218 cpus 1 group 01e5d218 cpus 2 group 01e6d218 cpus 3 [0.105585] CPU1 attaching sched-domain: [0.105588] domain 0: span 0-3 level MC [0.105590] groups: group 01e4d218 cpus 1 group 01e5d218 cpus 2 group 01e6d218 cpus 3 group 01e3d218 cpus 0 [0.105598] CPU2 attaching sched-domain: [0.105600] domain 0: span 0-3 level MC [0.105602] groups: group 01e5d218 cpus 2 group 01e6d218 cpus 3 group 01e3d218 cpus 0 group 01e4d218 cpus 1 [0.105610] CPU3 attaching sched-domain: [0.105612] domain 0: span 0-3 level MC [0.105614] groups: group 01e6d218 cpus 3 group 01e3d218 cpus 0 group 01e4d218 cpus 1 group 01e5d218 cpus 2 [0.106125] devtmpfs: initialized [0.106618] regulator: core version 0.5 [0.106712] NET: Registered protocol family 16 [0.107752] bio: create slab bio-0 at 0 [0.177270] NET: Registered protocol family 2 [0.177454] IP route cache hash table entries: 32768 (order: 6, 262144 bytes) [0.177936] TCP established hash table entries: 65536 (order: 8, 1048576 bytes) [0.179254] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [0.180569] TCP: Hash tables configured (established 65536 bind 65536) [0.180575] TCP reno registered [0.180953] NET: Registered protocol family 1 [0.181033] Unpacking initramfs... [0.388320] Freeing initrd memory: 7962k freed [0.389568] audit: initializing netlink socket (disabled) [0.389600] type=2000 audit(1332325754.121:1): initialized [0.390265] HugeTLB registered 1 MB page size, pre-allocated 0 pages [0.392203] VFS: Disk quotas dquot_6.5.2 [0.392292] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [0.392424] msgmni has been set to 1997 [0.393146] alg: No test for stdrng (krng) [0.393214] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) [0.393222] io scheduler noop registered [0.393228] io scheduler anticipatory registered [0.393234] io scheduler deadline registered (default) [0.393298] io scheduler cfq registered [0.393927] cio: Channel measurement facility initialized using format extended (mode autodetected) [0.394980] TCP cubic registered [0.395115] NET: Registered protocol family 10 [0.396450] Mobile IPv6 [0.396460] NET: Registered protocol family 17 [0.396524] PM: Resume from disk failed. [0.396529] registered taskstats version 1 [0.396704] Initalizing network drop monitor service [0.396783] Freeing unused kernel memory: 220k freed [0.415296] udev[67]: starting version 164 [0.435185] qeth: loading core functions [0.441400] dasd-fba 0.0.0200: New FBA DASD 9336/10 (CU 6310/80) with 512 MB and
Bug#513256: release-notes: Risc of loss of data on s390 architecture when running under not fully updated z/VM.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: release-notes Severity: important The release notes should warn that running Debian Lenny under z/VM 5.3 prior to service level 802 will likely lead to filesystem corruption and at least RSU 5305 should be applied before running or upgrading to Lenny. Starting with Kernel 2.6.25, Linux on the s390 architecture running under z/VM hypervisor uses a new CCW for DASD access that triggers an error in z/VM leading to I/O errors and finally file system inconsistency. This error could be confirmed running z/VM 5.3 with RSU (Recommended Service Update) 5304 and was fixed by IBM in RSU 5305 (service level 802). IBM problem report: http://www-01.ibm.com/support/docview.wss?uid=isg1VM64417 (in the problem report a z/OS guest ist mentioned, nevertheless this problem also affects linux guests). Greetings, Martin - -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: s390 (s390x) Kernel: Linux 2.6.26-1-s390x (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash - -- - Martin Grimm IT-Consultant Millenux GmbH Tel. +49 711 88770-178 Lilienthalstraße 2/1 Fax +49 711 88770-349 70825 Korntal/Stuttgartmartin.gr...@millenux.com http://www.millenux.com Geschäftsführer: Markus Klingspor, Thomas Uhl Sitz und Amtsgericht Stuttgart, HRB 21058 - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJfzxVNI3HwMgXf7ERAuv6AJ9IfpunW6Jji/qR0K2bf/26Tgk1IwCdEGPb 63wyNel40FKUfugggBvLUR0= =VS1y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#408375: Missing support for qeth network devices in layer2 mode makes debian installer unuseable (patch attached)
Frans Pop schrieb: On Thursday 25 January 2007 13:24, Martin Grimm wrote: Attached patch for s390-netdevice adds the possibility to set the device to layer2 mode before activating it. Also the configuration file in /etc/sysconfig/hardware/config file for qeth device will be set up correctly for normal system startup. Your patch has been applied and a new version uploaded (with minor modifications). It would be great if you could test the new version and let us knows if it works correctly. It should be available in the next daily built image, i.e. in about 24 hours. Thanks, FJP Tested with daily built from Feb 01 2007. Works correctly :-) Greetings, Martin -- -- Martin Grimm [EMAIL PROTECTED] Mi||enux phone: +49.711.88770.300 Lilienthalstrasse 2 fax: +49.711.88770.349 70825 Stuttgart-Korntal, Germany Key fingerprint: 9BB0 AFE1 C133 F88B A27F 4F12 348D C7C0 C817 7FB1 -- Linux without limits: http://linux.zSeries.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408375: Missing support for qeth network devices in layer2 mode makes debian installer unuseable (patch attached)
Package: s390-netdevice
Version: 0.0.14
Severity: important
Installing debian etch on IBM zSeries(s390) fails if the network
device used for installation is a qeth device in layer2 mode.
(e.g. a NIC connected to a z/VM vswitch in ethernet mode).
qeth defaults to layer3 mode and setting the device online fails
if mode is not set up correctly.
Without network connectivity installation can't proceed.
Attached patch for s390-netdevice adds the possibility to set the
device to layer2 mode before activating it. Also the configuration
file in /etc/sysconfig/hardware/config file for qeth device
will be set up correctly for normal system startup.
Greetings,
Martin
--
--
Martin Grimm [EMAIL PROTECTED]
Mi||enux phone: +49.711.88770.300
Lilienthalstrasse 2 fax: +49.711.88770.349
70825 Stuttgart-Korntal, Germany
Key fingerprint: 9BB0 AFE1 C133 F88B A27F 4F12 348D C7C0 C817 7FB1
--
Linux without limits: http://linux.zSeries.org
--- s390-netdevice-0.0.14/debian/s390-netdevice.templates 2006-10-24 19:14:12.0 +0200
+++ s390-netdevice-0.0.15/debian/s390-netdevice.templates 2007-01-17 13:51:38.0 +0100
@@ -55,6 +55,7 @@
channels = ${device0}, ${device1}, ${device2}
port = ${port}
portname = ${portname}
+ layer2 = ${layer2}
Template: s390-netdevice/qeth/no
Type: error
@@ -81,6 +82,16 @@
_Description: Port:
Please enter a relative port for this connection.
+Template: s390-netdevice/qeth/layer2
+Type: boolean
+Default: false
+_Description: layer2 mode
+ Do you want to run this card in layer2-Mode?
+ This will make the OSA-Express adapter keep the MAC
+ addresses of IPV4 packets. By default, the
+ OSA-Express adapter removes LLC headers from incoming
+ IPv4 packets.
+
Template: s390-netdevice/iucv/confirm
Type: boolean
Default: true
diff -Naur s390-netdevice-0.0.14/netdevice.c s390-netdevice-0.0.15/netdevice.c
--- s390-netdevice-0.0.14/netdevice.c 2006-10-24 19:14:12.0 +0200
+++ s390-netdevice-0.0.15/netdevice.c 2007-01-22 13:54:09.0 +0100
@@ -58,6 +58,7 @@
{
struct channel *channels[3];
int port;
+ int layer2;
char portname[32];
} qeth;
struct
@@ -104,6 +105,7 @@
GET_CTC_CHANNELS,
GET_CTC_PROTOCOL,
GET_QETH_DEVICE,
+ GET_QETH_LAYER2,
GET_QETH_PORT,
GET_QETH_PORTNAME,
GET_IUCV_DEVICE,
@@ -447,6 +449,22 @@
return WANT_NEXT;
}
+static enum state_wanted get_qeth_layer2 (void)
+{
+ char *ptr;
+ int ret = my_debconf_input (critical, TEMPLATE_PREFIX qeth/layer2, ptr);
+
+ if (ret == 30)
+ return WANT_BACKUP;
+ if (ret)
+ return WANT_ERROR;
+
+ device_current-qeth.layer2 = strstr(ptr, true) ? 1 : 0;
+
+ return WANT_NEXT;
+
+}
+
static enum state_wanted get_qeth_port (void)
{
char *ptr;
@@ -561,7 +579,7 @@
return WANT_ERROR;
}
-static enum state_wanted write_ccwgroup (const char *driver_name, const char *device_name, const char *group)
+static enum state_wanted write_ccwgroup (const char *driver_name, const char *device_name, const char *group, int layer2)
{
struct sysfs_device *device;
struct sysfs_driver *driver;
@@ -583,6 +601,15 @@
if (!device)
return WANT_ERROR;
+ if (layer2)
+ {
+ attr = sysfs_get_device_attr (device, layer2);
+ if (!attr)
+ return WANT_ERROR;
+ if (sysfs_write_attribute (attr, 1, 1) 0)
+ return WANT_ERROR;
+ }
+
attr = sysfs_get_device_attr (device, online);
if (!attr)
return WANT_ERROR;
@@ -605,7 +632,7 @@
snprintf (buf, sizeof (buf), %s,%s\n, device_current-ctc.channels[0]-name, device_current-ctc.channels[1]-name);
- ret = write_ccwgroup (ctc, device_current-ctc.channels[0]-name, buf);
+ ret = write_ccwgroup (ctc, device_current-ctc.channels[0]-name, buf, 0);
if (ret)
return ret;
@@ -632,7 +659,7 @@
snprintf (buf, sizeof (buf), %s,%s,%s\n, device_current-qeth.channels[0]-name, device_current-qeth.channels[1]-name, device_current-qeth.channels[2]-name);
- ret = write_ccwgroup (qeth, device_current-qeth.channels[0]-name, buf);
+ ret = write_ccwgroup (qeth, device_current-qeth.channels[0]-name, buf, device_current-qeth.layer2);
if (ret)
return ret;
@@ -643,6 +670,11 @@
snprintf (buf, sizeof (buf), CCWGROUP_CHANS=(%s %s %s)\n, device_current-qeth.channels[0]-name, device_current-qeth.channels[1]-name, device_current-qeth.channels[2]-name);
fwrite (buf, strlen (buf), 1, config);
+ if (device_current-qeth.layer2)
+ {
+ snprintf (buf, sizeof (buf), QETH_OPTIONS=layer2\n);
+ fwrite (buf, strlen (buf), 1, config);
+ }
fclose (config);
@@ -696,6 +728,9 @@
case GET_QETH_DEVICE:
state_want = get_qeth_device ();
break;
+ case GET_QETH_LAYER2:
+state_want = get_qeth_layer2 ();
+break;
case GET_QETH_PORT:
state_want = get_qeth_port ();
break;
@@ -767,6 +802,9 @@
state = CONFIRM_CTC
