Alfred M. Szmidt wrote:
[Adding CC to bug-hurd, _again_, don't remove it!]
22: 9186 IO-APIC-level libata, NVidia CK804
23: 13705 IO-APIC-level libata, eth0
These two could cause problems, I don't know what libata or nvidia is.
A quick search on the Internet provided the information that libATA is a
library used inside the Linux kernel to support ATA host controllers and
devices. libATA provides an ATA driver API, class trasports for ATA and
ATAPI devices, and SCSI<->ATA translation for ATA devices according to
the T10SAT specification.
Nvidia is a company, well known for their GForce series of graphics
controllers, and more to the point nvidia ck804 is a lan contoller used
on my motherboard to implement a gigabit lan interface.
But if GNU Mach has support for your NIC and any of these two, it
might explain the sudden reboot. Have you tried compiling a really
bare kernel with only say an IDE driver?
>Could you check where that EIP is? gdb is your friend, issue the
>following in gdb: info line *EIP
I will try, but the most frequent result is still a reboot, so as a
consequence it might take some time before I can get into gdb
again. Good to know that it's gdb by the way, since I know gdb. I
was afraid that it might be something unique to mach.
To properly debug GNU Mach you will either have to use printf's in the
code, or hack it to support a serial debugger. Or use GNU Mach 2.x,
which doesn't even compile. For this you could have equally used nm
or somesuch instead of firing up gdb on the kernel image just to get
the function name where things died.
OK, I will have to go the printf route. I usually try for a debugger
first, since it usually provides more information and a lot faster.
Well, since there is no such option. Sigh...
In wichfile do I find the main() function for gnumah? A quick search
with find provided the following alternatives:
main()
main(argc, argv)
main(argc, argv)
./config.guess
main(argc,argv)
./chips/build_font.c
void i16_main(int _argc, char **_argv)
./i386/dos/i16/i16_main.c
extern void setup_main();
setup_main();
./i386/i386at/model_dep.c
before calling i16_main(). */
./i386/pc/i16/i16_init.c
void i16_main(void)
./i386/pc/i16/i16_main.c
void setup_main()
void slave_main()
./kern/startup.c
static __inline__ void run_main(void);
* Function : run_main(void) *
static __inline__ void run_main(void)
AM53C974_main();
run_main();
static void AM53C974_main(void)
run_main();
./linux/src/drivers/scsi/AM53C974.c
* 2. NCR5380_main() shouldn't be called before it has exited, because
* 3. We don't want to inline NCR5380_main() because of space concerns,
* Function : run_main(void)
static __inline__ void run_main(void) {
NCR5380_main();
run_main();
run_main();
printk("scsi%d : main() : command for target %d
lun %d removed from issue_queue\n",
printk("scsi%d : main(): select() failed,
returned to issue_queue\n",
printk("scsi%d : main() : performing information
transfer\n",
printk("scsi%d : main() : done set false\n",
instance->host_no); * from the disconnected queue, and restarting
NCR5380_main()
run_main();
* called where the loop started in NCR5380_main().
./linux/src/drivers/scsi/NCR5380.c
main()
./linux/src/drivers/scsi/advansys.c
* main() use the stack at all after fork(). Thus, no function
* won't be any messing with the stack from main(), but we define
./linux/src/include/asm-i386/unistd.h
extern struct exec_domain *lookup_exec_domain(unsigned long personality);
extern int register_exec_domain(struct exec_domain *it);
extern int unregister_exec_domain(struct exec_domain *it);
./linux/src/include/linux/personality.h
I am a bit spoiled for choises.
Regards,
Sören Jonsson
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
