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#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#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 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#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#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#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#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#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#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#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 > Cheers, Kyle -- 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]
