tape server on netra t1
Hi! I am having problems with linux-sparc and tape drives. I set up a netra t1 as an amanda backup server, which runs debian sid and kernel 2.6.5-rc3-bk4. 10 others linux boxes are the clients. Minimal fs corruption occurs when the tape is under heavy I/O. The server has attached externally a dell PV-122T tape loader and internally 2 scsi hard drives, the loader and disks in different SCSI busses: <--- BEGIN ---< sym0: <896> rev 0x7 at pci :02:08.0 irq 4,7e0 sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking sym0: SCSI BUS has been reset. scsi0 : sym-2.1.18i Vendor: SEAGATE Model: ST318305LSUN18G Rev: 0340 Type: Direct-Access ANSI SCSI revision: 03 sym0:0:0: tagged command queuing enabled, command queue depth 16. sym0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25.0 ns, offset 31) Vendor: FUJITSU Model: MAJ3182M SUN18G Rev: 0804 Type: Direct-Access ANSI SCSI revision: 02 sym0:1:0: tagged command queuing enabled, command queue depth 16. sym1: <896> rev 0x7 at pci :02:08.1 irq 4,7e0 sym1: No NVRAM, ID 7, Fast-40, LVD, parity checking sym1: SCSI BUS has been reset. scsi1 : sym-2.1.18i Vendor: DELL Model: PV-122T Rev: D37r Type: Medium Changer ANSI SCSI revision: 02 Vendor: HPModel: Ultrium 1-SCSIRev: E32K Type: Sequential-Access ANSI SCSI revision: 03 sym1:6: FAST-40 WIDE SCSI 80.0 MB/s ST (25.0 ns, offset 15) st: Version 20040318, fixed bufsize 32768, s/g segs 256 Attached scsi tape st0 at scsi1, channel 0, id 6, lun 0 st0: try direct i/o: yes (alignment 512 B), max page reachable by HBA 98140 SCSI device sda: 35378533 512-byte hdwr sectors (18114 MB) SCSI device sda: drive cache: write through sda: sda1 sda2 sda3 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 sym0:1: FAST-40 WIDE SCSI 80.0 MB/s ST (25.0 ns, offset 31) SCSI device sdb: 35378533 512-byte hdwr sectors (18114 MB) SCSI device sdb: drive cache: write through sdb: sdb1 sdb2 sdb3 Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0 Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0 Attached scsi generic sg1 at scsi0, channel 0, id 1, lun 0, type 0 Attached scsi generic sg2 at scsi1, channel 0, id 5, lun 0, type 8 Attached scsi generic sg3 at scsi1, channel 0, id 6, lun 0, type 1 >--- END ---> Everything works as expected until the tape drive at /dev/nst0 is under fire, when heavy tape I/O occurs I get the following errors, which I have never seen before without the tape loader: <--- BEGIN ---< SABRE0: PCI SERR signal asserted. SABRE0: PCI bus error, PCI_STATUS[2aa0] SABRE0: Uncorrectable Error, primary error type[DMA Write:Translation Error] SABRE0: bytemask[00ff] dword_offset[6] was_block(0) SABRE0: UE AFAR [2f28b530] SABRE0: UE Secondary errors [(DMA Write)(Translation Error)] SABRE0: IOMMU Error, type[Invalid Error] SABRE0: IOMMU TAG(8)[RAW(00c616a6)error(Invalid Error)wr(0)sz(8K)vpg(c2d4c000)] SABRE0: IOMMU DATA(8)[RAW(6fe0)valid(1)used(1)cache(0)ppg() SABRE0: PCI SERR signal asserted. SABRE0: PCI bus error, PCI_STATUS[0aa0] SABRE0: PCI SERR signal asserted. SABRE0: PCI bus error, PCI_STATUS[0aa0] < 2 next lines repetitive... > SABRE0: PCI SERR signal asserted. SABRE0: PCI bus error, PCI_STATUS[0aa0] >--- END ---> Then fs errors occurs and debian mount the fs as read-only, a reboot and fsck.ext3 fixes the problem. -otto
Re: /lib64/libc.so.6: unexpected reloc type 0x08
On Tue, Dec 02, 2003 at 12:01:00PM -0500, Andy Dougherty wrote: > On Mon, 1 Dec 2003, Ben Collins wrote: > > You probably want 32-bit anyway, so try this instead: > [sparc32] > > Yes, I agree that's usually the case, but in this case in particular I > wanted 64-bits :-). glibc was broken, Ben and DaveM fix it. Just wait to the next glibc in your debian mirrors. -solca
Re: packet recompiles
On Thu, Nov 27, 2003 at 12:53:21PM -0500, Ben Collins wrote: > On Thu, Nov 27, 2003 at 05:27:52PM +0100, Peter Keel wrote: > > [sorry for writing the last few messages with a wrong email-address] > > > > Hello > > > > I'm trying to recompile some essential libraries for Sparc, since > > I know that some of those are meant for V7-architecture, whereas > > binaries for V8 and V9 could be much faster. > > > > Now, I'd like to do this the Debian way. The question is: > > if I do "apt-get -b source glibc", which optimizations > > will be done? Or do I end up with another V7-binary? If > > nothing will be changed, how do I tell the compiler to > > compile this for V9? (same for openssl and ssh). Preferably > > in a generic way, without modifying the makefiles. > > glibc in unstable is already targeted at v8. You can also install > libc6-sparcv9, but I think it is broken at the moment. Yes, it is still broken, in the last days i haven't seen updates to sid in any platform, maybe people is still auditing the compromised servers. -solca
Re: E250
On Thu, Nov 20, 2003 at 11:41:55AM -0500, Robert Ambrogi wrote: > Trying to bring the Debian Sparc "woody" release up on a Sparc E250. > > I get through the base install, re-boot and log in. > > I figure I'm home wrong > > I now need to load in "everything else" > > Go through the docs, upgrade my /etc/apt/sources.lst; it now has 5 lines, one > each reflecting CDs 2-6 of the downloaded iso's. > > I invoke something like apt-cache search gnome*, and scads of stuff comes > scrolling across the screen. > > All set. > > However, when I use tasksel, dselect, or apt-get to load anything, it always > complains about unmet dependencies. > > This is my first experience with Debian. I was under the opinion that all > the dependencies should be loaded automagically, along with my requested > package. > > What am I doing wrong here? You need to run 'apt-get update' before installing from new apt sources. -solca
Re: Kernel compile problems, revisited.
On Wed, Nov 19, 2003 at 01:35:57PM -0500, Ben Collins wrote: > > > gcc -o check_asm check_asm.c > > > ./check_asm >> asm_offsets.h > > > ./check_asm: error while loading shared libraries: /lib64/libc.so.6: > > > unexpected reloc type 0x08 > > > make[1]: *** [check_asm] Error 127 > > > make[1]: Leaving directory > > > `/usr/src/kernel-source-2.4.21/arch/sparc64/kernel' > > > make: *** [check_asm] Error 2 > > > > > > > > > Is this a bug in the current Debian unstable libc6-sparc64, or in > > > something else? > > > > > > ii libc6-sparc64 2.3.2.ds1-10 GNU C Library: 64bit Shared libraries > > > for Ul > > > > You must `dpkg -P libc6-dev-sparc64` now or wait for the next version. > > Actually, just doing "sparc32 make ..." will work aslong as you have the > latest sparc-utils package. Hmm... sparc32 command was not doing the right thing last time i check, now is working properly. -solca
Re: Kernel compile problems, revisited.
On Wed, Nov 19, 2003 at 05:51:41PM +0100, Pieter-Paul Spiertz wrote: > Hi, > > Yes, I'm still trying to build my own Linux-kernel for an Ultra Enterprise, > and I still got problems :( > > While doing a 'make dep' on kernel-source-2.4.21, on a Debian unstable > machine: > > tellar:/usr/src/kernel-source-2.4.21> make dep > make -C arch/sparc64/kernel check_asm > make[1]: Entering directory > `/usr/src/kernel-source-2.4.21/arch/sparc64/kernel' > gcc -E -D__KERNEL__ -I/usr/src/kernel-source-2.4.21/include -P tmp.c -o tmp.i > /bin/sh ./check_asm.sh -data task tmp.i check_asm_data.c > /bin/sh ./check_asm.sh -data mm tmp.i check_asm_data.c > /bin/sh ./check_asm.sh -data thread tmp.i check_asm_data.c > gcc -D__KERNEL__ -I/usr/src/kernel-source-2.4.21/include -m64 -mcmodel=medlow > -ffixed-g4 -S -o check_asm_data.s check_asm_data.c > /bin/sh ./check_asm.sh -ints check_asm_data.s check_asm.c > /bin/sh ./check_asm.sh -printf task tmp.i check_asm.c > /bin/sh ./check_asm.sh -printf mm tmp.i check_asm.c > /bin/sh ./check_asm.sh -printf thread tmp.i check_asm.c > gcc -o check_asm check_asm.c > ./check_asm >> asm_offsets.h > ./check_asm: error while loading shared libraries: /lib64/libc.so.6: > unexpected reloc type 0x08 > make[1]: *** [check_asm] Error 127 > make[1]: Leaving directory `/usr/src/kernel-source-2.4.21/arch/sparc64/kernel' > make: *** [check_asm] Error 2 > > > Is this a bug in the current Debian unstable libc6-sparc64, or in > something else? > > ii libc6-sparc64 2.3.2.ds1-10 GNU C Library: 64bit Shared libraries for Ul You must `dpkg -P libc6-dev-sparc64` now or wait for the next version. -solca
Re: x server no running on a ultra 60
On Tue, Nov 18, 2003 at 02:47:19PM -0600, [EMAIL PROTECTED] wrote: > hello guys > i have a debian 3.0.1 runing on a sparc ultra 60 whit a SUN elite 3D > i have some problems to start the x server due to errors reporting > when loading /usr/X11R6/lib/modules/libshadow.a > FBIOPUT_VSCREENINFO:invalid argument > > Fatal server error: > AddScreen/ScreenInit Failed for driver 0 > > Xfree configurator does not correct the mistake > > some help to start the x server without black magic ??? try without 'fbdev' driver nor 'Option FBDev True' in your X config. -solca
Re: Image too large to fit into destination with 2.6.0-test9
On Tue, Nov 18, 2003 at 07:57:27PM +0100, Thomas Habets wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tuesday 18 November 2003 18:10, Otto Solares wrote: > > you must 'make image' first then use arch/sparc64/boot/image for silo. > > You mean sparc, not sparc64? It's a sparcstation 4, not an ultrasparc. Good, i have a ss4 too. > Like I said, I tried arch/sparc/boot/image. I tried it raw and I tried it > gzipped, I've also tried it stripped&&gzipped, which got it down to 3.0M, > 1.3M gzipped (gzip -9) > > So: > cp arch/sparc/boot/image . > strip -R .comment -R .note image -o image.stripped # i've tried w/o this > gzip -9 image.stripped # I've tried w/o this > cp image.stripped.gz /boot/vmlinuz-2.6.0-test9 > > I used "make all", which accoring to "make help" includes "make image" these are the steps i do to compile a 2.6 kernel on my ss4: cp arch/sparc/defconfig .config make oldconfig make make image make modules make modules_install cp arch/sparc/boot/image /boot/vmlinuz silo -U -f # not needed but anyway... :) The only problem i have with my ss4 and kernel 2.6 is the lack of keyboard and mouse, i have looked deeply in the sunzilog code and can't find a solution. -solca
Re: Image too large to fit into destination with 2.6.0-test9
On Tue, Nov 18, 2003 at 05:55:31PM +0100, Thomas Habets wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tuesday 18 November 2003 17:34, [EMAIL PROTECTED] wrote: > > Silo has gzip built in. You can just gzip the kernel image, and then > > just point silo at the .gz file, and it'll do all the rest for you. > > That's what I meant I tried with the gzip-lines below. Sorry for being > unclear. you must 'make image' first then use arch/sparc64/boot/image for silo. -solca
Re: 64bits & df
On Wed, Nov 12, 2003 at 05:57:14PM -0800, David S. Miller wrote: > I've also just found a few problems with 32-bit statfs64 system > calls in the kernel when running on sparc64, so best to stay > away from 2.6.x without the following patch and until Ben looks > into the glibc side issues. The problem is fixed in all my boxes with that patch, thank you! -solca
Re: 64bits & df
On Wed, Nov 12, 2003 at 05:30:22PM -0800, David S. Miller wrote: > On Wed, 12 Nov 2003 18:18:51 -0600 > Otto Solares <[EMAIL PROTECTED]> wrote: > > > Hopefully glibc's statfs64 does not depend on kernel 2.4. > > The statfs64 system call only exists in 2.6.x kernels that is > why 2.4.x returns -ENOSYS and then glibc downgrades to use the > older statfs system call instead. Thank you. Hopefully Ben will find a solution, weird he does not have the same problem using 2.6 and latest sid's glibc. -solca
Re: 64bits & df
On Wed, Nov 12, 2003 at 04:03:41PM -0800, David S. Miller wrote: > On Wed, 12 Nov 2003 18:05:08 -0600 > Otto Solares <[EMAIL PROTECTED]> wrote: > > > does this make sense?, i put a printf inside the syscall number decoding > > but maybe its wrong, if write is syscall nr. 4 its right i guess. > > > > syscall number: 234 > > nis_syscall(0x292b0, 0x58) = -1 EINVAL (Invalid argument) > > syscall number: 4 > > write(2, "df: ", 4df: ) = 4 > > Perfect, that's exactly what I needed. Thanks! > > System call 234 is sys_statfs64 > > sys_statfs64() returns -EINVAL if the second argument is not > equal to sizeof(struct statfs64). > > The correct value should be 120 (or 0x78 in hex), but 88 (0x58 in > hex) is what is being passed in here. > > It seems that struct statfs64 is not correct in the sparc/sparc64 > glibc sources. Ben can you go check this out? Hopefully glibc's statfs64 does not depend on kernel 2.4. -solca
Re: 64bits & df
On Wed, Nov 12, 2003 at 03:12:46PM -0800, David S. Miller wrote:
> On Wed, 12 Nov 2003 17:13:55 -0600
> Otto Solares <[EMAIL PROTECTED]> wrote:
>
> > nis_syscall(0x28f90, 0x58) = -1 ENOSYS (Function not
> > implemented)
> ...
>
> > nis_syscall(0x29240, 0x58) = -1 EINVAL (Invalid argument)
>
> I wish there was a way to make strace print out the raw system call
> number instead of the "nis_syscall" strings. This strace build
> doesn't know about all of the NPTL system call assignments so it
> can't print the system call number correctly.
>
> If anything strace should do something like
>
> printf("nis_syscall_%d", syscall_num);
>
> so that the raw syscall number could be determined.
>
> I need this information in order to debug this.
does this make sense?, i put a printf inside the syscall number decoding
but maybe its wrong, if write is syscall nr. 4 its right i guess.
syscall number: 234
nis_syscall(0x292b0, 0x58) = -1 EINVAL (Invalid argument)
syscall number: 4
write(2, "df: ", 4df: ) = 4
-solca
Re: 64bits & df
On Wed, Nov 12, 2003 at 02:56:07PM -0800, David S. Miller wrote:
> On Wed, 12 Nov 2003 15:28:20 -0500
> Ben Collins <[EMAIL PROTECTED]> wrote:
>
> > > Can be a 2.6 problem? i don't have 2.4 anymore...
> >
> > That's a tricky one. I've no idea why it would do that for you. I am
> > running 2.6 aswell without these problems.
>
> One thing to keep in mind btw, 2.6.x is going to allow glibc to use
> NPTL. I know the current glibc has Sparc NPTL support in it because
> when I'm running 2.4.x kernels glibc tries to invoke sys_exit_group()
> and this spits out a few kernel messages early in bootup.
>
> If reverting to 2.4.x fixes the problem for this person, that would
> be telling.
I revert back to 2.4.21 and the problem ceased, interesting is the
strace difference between 2.4 and 2.6:
2.4:
nis_syscall(0x28f90, 0x58) = -1 ENOSYS (Function not implemented)
statfs("/", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=498576,
f_bfree=189806, f_bavail=164479, f_files=253440, f_ffree=181239, f_fsid={0, 0},
f_namelen=255, f_frsize=1
}) = 0
2.6:
nis_syscall(0x29240, 0x58) = -1 EINVAL (Invalid argument)
-solca
Re: 64bits & df
On Wed, Nov 12, 2003 at 02:50:31PM -0500, Ben Collins wrote: > > --- > > > nis_syscall(0x29240, 0x58) = -1 EINVAL (Invalid argument) > > > write(2, "df: ", 4) = 4 > > > write(2, "`/\'", 3) = 3 > > > write(2, ": Invalid argument", 18) = 18 > > > write(2, "\n", 1) = 1 > > > nis_syscall(0x29298, 0x58) = -1 EINVAL (Invalid argument) > > > write(2, "df: ", 4) = 4 > > > write(2, "`/proc\'", 7) = 7 > > > write(2, ": Invalid argument", 18) = 18 > > > write(2, "\n", 1) = 1 > > > nis_syscall(0x292f0, 0x58) = -1 EINVAL (Invalid argument) > > > write(2, "df: ", 4) = 4 > > > write(2, "`/dev/pts\'", 10) = 10 > > > write(2, ": Invalid argument", 18) = 18 > > > write(2, "\n", 1) = 1 > > > nis_syscall(0x29348, 0x58) = -1 EINVAL (Invalid argument) > > > write(2, "df: ", 4) = 4 > > > write(2, "`/sys\'", 6) = 6 > > > write(2, ": Invalid argument", 18) = 18 > > > write(2, "\n", 1) = 1 > > > > i can confirm this behavior on 3 differents sparcs with sid, woody uses > > statfs. > > Do you have nis listed in /etc/nsswitch.conf? Just the default for netgroups, commenting out that line doesn't differ, file have same content on x86 as sparc: # /etc/nsswitch.conf # # Example configuration of GNU Name Service Switch functionality. # If you have the `glibc-doc' and `info' packages installed, try: # `info libc "Name Service Switch"' for information about this file. passwd: files group: files shadow: files hosts: files dns networks: files protocols: files services: files ethers: files rpc:files netgroup: nis Can be a 2.6 problem? i don't have 2.4 anymore... -solca
Re: 64bits & df
On Wed, Nov 12, 2003 at 01:46:20PM -0500, Ben Collins wrote:
> On Tue, Nov 11, 2003 at 07:40:34PM -0600, Otto Solares wrote:
> > Hi!
> >
> > i am trying to compile an app with 64bits on a ultrasparc,
> > so i installed lib6-dev-sparc64 package, kernel 2.6.0-test9-bk16:
> >
> > [EMAIL PROTECTED]:~$ gcc -o hello hello.c
> > [EMAIL PROTECTED]:~$ file hello
> > hello: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), for GNU/Linux
> > 2.4.18, dynamically linked (uses shared libs), not stripped
> > [EMAIL PROTECTED]:~$ ./hello
> > ./hello: error while loading shared libraries: /lib64/libc.so.6: unexpected
> > reloc type 0x08
>
> Something is currently broken with glibc for 64-bit. I'm not sure what
> or why, but I have to look at it this week.
i was trying to compile glibc to figure out something but is too big to my poor
sparcs :(
> > and this 'df' problem:
> >
> > [EMAIL PROTECTED]:~$ df -h
> > FilesystemSize Used Avail Use% Mounted on
> > df: `/': Invalid argument
> > df: `/proc': Invalid argument
> > df: `/dev/pts': Invalid argument
> > df: `/sys': Invalid argument
>
> df is working fine for me. Is something broken in your /etc/fstab?
# /etc/fstab: static file system information.
#
#
/dev/md0/ ext3errors=remount-ro,noatime 0 1
/dev/md1noneswapsw 0 0
/dev/cdrom /cdrom iso9660 ro,user,noauto 0 0
proc/proc procdefaults0 0
sys /syssysfs defaults0 0
strace on x86 sid show that df uses statfs:
statfs64("/", 84, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=984313,
f_bfree=686620, f_bavail=636618, f_files=500960, f_ffree=418223, f_fsid={0, 0},
f_namelen=255, f_frsize=4096}) = 0
write(1, "/dev/hda2 3.8G 1.2G"..., 46) = 46
statfs64("/proc", 84, {f_type="PROC_SUPER_MAGIC", f_bsize=4096, f_blocks=0,
f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255,
f_frsize=4096}) = 0
statfs64("/dev/pts", 84, {f_type="DEVPTS_SUPER_MAGIC", f_bsize=4096,
f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0},
f_namelen=255, f_frsize=4096}) = 0
statfs64("/var/spool/squid", 84, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096,
f_blocks=4810951, f_bfree=789964, f_bavail=545575, f_files=2448000,
f_ffree=1509469, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
write(1, "/dev/hdc1 19G 16G"..., 61) = 61
statfs64("/sys", 84, {f_type=0x62656572, f_bsize=4096, f_blocks=0, f_bfree=0,
f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096})
= 0
strace on sparc sid uses nis_syscall:
---
> nis_syscall(0x29240, 0x58) = -1 EINVAL (Invalid argument)
> write(2, "df: ", 4) = 4
> write(2, "`/\'", 3) = 3
> write(2, ": Invalid argument", 18) = 18
> write(2, "\n", 1) = 1
> nis_syscall(0x29298, 0x58) = -1 EINVAL (Invalid argument)
> write(2, "df: ", 4) = 4
> write(2, "`/proc\'", 7) = 7
> write(2, ": Invalid argument", 18) = 18
> write(2, "\n", 1) = 1
> nis_syscall(0x292f0, 0x58) = -1 EINVAL (Invalid argument)
> write(2, "df: ", 4) = 4
> write(2, "`/dev/pts\'", 10) = 10
> write(2, ": Invalid argument", 18) = 18
> write(2, "\n", 1) = 1
> nis_syscall(0x29348, 0x58) = -1 EINVAL (Invalid argument)
> write(2, "df: ", 4) = 4
> write(2, "`/sys\'", 6) = 6
> write(2, ": Invalid argument", 18) = 18
> write(2, "\n", 1) = 1
i can confirm this behavior on 3 differents sparcs with sid, woody uses statfs.
-solca
64bits & df
Hi! i am trying to compile an app with 64bits on a ultrasparc, so i installed lib6-dev-sparc64 package, kernel 2.6.0-test9-bk16: [EMAIL PROTECTED]:~$ gcc -o hello hello.c [EMAIL PROTECTED]:~$ file hello hello: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), for GNU/Linux 2.4.18, dynamically linked (uses shared libs), not stripped [EMAIL PROTECTED]:~$ ./hello ./hello: error while loading shared libraries: /lib64/libc.so.6: unexpected reloc type 0x08 and this 'df' problem: [EMAIL PROTECTED]:~$ df -h FilesystemSize Used Avail Use% Mounted on df: `/': Invalid argument df: `/proc': Invalid argument df: `/dev/pts': Invalid argument df: `/sys': Invalid argument -solca
Re: cannot find sparc64.gz
On Mon, Aug 18, 2003 at 04:00:45PM -0700, David S. Miller wrote: > On Tue, 19 Aug 2003 00:04:39 +0200 > Antonello <[EMAIL PROTECTED]> wrote: > > > The only difference I notice is the use of EGCS in the Debian build, while > > I > > used a more vanilla gcc-3.3 (the current unstable builds). > > As I told you in private email gcc-3.3 can only successfully > compile current 2.4.22-rcX kernels. As per Ben Collin's info, we can use woody's gcc-3.3.1 to compile 2.6 kernels. -solca
Re: apt update issue
On Sun, Aug 10, 2003 at 04:37:12PM -0400, Matt Herzog wrote: > Hello Sparc people. > > Perhaps I should address this mail to the apt or dpkg mailing list > but I thought I'd try here forst in case it's a Sparc-specific issue. > I already and repeatedly tried the suggested solution to no avail. that command works perfectly here on woody sparcs, you must 'update' then 'dist-upgrade' first. -solca
sunzilog mess in 2.5/2.6
Hi!
i am trying to figure what is going wrong with the sunzilog
driver but i can't figure what is bad in sunzilog.c i don't
have keyboard/mouse nor serial i/o, maybe someone can connect
all the bits from the following info:
-
Relevant dmesg from 2.4:
Sparc Zilog8530 serial driver version 1.68.2.2
Sun Mouse-Systems mouse driver version 1.00
tty00 at 0xf114 (irq = 12,7e8) is a Zilog8530
tty01 at 0xf110 (irq = 12,7e8) is a Zilog8530
tty02 at 0xf104 (irq = 12,7e8) is a Zilog8530
tty03 at 0xf100 (irq = 12,7e8) is a Zilog8530
Sun TYPE 5 keyboard detected without keyclick
dmesg from a modified 2.6.0-test2-bk3:
Serial: Sun Zilog driver (2 chips, 4 channels).
zs: channel 0 at 0x01fff114 (irq = 12,7e8) is a SunZilog at chip 0
zs: channel 1 at 0x01fff110 (irq = 12,7e8) is a SunZilog at chip 0
zs: channel 2 at 0x01fff104 (irq = 12,7e8) is a SunZilog at chip 1
zs: channel 3 at 0x01fff100 (irq = 12,7e8) is a SunZilog at chip 1
ttyS0 at MMIO 0x01fff114 (irq = 12,7e8) is a SunZilog
ttyS1 at MMIO 0x01fff110 (irq = 12,7e8) is a SunZilog
mice: PS/2 mouse device common for all mice
evbug.c: Connected device: "Sun Mouse", zs/serio1/input0
input: Sun Mouse on zs/serio1
[ i am sure keyboard get registered in serio but doesn't show up here ]
-
relevant prtconf from 2.4 (or 2.6 - zs nodes are the same):
Node 0xf005a538
port-b-ignore-cd:
port-a-ignore-cd:
reg: 000f.0110.0004
interrupts: 0028
device_type: 'serial'
name: 'zs'
Node 0xf005b9d8
reg: 000f.0100.0004
interrupts: 0028
port-b-ignore-cd:
port-a-ignore-cd:
keyboard:
device_type: 'serial'
name: 'zs'
-
diff from prtconf-2.4 & prtconf-2.6:
13c13
< clock-frequency: 0442d878
---
> clock-frequency: 0442d9d0
75c75
< #power-cycles: '197'
---
> #power-cycles: '204'
336c336
< clock-frequency: 0885b0f0
---
> clock-frequency: 0885b3a0
[ is not supposed prtconf to get same results every time? ]
-
every `/etc/init.d/setserial stop` i get:
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 0726
tsk->{mm,active_mm}->pgd = f86cf000
\|/ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
setserial(483): Oops [#1]
TSTATE: 004411009605 TPC: 004fc68c TNPC: 004fc690 Y:
Not tainted
TPC:
g0: 0001 g1: 004e5324 g2: f80011f43850 g3:
f8001121b440
g4: f80010c59220 g5: g6: f800102d g7:
o0: o1: f8001121a3a0 o2: o3:
f8001082c118
o4: 0059ff40 o5: sp: f800102d30d1 ret_pc:
004e5e94
RPC:
l0: f8001082c000 l1: l2: f8001082ca60 l3:
0020
l4: f8001082cd38 l5: 0001 l6: l7:
7017244c
i0: f8001082c000 i1: f8001121a3a0 i2: 004fc680 i3:
0010
i4: f80011e3cec0 i5: i6: f800102d3191 i7:
004e5994
I7:
Instruction DUMP: 9de3bf40 e25e2a58 a6046020 7ffca2f4 90100013
7fffa062 90100019 80a22000
-
`setserial -a /dev/ttyS0` from 2.4:
/dev/ttyS0, Line 0, UART: unknown, Port: 0xf114, IRQ: 7173248
Baud_base: 0, close_delay: 50, divisor: 16
closing_wait: 3000
Flags: spd_normal
`setserial -a /dev/ttyS0` from 2.6:
/dev/ttyS0, Line 0, UART: undefined, Port: 0x, IRQ: 6515136
Baud_base: 307200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal
[ weird setserial info in 2.6 ]
-
Let's get this f***ing bug fixed!! just show me the way if you have no time...
-solca
Re: egcs64 package
On Sat, Aug 02, 2003 at 06:47:57PM -0400, Ben Collins wrote: > On Sat, Aug 02, 2003 at 04:21:22PM -0600, Otto Solares wrote: > > On Sat, Aug 02, 2003 at 05:17:03PM -0400, Ben Collins wrote: > > > You don't need egcs64 in unstable. Use the latest gcc-3.2 or gcc-3.3 > > > packages instead. > > > > 2.6.0-testX compiles with gcc-3.3 now? > > Has since 3.3.1-0ds2 packages (7/28 snapshot of 3.3.1). Fine. update-alternatives --config cc shows nothing to configure, how can i set gcc-3.3.1 the default? -solca
Re: egcs64 package
On Sat, Aug 02, 2003 at 05:17:03PM -0400, Ben Collins wrote: > You don't need egcs64 in unstable. Use the latest gcc-3.2 or gcc-3.3 > packages instead. 2.6.0-testX compiles with gcc-3.3 now? -solca
Re: 2.6-test2 on unusual UE2
On Mon, Jul 28, 2003 at 01:41:50PM -0500, Greg Moeller wrote: > > > I'm trying to compile kernels with egcs64 (egcs-2.92.11) and gcc 3.0.4 > > > (both > > > defaults from debian) > > > > First off, I don't think gcc-3.0.4 is default in anything but testing > > right now. You should be using the gcc-3.2 from unstable to compile > > sparc64 kernels. > > > I switched apt to unstable and installed 3.2.3, but when I did, as stopped > working: > [EMAIL PROTECTED]:~$ as > as: error while loading shared libraries: libbfd-2.14.90.0.1.so: cannot open > shared object file: No such file or directory > [EMAIL PROTECTED]:~$ ls -l /usr/lib/libbfd* > -rw-r--r--1 root root 594372 Jul 24 16:16 > /usr/lib/libbfd-2.14.90.0.5.so same issue here, i did the following: # cd /usr/lib # ln -s liblibbfd-2.14.90.0.5.so libbfd-2.14.90.0.1.so hopefully will be fixed in next binutils. -solca
Re: Openboot question -- Solution
On Mon, Jul 28, 2003 at 11:41:26AM +0200, Hendrik Sattler wrote: > Which key is meant to be the L1-Key? L1 key <-> Stop key -solca
sparc32 sunkbd 2.6.0-test1
Hi ppl, i was able to boot 2.6.0-test1 but the keyboard sun type 5c doesn't work & FB console doesn't work, just PROM console. I think i have a correct .config file. Is a 2.6.0-test1 stock with davem's patch to get rid of pci on non-pci sparcs, i don't think these patch will create any problems, anyway is attached too. Any help please? Attached is my system's info. -solca cpu : Fujitsu MB86904 fpu : Lsi Logic/Meiko L64804 or compatible promlib : Version 3 Revision 2 prom: 2.20 type: sun4m ncpus probed: 1 ncpus active: 1 BogoMips: 84.78 MMU type: Fujitsu Swift contexts: 256 nocache total : 1048576 nocache used: 102912 # # Automatically generated make config: don't edit # CONFIG_MMU=y CONFIG_UID16=y CONFIG_HIGHMEM=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_KMOD=y # # General setup # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SMP is not set CONFIG_SPARC32=y CONFIG_SBUS=y CONFIG_SBUSCHAR=y CONFIG_SERIAL_CONSOLE=y CONFIG_SUN_AUXIO=y CONFIG_SUN_IO=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_SUN_PM=y # CONFIG_SUN4 is not set # CONFIG_PCI is not set # CONFIG_SUN_OPENPROMFS is not set CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_SUNOS_EMUL is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Generic Driver Options # # CONFIG_FW_LOADER is not set # # Graphics support # CONFIG_FB=y # CONFIG_FB_BW2 is not set # CONFIG_FB_CG3 is not set # CONFIG_FB_CG6 is not set CONFIG_FB_SBUS=y CONFIG_FB_TCX=y # CONFIG_FB_CG14 is not set # CONFIG_FB_P9100 is not set # CONFIG_FB_LEO is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # # CONFIG_VGA_CONSOLE is not set # CONFIG_MDA_CONSOLE is not set # CONFIG_PROM_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_PCI_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_SUN8x16=y # CONFIG_FONT_SUN12x22 is not set # # Logo configuration # # CONFIG_LOGO is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Serial drivers # # # Non-8250 serial port support # CONFIG_SERIAL_SUNCORE=y CONFIG_SERIAL_SUNZILOG=y # CONFIG_SERIAL_SUNZILOG_CONSOLE is not set CONFIG_SERIAL_CORE=y # # Misc Linux/SPARC drivers # # CONFIG_SUN_OPENPROMIO is not set CONFIG_SUN_MOSTEK_RTC=m # # Block devices # # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_RAM is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL is not set # # SCSI device support # CONFIG_SCSI=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_REPORT_LUNS=y # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_QLOGICPTI is not set # CONFIG_SCSI_DEBUG is not set CONFIG_SCSI_SUNESP=y # # Fibre Channel support # # CONFIG_FC4 is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_XFRM_USER is not set # CONFIG_VLAN_8021Q is not set # CONFIG_LLC is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETDEVICES=y # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_MII is not set CONFIG_SUNLANCE=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNQE is not set # # Ethernet (1000 Mbit) # # CONFIG_MYRI_SBUS is not set # # Ethernet (1 Mbit) # # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token
Re: sparc32/64 kernel 2.6.0-test1
On Thu, Jul 24, 2003 at 09:34:09AM -0400, Ben Collins wrote: > Weird. Well, I am building 2.6.0-test1 (no ac stuff) with gcc-3.2.3 on > sparc64 without any problems. right, i fallback to no ac stuff. > Try doing this: > > cp arch/sparc64/defconfig .config > make oldconfig > make vmlinux > make image > > Then boot using arch/sparc64/boot/image > > If that works, then we know it's in your config. finally success! i boot sparc32, well i had to deselect a lot of options because the kernel was to large with oldconfig to boot. Too i don't have keyboard and my kernel panics when touching swap, but first i got to realize how to enable kbd to further debug. thank you. -solca
Re: sparc32/64 kernel 2.6.0-test1
On Tue, Jul 22, 2003 at 08:49:26AM -0400, Ben Collins wrote: > > bad: scheduling while atomic! > > > > and a numbers like: > > > > [0x:?] > > Do you have preemption enabled? If so, disable it. yep, it was enabled. Now i get (both sparc/sparc64) with 'linux -p' to this point (linux-2.6.0-test1-ac3): biovec pool[5]: 256 bvecs: 1 entries (3072 bytes) it hangs for a few seconds then reboots. -solca
Re: sparc scsi esp depends on pci & hangs on boot
On Wed, Jul 23, 2003 at 12:27:37AM -0700, David S. Miller wrote: > On Wed, 23 Jul 2003 01:20:56 -0600 > Otto Solares <[EMAIL PROTECTED]> wrote: > > > everything else includes the generic one (pci dependant). > > With this model what happens if a box had more than one > > bus type (if technically possible)? > > If the architecture wants to support such situations, > then the implementation needs to vector off to different > operations based upon the actual bus type. > > Even though technically devices having SBUS and PCI variants could do > this, none do currently, and also I do not use the generic device > model in the SBUS layer, therefore I'm not going to add such multi-bus > support to what Sparc uses for dma-mapping.h ok, i understand now. Theorically could be nice the new API, i better stick with the current per-bus-drivers. > If someone is bored and willing to do all of the generic device and > ->dma_ops work for Sparc and SBUS, feel free to send me some patches. > Otherwise, it won't get done :-) :) fine with me. -solca
Re: sparc scsi esp depends on pci & hangs on boot
FYI i had compile both sparc32/sparc64 with these patch and finally that fu**ing PCI dependency is gone! thank you :) This should be done in asm-generic/dma-mapping.h IMHO with others archs in mind. -solca On Wed, Jul 23, 2003 at 12:20:08AM -0700, David S. Miller wrote: > On Wed, 23 Jul 2003 08:02:22 +0100 > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > On Tue, Jul 22, 2003 at 11:57:14PM -0700, David S. Miller wrote: > > > I don't see why this is a problem. Either do this, or fix > > > asm-generic/dma-mapping.h which is not GENERIC because it > > > depends upon something SPECIFIC, specifically PCI. > > > > The latter is what need to be done. > > I'll do the following for now. > > # This is a BitKeeper generated patch for the following project: > # Project Name: Linux kernel tree > # This patch format is intended for GNU patch command version 2.5 or higher. > # This patch includes the following deltas: > #ChangeSet1.1518 -> 1.1519 > # include/asm-sparc64/dma-mapping.h 1.1 -> 1.2 > # include/asm-sparc/dma-mapping.h 1.1 -> 1.2 > # > # The following is the BitKeeper ChangeSet Log > # > # 03/07/23[EMAIL PROTECTED] 1.1519 > # [SPARC]: Do not include asm-generic/dma-mapping.h if !CONFIG_PCI. > # > # > diff -Nru a/include/asm-sparc/dma-mapping.h b/include/asm-sparc/dma-mapping.h > --- a/include/asm-sparc/dma-mapping.h Wed Jul 23 00:06:03 2003 > +++ b/include/asm-sparc/dma-mapping.h Wed Jul 23 00:06:03 2003 > @@ -1 +1,5 @@ > +#include > + > +#ifdef CONFIG_PCI > #include > +#endif > diff -Nru a/include/asm-sparc64/dma-mapping.h > b/include/asm-sparc64/dma-mapping.h > --- a/include/asm-sparc64/dma-mapping.h Wed Jul 23 00:06:03 2003 > +++ b/include/asm-sparc64/dma-mapping.h Wed Jul 23 00:06:03 2003 > @@ -1 +1,5 @@ > +#include > + > +#ifdef CONFIG_PCI > #include > +#endif
Re: sparc scsi esp depends on pci & hangs on boot
On Wed, Jul 23, 2003 at 08:04:55AM +0100, Christoph Hellwig wrote: > If you want to help fix asm-generic/dma-mapping.h to be noops > if !CONFIG_PCI or even better make it always noops and add an > asm-generic/dma-mapping-in-terms-of-pci.h for those who want > them to map to PCI. if !CONFIG_PCI -> noops else include asm-generic/dma-mapping.h That seems doable, but.. just arm, i386 & parisc have their own dma-mapping.h everything else includes the generic one (pci dependant). With this model what happens if a box had more than one bus type (if technically possible)? -solca
Re: sparc scsi esp depends on pci & hangs on boot
On Tue, Jul 22, 2003 at 11:29:11PM -0700, David S. Miller wrote: > On Wed, 23 Jul 2003 07:28:36 +0100 > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > Putting it into linux/dma-mapping.h is fine with me, but I expect to > > see more users of the dma-mapping API soon.. > > And unlike this particular scsi layer usage, such drivers will be > dependant upon things like CONFIG_PCI and thus won't get compiled > in unless CONFIG_PCI has been enabled in the kernel configuration. I originally though the whole idea was to remove the PCI dependency. -solca
Re: GUI on Sparc 2
On Tue, Jul 22, 2003 at 07:45:10PM -0800, [EMAIL PROTECTED] wrote: > Someone please tell me how to turn off > startup of kde without de-installing it. quick fix: rm /etc/rc2.d/S99kdm long fix: edit /etc/X11/default-display-manager and adjust to your taste. -solca
Re: sparc scsi esp depends on pci & hangs on boot
On Tue, Jul 22, 2003 at 05:54:00PM -0700, David S. Miller wrote: > On Tue, 22 Jul 2003 12:26:09 -0600 > Otto Solares <[EMAIL PROTECTED]> wrote: > > > converting the esp scsi driver to sbus without > > pci requirement is the right step IMO. Maybe > > the scsi people can comment on this. > > No, the problem is that SCSI DMA transfer direction > macros are defined in terms of PCI ones. That's all, > it's a minor issue and probably easily solved. these are the ofending messages: In file included from include/asm/dma-mapping.h:1, from include/linux/dma-mapping.h:13, from include/scsi/scsi_cmnd.h:4, from drivers/scsi/scsi.h:20, from drivers/scsi/scsi.c:57: include/asm-generic/dma-mapping.h: In function `dma_supported': include/asm-generic/dma-mapping.h:19: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h:19: (Each undeclared identifier is reported only once include/asm-generic/dma-mapping.h:19: for each function it appears in.) include/asm-generic/dma-mapping.h: In function `dma_set_mask': include/asm-generic/dma-mapping.h:27: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function `dma_alloc_coherent': include/asm-generic/dma-mapping.h:36: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function `dma_free_coherent': include/asm-generic/dma-mapping.h:45: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function `dma_map_single': include/asm-generic/dma-mapping.h:54: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function `dma_unmap_single': include/asm-generic/dma-mapping.h:63: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function `dma_map_page': include/asm-generic/dma-mapping.h:73: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function `dma_unmap_page': include/asm-generic/dma-mapping.h:82: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function `dma_map_sg': include/asm-generic/dma-mapping.h:91: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function `dma_unmap_sg': include/asm-generic/dma-mapping.h:100: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function `dma_sync_single': include/asm-generic/dma-mapping.h:109: `pci_bus_type' undeclared (first use in this function) include/asm-generic/dma-mapping.h: In function `dma_sync_sg': include/asm-generic/dma-mapping.h:118: `pci_bus_type' undeclared (first use in this function) make[2]: *** [drivers/scsi/scsi.o] Error 1 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 -solca
Re: sparc scsi esp depends on pci & hangs on boot
On Tue, Jul 22, 2003 at 08:09:05AM -0400, Pete Zaitcev wrote: > > Date: Mon, 21 Jul 2003 20:51:42 -0600 > > From: Otto Solares <[EMAIL PROTECTED]> > > > ultra enterprise 1 (sun4u sparc64) > > sparc station 4(sun4m sparc32) > > > > on both i need to enable PCI support even > > when these boxes doesn't have a PCI bus, > > I'll look into sparc32 problems when I get from Canada. good. converting the esp scsi driver to sbus without pci requirement is the right step IMO. Maybe the scsi people can comment on this. -solca
Re: sparc32/64 kernel 2.6.0-test1
On Mon, Jul 21, 2003 at 11:00:42PM -0400, Ben Collins wrote: > > > I said _gcc-3.2.3_ Nothing else will work for sparc64 and 2.6 kernels. > > > Install gcc and gcc-3.2 packages from unstable. > > > > i tried gcc-3.2.3 with no luck. > > Boot with "linux -p" so I can see the last bit of output. What sort of > sparc64 is this? the box is an sparc64 Ultra Enterprise 1, cpu as reported by 2.4.19: [EMAIL PROTECTED]:~$ cat /proc/cpuinfo cpu : TI UltraSparc I (SpitFire) fpu : UltraSparc I integrated FPU promlib : Version 3 Revision 11 prom: 3.11.1 type: sun4u ncpus probed: 1 ncpus active: 1 Cpu0Bogo: 285.08 Cpu0ClkTck : 0885b768 MMU Type: Spitfire i tried linux-2.6.0-test1-ac1 cause ac2 doesn't compile. with the -p param i get more output, it seems to boot normaly until it gets into a very quick loop, i can discern the last part like: bad: scheduling while atomic! and a numbers like: [0x:?] -solca
Re: sparc32/64 kernel 2.6.0-test1
On Sun, Jul 20, 2003 at 08:50:37PM -0400, Ben Collins wrote: > On Sun, Jul 20, 2003 at 06:47:49PM -0600, Otto Solares wrote: > > On Sun, Jul 20, 2003 at 01:09:37PM -0600, Otto Solares wrote: > > > On Sun, Jul 20, 2003 at 02:38:07PM -0400, Ben Collins wrote: > > > > > > > > "make image" and then user arch/sparc64/boot/image to boot with instead > > > > of vmlinux. > > > > > > thanks for the quick response! > > > > > > ok, i will test it now, "make image" works for both sparc32/64? > > > > yep, it works now boots but hangs on boot, weird... > > > > > > Also, what compiler are you using? It had better be gcc-3.2.3 (latest in > > > > unstable). > > > > > > i try with both gcc-3.2.3 and gcc-2.95.4 on sparc32, on sparc64 only > > > gcc-2.95.4. > > > > gcc-3.3.1 is on my system now and it gets a hang on boot too. > > I said _gcc-3.2.3_ Nothing else will work for sparc64 and 2.6 kernels. > Install gcc and gcc-3.2 packages from unstable. i tried gcc-3.2.3 with no luck. -solca
sparc scsi esp depends on pci & hangs on boot
Hi ppl,
just reporting on 2.6.0-test1 on sparcs:
i am trying to compile linux-2.6.0-test1-{mm1,mm2,ac1,ac2)
on 2 differents sparcs, both latest debian sid & gcc-3.2.3:
ultra enterprise 1 (sun4u sparc64)
sparc station 4(sun4m sparc32)
on both i need to enable PCI support even
when these boxes doesn't have a PCI bus,
i think the main bus is SBUS and i get
errors when compiling the Sun ESP scsi
controller about functions for DMA depending
on PCI. I don't think is convenient for
these old boxes having support for PCI
because enlarge the kernel and it really
doesn't have that type of bus.
And when i enable PCI support the sparc32
compiles fine but hangs inmediately on boot.
The sparc64 doesn't compile with ac2 patch:
arch/sparc64/kernel/built-in.o(.init.text+0x3bcc): In function
`pdev_cookie_fillin':
: referencia a `pci_remove_bus_device' sin definir
make: *** [vmlinux] Error 1
The others mentioned kernels hangs when booting.
Yes, i have selected proper configuration for the
CONFIG_INPUT_*=y layer, CONFIG_VT_CONSOLE=y,
CONFIG_HW_CONSOLE=y and CONFIG_PROM_CONSOLE=y.
I even tried both CONFIG_FRAMEBUFFER_CONSOLE set to y/n
Any help will be apreciated as i really want
the 2.6 kernels support both sparc32 and sparc64
boxes, googling i found osinvestor.com/sparc but
is down and in the sparclinux archives there are
patches but they appear to be applied on linus
2.6.0-test1 kernel.
Thanks.
-solca
Re: sparc32/64 kernel 2.6.0-test1
On Sun, Jul 20, 2003 at 01:09:37PM -0600, Otto Solares wrote: > On Sun, Jul 20, 2003 at 02:38:07PM -0400, Ben Collins wrote: > > > > "make image" and then user arch/sparc64/boot/image to boot with instead > > of vmlinux. > > thanks for the quick response! > > ok, i will test it now, "make image" works for both sparc32/64? yep, it works now boots but hangs on boot, weird... > > Also, what compiler are you using? It had better be gcc-3.2.3 (latest in > > unstable). > > i try with both gcc-3.2.3 and gcc-2.95.4 on sparc32, on sparc64 only > gcc-2.95.4. gcc-3.3.1 is on my system now and it gets a hang on boot too. -solca
Re: sparc32/64 kernel 2.6.0-test1
On Sun, Jul 20, 2003 at 02:38:07PM -0400, Ben Collins wrote:
> On Sun, Jul 20, 2003 at 12:32:56PM -0600, Otto Solares wrote:
> > Hi ppl,
> >
> > i managed to compile linux-2.6.0-test1-ac2 (linux-2.6.0-test1-mm* series
> > don't compile at all) but when trying to boot it gets an error about
> > image too long, indeed the image size is much longer than 2.{2,4} used
> > to be, is a kernel with the basics to boot and everything as modules,
> > so i try to strip vmlinux and now i get a "cannot find a loadable
> > segment in your ELF image" error when booting, any idea how to boot
> > this beast on sparc32 hardware? on sparc64 i get a freeze on boot...
> > i googled and find that osinvestor.com/sparc32 have patches for
> > sparc32 BUT is down :( i read too that sparc32 has no maintainer
> > at all :(sad because i got a lot of sparc32 boxes and i want
> > 2.6 support on it (that's why i am testing)...
> >
> > hardware: archproblem:
> > ss4 (sun4m) sparc32 image size too long
> > ultraE1 (sun4u) sparc64 freeze inmediately on boot
> > netrat1 (sun4u) sparc64 freeze inmediately on boot
> > ultra250(sun4u) sparc64 freeze inmediately on boot
> > classic (sun4c) sparc32 image size too long
> >
> > all sparc32 boxes with sid and sparc64 with woody.
>
>
> "make image" and then user arch/sparc64/boot/image to boot with instead
> of vmlinux.
thanks for the quick response!
ok, i will test it now, "make image" works for both sparc32/64?
> Also, what compiler are you using? It had better be gcc-3.2.3 (latest in
> unstable).
i try with both gcc-3.2.3 and gcc-2.95.4 on sparc32, on sparc64 only
gcc-2.95.4.
-solca
sparc32/64 kernel 2.6.0-test1
Hi ppl,
i managed to compile linux-2.6.0-test1-ac2 (linux-2.6.0-test1-mm* series
don't compile at all) but when trying to boot it gets an error about
image too long, indeed the image size is much longer than 2.{2,4} used
to be, is a kernel with the basics to boot and everything as modules,
so i try to strip vmlinux and now i get a "cannot find a loadable
segment in your ELF image" error when booting, any idea how to boot
this beast on sparc32 hardware? on sparc64 i get a freeze on boot...
i googled and find that osinvestor.com/sparc32 have patches for
sparc32 BUT is down :( i read too that sparc32 has no maintainer
at all :(sad because i got a lot of sparc32 boxes and i want
2.6 support on it (that's why i am testing)...
hardware: archproblem:
ss4 (sun4m) sparc32 image size too long
ultraE1 (sun4u) sparc64 freeze inmediately on boot
netrat1 (sun4u) sparc64 freeze inmediately on boot
ultra250(sun4u) sparc64 freeze inmediately on boot
classic (sun4c) sparc32 image size too long
all sparc32 boxes with sid and sparc64 with woody.
Any help?
-solca
