[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Boot problems with AMD64

From: Soren Jonsson
Subject: Re: Boot problems with AMD64
Date: Sun, 15 Jan 2006 07:28:26 +0100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)

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(argc, argv)
main(argc, argv)


void i16_main(int _argc, char **_argv)

extern void     setup_main();

  before calling i16_main().  */

void i16_main(void)

void setup_main()
void slave_main()

static __inline__ void run_main(void);
* Function : run_main(void)                                               *
static __inline__ void run_main(void)
static void AM53C974_main(void)

* 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) {
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()
*       called where the loop started in NCR5380_main().


* main() use the stack at all after fork(). Thus, no function
* won't be any messing with the stack from main(), but we define

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);

I am a bit spoiled for choises.


Sören Jonsson

reply via email to

[Prev in Thread] Current Thread [Next in Thread]