Re: New procps, may break
On Fri, Jul 30, 2004 at 01:58:07PM +0200, Goswin von Brederlow wrote: > The presence of /lib64 has nothing to do with it being used. Best way > to actualy test for it I can think of is compiling a conftest and > checking where it gets the libc from. That would work on all archs and > distributions afaik. Yes, that sounds pretty hard to do. Considering free is nowish I think I"ll leave that for next release. > You're 'lib64=lib' in debian/rules should work for all debian > archs. It's what the README says to do after all. :) Strangely enough it *did* break on os390. I missed one in the install step so have had to make a 3.2.2-2 to fix it for at least that arch. I'm surprised to worked on the amd64, I suspect yours may not be bi-arch or whatever it is called when you have both 64-bit and 32-bit compiling going on. Now unless it is supposed to be in /lib64 everything should be ok. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org
Re: New procps, may break
On Thu, Jul 29, 2004 at 02:46:40PM -0700, David S. Miller wrote: > Can you elaborate on the expected potential failure? > You do have something specific your worried about, otherwise > you wouldn't mention anything :-) > > Thanks. And I'll try to help out with whatever explodes. Hello David, Probably the first thing I should mention is that the procps is different to the one RedHat uses (if you are here without the RedHat hat on then it doesn't matter). Just letting you know in case you're looking at their package and wondering what all the fuss is about. Yes, I suppose actually specifying what sort of breakage would of made everyone's job easier, sorry about that. The problems I would expect would be things like it doesn't compile correctly, it compiles but puts a 32 bit library in the wrong directory or puts a 64 bit library in the wrong directory. If you compile it, install it and are happy about what libproc.so.3.2.2 is and where it has been installed then you have none of the foreseeable set of problems. I've hard-coded for the library to be installed in /lib to get around problems we had on one of the 64-bit arches, possibly sparc or hppa. I cannot find the bug # about it but it put the wrong file in the wrong directory. That hard coding might cause problems on sparc, but more likely on things like ia64, hppa or amd64. I don't understand those arches at all. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org
New procps, may break
Hello, A new procps has been uploaded. I think the 64bit arches will be ok but I'd just like to let you lot know that there might be problems on the sparc or amd64. Complaining won't fix it, but patches that don't break the package in other exciting ways will fix it. I know it works ok for an alpha so the compliing part is fine, but the lib vs lib64 might be a problem. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/ MIEE Debian developer csmall at : enc.com.au ieee.org debian.org
Re: Compiling a kernel that works
On Sun, Jun 29, 2003 at 09:12:53PM -0400, Ben Collins wrote: > > That worked fine, once I included the ext3 (which I remembered) and the > > tulip card (which I forgot) > > > > That seems happy. I normally use make-kpkg and install the resulting > > .deb file. Could that be the reason why it is breaking? > > Nope...I use make-kpkg aswell. I'd say you are just creating a kernel > that is missing some needed parts. OK, I'll make-kpkg a kernel with exactly the same config and see if that goes ok. There is still one problem, more annoying than anything. The kernel ignores the kernel parameters, including the root= line. With identical silo configs, an old kernel will know root is /dev/hda1 while the one using your instructions (and when I compile it sometimes if it gets that far) thinks the kernel parameters are "" This happens even if I put it on the silo line, eg linux root=/dev/hda1 The only way to get it to work is to break to the ok prompt and type boot linux root=/dev/hda1 it then knows the kernel paramters are "root=/dev/hda1" and mounts / correctly and happily goes on its way. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Re: Compiling a kernel that works
On Sun, Jun 29, 2003 at 08:05:40PM -0400, Ben Collins wrote: > On Mon, Jun 30, 2003 at 11:07:00AM +1000, Craig Small wrote: > > On Fri, Jun 27, 2003 at 02:37:28PM -0400, Ben Collins wrote: > > > First, compile a stock sparc64 kernel, without any of these patches. Use > > > 2.4.21, and do: > > > > > > cd /usr/src/linux-2.4.21 > > > cp arch/sparc64/defconfig .config > > > make oldconfig > > > make dep > > > make vmlinux > > > > > > After that, try to boot vmlinux. > > > > It says "image too large to fit in destination" > > The next thing would be to cut down the image, but then I'll be back > > where I was before. > > > > -rwxr-xr-x1 root root 3854163 Jun 30 10:31 vmlinux > > "make image" and use arch/sparc64/boot/image That worked fine, once I included the ext3 (which I remembered) and the tulip card (which I forgot) That seems happy. I normally use make-kpkg and install the resulting .deb file. Could that be the reason why it is breaking? - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Re: Compiling a kernel that works
On Fri, Jun 27, 2003 at 02:37:28PM -0400, Ben Collins wrote: > First, compile a stock sparc64 kernel, without any of these patches. Use > 2.4.21, and do: > > cd /usr/src/linux-2.4.21 > cp arch/sparc64/defconfig .config > make oldconfig > make dep > make vmlinux > > After that, try to boot vmlinux. It says "image too large to fit in destination" The next thing would be to cut down the image, but then I'll be back where I was before. -rwxr-xr-x1 root root 3854163 Jun 30 10:31 vmlinux > The "Memory Address not Aligned" does not come from SILO or the kernel, > from what I can see. Seems like an OBP message. Not sure what would give > you that. Perhaps try an uncompressed vmlinux instead of a compressed > vmlinuz. I don't know what an OBP is but from what I have read it is the prom giving that message. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Compiling a kernel that works
Hello,
I seem to be having a lot of problems getting a kernel that will work
on the sparc64 arch. All I need it to do is to use a VPN protocol - any
VPN protocol.
Here is my sorry tale of VPNs
- IPsec - doesn't work because the ioctls fail
- l2tpd - bus error
- pptpd kernel oops if i try to merge the modules in, cannot use new
kernel because of the following problem
When I try to compile a kernel and then boot it I get this:
Boot device: disk File and args:
SILO boot:
Uncompressing image...
|
Memory Address not Aligned
ok
I've tried gcc-2.95, gcc-3.2 and gcc-3.3 and kernel 2.4.20 and 2.4.21
It's an Sun X1 system.
Please CC me in replies.
here is the oops
Unable to handle kernel paging request in mna handler<1> at virtual
address 90fa2b6bd0fe2b6f
current->{mm,active_mm}->context = 0692
current->{mm,active_mm}->pgd = f80064731000
\|/ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
pptpctrl(683): Oops
TSTATE: 004411009607 TPC: 020288c4 TNPC: 020288c8 Y:
Tainted: P
g0: 00694400 g1: 35b66dfe78a47a9a g2: fff34d1519ac158f g3:
67425f1636e9fc40
g4: f800 g5: fff34d15 g6: f8006454 g7:
0010
o0: o1: 0011 o2: 0010 o3:
0080
o4: 0080 o5: 67425f16 sp: f80064542cb1 ret_pc:
02026158
l0: f800645435e0 l1: f800645435c0 l2: f80064543560 l3:
0800
l4: 0398 l5: 00696c00 l6: 00696c00 l7:
0042f900
i0: 90fa2b6bd0fe2b6b i1: b3f1ade4f3f5bfec i2: 0010 i3:
f80064543720
i4: f80065f16000 i5: f8006606a460 i6: f80064542e71 i7:
020261b4
Caller[020261b4]
Caller[020268a0]
Caller[02020678]
Caller[02020574]
Caller[0201fc44]
Caller[0202d244]
Caller[0202c574]
Caller[004c5c8c]
Caller[004c3214]
Caller[004bed70]
Caller[004666a8]
Caller[00410934]
Caller[0001389c]
Instruction DUMP: 81cfe008 0100 9de3be40 9a102000
9607a7ef c026 81802000 8273401a
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
Press L1-A to return to the boot prom
--
Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5
Eye-Net Consulting http://www.enc.com.au/<[EMAIL PROTECTED]>
MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Debian Woody on a Sun T1 and X1
Hello, I thought I'd pass back my comments about the Debian 3.0 CD and my attempts to install it on a T1 and X1. The T1 Its the older T1, 105 I think they're called. The old 2.2 Debian installed fine on them. The new one has problems. You get *lots* of CD timeouts, so many that it is impossible to get past the point where you install the base system. Everything up to that point seems ok. Abandoned it there and reverted back to Solaris, sigh. The X1 I was expecting problems. I got a few. First problem is nothing to do with Debian, no CD. So I gutted a PC and stole its IDE drive and opened the T1 and installed it sort of hanging out. CD booted, then stopped, no /boot/sparc64.gz typed rescue, which didn't go to rescue but booted and went into normal install mode, cool! BTW, /boot has a sparc64 (no gz) Installation went fine, except the dreaded evil X1 ethernet ports. Ah yes the loverly Davicoms. Well after *lots* of mucking around I found out through mainly trial and error that you use the tulip driver (they should rename it to freak card driver, anything wierd uses it) of course murphy says the tulip driver is not visible in modconf... Yay, detected, but then Tx buffer timeouts, I hate those because its Finnish for "something is screwed with the driver". OK, try the tulip driver withi option full_duplex=1 and.. it works! Except my link lights are flashing at me. The port works fine and it seems all ok, except if there is no connection they flicker. And then... the bloody ports are back to front. eth0 is port 1 on the back and eth1 is port 0. That's annoying. Still, the X1 is working, been up for 7 days straight now. No ethernet errors. I'm converting two more tomorrow. I think I'll leave the X1 as Solaris. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Netra T1s hate SUNGEM and QFE
Hello, You might remember my problem with a Netra T1 105 and a qfe card. Any packet that hit the qfe card locked the box up with no error message. A power cycle was needed. The solution was to try the qfe in a Netra T1 AC200. Problem #1, the Debian kernel in the install CD doesn't understand the IDE chip. OK, so we rip the drives out of the T1 105 and put them into the T1 AC200. Ah, Sun in their wisdom changed the interface from an hme to an eri, bastards. This means you need to use the SUNGEM driver. OK, recompile with new driver, I got eth0 to eth5 (0-3 qfe using happy meal driver, 4-5 using SUNGEM driver). Kernel is 2.4.17 First problem, what does this mean? # hwclock --show Timed out waiting for time change. Sounds like the public service or something. kernel: eth0-3: Quattro HME (PCI/CheerIO) 10/100baseT Ethernet DEC 21153 PCI Bridge kernel: eth0: Quattro HME slot 0 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:bf:01:40 kernel: eth1: Quattro HME slot 1 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:bf:01:41 kernel: eth2: Quattro HME slot 2 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:bf:01:42 kernel: eth3: Quattro HME slot 3 (PCI/CheerIO) 10/100baseT Ethernet 08:00:20:bf:01:43 kernel: sungem.c:v0.96 11/17/01 David S. Miller (davem@redhat.com) kernel: eth4: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:03:ba:0b:be:3e kernel: eth5: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:03:ba:0b:be:3d All is well until we start putting some load on the eth4 and eth5 interfaces, first we get this stuff: kernel: eth5: TX MAC max packet size error. kernel: eth5: TX MAC xmit underrun. kernel: NETDEV WATCHDOG: eth5: transmit timed out kernel: eth5: transmit timed out, resetting kernel: eth5: TX_STATE[003ffc05::0019] kernel: eth5: RX_STATE[0300c805:0001:0001] kernel: eth5: Link is up at 100 Mbps, half-duplex. and kernel: eth5: TX MAC xmit underrun. kernel: eth5: RX MAC fifo overflow. kernel: eth5: TX MAC xmit underrun. and then the netra decides to give the whole game away and just stop sending or receiving packets on that interface. It only happens with eth4 and eth5 (the eri using GEM) and when there is reasonable load, like downloading a big webpage, which really is not that big at all. Any suggestions? I've moved eth5 onto eth3 so I only got one dodgy interface left. Please CC me. -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Re: qfe locks up hard
On Thu, Jan 31, 2002 at 09:47:00AM -0500, Ben Collins wrote: > On Thu, Jan 31, 2002 at 05:23:21PM +1100, Craig Small wrote: > > Linux version 2.4.17 ([EMAIL PROTECTED]) (gcc version 3.0.3) #1 Wed Jan 16 > > Don't build with gcc-3.0. Install the egcs64 package, and rebuild the > kernel with that. OK, I tried that and it is marginally better. I can bring the interface up, it auto negotiates and then after, say 30 seconds, it locks up hard instead of locking up immediately. :( I'll fiddle around with some kernel settings to see if it makes a difference. I wish I could at least see a panic message or something. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
qfe locks up hard
lun 0 sym0:0: FAST-20 WIDE SCSI 40.0 MB/s ST (50.0 ns, offset 16) SCSI device sda: 35378533 512-byte hdwr sectors (18114 MB) Partition check: sda: sda1 sda2 sda3 sda4 sda5 sda6 sym0:1: FAST-20 WIDE SCSI 40.0 MB/s ST (50.0 ns, offset 16) SCSI device sdb: 35378533 512-byte hdwr sectors (18114 MB) sdb: sdb1 sdb3 sdb4 sdb8 md: raid1 personality registered as nr 3 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. LVM version 1.0.1-rc4(ish)(03/10/2001) NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 16384 bind 16384) ip_conntrack (476 buckets, 3808 max) ip_tables: (c)2000 Netfilter core team NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. INIT: version 2.84 booting Activating swap. Adding Swap: 51184k swap-space (priority -1) Checking root file system... fsck 1.25 (20-Sep-2001) /dev/sda1 was not cleanly unmounted, check forced. /dev/sda1: 2144/128000 files (0.6% non-contiguous), 9801/256000 blocks Calculating module dependencies... done. Loading modules: Checking all file systems... fsck 1.25 (20-Sep-2001) /dev/sda4 was not cleanly unmounted, check forced. /dev/sda4: 21433/768544 files (0.3% non-contiguous), 98993/1536000 blocks /dev/sda5 was not cleanly unmounted, check forced. /dev/sda5: 834/768544 files (2.0% non-contiguous), 39210/1536000 blocks /dev/sda6 was not cleanly unmounted, check forced. /dev/sda6: 11/540672 files (0.0% non-contiguous), 16983/1080832 blocks Setting kernel variables. Mounting local filesystems... /dev/sda4 on /usr type ext2 (rw) /dev/sda5 on /var type ext2 (rw) /dev/sda6 on /home type ext2 (rw) Setting up IP spoofing protection: rp_filter. Configuring network interfaces: done. Starting portmap daemon: portmap. Setting the System Clock using the Hardware Clock as reference... System Clock set. Local time: Thu Jan 31 17:16:55 EST 2002 Cleaning: /tmp /var/lock /var/run. Initializing random number generator... done. Setting audio parameters...none. INIT: Entering runlevel: 2 Starting system log daemon: syslogd klogd. Starting internet superserver: inetd. Starting IP Protocols Logger: ippl. Starting IP Tables Firewall: net/ipv4/ip_forward = 1 . Starting OpenBSD Secure Shell server: sshd. Starting periodic command scheduler: cron. Debian GNU/Linux 3.0 sydfwl03 ttyS0 sydfwl03 login: Debian GNU/Linux 3.0 sydfwl03 ttyS0 sydfwl03 login: -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Does LPRng 3.7.4-2 work for you?
G'day people with 64 bit computers (perhaps), I am the Debian maintainer for LPRng. This package had a severe problem in version 3.7.4-1 where lpd would immediately die on startup. A fix was kindly provided by an alpha user and I uploaded 3.7.4-2 But I've heard scattered reports of lpd crashing on alphas or sparcs. I'm not sure exactly what version they're running to know if this fix has fixed things or there is another nasty lurking there. If you run LPRng and are using 3.7.4-2 then could you drop me a line and say "yeah it's working" and just a few words about the config. I don't need the printcap, just something like are the clients (where you print) are local or remote and are the printers connected to parallel port or networked printers. Thanks for your help, and for the alpha people; yes I will get my PC164SX going one day.. blame aussie memory prices. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/<[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Re: Bug#46386: NO 2.1r3 SPARC CDs: lprng depends
J.A. Bezemer said: > Due to this problem, NO 2.1_r3 CD IMAGES CAN BE MADE FOR SPARC!! > > This problem was already reported 4-9-99 and still not corrected. Please > correct this ASAP. This was reported as bug #44685 which I will be merging with this bug. I don't do the Sparc packages, but will tell the sparc people to get their act together but I have already emailled them about this bug with no response. - Craig -- Craig Small VK2XLZ, PGP: AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90 Eye-Net Consulting http://www.eye-net.com.au/ <[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
Re: Bug#44685: Dependency problem with LPRng (fwd)
G'day sparc people, This bug is for whoever does the sparc version of lprng, it is not a generic deb or upstream issue. - Forwarded message from Alexandre Vitrac - >From [EMAIL PROTECTED] Fri Sep 10 16:30:05 1999 Message-ID: <[EMAIL PROTECTED]> X-Mailer: XFMail 1.3 [p0] on Solaris X-Priority: 3 (Normal) In-Reply-To: <[EMAIL PROTECTED]> Date: Fri, 10 Sep 1999 08:29:30 +0200 (MET DST) Organization: CS SI Athesa Sender: [EMAIL PROTECTED] From: Alexandre Vitrac <[EMAIL PROTECTED]> To: Craig Small <[EMAIL PROTECTED]> Subject: Re: Bug#44685: Dependency problem with LPRng Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] X-Sorted: Debian On 10-Sep-99 Craig Small wrote: > Having a quick look at the packages on master and other sites, they all > have the dependency of libncurses4 (with no version, as it should be). > However, I did notice the sparc arch did have versioned dependencies, > are you running a sparc? Yes I'm running a sparc version of Debian GNU/Linux. So there's probably no problem with the archive. How will the problem be solved ? Will there be a new upload of libncurses of a new upload of lprng ? Looking at the BTS I saw that libncurses was upgraded to 3.1 due to problems with glibc2.1 on version 3. And if I'm not mistaken, the sparc port is based on a pre-version of glibc2.1. This is probably why the sparc package for lprng places a dependency on this specific version. == Alexandre Vitrac CS SI ATHESA E-mail : [EMAIL PROTECTED] == - End of forwarded message from Alexandre Vitrac - -- Craig Small VK2XLZ, PGP: AD 8D D8 63 6E BF C3 C7 47 41 B1 A2 1F 46 EC 90 Eye-Net Consulting http://www.eye-net.com.au/ <[EMAIL PROTECTED]> MIEEE <[EMAIL PROTECTED]> Debian developer <[EMAIL PROTECTED]>
