Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Fri, Jul 31, 2009 at 06:00:48PM -0400, Carlos O'Donell wrote:
On Fri, Jul 31, 2009 at 5:26 PM, John David
Anglind...@hiauly1.hia.nrc.ca wrote:
I don't have more details... The idea is as Carlos outlined. There's
code in the binutils elf32-hppa.c and elf64-hppa.c files to implement
the above for dynamic libraries. That's what made me think of it.
Binutils is not involved in the kernel module loader, instead
arch/parisc/kernel/module.c (get_fdesc) chooses where the gp will
point to.
If you set gp to the middle of the GOT table, *and* implement
long/short ldd access on 64-bit, then you would get a total of 8191
possible slots per module.
Personally I think the lower risk, quicker fix, is to implement a fix
for 64-bit kernels that uses ldd in format 3 for all offsets 15
bytes, and thus allow you to set MAX_GOTS to 4095.
Note: ldd format 3 can't be used to load immediate values between 15
and -16 bytes.
Is it as simple as:
diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
index ef5caf2..0502fab 100644
--- a/arch/parisc/kernel/module.c
+++ b/arch/parisc/kernel/module.c
@@ -82,13 +82,6 @@
return -ENOEXEC;\
}
-/* Maximum number of GOT entries. We use a long displacement ldd from
- * the bottom of the table, which has a maximum signed displacement of
- * 0x3fff; however, since we're only going forward, this becomes
- * 0x1fff, and thus, since each GOT entry is 8 bytes long we can have
- * at most 1023 entries */
-#define MAX_GOTS 1023
-
/* three functions to determine where in the module core
* or init pieces the location is */
static inline int in_init(struct module *me, void *loc)
@@ -126,6 +119,14 @@ struct stub_entry {
};
#endif
+/* Maximum number of GOT entries. We use a long displacement ldd from
+ * the bottom of the table, which has 16-bit signed displacement from
+ * %dp. Because we only use the forward direction, we're limited to
+ * 15-bits - 1, and because each GOT entry is 8-bytes wide, we're limited
+ * to 4095 entries.
+ */
+#define MAX_GOTS (((1 15) - 1) / sizeof(struct got_entry))
+
/* Field selection types defined by hppa */
#define rnd(x) (((x)+0x1000)~0x1fff)
/* fsel: full 32 bits */
@@ -151,6 +152,15 @@ static inline int reassemble_14(int as14)
((as14 0x2000) 13));
}
+/* Unusual 16-bit encoding, for wide mode only. */
+static inline int reassemble_16a(int as16)
+{
+ int s, t;
+ t = (as16 1) 0x;
+ s = (as16 0x8000);
+ return (t ^ s ^ (s 1)) | (s 15);
+}
+
static inline int reassemble_17(int as17)
{
return (((as17 0x1) 16) |
@@ -460,12 +470,16 @@ static Elf_Addr get_stub(struct module *me, unsigned long
value, long addend,
*/
switch (stub_type) {
case ELF_STUB_GOT:
+ unsigned int d = get_got(me, value, addend) 0x7fff;
+
stub-insns[0] = 0x537b;/* ldd 0(%dp),%dp */
stub-insns[1] = 0x53610020;/* ldd 10(%dp),%r1 */
stub-insns[2] = 0xe820d000;/* bve (%r1)*/
stub-insns[3] = 0x537b0030;/* ldd 18(%dp),%dp */
- stub-insns[0] |= reassemble_14(get_got(me, value, addend)
0x3fff);
+ if (d 15)
+ stub-insns[0] |= reassemble_16a(d);
+
break;
case ELF_STUB_MILLI:
stub-insns[0] = 0x2020;/* ldil 0,%r1 */
I don't think we need to worry about the initial 15-bytes displacement,
since they're all within the first got_entry? (The resulting assembly
looks alright from a 64-bit toolchain:
k...@shortfin ~ $ cat foo.S
.text
a:
ldd 32760(%r27),%r27
break 0,0
a:
0: 53 7b ff f0 ldd 7ff8(dp),dp
int main(void) {
unsigned int opcode = 0x537b;
opcode |= re_assemble_16(32760);
printf(0x%x\n, opcode);
return 0;
}
k...@shortfin ~ $ ./foo
0x537bfff0
Looks pretty happy?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517183: irqbalance: segv on startup
On Sun, Mar 15, 2009 at 02:23:09PM +, Stephen Gran wrote: This one time, at band camp, Kyle McMartin said: On Thu, Feb 26, 2009 at 09:08:54AM +, Stephen Gran wrote: sg...@spontini:~$ sudo /usr/sbin/irqbalance --debug Package 0: cpu mask is 0001 (workload 0) Cache domain 0: cpu mask is 0001 (workload 0) CPU number 0 (workload 0) Package 2: cpu mask is 0004 (workload 0) Cache domain 2: cpu mask is 0004 (workload 0) CPU number 2 (workload 0) Segmentation fault Hrm. Cool. I've been hoping that Neil was going to do a new upsteam release of irqbalance and save me having to patch once and then swap it out... I'll kick on my ia64 and take a poke tonight. Any chance of you uploading a version with my patch to s-p-u? We have several d.o machines where it won't run because of this issue. If you don't have time to deal with it, I can ask the RT and do an NMU for it. Also, it would of course be nice to have this fixed in unstable :) Sure, I can try. It's been a while, if you don't see it there by tomorrow, please do it yourself, as it means I've made a hash of it. regards, Kyle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517183: irqbalance: segv on startup
On Thu, Feb 26, 2009 at 09:08:54AM +, Stephen Gran wrote: sg...@spontini:~$ sudo /usr/sbin/irqbalance --debug Package 0: cpu mask is 0001 (workload 0) Cache domain 0: cpu mask is 0001 (workload 0) CPU number 0 (workload 0) Package 2: cpu mask is 0004 (workload 0) Cache domain 2: cpu mask is 0004 (workload 0) CPU number 2 (workload 0) Segmentation fault Hrm. Cool. I've been hoping that Neil was going to do a new upsteam release of irqbalance and save me having to patch once and then swap it out... I'll kick on my ia64 and take a poke tonight. regards, Kyle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510103: irqbalance detects incorrect number of CPUs on newer kernels
On Fri, Jan 02, 2009 at 09:07:29PM +0100, Janusz Dziemidowicz wrote:
2009/1/1 Kyle McMartin k...@infradead.org:
Hrm, we're carrying a fairly large patch against irqbalance that deals
with cpu parsing in Fedora that hasn't made it upstream for some reason.
I'll poke...
In the meantime:
Index: cputree.c
===
--- cputree.c (revision 19)
+++ cputree.c (working copy)
@@ -319,7 +319,8 @@
return;
do {
entry = readdir(dir);
-if (entry strlen(entry-d_name)3
strstr(entry-d_name,cpu)) {
+ if (entry strlen(entry-d_name)3
memcmp(entry-d_name,cpu,3) == 0
+ isdigit(entry-d_name[3]))
char new_path[PATH_MAX];
sprintf(new_path, /sys/devices/system/cpu/%s,
entry-d_name);
do_one_cpu(new_path);
That's exactly the same way I've fixed this (I was about to post it
here). Thanks anyway:)
Excellent, cheers.
Kyle
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508045: Problems with Etch-Lenny upgrade
On Thu, Jan 01, 2009 at 01:07:21AM -0700, Kurt Fitzner wrote: Sorry to take so long to get back to you. Kyle McMartin wrote: What was the starting kernel version? The latest stable etch kernel? Yes. I performed a dist-upgrade while it was still on etch before I altered sources.list to lenny. I suspect the fault for this lies in glibc trickery, though I'm not sure off-hand. I don't recall any changes in the kernel to these syscalls in the gap of versions between etch and lenny. I did some searches when I was in the middle of trying to get the upgrade to work. Other people who have experienced the problem with df were advised to check their /proc. Everything relevant to df in my /proc seemed to be ok, so I wondered if maybe coreutils switched from parsing files in /proc to syscalls in the upgrade? That's just a shot in the dark, though. Hi Kurt, I'll look into this, bootstrapping the relevant chroots now. regards, Kyle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510103: irqbalance detects incorrect number of CPUs on newer kernels
On Mon, Dec 29, 2008 at 11:14:07AM +0100, Janusz Dziemidowicz wrote:
irqbalance detects incorrect number of processors on kernel 2.6.26. I
have a single dual core processor (/proc/cpuinfo available below), but
irqbalance debug shows:
Hrm, we're carrying a fairly large patch against irqbalance that deals
with cpu parsing in Fedora that hasn't made it upstream for some reason.
I'll poke...
In the meantime:
Index: cputree.c
===
--- cputree.c (revision 19)
+++ cputree.c (working copy)
@@ -319,7 +319,8 @@
return;
do {
entry = readdir(dir);
-if (entry strlen(entry-d_name)3
strstr(entry-d_name,cpu)) {
+ if (entry strlen(entry-d_name)3
memcmp(entry-d_name,cpu,3) == 0
+ isdigit(entry-d_name[3]))
char new_path[PATH_MAX];
sprintf(new_path, /sys/devices/system/cpu/%s,
entry-d_name);
do_one_cpu(new_path);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508045: Problems with Etch-Lenny upgrade
On Fri, Dec 26, 2008 at 12:57:00PM -0700, Kurt Fitzner wrote: Perhaps I should mention a problem I had upgrading Etch to Lenny. I made a Debian bug report about it because it seemed like it might be a general Debian issue, but now I'm not so sure. The gist of the issue is that df stops working after coreutils is upgraded until the system is rebooted with a new kernel. This causes any package upgrade that depends on df (such as mysql) to fail - which causes the whole upgrade procedure to fail. I managed to get it going again by replacing df with a shell script that just echo'ed a pretend output for df. What was the starting kernel version? The latest stable etch kernel? I suspect the fault for this lies in glibc trickery, though I'm not sure off-hand. I don't recall any changes in the kernel to these syscalls in the gap of versions between etch and lenny. regards, Kyle -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#364562: linux32 doesn't work on hppa64 kernels
On Sun, Dec 21, 2008 at 11:18:33AM +0100, Moritz Muehlenhoff wrote: I spent some time trying to fix this a while ago at Jeff Bailey's request, but it required nasty invasive changes that I didn't have time to debug. (It's not really an improvement when /sbin/init fails to exec...) If I have some time this week, I'll dust off the diff and see if I can finagle it to work. Does this error still occur with more recent kernel versions? Shouldn't, the code wasn't actually implemented when the bug was filed, but I've since (years...) added it. k...@shortfin:~$ dchroot I: [sid chroot] Running login shell: '/bin/bash' (sid)k...@shortfin:~$ uname -a Linux shortfin 2.6.28-rc7-09492-g933cc21-dirty #6 SMP Thu Dec 18 10:13:40 PST 2008 parisc GNU/Linux (sid)k...@shortfin:~$ logout k...@shortfin:~$ uname -a Linux shortfin 2.6.28-rc7-09492-g933cc21-dirty #6 SMP Thu Dec 18 10:13:40 PST 2008 parisc64 GNU/Linux -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500985: irqbalance update in etch?
On Wed, Oct 01, 2008 at 03:12:38PM +0200, Peter Palfrader wrote: + * Non maintainer upload. + * irqbalance would segfault on startup when /proc/interrupts contains +an interrupt with a number of 256 or larger, since internally it +stored data in a fixed-length array. Newer versions (say 0.55) have +replaced the data structure with a list so this is fixed there. For +now we just skip interrupts with such high numbers, since it's the +least invasive approach during the stable cycle. + The patch looks fine to me. I mean, the machines with higher interrupts were crashing anyway, so simply chugging along ignoring them seems like an improvement. regards, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486069: Bug#494191: eperl: Hangs on hppa
On Fri, Aug 08, 2008 at 06:30:40PM +0300, Niko Tyni wrote: Note that inn and inn2 have since been fixed AFAIK, so there's something like 26 more suspected packages left. Could you please post the list here (to [EMAIL PROTECTED]) There's likely enough folks here who can follow proper NMU procedure to upload the fixes. regards, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464953: Amd64 hotfix
On Mon, Feb 11, 2008 at 01:54:35PM -0500, Ivan Jager wrote: I modified the hotfix so it will also patch compat_sys_vmsplice, which would be important on amd64 boxen with x86 compatibility enabled. these hotfixes are so completely wrong, it's not even funny. you're playing russian roulette with the return value. 0: b8 da ff ff ff mov$0xffda,%eax 5: c3 retq is more correct (return -ENOSYS) regards, kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458133: Details, please
On Mon, Dec 31, 2007 at 01:00:10PM -0600, Steve M. Robbins wrote: 00:05 pusling lamont: what is bus error on hppa ? 00:06 lamont pusling: unaligned load/store 00:06 lamont pusling: more specically, valid address, permission fault 00:06 pusling lamont: is unaligned load/store enough to make builds fail ? 00:06 lamont pusling: was - I turned that off rather recently So it sounds to me like there are two issues: 1. There is a bug, somewhere, that is generating an unaligned access correct. 2. HPPA can be configured to handle, somehow, unaligned accesses. the default mode is for unaligned accesses to be trapped, logged and emulated. lamont sets it to coredump for ease of getting a backtrace on the buildds. Your contention is that HPPA buildd machines should be reconfigured to handle unaligned access. That's fair enough, though in the past it has been claimed that this imposes a large performance penalty [1]. indeed it does. unaligned accesses are definitely a bug, unfortunately lacking manpower to fix all of them. Irrespective of how the buildd machines are configured, however, there is a bug. I think it should be tracked. agreed. [1] http://lists.debian.org/debian-devel/2007/11/msg00871.html -Steve cheers, kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458461: irqbalance: Please add LSB formatted dependency info in init.d script
On Mon, Dec 31, 2007 at 06:23:35PM +0100, Petter Reinholdtsen wrote: +### BEGIN INIT INFO +# Provides: irqbalance +# Required-Start:$remote_fs $syslog +# Required-Stop: $remote_fs $syslog +# Default-Start: 2 3 4 5 +# Default-Stop: 0 1 6 +### END INIT INFO looks good, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436490: irqbalance silently dies
On Wed, Aug 08, 2007 at 01:59:43AM +0530, Ritesh Raj Sarraf wrote: Package: irqbalance Version: 0.55-2 Severity: grave Justification: renders package unusable This is the current description of the package in Debian. irqbalance - Daemon to balance interrupts for SMP systems My understanding of a daemon is that the process keeps running in the background. But in case of irqbalance, the process silently exits. There are no messages logged into syslog or dmesg. It didn't die. It only rebalances once for a single socket, multi-core system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436143: minor fix in irqbalance initscript
On Sun, Aug 05, 2007 at 11:22:27PM +0530, Ritesh Raj Sarraf wrote: Package: irqbalance Version: 0.55-2 Severity: normal Tags: patch cool, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426391: linux-2.6: [hppa] parisc64-smp - kernel panic on boot
On Fri, Jun 29, 2007 at 12:30:07AM +0200, Frans Pop wrote: found 426391 2.6.21-5 thanks On Monday 28 May 2007 15:06, Frans Pop wrote: Kernel panic - not syncing: Kernel Fault This kernel panic still happens with 2.6.21-5. Yeah, I'll get the patch into SVN soon... Sorry, Kyle M. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430741: new chipsets for 915resolution
Package: 915resolution
Severity: wishlist
Upstream seems to be slow at updating the list of supported chipsets,
if Debian will support -i810 on i965GM and newer.
02-new-chipsets.dpatch is inline:
#! /bin/sh /usr/share/dpatch/dpatch-run
## 02-new-chipsets.dpatch by [EMAIL PROTECTED]
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: No description.
@DPATCH@
diff -urNad 915resolution-0.5.2~/915resolution.c
915resolution-0.5.2/915resolution.c
--- 915resolution-0.5.2~/915resolution.c2007-06-26 17:04:05.0
+
+++ 915resolution-0.5.2/915resolution.c 2007-06-26 17:10:39.0 +
@@ -56,12 +56,12 @@
typedef enum {
CT_UNKWN, CT_845G, CT_855GM, CT_865G, CT_915G, CT_915GM, CT_945G, CT_945GM,
-CT_946GZ, CT_965Q, CT_965G
+CT_946GZ, CT_965Q, CT_965G, CT_965GM, CT_G33, CT_Q33, CT_Q35
} chipset_type;
char * chipset_type_names[] = {
UNKNOWN, 845G, 855GM, 865G, 915G, 915GM, 945G, 945GM,
-946GZ, 965Q, 965G
+946GZ, 965Q, 965G, 965GM, G33, Q33, Q35
};
typedef enum {
@@ -221,6 +221,22 @@
type = CT_965G;
break;
+case 0x2a008086:
+type = CT_965GM;
+break;
+
+case 0x29c08086:
+type = CT_G33;
+break;
+
+case 0x29d08086:
+type = CT_Q33;
+break;
+
+case 0x29b08086:
+type = CT_Q35;
+break;
+
default:
type = CT_UNKWN;
break;
@@ -507,6 +523,10 @@
case CT_946GZ:
case CT_965Q:
case CT_965G:
+case CT_965GM:
+case CT_G33:
+case CT_Q33:
+case CT_Q35:
outl(0x8090, 0xcf8);
map-b1 = inb(0xcfd);
map-b2 = inb(0xcfe);
@@ -557,6 +577,10 @@
case CT_946GZ:
case CT_965Q:
case CT_965G:
+case CT_965GM:
+case CT_G33:
+case CT_Q33:
+case CT_Q35:
outl(0x8090, 0xcf8);
outb(map-b1, 0xcfd);
outb(map-b2, 0xcfe);
@@ -804,6 +828,18 @@
else if (!strcmp(argv[index], 965G)) {
*forced_chipset = CT_965G;
}
+else if (!strcmp(argv[index], 965GM)) {
+*forced_chipset = CT_965GM;
+}
+else if (!strcmp(argv[index], G33)) {
+*forced_chipset = CT_G33;
+}
+else if (!strcmp(argv[index], Q33)) {
+*forced_chipset = CT_Q33;
+}
+else if (!strcmp(argv[index], Q35)) {
+*forced_chipset = CT_Q35;
+}
else {
*forced_chipset = CT_UNKWN;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#145412: xserver-xfree86: [ati/atimisc] CPIO support disabled on ia64 (Debian patch #450), but MMIO not supported for Mach64 GR rev 39
On Tue, Jun 19, 2007 at 10:34:53PM +0200, Bruno Rodrigues wrote: This bug was reported five years ago! I have no IA64 anymore to test this, so from me you can safely close this bug with a can't-reproduce or similar. Last I tried (about a year ago) it was still the case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426391: linux-2.6: [hppa] parisc64-smp - kernel panic on boot
On Mon, May 28, 2007 at 04:33:56PM +0200, Frans Pop wrote: On Monday 28 May 2007 15:06, Frans Pop wrote: The boot failed with the following messages. Additional info: this was the official package (grabbed from incoming). It was compiled using (from the build log [1]): libc6-dev_2.5-7 linux-kernel-headers_2.6.18-7 gcc-4.1_4.1.2-8 g++-4.1_4.1.2-8 binutils_2.17cvs20070426-7 libstdc++6-4.1-dev_4.1.2-8 libstdc++6_4.2-20070516-1 There is a problem with new(er) binutils, Jeff Bailey is working on fixing it. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405830: kernel-package passes empty CROSS_COMPILE to make
Package: kernel-package
Somewhere between 2.6.18-7 and 2.6.18-8, something changed which causes
make-kpkg to pass CROSS_COMPILE to make. CROSS_COMPILE is set by
arch/parisc/Makefile in the kernel to the correct value when CONFIG_64BIT
is set in the kernel config (as it is for config.{parisc64,parisc64-smp}).
It would be nice if the empty CROSS_COMPILE wasn't set, so we could
control it in the kernel, but I have a patch for make-kpkg to pass it
there... It's currently build testing a kernel build, but it will take a
while to get to the failure point.
diff -Nur kernel-package-10.065/kernel/ruleset/arches/hppa.mk
kernel-package-10.065~/kernel/ruleset/arches/hppa.mk
--- kernel-package-10.065/kernel/ruleset/arches/hppa.mk 2006-08-24
00:41:45.0 -0400
+++ kernel-package-10.065~/kernel/ruleset/arches/hppa.mk2006-12-28
12:19:33.0 -0500
@@ -43,6 +43,10 @@
# This doesn't seem to work, but the other archs do it...
DEBCONFIG=$(CONFDIR)/config.$(KPKG_SUBARCH)
+ifneq (,$(findstring $(KPKG_SUBARCH), parisc64))
+ KERNEL_CROSS:=hppa64-linux-gnu-
+endif
+
#Local variables:
#mode: makefile
#End:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405830: bummer patch doesn't help
Bummer, the patch doesn't help. CROSS_COMPILE is still set to an empty string. Looking through make-kpkg I can't see how the other architectures which need to build both 64bit and 32bit images the same way handle this... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399709: use sysconf
too lazy to make a patch for this crap code but it's pretty easy to get PAGE_SHIFT via sysconf(_SC_PAGESIZE) and much less ugly... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389296: linux-2.6_2.6.18-1(hppa/unstable): FTBFS: Missing build-dep?
On Sat, Oct 14, 2006 at 10:24:24AM +0200, Aurelien Jarno wrote: Basically it checks for /usr/bin/hppa64-linux-gnu-gcc, which is an alternative. My guess is the the build daemon has the alternative broken (or the gcc package), as the package linux-2.6 builds correctly on my machine here. Could somebody who has access to the build daemon check that the alternative is not broken? i put a patch in forcing CROSS_COMPILE. i don't particularly care about people building linux-2.6 src pkg on !debian/ubuntu... anyway 2.6.18-3 seems to build ok here with the alternative symlink rm'd. cheers, kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389296: linux-2.6_2.6.18-1(hppa/unstable): FTBFS: Missing build-dep?
On Sun, Sep 24, 2006 at 05:35:44PM -0600, [EMAIL PROTECTED] wrote: /build/buildd/linux-2.6-2.6.18/debian/build/build-hppa-none-parisc64/scripts/gcc-version.sh: line 11: hppa64-linux-gcc-4.1: command not found /build/buildd/linux-2.6-2.6.18/debian/build/build-hppa-none-parisc64/scripts/gcc-version.sh: line 12: hppa64-linux-gcc-4.1: command not found /build/buildd/linux-2.6-2.6.18/debian/build/build-hppa-none-parisc64/arch/parisc/Makefile:43: *** Sorry, your compiler is too old (). GCC v3.3 or above is required.. Stop. The hell? This should be trying to use ``hppa64-linux-gnu-gcc'' not ``hppa64-linux-gcc-4.1.'' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342545: [parisc-linux] Re: Bug#342545: qt-x11-free FTBFS
On Thu, Aug 24, 2006 at 08:56:40PM -0400, John David Anglin wrote: I'm fairly certain we have a bug in handling unaligned fixups for doubles in the kernel. This caused a problem for libffi. This depends on whether the kernel is 32/64 bits. I'll try to come up with some testcases. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342545: qt-x11-free FTBFS
On Wed, Aug 23, 2006 at 10:39:04AM +0200, Matthias Klose wrote: The qt-x11-free package builds fine with a standard Debian setup. Building with prctl --unaligned=signal makes the bug reproducible. Right. The buildd is set up to deliver SIGBUS on unaligned accesses. This is configurable, and not the default kernel behaviour. It is, however, a Good Thing(tm). Unaligned accesses are quite costly, so catching and fixing them on the buildd is ideal. However, in most cases they are nontrivial to fix and should be rebuilt and uploaded and a bug filed with upstream... When I initially added prctl for parisc, iirc there were three options logging an unaligned access, delivering a SIGBUS, or silently catching it and continuing on. I have a machine that can be used to do these rebuilds, if need be. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342545: qt-x11-free FTBFS
On Wed, Aug 23, 2006 at 05:22:45PM -0700, Steve Langasek wrote: That would be wonderful if you, or another hppa porter, could track down where the bug lies. libgcc2 is almost certainly the wrong package, since nothing should be *using* libgcc2 in a fresh build of qt-x11-free; it may be a bug in libgcc4 instead, but I think that's yet to be determined. In the meantime, I think it's best to reassign this back to qt-x11-free. Agreed, probably the best course of action. I'll kick off a build in my sid chroot with prctl set to dump core and we'll see what happens. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380272: kernel-image-2.6-686-smp: cpqarray module fails to detect arrays
Hello Joshua,
On Fri, Aug 18, 2006 at 09:59:16AM -0600, Joshua Rubin wrote:
I have confirmed that loading cpqarray first fixes the problem on several
systems now. I have also realized that when this is the case, the sym53c8xx
driver is not needed or loaded. I thought this was noteworthy. It appears
that your presumption was correct that the sym53c8xx and cpqarray modules do
not play nicely.
The problem is because they both claim support for the same PCI Ids:
cpqarray.c,
static const struct pci_device_id cpqarray_pci_device_id[] =
{
{ PCI_VENDOR_ID_NCR, PCI_DEVICE_ID_NCR_53C1510,
0x0E11, 0x4048, 0, 0, 0}, /* LC2 */
{ PCI_VENDOR_ID_NCR, PCI_DEVICE_ID_NCR_53C1510,
0x0E11, 0x4040, 0, 0, 0}, /* Integrated Array */
};
and sym53c8xx_2/sym_glue.c,
static struct pci_device_id sym2_id_table[] __devinitdata = {
{ PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_LSI_53C1510,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL },
{ PCI_VENDOR_ID_LSI_LOGIC, PCI_DEVICE_ID_NCR_53C1510,
PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0UL }, /* new */
};
More correctly, the problem is because sym2 is claiming support
for all devices with these PCI device/vendor id.
Can we get the output of lspci -v output from your machine?
If LSI was kind, the PCI class might be different between the two,
or some other clue might be there to differentiate them.
Is this something that can be handled in the initramfs automatically instead
of forcing everyone running these systems to update
their /etc/initramfs-tools/modules file?
The easiest thing to do from the initramfs point of view is to simply
load cpqarray in preference to sym53c8xx.
Regards,
Kyle M.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380272: kernel-image-2.6-686-smp: cpqarray module fails to detect arrays
On Fri, Aug 18, 2006 at 04:18:58PM -0700, James Bottomley wrote: That's this fix, isn't it? http://www.kernel.org/git/?p=linux/kernel/git/jejb/scsi-rc-fixes-2.6.git;a=commit;h=b2b3c121076961333977f485f0d54c22121df920 Yup. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383481: supporting evidence to claim
Let's take a quick look in
linux-2.6/drivers/video/nvidia/nv_hw.c:NvLoadStateExt(), shall we?
{...}
if (par-Architecture = NV_ARCH_40) {
NV_WR32(par-PRAMIN, 0x * 4, 0x8010);
NV_WR32(par-PRAMIN, 0x0001 * 4, 0x00101202);
NV_WR32(par-PRAMIN, 0x0002 * 4, 0x8011);
NV_WR32(par-PRAMIN, 0x0003 * 4, 0x00101204);
NV_WR32(par-PRAMIN, 0x0004 * 4, 0x8012);
NV_WR32(par-PRAMIN, 0x0005 * 4, 0x00101206);
NV_WR32(par-PRAMIN, 0x0006 * 4, 0x8013);
NV_WR32(par-PRAMIN, 0x0007 * 4, 0x00101208);
NV_WR32(par-PRAMIN, 0x0008 * 4, 0x8014);
NV_WR32(par-PRAMIN, 0x0009 * 4, 0x0010120A);
NV_WR32(par-PRAMIN, 0x000A * 4, 0x8015);
NV_WR32(par-PRAMIN, 0x000B * 4, 0x0010120C);
NV_WR32(par-PRAMIN, 0x000C * 4, 0x8016);
NV_WR32(par-PRAMIN, 0x000D * 4, 0x0010120E);
NV_WR32(par-PRAMIN, 0x000E * 4, 0x8017);
NV_WR32(par-PRAMIN, 0x000F * 4, 0x00101210);
NV_WR32(par-PRAMIN, 0x0800 * 4, 0x3000);
NV_WR32(par-PRAMIN, 0x0801 * 4, par-FbMapSize - 1);
NV_WR32(par-PRAMIN, 0x0802 * 4, 0x0002);
NV_WR32(par-PRAMIN, 0x0808 * 4, 0x02080062);
NV_WR32(par-PRAMIN, 0x0809 * 4, 0x);
NV_WR32(par-PRAMIN, 0x080A * 4, 0x1200);
NV_WR32(par-PRAMIN, 0x080B * 4, 0x1200);
NV_WR32(par-PRAMIN, 0x080C * 4, 0x);
NV_WR32(par-PRAMIN, 0x080D * 4, 0x);
NV_WR32(par-PRAMIN, 0x0810 * 4, 0x02080043);
NV_WR32(par-PRAMIN, 0x0811 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0812 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0813 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0814 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0815 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0818 * 4, 0x02080044);
NV_WR32(par-PRAMIN, 0x0819 * 4, 0x0200);
NV_WR32(par-PRAMIN, 0x081A * 4, 0x);
NV_WR32(par-PRAMIN, 0x081B * 4, 0x);
NV_WR32(par-PRAMIN, 0x081C * 4, 0x);
NV_WR32(par-PRAMIN, 0x081D * 4, 0x);
NV_WR32(par-PRAMIN, 0x0820 * 4, 0x02080019);
NV_WR32(par-PRAMIN, 0x0821 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0822 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0823 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0824 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0825 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0828 * 4, 0x020A005C);
NV_WR32(par-PRAMIN, 0x0829 * 4, 0x);
NV_WR32(par-PRAMIN, 0x082A * 4, 0x);
NV_WR32(par-PRAMIN, 0x082B * 4, 0x);
NV_WR32(par-PRAMIN, 0x082C * 4, 0x);
NV_WR32(par-PRAMIN, 0x082D * 4, 0x);
NV_WR32(par-PRAMIN, 0x0830 * 4, 0x0208009F);
NV_WR32(par-PRAMIN, 0x0831 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0832 * 4, 0x1200);
NV_WR32(par-PRAMIN, 0x0833 * 4, 0x1200);
NV_WR32(par-PRAMIN, 0x0834 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0835 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0838 * 4, 0x0208004A);
NV_WR32(par-PRAMIN, 0x0839 * 4, 0x0200);
NV_WR32(par-PRAMIN, 0x083A * 4, 0x);
NV_WR32(par-PRAMIN, 0x083B * 4, 0x);
NV_WR32(par-PRAMIN, 0x083C * 4, 0x);
NV_WR32(par-PRAMIN, 0x083D * 4, 0x);
NV_WR32(par-PRAMIN, 0x0840 * 4, 0x02080077);
NV_WR32(par-PRAMIN, 0x0841 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0842 * 4, 0x1200);
NV_WR32(par-PRAMIN, 0x0843 * 4, 0x1200);
NV_WR32(par-PRAMIN, 0x0844 * 4, 0x);
NV_WR32(par-PRAMIN, 0x0845 * 4, 0x);
NV_WR32(par-PRAMIN, 0x084C * 4, 0x3002);
NV_WR32(par-PRAMIN, 0x084D * 4, 0x7FFF);
NV_WR32(par-PRAMIN, 0x084E * 4,
par-FbUsableSize | 0x0002);
{...}
Wow. Looks a lot like copying register bank settings. Much like
the drivers listed in Bug#383403.
Enjoy.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364562: linux32 doesn't work on hppa64 kernels
On Mon, Apr 24, 2006 at 11:07:19AM +0200, Matthias Klose wrote: Package: linux32 Version: 1-3 $ uname -m parisc64 $ linux32 uname -m parisc64 I spent some time trying to fix this a while ago at Jeff Bailey's request, but it required nasty invasive changes that I didn't have time to debug. (It's not really an improvement when /sbin/init fails to exec...) If I have some time this week, I'll dust off the diff and see if I can finagle it to work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363450: support hppa in numactl
Package: numactl Severity: wishlist Tags: patch Please add support for hppa to numactl. Patch follows. The only syscall # which needs definition is migrate pages, as the rest are now in linux-kernel-headers asm/unistd.h. Cheers, Kyle --- numactl/syscall.c~ 2006-04-19 06:44:13.0 + +++ numactl/syscall.c 2006-04-19 06:43:47.0 + @@ -48,6 +48,10 @@ #define __NR_get_mempolicy 1260 #define __NR_set_mempolicy 1261 +#elif defined(__hppa__) + +#define __NR_migrate_pages 272 + #elif defined(__i386__) #define __NR_mbind 274 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332962: ACK metoo
I'm also seeing this bug on a dual cpu A500-7X... Will investigate and hopefully we'll find a solution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353480: [parisc-linux] Re: Bug#353480: yaird: [hppa] /dev/sd* device nodes not created and eth0 not enabled
On Tue, Feb 21, 2006 at 02:46:09PM +0100, Joel Soete wrote: hihi, as I have to rebuild the pkg is also discover: udev_libc_wrapper.h:69:2: warning: #warning inotify unsupported on this architecture! Good catch, I missed this. Yes, this should also go upstream... not that I've yet received any reply from upstream to my first change... Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353480: yaird: [hppa] /dev/sd* device nodes not created and eth0 not enabled
On Sat, Feb 18, 2006 at 10:02:28PM +0100, Frans Pop wrote: udevd[862]: get_netlink_msg: unable to receive kernel netlink message: No buffer space available !-- not sure about this message, but the same is shown for initramfs-tools -- This is the reason you aren't getting /dev/sd* nodes. I debugged this yesterday, needs new udev upload, more details here: http://marc.theaimsgroup.com/?l=linux-hotplug-develm=114019842906313w=2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350963: wpasupplicant: wait-for-interface option -w does not work anymore
On Thu, Feb 02, 2006 at 02:06:56AM +0100, Sven Koch wrote: (starting by hand, the init-script does not output any errors but deamon is just not running afterwards) Ok. I thought I had fixed this, but I clearly need to reopen that bug aurora:/etc/default# wpa_supplicant -w -i ath0 -D madwifi -c Hmm, I think the order of the arguments matters, try putting it after the -i? Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350482: [hppa] module xfs relocation of symbol freeze_bdev is out of range
On Sun, Jan 29, 2006 at 10:24:55PM +0100, Frans Pop wrote: I have cloned the installation report to #350482 and reassigned that to the linux-2.6 source package for this issue. The user confirmed this issue is still there for 2.6.15. I'll leave it to kernel maintainers to determine if this should be RC or not. The problem is caused because the module is too damn big and a 17-bit branch displacement relocation can't reach a symbol. I think Randolph was working on this for Fabio, not sure what the results of that were... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
On Fri, Jan 27, 2006 at 10:19:55PM -0800, Steve Langasek wrote: After changing addr to value, compiles fine; prctl -q runs ok now, prctl --unaligned=signal doesn't have any effect. You say that it's going to be the prctl() function in the kernel that needs further tweaks? I'm not sure, I'd recommend adding a printk to GET/SET_UNALIGN_CTL to see if the correct values are being set to flags, barring that I'll take a look at alpha's unaligned handler and see if I missed something when I said shouldn't need any other work. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
After changing addr to value, compiles fine; prctl -q runs ok now, prctl
--unaligned=signal doesn't have any effect. You say that it's going to be
the prctl() function in the kernel that needs further tweaks?
I suspect this is the problem:
(linux/prctl.h)
# define PR_UNALIGN_NOPRINT 1 /* silently fix up unaligned user
accesses */
# define PR_UNALIGN_SIGBUS 2 /* generate SIGBUS on unaligned user
access */
(asm-parisc/processor.h asm-ia64/processor.h)
#define PARISC_UAC_NOPRINT (1UL 0) /* see prctl and unaligned.c */
#define PARISC_UAC_SIGBUS (1UL 1)
IE, NOPRINT is set by 1, and SIGBUS set by 2.
on alpha, because it's reusing the OSF/1 crap, the order is
NOPRINT, NOFIX, SIGNAL, ie: 1, 2, 4.
I don't know what the best way to fix this is, but something like
this patch will probably help,
Index: prctl-1.4/prctl.c
===
--- prctl-1.4.orig/prctl.c 2003-03-05 13:52:32.0 -0500
+++ prctl-1.4/prctl.c 2006-01-28 01:47:20.0 -0500
@@ -67,6 +67,11 @@
printf( --fpemu=[silent|signal|default]\n);
}
+#ifdef __alpha__
+#undef PR_UNALIGN_SIGBUS
+#define PR_UNALIGN_SIGBUS 4
+#endif /* __alpha__ */
+
int set_unaligned(int prctl_val)
{
int alignval, retval;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350239: [hppa] ld doesn't like outputting to /dev/null
Package: binutils
Version: 2.16.1cvs20051214-1
The Linux kernel's make menuconfig on hppa currently fails because
it tries to do
scripts/kconfig/lxdialog/check-lxdialog.sh:
[..]
echo main() {} | $cc -lncurses -xc - -o /dev/null 2 /dev/null
[..]
To check which ncurses library it is able to link against.
This output to /dev/null causes none of the ncurses options to get
picked and thus, lxdialog to fail to link.
[EMAIL PROTECTED]:~/git/parisc-2.6% echo main() {} | gcc -lncursesw -xc - -o
/dev/null
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
Downgrading to previous version of binutils have the same problem, so
I'm unsure when this was introduced (and don't have time to sleuth too
far back).
Currently this change is pending for 2.6.16, so no release kernels
are bitten by it yet, but I suspect it may be a problem for other
Debian arches (though it wasn't on i386/ia64).
[CC'd to debian-hppa so some hppa toolchain guru can see it]
Cheers,
Kyle
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
On Thu, Jan 26, 2006 at 03:23:08AM -0800, Steve Langasek wrote: Should be 'value' instead of 'addr', I guess? Yeah, oops, I just cribbed it from the one I did for parisc for LaMont. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349765: linux-2.6.14-2-alpha-generic: please support the prctl syscall
On Tue, Jan 24, 2006 at 07:06:00PM -0800, Steve Langasek wrote:
So please make it work; knowing this exists and should be supported, I'm not
willing to hack up prctl's source to use __NR_osf_setsysinfo instead. :)
Bleh.
Untested, as I don't have an alpha. arch/alpha/kernel/traps.c already
contained jazz to check if the various TIF_ were set, they were just
lacking a convenient way to set things. You probably need to make prctl()
know which bits to twiddle.
diff --git a/include/asm-alpha/thread_info.h b/include/asm-alpha/thread_info.h
index 69ffd93..011daaf 100644
--- a/include/asm-alpha/thread_info.h
+++ b/include/asm-alpha/thread_info.h
@@ -92,5 +92,20 @@ register struct thread_info *__current_t
#define _TIF_ALLWORK_MASK (_TIF_WORK_MASK \
| _TIF_SYSCALL_TRACE)
+#define ALPHA_UAC_SHIFT6
+#define ALPHA_UAC_MASK (TIF_UAC_NOPRINT | TIF_UAC_NOFIX | \
+TIF_UAC_SIGBUS)
+
+#define SET_UNALIGN_CTL(task,value)({ \
+ (task)-thread_info-flags = (((task)-thread_info-flags \
+ ~ALPHA_UAC_MASK) | (((value) ALPHA_UAC_SHIFT) \
+ ALPHA_UAC_MASK)); \
+ 0; })
+
+#define GET_UNALIGN_CTL(task,value)({ \
+ put_user(((task)-thread_info-flags ALPHA_UAC_MASK)\
+ ALPHA_UAC_SHIFT, (int __user *)(addr)); \
+ })
+
#endif /* __KERNEL__ */
#endif /* _ALPHA_THREAD_INFO_H */
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#344538: build problems on sarti (was: Bug#344538: tetex-base: tex-common to Pre-Depends, otherwise installation fails)
On Fri, Jan 06, 2006 at 02:18:38PM +0200, Martin-?ric Racine wrote: Anyhow, given how hppa is already among the architectures that did not re-qualify for Etch, I propose that, from now on, hppa be ignored for deciding whether a package is considered valid for going into Testing. Uhm. You're wrong? http://release.debian.org/etch_arch_qualify.html In any case, might as well ignore it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341675: [EMAIL PROTECTED]: cppunit: FTBFS on hppa]
On Sat, Dec 03, 2005 at 12:45:21PM -0500, Steve M. Robbins wrote: 0x4200f534 in __umoddi3 () from /lib/libgcc_s.so.2 Could you tell us what the specific illegal instruction was? You should be able to disassemble that address with x/i 0x4200f534 in gdb. This looks mostly like a GCC bug... Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310136: How about this bug ?
On Thu, Nov 03, 2005 at 11:08:08AM +0100, Yannick Torres wrote: Hello, How about this bug ? Is there a solution ? I don't have my laptop right now, making it extremely difficult to work on wpasupplicant. Sorry, patience please. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333766: libc6: SIGBUS in libm on hppa breaks qt-x11-free
On Thu, Oct 13, 2005 at 05:04:55PM -0700, Steve Langasek wrote: To say that this is a compiler bug, you would have to show that gcc-4.0 is *wrong* to 32-bit align the fenv_t struct instead of 64-bit aligning it. You'd have to check with the compiler folks to be sure, but I don't think this is a correct assertion for a struct of 32-bit unsigned ints. If it wants to use fldd (floating point load double) it must be 8-byte aligned, otherwise it will take an unaligned access trap. I believe I added code to the kernel recently that will let someone toggle on and off unaligned access traps/logging with prctl... Might be worth checking. At any rate, knowing that gcc-3.4 does this alignment differently gives us a viable workaround for qt; since qt is already building with g++-3.4 on hppa (et al.), it's no trouble to also make it build-depend on and use gcc-3.4. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332962: tulip module no longer works on a500
On Sun, Oct 09, 2005 at 11:55:24PM -0600, Grant Grundler wrote: Looks very similar to 2.6.8 output. So the 2.6.12 output from the debian kernel is just wierd. (Maybe compiler/toolchain bug?) I just booted linux-image-2.6.12-1 on my a500: % cat /proc/ioports - : PCI00 Ports 0040-007f : :00:04.0 0080-00ff : :00:00.0 0080-00ff : tulip 0100-01ff : :00:01.0 0100-01ff : sym53c8xx 0200-02ff : :00:01.1 0200-02ff : sym53c8xx 0300-03ff : :00:02.0 0300-03ff : sym53c8xx 0400-04ff : :00:02.1 0400-04ff : sym53c8xx 0500-053f : :00:05.0 Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331533: file reference in default wpa_supplicant.conf points to wrong location
On Mon, Oct 03, 2005 at 02:55:04PM +0200, Eduard Bloch wrote:
wpa_supplicant.conf tells you to look in
/usr/share/doc/wpasupplicant/wpa_supplicant.conf.gz for details. However, the
path should be:
/usr/share/doc/wpasupplicant/examples/wpa_supplicant.conf.gz .
Oops.
#network={
#ssid=ournet
#psk=w243sd5f324asdf5123sadf54324
#}
I'll add this.
Thanks!
Kyle
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331033: no configuration found
close 331033 thanks Not a bug. Take the hint and edit /etc/default/wpasupplicant. I removed the patch to put a default config in because it does not agree with having multiple interfaces. Also, don't forget to pass -D. linux:~# rm /var/run/wpa_supplicant/ath0 linux:~# wpa_supplicant -B -c /etc/wpa_supplicant.conf -i ath0 ioctl[SIOCSIWPMKSA]: Operation not supported ioctl[PRISM2_IOCTL_PRISM2_PARAM]: Operation not supported ioctl[PRISM2_IOCTL_HOSTAPD]: Operation not supported Failed to set encryption. ioctl[PRISM2_IOCTL_HOSTAPD]: Operation not supported Failed to set encryption. ioctl[PRISM2_IOCTL_HOSTAPD]: Operation not supported Failed to set encryption. ioctl[PRISM2_IOCTL_HOSTAPD]: Operation not supported Failed to set encryption. ioctl[PRISM2_IOCTL_PRISM2_PARAM]: Operation not supported ioctl[PRISM2_IOCTL_PRISM2_PARAM]: Operation not supported downgrading back to 0.4.2-1 fixes the problem. Regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322174: wpasupplicant: Line 475: failed to parse eap 'FAST'.
On Mon, Sep 26, 2005 at 07:51:18AM +0200, Marc Haber wrote: Is that non-functionality documented prominently enough? It's in the readme. It would be nice, I suppose, if choosing methods that don't work yelled in the output a bit more, and I'll add a comment to the wpa_supplicant.conf. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330138: wpasupplicant: Should depend on libopensc-openssl
On Mon, Sep 26, 2005 at 09:47:30AM +0100, Peter Hicks wrote: On a laptop where wpasupplicant was working last week, today's upgrade breaks and reports problems loading an OpenSC library. Installing libopensc-openssl works around this problem - should the package depend on it? How odd, I don't have this package installed... Which authentication methods are you using? Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330138: wpasupplicant: Should depend on libopensc-openssl
On Mon, Sep 26, 2005 at 08:38:01PM +0100, Peter Hicks wrote: Numerous, and I had the OpenSC libraries installed on my laptop for other projects. Certainly, the configuration files referenced some .so files. Sorry I can't be more specific, I was more concerned with fixing authentication on my wireless kit than keeping track of what broke and how I'd fix it. This is really confusing me. I can't find any dlopen or anything inside wpa supplicant. I'm tempted to think this is actually a bug on OpenSSL. Any chance you could narrow it down enough that I could add that auth type and try to reproduce? Thanks, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330138: wpasupplicant: Should depend on libopensc-openssl
On Mon, Sep 26, 2005 at 08:38:01PM +0100, Peter Hicks wrote: Numerous, and I had the OpenSC libraries installed on my laptop for other projects. Certainly, the configuration files referenced some .so files. Sorry I can't be more specific, I was more concerned with fixing authentication on my wireless kit than keeping track of what broke and how I'd fix it. Spoke too soon. The problem is engine. I didn't specify any, and the default is to not load any, but depending on the config, some could be loaded. I'm tempted to just comment this in the config file, and add a suggests or recommends on the required packages. Any thoughts? Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304032: wpasupplicant: [PATCH] Please add support for starting/stopping wpa_supplicant on ifup/ifdown
Sorry for taking so long to get back to you, finally clearing out a bunch of the bugs on the package. On Sun, Apr 10, 2005 at 10:50:22PM +1000, Daniel Pittman wrote: I almost never use the wireless interface in my laptop, but when I do I need WPA support, so I have wpa_supplicant configured deal with that for me. Recent wpa_supplicant supports waiting for the interface to appear before it will do anything for you. Does this do more or less what you need or do you still want this ifup/ifdown stuff. I'm tempted to not do anything about that, mostly because most wireless cards are becoming MiniPCI and not hotpluggable, and become I'm lazy. :P Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296291: wpasupplicant: WEP no longer works
On Mon, Feb 21, 2005 at 09:08:16AM -0600, [EMAIL PROTECTED] wrote: Ever since upgrading to 3.8 (from Debian's previous package, version 3.2 I think), wpa_supplicant no longer works with WEP. If I don't use wpa_supplicant and configure the interface manually with iwconfig, I can set the WEP key and everything works as expected. I'm using the latest madwifi cvs... Is this still a bug? I'm tempted to close this as fixed upstream. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304087: wpasupplicant not working with ipw2100 driver
On Sun, Apr 10, 2005 at 09:35:16PM +0200, Andreas Pakulat wrote: Package: wpasupplicant Version: 0.3.8-1 Severity: important Is this still a problem? I'm tempted to close this as fixed-upstream. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296310: wpasupplicant: s/hyphen/minus/ fixes in manpages
On Mon, Feb 21, 2005 at 06:11:43PM +0100, Achim Bohnet wrote: Applied in 0.4.4-1. Thanks! Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304088: wpasupplicant: should state more clearly that prism54 driver is not working
On Sun, Apr 10, 2005 at 09:38:11PM +0200, Andreas Pakulat wrote: Package: wpasupplicant Version: 0.3.8-1 Severity: wishlist It most certainly is working now, don't know about then. Can this bug be closed? Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305171: wpasupplicant: Workaround for ipw with scan_ssid=1 (hidden AP) [PATCH]
On Mon, Apr 18, 2005 at 02:37:22PM +0200, H?kan Lindqvist wrote: Package: wpasupplicant Version: 0.3.8-1 Severity: wishlist Sorry for taking so long to get back to you. Does this bug still apply to 0.4.4? Thanks. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322176: wpasupplicant: defaults file should have dedicated option for the interface
On Tue, Aug 09, 2005 at 04:36:12PM +0200, Marc Haber wrote: Package: wpasupplicant Severity: wishlist As the option interface is required on the wpa_supplicant command line, /etc/default/wpasupplicant should have a dedicated field for that setting. Hi, I'm not sure if this is a good idea, because it's possible to specify multiple configurations (interface, config file pairs) by seperating them with -N on the command line. Though, this is quite a corner case configuration... Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322175: /etc/default/wpasupplicant refers to non-existing interface option in docs
On Tue, Aug 09, 2005 at 04:34:20PM +0200, Marc Haber wrote: /etc/default/wpasupplicant says # -i ifname Interface (required, unless specified in config) however, the example config file does not say where the interface name can be configured. Ah, this was an option I added in a patch, but forgot to add to the default config file. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322174: wpasupplicant: Line 475: failed to parse eap 'FAST'.
On Tue, Aug 09, 2005 at 04:31:22PM +0200, Marc Haber wrote: The config file shipped in /usr/share/doc/wpasupplicant/examples/wpa_supplicant.conf.gz does not seem to be compatible with the current software, as wpasupplicant complains about an unknown EAP method 'FAST' on startup. EAP-FAST requires OpenSSL to be recompiled with a patch supplied in the wpa_supplicant source. I've enabled it in the upcoming 0.4.4 release, however, before it is functional, one would need to rebuild OpenSSL. I do not have time to consider whether it would be a good idea to file a bug on OpenSSL and get them to integrate the patch, nor what the ramifications of this would be. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317180: Patch to add syslog support to wpasupplicant
On Sat, Jul 16, 2005 at 06:57:31PM +0300, Andrew McMillan wrote: tags 317180 +patch thanks Thanks! Hi, Attached is a patch for wpasupplicant which adds a configuration item CONFIG_LOG_TO_SYSLOG and enables it in the Debian build. Cool! 14_log_to_syslog.dpatch This (optionally) changes the function of wpa_printf and friends to log all of their messages to syslog, using appropriate log levels. I like this patch a lot. Could you please discuss integrating this with upstream? Thanks! Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317548: wpasupplicant version =0.4 incompatible ipw2200
On Sat, Jul 09, 2005 at 05:17:30PM +0200, Thierry CHICH wrote: A simple solution is to come back to the stable version of wpasupplicant. Perhaps the 1.0.4 of ipw2200 is fixing this bug, put it does not appear as an evidence on the web site. ipw2200 is working fine for me, upgrade your driver. Cheers, -- Kyle McMartin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315881: [Pkg-freeciv-devel] Bug#315881: freeciv: Freeciv causes computer to hang
On Sun, Jun 26, 2005 at 06:58:04PM +0100, Noel Torres wrote: Every time I've started to play, I heard (after more or less time of continuous play) a bunch of harddisk noise, and when I tried to Alt-F1 or to run 'top' or to change directory to save the game or any other similar (kernel-related) task, it does not work and system becomes unusable and, thus, it must be hard-rebooted. Can you please post the specifications of your computer? Arch, processor, amount of ram, etc. Additionally, what kernel you are using. Cheers, -- Kyle McMartin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#162690: Bug #162690: [parisc]gcc 3.x produces openssl test code that SEGVs with -march=2.0 and optimization 0
On Sat, May 21, 2005 at 03:06:14PM +0200, Falk Hueffner wrote: this is an ancient bug report about a miscompilation of openssl on hppa. Can somebody please check whether this is still an issue? I tried this: compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DOPENSSL_NO_KRB5 -DB_ENDIAN -DTERMIO -O1 -march=2.0 -fomit-frame-pointer -Wall -DBN_DIV2W gcc version 3.3.5 (Debian 1:3.3.5-12) And the test suite seemed to pass. I think the bug can safely be closed, since gcc3.3 is the default compiler in sarge. -- Kyle McMartin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308873: ITP: mercurial -- scalable distributed SCM
On Thu, May 12, 2005 at 11:36:40PM +0200, Vincent Danjean wrote: Mercurial is a very efficient distributed SCM. It is very similar to git (the SCM used by Linus for the kernel), but does not take so many place to save data (it stores diff instead of plain file for modified files) Does it still use a non-free python extension? I believe it was the 'profile' module. Cheers, -- Kyle McMartin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301489: kernel is unable to mount file system on raid0 device
On Sat, Mar 26, 2005 at 11:20:11AM +0100, Matthias Klose wrote: mdadm: /dev/md0 has been started with 2 drives. I'm not really sure what to say. None of that code has been modified in any of the hppa patches. Are you sure the device labels are correct? mdadm shows /dev/md0 starting as a raid0, but you're trying to mount /dev/md1. /dev/md1: The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 device Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301498: Badness in smp_call_function
On Sat, Mar 26, 2005 at 12:20:48PM +0100, Matthias Klose wrote: Backtrace: [10115720] dump_stack+0x20/0x38 [10121688] smp_call_function+0xd8/0x4c0 [10114320] flush_data_cache+0x38/0x70 [10112eb8] free_initmem+0x78/0x560 [10112304] init+0x2e4/0x4a0 [1010647c] ret_from_kernel_thread+0x24/0x38 This is a harmless warning. Unfortunately it's probably too late to comment out it's source for sarge. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300096: O: electric -- electrical CAD system
Package: wnpp Severity: normal I no longer have time to maintain this package. The new upstream version is out, but is written in Java instead, I am unable to make enough time to move to the new version. Regards, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300095: O: madplay -- MPEG audio player in fixed point
Package: wnpp Severity: normal I'm orphaning this package due to lack of time. There are a few outstanding bugs on this software, but none of them look particularly critical and are mostly waiting on upstream action. Thanks, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300100: O: vipec -- network analyzer for electrical networks
Package: wnpp Severity: normal I no longer have sufficient time to maintain this package, watching for new releases, etc. I believe it would be better off in someone elses hands. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#287220: wpa_supplicant and unkown open AP
On Sun, Mar 13, 2005 at 02:19:43PM +0100, Martin Samuelsson wrote: As a matter of fact I reported this feature lack as a wishlist bug to the debian bug tracking system when migrating from waproamd to wpasupplicant. Please see http://bugs.debian.org/287220 for that report. Unless I'm wrong and wpasupplicant indeed already supports connecting to unlisted networks my opinion is that adding the special case to connect to anything when ssid=any would be the clean and natural thing to do. I'm working on a patch for this, but have been exceedingly busy for this. Expect an upload soonish, hopefully. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299268: followup using pre-rc3 images from sid
On Tue, Mar 15, 2005 at 06:02:27AM +, Martin Michlmayr wrote: I suggest we close this bug since all issues have been reported in other bugs already. OK? Works for me. Cheers, Kyle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299268: Netwinder latest daily success
Package: installation-reports Possibly a followup to #253789, sorry for the long delay, I had to fix the board. Debian-installer-version: Sat, 12 Mar 21:10 EST 2005 http://people.debian.org/~kmuto/d-i/images/daily/netwinder/netboot/boot.img uname -a: Linux barad-dur 2.4.27-netwinder #1 Tue Feb 22 15:24:37 GMT 2005 armv4l GNU/Linux Date: Sat Mar 12 22:55:51 EST 2005 Method: Network booted from local DHCP server. Serial console. Machine: Rebel Netwinder Processor: [EMAIL PROTECTED]:~% cat /proc/cpuinfo Processor : StrongARM-110 rev 4 (v4l) BogoMIPS: 185.95 Features: swp half 26bit fastmult Hardware: Rebel-NetWinder Revision: 58ff Serial : 1e0e Memory: 64MB Root Device: 2.2GB IDE Root Size/partition table: Disk /dev/hda: 2167 MB, 2167603200 bytes 255 heads, 63 sectors/track, 263 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 11 88326 83 Linux /boot /dev/hda2 12 25 112455 83 Linux / /dev/hda3 26 263 19117355 Extended /dev/hda4 1 1 00 Empty Partition 4 has different physical/logical beginnings (non-Linux?): phys=(0, 0, 0) logical=(0, 0, 1) Partition 4 has different physical/logical endings: phys=(0, 0, 0) logical=(267349, 89, 4) Partition 4 does not end on cylinder boundary. /dev/hda5 26 128 827316 83 Linux /usr /dev/hda6 129 160 257008+ 83 Linux /var /dev/hda7 161 175 120456 82 Linux swap /dev/hda8 176 182 56196 83 Linux /tmp /dev/hda9 183 263 650601 83 Linux /home Output of lspci and lspci -n: [EMAIL PROTECTED]:~% lspci :00:00.0 Co-processor: Digital Equipment Corporation StrongARM DC21285 (rev 03) :00:09.0 VGA compatible controller: Intergraphics Systems CyberPro 2000A (rev 01) :00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) :00:0c.0 ISA bridge: Symphony Labs W83C553 (rev 10) :00:0c.1 IDE interface: Symphony Labs SL82c105 (rev 05) :00:0d.0 Ethernet controller: Winbond Electronics Corp W89C940F [EMAIL PROTECTED]:~% lspci -n :00:00.0 0b40: 1011:1065 (rev 03) :00:09.0 0300: 10ea:2010 (rev 01) :00:0a.0 0200: 1011:0019 (rev 41) :00:0c.0 0601: 10ad:0565 (rev 10) :00:0c.1 0101: 10ad:0105 (rev 05) :00:0d.0 0200: 1050:5a5a Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] (see below) Create file systems:[O] Mount partitions: [O] Install base system:[O] (network failed once, and retried) Install boot loader:[O] Reboot: [O] Comments/Problems: Most of this will, I guess, apply to sarge+1... I guess detect cd was fine, since it detected that I don't have one. Chose multiuser system and it partitioned things well. /boot was correctly ext2r0, excellent! Was necessary to: setenv cmdappend console=ttyS0,115200,8n1 setenv rootdev /dev/ram to get a serial console, and get the initrd going. Very awesome that the NeTTROM settings are spewed at the end, very very helpful! Seemed to hang a bit at Configuring the base system before the Debian Configuration menus, some feedback would be nice, as these are very slow machines. Maybe a whirlygig would be appropriate... Thanks! Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299268: Netwinder latest daily success
On Sun, Mar 13, 2005 at 05:15:59AM +, Martin Michlmayr wrote: That's probably a problem with your network, though? Yeah. I wasn't sure if the fact that a component failed would make a difference in the install process somehow, so I thought I should note it. All of the standard schemes have a correct /boot partition and if you manually partition your disk it will warn you if you don't have an appropriate /boot. Awesome. #274695: Detect serial console on ARM and show console= entry *Nod* Ok. What about that rootdev parameter above? I suppose this is to boot the installer rather than to boot Debian. (Just wondering since you mention this after having installed Debian, so I wonder why you would want to see /dev/ram instead of /dev/hda) Ah, right, I see you mention initrd. Well, booting the initrd should be explained in the installation manual (does it? I don't know for sure but I thought it did), but you're right that the screen at the end of the 1st stage should mention the console= parameter. Yeah. A netwinder is always going to have rootdev set to something, afaict, so a user will always need to point rootdev=/dev/ram in order for the initrd to be mounted. This is a known problem with debootstrap, and really dpkg, which doesn't supply the necessary details to display this information. See #244563: Please make Installing base packages progress more granual Fair enough. Cheers! Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299268: followup using pre-rc3 images from sid
Debian-installer-version: d-i pre-rc3 ftp://ftp.debian.org/debian/dists/sid/main/installer-arm/20050305/images/netwinder/netboot/boot.img uname -a: Linux barad-dur 2.4.27-netwinder #1 Tue Feb 22 15:24:37 GMT 2005 armv4l GNU/Linux Date: Sun Mar 13 01:00:51 EST 2005 Method: Netinst booted off a local dhcp/tftp server. Machine: Rebel Netwinder Processor: StrongARM-110 rev 4 (v4l) Memory: 64M Root Device: 2.2GB IDE Root Size/partition table: same as before Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] Comments/Problems: Comments from #299268 apply here. Sorry, I should have used the pre-rc3 images from the get-go, but I didn't not know about them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296291: Upstream developer release works properly
On Fri, Feb 25, 2005 at 09:45:11AM -0700, Benj Carson wrote: I've compiled the upstream developer release as of 2005-02-24 (http://hostap.epitest.fi/cgi-bin/viewcvs.cgi/hostap/hostap.tar.gz?tarball=1) and associating with WEP-enabled networks now works properly. In correspondance with Jouni, I think I've figured out how to unstick this mess. Afaict, only madwifi is fixed in CVS? I'm trying to get a bunch more wireless cards in order to get a good testing environment set up. Thanks for the heads up! Cheers! Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296978: Successful install on hppa --- C3000
Package: installation-reports Debian-installer-version: p.d.o/~jbailey/ from 2005-02-25 uname -a: Linux celebdil 2.6.8-2-32-smp #1 SMP Mon Feb 7 22:19:10 EST 2005 parisc GNU/Linux Date: Sat Feb 26 00:57:32 EST 2005 Method: Net Install via Daily Build http://people.debian.org/~jbailey/d-i/hppa/2005-02-25/netboot/2.6/boot.img Machine: HP Visualize C3000 Processor: PA8500 400MHz Memory: 2GB Root Device: /dev/sda Root Size/partition table: Device Boot Start End Blocks Id System /dev/sda1 * 1 48 49136 f0 Linux/PA-RISC boot /dev/sda2 49 292 249856 82 Linux swap /dev/sda3 293 780 499712 83 Linux (/) /dev/sda4 7818678 80875525 Extended /dev/sda5 7811734 976880 83 Linux (/var) /dev/sda617353641 1952752 83 Linux (/usr) /dev/sda736428678 5157872 83 Linux (/home) Output of lspci and lspci -n: % lspci :00:0c.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) :00:0d.0 Multimedia audio controller: Analog Devices AD1889 sound chip :00:0e.0 IDE interface: National Semiconductor Corporation 87415/87560 IDE (rev 03) :00:0e.1 Bridge: National Semiconductor Corporation 87560 Legacy I/O (rev 01) :00:0e.2 USB Controller: National Semiconductor Corporation USB Controller (rev 02) :00:0f.0 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 04) :00:0f.1 SCSI storage controller: LSI Logic / Symbios Logic 53C896/897 (rev 04) :01:04.0 Display controller: Hewlett-Packard Company A4977A Visualize EG (rev 03) :02:01.0 Fibre Channel: Hewlett-Packard Company Tach XL2 Fibre Channel Host Adapter (rev 0b) :03:02.0 Display controller: Hewlett-Packard Company Visualize FX4 (rev 02) % lspci -n :00:0c.0 0200: 1011:0019 (rev 41) :00:0d.0 0401: 11d4:1889 :00:0e.0 0101: 100b:0002 (rev 03) :00:0e.1 0680: 100b:000e (rev 01) :00:0e.2 0c03: 100b:0012 (rev 02) :00:0f.0 0100: 1000:000b (rev 04) :00:0f.1 0100: 1000:000b (rev 04) :01:04.0 0380: 103c:1005 (rev 03) :02:01.0 0c04: 103c:1029 (rev 0b) :03:02.0 0380: 103c:1008 (rev 02) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] Comments/Problems: The purpose behind this was to test Debian Installer with the new 2.6.8-2 kernels. Everything seemed to go quite well. Will hopefully get a chance to test a CD boot soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#287223: wpasupplicant doesn't bring up interfaces
I'll look into this. I'm not sure the best way to integrate this yet, but I'll look at the code and we'll see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291254: Doesn't work with the latest kernel-source-2.6.8
On Wed, Jan 19, 2005 at 10:53:16AM +0100, Aurelien Jarno wrote: It seems that kernel-patch-2.6.8-hppa doesn't work with kernel-source-2.6.8 (ie version 2.6.8-12), so it is simply unuseable: Thanks, I've already fixed this in my working tree, but I've been working fairly heavily with Bdale and others to make sure the next upload works well for everyone, so I've not yet uploaded it yet. I expect to have fixed things up in a short while. If you're really desperate for punishment, you can fetch the latest debs from http://parisc-linux.org/~kyle/debian-kernel/2005-01-18/. Cheers, Kyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
