Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
David O'Brien wrote: Yes, but the proper approach would be: [ ... ] What we got: I've developed the proc splitting on i386 and it works for me. The diffs are at http://___. AXP hackers, go to it. That's a heck of a lot more than the Alpha people normally get! Generally , it's cvs commit log: break alpha. In any case, Peter Fixed it... Yeah, Peter! -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
John Baldwin wrote: halted CPU 0 halt code = 2 kernel stack not valid halt PC = fc553020 You overflowed your kernel stack. You can use srm to dump the memory at that address (I can't remember the stupid SRM syntax for the life of me though) and wade through it looking for kernel-text addresses to figure out the stack trace. From my reading of the x86 source, one of the things Julian did was seperate out the allocation of stack pages, using a defined value. This may be as simple as putting a larger number in your config file... I don't know what the Alpha default was before the change, but I do know that it runs 8K pages, which if KPAGES is in 4K chunks, might have reduced your stack size on you... Not brilliant, but something to try... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
Terry Lambert wrote: John Baldwin wrote: halted CPU 0 halt code = 2 kernel stack not valid halt PC = fc553020 You overflowed your kernel stack. You can use srm to dump the memory at that address (I can't remember the stupid SRM syntax for the life of me though) and wade through it looking for kernel-text addresses to figure out the stack trace. From my reading of the x86 source, one of the things Julian did was seperate out the allocation of stack pages, using a defined value. This may be as simple as putting a larger number in your config file... I don't know what the Alpha default was before the change, but I do know that it runs 8K pages, which if KPAGES is in 4K chunks, might have reduced your stack size on you... Not brilliant, but something to try... -- Terry Actually, this was the result of not correctly setting up the new argument to the fork trampoline code. We now have a fully viable Alpha + KSE kernel as of about 5 minutes ago: [3:19am]~/ffp4-102 p4 describe -du 1155 Change 1155 by peter@peter_up2000 on 2001/08/28 03:12:57 Really solve the alpha KSE problem. This was submitted from an alpha running the KSE kernel in multiuser mode! Affected files ... ... //depot/projects/kse/sys/alpha/alpha/vm_machdep.c#5 edit Differences ... //depot/projects/kse/sys/alpha/alpha/vm_machdep.c#5 (text+ko) @@ -210,7 +210,7 @@ (u_int64_t)fork_return; /* s0: a0 */ td2-td_pcb-pcb_context[1] = (u_int64_t)exception_return;/* s1: ra */ - td2-td_pcb-pcb_context[2] = (u_long) p2; /* s2: a1 */ + td2-td_pcb-pcb_context[2] = (u_long)td2; /* s2: a1 */ td2-td_pcb-pcb_context[7] = (u_int64_t)fork_trampoline; /* ra: assembly magic */ #ifdef SMP fork_trampoline() changed from a 'struct proc *p' to 'struct thread *td' argument and got missed here. The box is now running quite happily.. All that remains is to get the rest of the alpha kernel to compile, not just the subset that I actually use. :) And then comes tidying up the loose ends. :-] Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
Peter Wemm writes: Actually, this was the result of not correctly setting up the new argument to the fork trampoline code. We now have a fully viable Alpha + KSE kernel as of about 5 minutes ago: Excellent. Thank you, Peter. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
On Mon, Aug 27, 2001 at 11:04:39PM -0700, Terry Lambert wrote: It has been pointed out that the stumbling block is ~10 lines of Akpha assembly language code that Julian is asking that someone familiar with the Alpha write. Julian is not an Alpha assembly language guru. In order to make these changes, he would have to do a lot of work, whereas someone who knew Alpha assembly language could do them very quickly. Yes, but the proper approach would be: Dear Alpha guys, I've compiled all the C code on the Alpha, but I know the xyz.S file needs changing. I don't know AXP asm to save my life, but here is the diff I had to do in the i386 xyz.S file: [ diff ] What this change does (for those AXP asm hackers that don't read Intel) is __. What would be the AXP change needed? What we got: I've developed the proc splitting on i386 and it works for me. The diffs are at http://___. AXP hackers, go to it. I think asking him to do this without knowledge of register save/restore and allocation plocies of the FreeBSD Alpha port is rather unfair. That is fine, but the -current AXP developers are a small lot. They need to have up-front leg work done, so the limited time they do have (where many i386-only people are tugging at their sleeves) is well spent. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
Julian Elischer writes: Can the IA64 and Alpha developers (Arm too?) look at the KSE patch set at http://www.freebsd.org/~julian/thediff This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) so that when this is checked into -current their architectures are not broken. (On teh other hand if they would rather fix up the breakage afterwards (which may be easier) then they should let me know so I can get on with committing it. Matt and I want to commit it ASAP, so we can get on with actual threading support. Peter has also indicated that he thinks that it should be done soon, so I need toknow if there will be forthcoming changes for the other architectures, or I should go ahead and commit... Please, please don't intentionally break other architectures. Esp ones that actually work, like alpha. Its basically just mechanical changes up until this point, right? You've carved up the proc struct ranamed some things, right? I'd really appreciate it if you could make the mechanical changes required to get it to the point where it at least compiles on alpha using beast.freebsd.org. At that point, the people on -alpha should be willing to test your patch and help fix any problems that come up. Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
The mecanincal changes in C code are pretty simple, but you really need a running machine to do them because you need to change-compile-change-compile-change-compile (etc.) It took me about 1 day to do the i386 specific things.. Having doen that is should take someone with a running alpha abut a half day to do the alpha version (now that I've done the 386) and someone with a clue about alpha assembler needs to make the same changes to the machine code. (it was probably about 10 lines of assembler changes). The bigest part is the re-arranging of the u-area and changing the code to follow that change. On Mon, 27 Aug 2001, Andrew Gallatin wrote: Julian Elischer writes: Can the IA64 and Alpha developers (Arm too?) look at the KSE patch set at http://www.freebsd.org/~julian/thediff This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) so that when this is checked into -current their architectures are not broken. (On teh other hand if they would rather fix up the breakage afterwards (which may be easier) then they should let me know so I can get on with committing it. Matt and I want to commit it ASAP, so we can get on with actual threading support. Peter has also indicated that he thinks that it should be done soon, so I need toknow if there will be forthcoming changes for the other architectures, or I should go ahead and commit... Please, please don't intentionally break other architectures. Esp ones that actually work, like alpha. Its basically just mechanical changes up until this point, right? You've carved up the proc struct ranamed some things, right? I'd really appreciate it if you could make the mechanical changes required to get it to the point where it at least compiles on alpha using beast.freebsd.org. At that point, the people on -alpha should be willing to test your patch and help fix any problems that come up. I REALLY want to have alpha (and hopefully other) ready to do at the same time. but at the same time, I'm 'carrying this' because as long as I'm not committed I have a daily merge job. And it's getting bigger as people change low level code in way s that may not be compatible with what I need. I would be happy if I could commit it in 2 weeks. I'd like some help from the other architecture people though. I've done 1.85 MB of patches and the machine dependednt parts are probably about 15K of that. Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
On Sun, Aug 26, 2001 at 10:44:04PM -0700, Julian Elischer wrote: This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) Have you even tried compiling this on beast.freebsd.org? You didn't say. Unfortuneatly the burdon is on you to make this work on the Alpha platform before you commit it. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
Actualy peter is most of the way through the alpha support as we speak. I wouldn't know what the alpha looks like from a architecture pov if it came and kicked me.. I did some small parts already but peter just checked in more in P4. On Mon, 27 Aug 2001, David O'Brien wrote: On Sun, Aug 26, 2001 at 10:44:04PM -0700, Julian Elischer wrote: This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) Have you even tried compiling this on beast.freebsd.org? You didn't say. Unfortuneatly the burdon is on you to make this work on the Alpha platform before you commit it. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
Julian Elischer wrote: Actualy peter is most of the way through the alpha support as we speak. I wouldn't know what the alpha looks like from a architecture pov if it came and kicked me.. I did some small parts already but peter just checked in more in P4. Latest news: The alpha made it to single user... (!). There is still a problem, but I will find that shortly. I have not yet built GENERIC, just my tuned kernel. Things like linux and osf1 compat still need doing. FWIW, the tail: ... Timecounter i8254 frequency 1193182 Hz ata0-slave: ata_command: timeout waiting for intr ata0-slave: identify failed acd0: CDROM CD-540E at ata0-master PIO4 Waiting 2 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST318404LW 0006 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 1 lun 0 da1: IBM DMVS18V 0250 Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) Mounting root from ufs:/dev/da0a Enter full pathname of shell or RETURN for /bin/sh: # ls halted CPU 0 halt code = 2 kernel stack not valid halt PC = fc553020 CPU 0 booting ... oops :-) On Mon, 27 Aug 2001, David O'Brien wrote: On Sun, Aug 26, 2001 at 10:44:04PM -0700, Julian Elischer wrote: This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) Have you even tried compiling this on beast.freebsd.org? You didn't say. Unfortuneatly the burdon is on you to make this work on the Alpha platform before you commit it. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
Andrew Gallatin wrote: I'd really appreciate it if you could make the mechanical changes required to get it to the point where it at least compiles on alpha using beast.freebsd.org. At that point, the people on -alpha should be willing to test your patch and help fix any problems that come up. It has been pointed out that the stumbling block is ~10 lines of Akpha assembly language code that Julian is asking that someone familiar with the Alpha write. Julian is not an Alpha assembly language guru. In order to make these changes, he would have to do a lot of work, whereas someone who knew Alpha assembly language could do them very quickly. I think asking him to do this without knowledge of register save/restore and allocation plocies of the FreeBSD Alpha port is rather unfair. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Ia64 and ALPHA (+arm, sparc?) kernel developers:
On 28-Aug-01 Peter Wemm wrote: Julian Elischer wrote: Actualy peter is most of the way through the alpha support as we speak. I wouldn't know what the alpha looks like from a architecture pov if it came and kicked me.. I did some small parts already but peter just checked in more in P4. Latest news: The alpha made it to single user... (!). There is still a problem, but I will find that shortly. I have not yet built GENERIC, just my tuned kernel. Things like linux and osf1 compat still need doing. FWIW, the tail: ... Timecounter i8254 frequency 1193182 Hz ata0-slave: ata_command: timeout waiting for intr ata0-slave: identify failed acd0: CDROM CD-540E at ata0-master PIO4 Waiting 2 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST318404LW 0006 Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) da1 at ahc0 bus 0 target 1 lun 0 da1: IBM DMVS18V 0250 Fixed Direct Access SCSI-3 device da1: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) Mounting root from ufs:/dev/da0a Enter full pathname of shell or RETURN for /bin/sh: # ls halted CPU 0 halt code = 2 kernel stack not valid halt PC = fc553020 You overflowed your kernel stack. You can use srm to dump the memory at that address (I can't remember the stupid SRM syntax for the life of me though) and wade through it looking for kernel-text addresses to figure out the stack trace. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Ia64 and ALPHA (+arm, sparc?) kernel developers:
Can the IA64 and Alpha developers (Arm too?) look at the KSE patch set at http://www.freebsd.org/~julian/thediff This compiles and runs pretty solidly on 386. it needs people who understand the other architectures to make the appropriate changes and send them to me (or check them int P4) so that when this is checked into -current their architectures are not broken. (On teh other hand if they would rather fix up the breakage afterwards (which may be easier) then they should let me know so I can get on with committing it. Matt and I want to commit it ASAP, so we can get on with actual threading support. Peter has also indicated that he thinks that it should be done soon, so I need toknow if there will be forthcoming changes for the other architectures, or I should go ahead and commit... -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +--x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
