Re: Boot problems with AMD64

[Soren Jonsson]

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