The booting issues with QEMU 0.9 should be gone. QEMU 0.10 works fine
also; it never had the problem. If you're using QEMU or KVM, don't
forget to set qemu_pci=1 in the boot monitor.
We'll have to investigate the VirtualBox Lance problems further. If
you're a VBox user, you can try to restart the Lance driver (as Matthias
Schmidt mentioned). It may work, but maybe not.
Enjoy that Minixy VM goodness (pun intended),
Arun
Hi,
Today i installed Minix 3.1.4 and now i am trying to compile
/usr/src/lib with "make all-gnu".
Probably something is broken here 'cause gcc fails to compile
/usr/src/lib/sysutil/profile.c with a lot of errors like this one:
profile.c:253 error: request for member '_' in something not a
structure or union.
It should be a little problem with the u64_t type definition....
--
--------------------
Maurizio Lombardi
Hi, with this patch it *should* works... or at least you will
understand where the problem is:
*** profile.c Sat Mar 28 08:25:37 2009
--- new_profile.c Sat Mar 28 09:01:56 2009
***************
*** 64,70 ****
if (cprof_locked) return; else cprof_locked = 1;
/* Read CPU cycle count into local variable. */
! read_tsc(&start._[U64_HI], &start._[U64_LO]);
/* Run init code once after system boot. */
if (init == 0) {
--- 64,71 ----
if (cprof_locked) return; else cprof_locked = 1;
/* Read CPU cycle count into local variable. */
! read_tsc(&hi, &lo);
! start = make64(lo, hi);
/* Run init code once after system boot. */
if (init == 0) {
***************
*** 108,115 ****
}
/* Save initial cycle count on stack. */
! cprof_stk[cprof_stk_top].start_1._[U64_HI] = start._[U64_HI];
! cprof_stk[cprof_stk_top].start_1._[U64_LO] = start._[U64_LO];
/* Check available call path len. */
if (cpath_len + strlen(name) + 1 > CPROF_CPATH_MAX_LEN) {
--- 109,115 ----
}
/* Save initial cycle count on stack. */
! cprof_stk[cprof_stk_top].start_1 = start;
/* Check available call path len. */
if (cpath_len + strlen(name) + 1 > CPROF_CPATH_MAX_LEN) {
***************
*** 170,177 ****
cprof_stk[cprof_stk_top].slot = cprof_slot;
/* Again save CPU cycle count on stack. */
! read_tsc(&cprof_stk[cprof_stk_top].start_2._[U64_HI],
! &cprof_stk[cprof_stk_top].start_2._[U64_LO]);
cprof_locked = 0;
}
--- 170,178 ----
cprof_stk[cprof_stk_top].slot = cprof_slot;
/* Again save CPU cycle count on stack. */
!
! read_tsc(&hi, &lo);
! cprof_stk[cprof_stk_top].start_2 = make64(lo, hi);
cprof_locked = 0;
}
***************
*** 180,191 ****
char *name;
{
u64_t stop, spent;
/* Procexit is not reentrant. */
if (cprof_locked) return; else cprof_locked = 1;
/* First thing: read CPU cycle count into local variable. */
! read_tsc(&stop._[U64_HI], &stop._[U64_LO]);
/* Only continue if sane. */
if (control.err) return;
--- 181,194 ----
char *name;
{
u64_t stop, spent;
+ unsigned long int hi, lo;
/* Procexit is not reentrant. */
if (cprof_locked) return; else cprof_locked = 1;
/* First thing: read CPU cycle count into local variable. */
! read_tsc(&hi, &lo);
! stop = make64(lo, hi);
/* Only continue if sane. */
if (control.err) return;
***************
*** 204,212 ****
sub64(spent, cprof_stk[cprof_stk_top].spent_deeper));
/* Clear spent_deeper for call level we're leaving. */
! cprof_stk[cprof_stk_top].spent_deeper._[U64_LO] = 0;
! cprof_stk[cprof_stk_top].spent_deeper._[U64_HI] = 0;
!
/* Adjust call path string and stack. */
cpath_len = cprof_stk[cprof_stk_top].cpath_len;
cpath[cpath_len] = '\0';
--- 207,214 ----
sub64(spent, cprof_stk[cprof_stk_top].spent_deeper));
/* Clear spent_deeper for call level we're leaving. */
! cprof_stk[cprof_stk_top].spent_deeper = cvu64(0);
!
/* Adjust call path string and stack. */
cpath_len = cprof_stk[cprof_stk_top].cpath_len;
cpath[cpath_len] = '\0';
***************
*** 221,227 ****
*/
/* Read CPU cycle count. */
! read_tsc(&stop._[U64_HI], &stop._[U64_LO]);
/* Calculate "big" difference. */
spent = sub64(stop, cprof_stk[cprof_stk_top].start_1);
--- 223,230 ----
*/
/* Read CPU cycle count. */
! read_tsc(&hi, &lo);
! stop = make64(lo, hi);
/* Calculate "big" difference. */
spent = sub64(stop, cprof_stk[cprof_stk_top].start_1);
***************
*** 236,242 ****
PRIVATE void cprof_init() {
message m;
int i;
!
cpath[0] = '\0';
cpath_len = 0;
cprof_stk_top = -1;
--- 239,245 ----
PRIVATE void cprof_init() {
message m;
int i;
!
cpath[0] = '\0';
cpath_len = 0;
cprof_stk_top = -1;
***************
*** 249,260 ****
for (i=0; i<CPROF_STACK_SIZE; i++) {
cprof_stk[i].cpath_len = 0;
cprof_stk[i].slot = 0;
! cprof_stk[i].start_1._[U64_LO] = 0;
! cprof_stk[i].start_1._[U64_HI] = 0;
! cprof_stk[i].start_2._[U64_LO] = 0;
! cprof_stk[i].start_2._[U64_HI] = 0;
! cprof_stk[i].spent_deeper._[U64_LO] = 0;
! cprof_stk[i].spent_deeper._[U64_HI] = 0;
}
}
--- 252,260 ----
for (i=0; i<CPROF_STACK_SIZE; i++) {
cprof_stk[i].cpath_len = 0;
cprof_stk[i].slot = 0;
! cprof_stk[i].start_1 = cvu64(0);
! cprof_stk[i].start_2 = cvu64(0);
! cprof_stk[i].spent_deeper = cvu64(0);
}
}
***************
*** 277,284 ****
memset(cprof_tbl[i].cpath, '\0', CPROF_CPATH_MAX_LEN);
cprof_tbl[i].next = 0;
cprof_tbl[i].calls = 0;
! cprof_tbl[i].cycles._[U64_LO] = 0;
! cprof_tbl[i].cycles._[U64_HI] = 0;
}
}
--- 277,283 ----
memset(cprof_tbl[i].cpath, '\0', CPROF_CPATH_MAX_LEN);
cprof_tbl[i].next = 0;
cprof_tbl[i].calls = 0;
! cprof_tbl[i].cycles = cvu64(0);
}
}
--
--------------------
Maurizio Lombardi
Probably there is a bug in the floppy disk driver:
When i try to do "mtools format /dev/fd0:" i get this error:
fd0: disk interrupt timed out
fs: I/O error on device 2/0
It is not an hardware problem, it works on Minix 3.1.3 r3066
I will file this bug in the bug tracker.
--
--------------------
Maurizio Lombardi
Great!
As I see in this fresh version, there's a new vm directory in servers
compared with 3.1.3a version.
--
Guanqun
Arun
Hi Ben,
'format -v /dev/fd0 1440' doesn't work for me, it fails with the same error.
I will try to debug the floppy driver and i will tell you something more, ok?
however, i found two new problems:
1) "make hdboot" fails because of errors in framework/audio_fw.c
DEV_READ undefined
DEV_WRITE undefined
.....
unknown selector REP_PROC_NR
illegal use of selector REP_PROC_NR
and so on....
2) I did a clean reinstall of Minix 3.1.4 and a terrible system panic
(hard reboot) occurred,
you can reproduce the problem (i hope) with the following sequence:
- Reinstall Minix 3.1.4
- Choose the "R" option (Reinstall Option, leave /home untouched)
- Install all packages (packman 'all')
System panic occours when packman will try to "Update GCC Libraries"
Everything work fine if you choose the "F" option (Full Reinstall Option)
--
--------------------
Maurizio Lombardi
I can't see any message, the machine just reboots.
> What are you running on? (which
> emulator/hardware?)
It's an old Pentium III PC with 32 Gb of HD and 96 Mb of RAM. Minix
runs on a partition of 3 Gb of RAM
--
--------------------
Maurizio Lombardi
OpenSolaris 2008.11
on x86_64
--------------------
Yes i am sure, it's the 3.1.4 r4203.
It works for you?
Sorry, 3 Gb of HD space.
The fix modified headers in /usr/src/include. If I understand you
correctly, you updated /usr/src/lib only? If so, try updating all of
/usr/src. Do a 'make clean' (just in case). Then, follow the
instructions here: http://www.minix3.org/tracking-current.html.
Let me know if that works.
Arun
Hi,
i'm trying to find this bug that prevent me to use the floppy drive.
However i need a little help:
Should i look for the bug only inside floppy.c or there is some other
component that can be involved in this behaviour?