Re: Lots of questions from someone.
Shadow Daemon wrote: Do you know anything about the technical details of how it works? Unfortunately, no. I've been trying to locate some old manuals on MCA architecture and low-level drivers for it, but IBM barely acknowledges the existence of old PS/2's, and no one seems to carry any substantial information about it. for any information on ps/2's and microchannel in general post a question on comp.sys.ibm.ps2.hardware. the microchannel god (that's with a small 'g'!) is peter wendt. pete.
Re: Lots of questions from someone.
On Wed, Jan 26, 2000 at 03:11:20PM -0500, Shadow Daemon wrote: Do you know anything about the technical details of how it works? Unfortunately, no. I've been trying to locate some old manuals on MCA architecture and low-level drivers for it, but IBM barely acknowledges the existence of old PS/2's, and no one seems to carry any substantial information about it. Ralf Brown interrupt list may have some info. See here http://www.ctyme.com/rbrown.htm for a searchable version. Hmmm...I wonder if my college library would have anything? I'll get back to you on this. I've been searching internet sites exclusively thus far...time to try a few real-world locations. I'll have a dig through my accumulated paperwork, and see what I can find. Could you write any code to support it explicitly? If I could find some technical information, I could certainly try :) If nothing else, I could come up with a buggy piece of crap that someone else could turn into a working driver. And that is what open source is all about. The quicker you can get something out the door, the sooner other people will help you with it. Al
Re: Lots of questions from someone.
Do you know anything about the technical details of how it works? Unfortunately, no. Look at the MCA support in linux2.2 - the code is fairly well documented Stuart
Fw: cvs commit: elks/arch/i86/kernel process.c
Al,
I happended to see this bug come across the CVS, and just wanted
to make sure that you've double checked it. This was the exact area that
had to be changed relating to ELK's sys_brk() bug that disallowed
data segments 32k... I can't quite remember the original code.
Regards,
Greg
: +/*
: + * We only need to do this as long as we support old format binaries
: + * that grow stack and heap towards each other
: + */
:void stack_check()
:{
:register __ptask currentp = current;
: - if (currentp-t_regs.sp currentp-t_endbrk)
: - {
: + if ((currentp-t_begstack currentp-t_enddata)
: + (currentp-t_regs.sp currentp-t_endbrk)) {
:printk("STACK (%d) ENTERED BSS (%ld) - PROCESS TERMINATING\n",
currentp-t_regs.sp, currentp-t_endbrk);
:do_exit(SIGSEGV);
:}
:
:
:
Re: Fw: cvs commit: elks/arch/i86/kernel process.c
On Thu, Jan 27, 2000 at 11:25:08AM -0700, Greg Haerr wrote:
Al,
I happended to see this bug come across the CVS, and just wanted
to make sure that you've double checked it. This was the exact area that
had to be changed relating to ELK's sys_brk() bug that disallowed
data segments 32k... I can't quite remember the original code.
I have double checked this and I am fairly sure it is right. All I have done
is add a consitional so the same checl as before is only done on binaries
with the old (current) layout.
I think you may be mis-remembering the bug. IIRC the 32K bug was in sys_brk()
and was related to the type of the argument being signed instead of unsigned.
Thanks for keeping a look out. I am glad someone reads the cvs commit messages.
Al
int sys_brk(len)
__pptr len;
{
register __ptask currentp = current;
if (len currentp-t_enddata ||
(len (currentp-t_endseg - HEAP_LIMIT))) {
return -ENOMEM;
}
currentp-t_endbrk = len;
return 0;
}
Regards,
Greg
: +/*
: + * We only need to do this as long as we support old format binaries
: + * that grow stack and heap towards each other
: + */
:void stack_check()
:{
:register __ptask currentp = current;
: - if (currentp-t_regs.sp currentp-t_endbrk)
: - {
: + if ((currentp-t_begstack currentp-t_enddata)
: + (currentp-t_regs.sp currentp-t_endbrk)) {
:printk("STACK (%d) ENTERED BSS (%ld) - PROCESS TERMINATING\n",
currentp-t_regs.sp, currentp-t_endbrk);
:do_exit(SIGSEGV);
:}
:
:
:
RE: Fw: cvs commit: elks/arch/i86/kernel process.c
: I think you may be mis-remembering the bug. IIRC the 32K bug was in
sys_brk()
: and was related to the type of the argument being signed instead of
unsigned.
I think you're right. The original bug can be reproduced by having
a small ELKS program that malloc's memory. We should be able
to malloc almost 64k. The previous version would fail whenever
the DS offset 32k.
Greg
:
: Thanks for keeping a look out. I am glad someone reads the cvs commit
messages.
:
: Al
:
: int sys_brk(len)
: __pptr len;
: {
: register __ptask currentp = current;
:
: if (len currentp-t_enddata ||
: (len (currentp-t_endseg - HEAP_LIMIT))) {
: return -ENOMEM;
: }
:
: currentp-t_endbrk = len;
: return 0;
: }
:
:
:
: Regards,
:
: Greg
:
: : +/*
: : + * We only need to do this as long as we support old format
binaries
: : + * that grow stack and heap towards each other
: : + */
: :void stack_check()
: :{
: :register __ptask currentp = current;
: : - if (currentp-t_regs.sp currentp-t_endbrk)
: : - {
: : + if ((currentp-t_begstack currentp-t_enddata)
: : + (currentp-t_regs.sp currentp-t_endbrk)) {
: :printk("STACK (%d) ENTERED BSS (%ld) - PROCESS TERMINATING\n",
: currentp-t_regs.sp, currentp-t_endbrk);
: :do_exit(SIGSEGV);
: :}
: :
: :
: :
Re: Lots of questions from someone.
Shadow Daemon wrote: Do you know anything about the technical details of how it works? Unfortunately, no. I've been trying to locate some old manuals on MCA architecture and low-level drivers for it, but IBM barely acknowledges the existence of old PS/2's, and no one seems to carry any substantial information about it. Hmmm...I wonder if my college library would have anything? I'll get back to you on this. I've been searching internet sites exclusively thus far...time to try a few real-world locations. Could you write any code to support it explicitly? If I could find some technical information, I could certainly try :) If nothing else, I could come up with a buggy piece of crap that someone else could turn into a working driver. -matt - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Shadow Daemon, aka mAtT bAlAuN Well, you can try the following MCA-PS/2 Links: http://members.tripod.com/~ps2page/ http://members.aol.com/mcapage0/mcaindex.htm - This one's got a lot of info http://www.dgmicro.com/mca/ - The MCA Linux site, they can probably help with drivers And there's always the newsgroup: comp.sys.ibm.ps2.hardware -- Jason S Colflesh [EMAIL PROTECTED] [EMAIL PROTECTED]
