跳转至

温馨提示

本文档会不定时更新同学们在实验过程中可能会出现的问题以及对应的解决办法，供同学们参考。特别感谢给本课程实验反馈问题、建议以及意见的同学。

实验环境问题

1. 高版本工具兼容问题

1.1 xv6如何在QEMU>=6.0.0上启动？

具体解决方案详见piazza （Fall 2022） ：https://piazza.com/class/l7fs47nofoc4pm/post/8

qemu

Patch文件：pmp.patch

该问题的解决方案来自20级某位大佬的分享，非常感谢这位大佬的贡献~~

1.2 使用高版本gcc (≥12)出现报错

具体解决方案详见piazza （Fall 2022） ：https://piazza.com/class/l7fs47nofoc4pm/post/22

gcc

2. VSCode无法连接实验平台

2.1 VSCode连接远程实验平台时提示ssh: connect to host 10.249.12.98 port 22: Connection timed out？

端口号写错了，请参考实验指导书要求来连接。

远程实验平台IP地址： 10.249.12.98 ，端口号： 6666

2.2 VSCode连接远程实验平台时出现bad owner or permission报错？

解决方法：进入路径C:\Users\用户名\.ssh，右击config文件进入属性中高级安全管理，选择禁止继承，并且删除所有此对象中继承的权限。

具体可以查看：https://www.cnblogs.com/Akkuman/p/11187776.html

2.3 在远程实验平台上clone xv6-oslab23-hitsz失败？

如图：

image-20220916095456586

原因：

远程实验平台给每位同学做了资源限额管理，出现这个问题的同学，有可能是之前的《计算机设计与实践》实验包cdp-tests占用了太多空间，你需要删除cdp-tests/waveform目录下的所有波形图文件（主要是波形图文件太大了）。

使用mobaxterm登录，输入如下命令：

image-20220916154734658

使用rm -rf *删除后，应该就能clone xv6-oslab23-hitsz。

2.4 VSCode连接远程实验平台时提示mkdir: cannot create directory '/home/students/XXX'

如图：

image-20220916154922685

image-20220916155011110

原因：

与上述问题一样，也是因为资源限额的问题。之前的《计算机设计与实践》实验包cdp-tests占用了太多空间，你需要删除cdp-tests/waveform目录下的所有波形图文件（主要是波形图文件太大了）。

使用mobaxterm登录，输入如下命令：

image-20220916154734658

3. VSCode无法用GDB图形化调试

3.1 远程实验平台图形化无法调试Failed to attach: Remote communication error？

VSCode远程调试时，提示如下错误：

gdb1

具体解决方案详见piazza （Fall 2022） ：https://piazza.com/class/l7fs47nofoc4pm/post/20

打开xv6工作目录下的.gdbint文件，将第三行target remote 127.0.0.1:***用#注释掉。

gdb2

3.2 远程平台调试时VSCode报错Failed to attach: 127.0.0.1:XXX: Connection timed out. (from target-select remote 127.0.0.11:XXX)?

如图：

qemu3

原因：

没有在终端输入make qemu-gdb，直接点了VSCode的debug的三角形符号进行调试。

或者，请检查launch.json的GDB端口号是否写对？

3.3 远程平台调试时VSCode报错Failed to attach: Truncated register 37 in remote 'g' packet?

如图：

image-20220915205054529

原因：

VSCode工作区路径不是XV6路径，嵌套了外面一层文件夹。

image-20220915205018098

解决方法：

首先 确认你的VSCode工作区路径是否是你的xv6路径，没有额外嵌套一层文件夹 。按下Ctrl+`，呼出终端，输入ls。你应该会看到如下情景：

ldap_example@OSLabExecNode0:~/xv6-oslab23-hitsz$ ls
conf  fs.img  grade-lab-util  gradelib.py  gradelib.pyc  kernel  LICENSE  Makefile  mkfs  README  user

如果不是，打开新的工作区，选择xv6所在的文件夹打开即可。正确的工作区应该如下显示：

image-20220915210332246

4. xv6运行报错

4.1 远程平台make qemu报错Is another process using the image [fs.img]?

如图：

qemu2

用ps或top命令查看一下是不是已经开启了qemu？如果qemu已经在运行，请先结束该进程。

具体解决方案详见piazza （Fall 2022） ：https://piazza.com/class/l7fs47nofoc4pm/post/23

另外一种解决方案：输入在xv6-oslab23-hitsz目录下输入make clean清除fs.img，然后再运行make qemu

image-20220916094737504

4.2 关于虚拟机实验环境提示/usr/bin/env: 'python': No such file or directory问题

虚拟机实验环境安装的是python3，只需让系统把python3识别为python即可，执行以下命令：

sudo ln -s /usr/bin/python3 /usr/bin/python

这个命令会在/usr/bin目录下创建一个python到python3的符号链接，之后再运行./grade-lab-util sleep就能正常调用 Python 解释器了。

5. git常见问题

5.1 无法推送怎么办？

如果你尝试推送到远程仓库，或者从远程仓库拉取，但是git却显示出这样的错误：

git@gitee.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights 
and the repository exists

这表明你没有权限推送到这个远程仓库。一般而言，这是由于你没有设置好自己的ssh密钥造成的。请参照3.4节 ssh密钥设置，设置自己的ssh密钥。

5.2 我怎么知道我修改了哪些文件？

通常而言，实验要求同学们提交 所有 被修改过的文件。通过将当前工作路径与上游仓库（课程实验提供的仓库）对应分支的内容相比较，可以方便地知道自己曾经修改过哪些文件，并打包提交。这里，我们将当前分支与上游仓库的syscall分支相比较：

lgz_admin@OSLabExecNode0:~/git_demo/xv6-oslab23-hitsz$ git fetch --all
Fetching origin
Fetching upstream
lgz_admin@OSLabExecNode0:~/git_demo/xv6-oslab23-hitsz$ git diff --stat upstream/syscall *
 kernel/kalloc.c  | 2 ++
 kernel/syscall.c | 1 +
 kernel/syscall.h | 1 +
 kernel/sysinfo.h | 1 +
 4 files changed, 5 insertions(+)

要比较其他分支，将第二条指令中的syscall改为对应分支名即可。

请先在本地切换到对应分支！

在比较的时候，你需要将本地分支与上游对应分支进行比较。举例而言，你不会想比较本地的util分支和远程的syscall分支，因为这两个不是一个实验的。请先使用git checkout 分支名以切换到对应分支，并在使用git diff --stat upstream/分支名 *时指定 同一个 上游分支。

未设置上游仓库？

如果git报告“fatal: ambiguous argument 'upstream/分支名': unknown revision or path not in the working tree.”，说明你尚未设置上游仓库。请先按本指南中的3.1-同步上游仓库一节完成上游仓库的设置与同步，再进行比较。

5.3 为什么我不能切换分支（checkout）？

通常而言，不能切换分支的主要原因是你当前有尚未保存的修改，此时checkout的话会触发以下错误：

lgz_admin@OSLabExecNode0: ~/git_demo/xv6-oslab23-hitsz$ git checkout util                                                                                                ─╯
error: Your local changes to the following files would be overwritten by checkout:
        Makefile
Please commit your changes or stash them before you switch branches.
Aborting

通过git status指令，我们可以检查当前git的状态。如果你的输出如下所示：

lgz_admin@OSLabExecNode0: ~/git_demo/xv6-oslab23-hitsz$ git status
On branch syscall
Your branch is up to date with 'origin/syscall'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   Makefile

no changes added to commit (use "git add" and/or "git commit -a")

这说明当前你的工作区有尚未保存的更改。请参考3.3.1 使用命令行完成操作或者3.3.2 使用VSCode内建的图形化界面完成操作节，完成commit操作。 或者，如果你希望直接放弃掉上一次commit后的 所有更改 ，那么你也可以使用-f选项强制切换分支，例如git checkout -f syscall。

5.4 验证commit.patch时报错？

在验证commit.patch是否正确时可能遇到如下报错：

git-apply-patch

首先，黄框内是警告，不重要，红框内才是报错。如果出现红框内cannot apply binary patch类似的输出说明我们的commit包含二进制文件，这时我们需要执行以下步骤：

  1. 将剩余的验证步骤执行完毕，切回分支头部
  2. 执行git rm 二进制文件名将上述二进制文件删除
  3. 使用git add和git commit操作提交这次修改
  4. 最后执行make diff重新生成commmit.patch

6. GDB 命令行调试问题

6.1 GDB 不能 stepi ecall 或 sret 指令

因为 gdb 版本不对，应该使用 riscv64-unknown-elf-gdb 而不是 gdb-multiarch 或 riscv64-unknown-linux-gnu-gdb。elf 表示裸机上执行的程序，通常为操作系统，linux-gnu 表示运行在 linux 上的程序，是正常的用户软件。裸机程序 gdb 才能调试特权级汇编语句。

6.2 gdb-dashboard 装上去没有显示

  1. 检查 ~/.config/gdb/gdbinit 文件是否存在，如果存在请删除。因为gdb 默认会选择 ~/.config/gdb/gdbinit 作为配置文件，优先级高于 ~/.gdbinit。
  2. tail ~/.gdbinit 查看文件末尾是否存在 set auto-load safe-path / 这一行，如果没有请手动添加。

6.3 VSCode 图形化调试可用，但 GDB 命令行调试失败

  • 问题根源

VSCode 图形化调试会自动处理与 QEMU 的连接（无需手动配置 target remote），若 .gdbinit 中保留该配置，会导致重复连接；而 GDB 命令行调试需手动通过 target remote 连接 QEMU，必须启用该配置。因此需根据调试方式切换注释状态。

  • 场景 1：用 VSCode 图形化界面调试

VSCode图形化界面调试需要注释第三行：target remote 127.0.0.1:***

set confirm off
set architecture riscv:rv64
target remote 127.0.0.1:25019
symbol-file kernel/kernel
set disassemble-next-line auto
set riscv use-compressed-breakpoints yes
  • 场景 2：用 GDB 命令行调试

删除第三行前的 #，取消注释

原因：GDB 命令行需通过该配置手动连接 QEMU 的调试端口（此处端口为 25019，需与你的 QEMU 启动端口一致）。

6.4 GDB进行调试时遇到 tcp:2600000 failed to find an available port: Address already in use?

image-20250915212013555

这是GDB尝试监听2600000端口进行调试连接，但该端口已被其他进程占用。

首先，你需要确认是哪个进程占用了 2600000 端口。

lsof -i :2600000

这些命令会列出正在使用 2600000 端口的进程信息，关键是要记下其 PID（进程标识符）

一旦找到了占用端口的 PID，你就可以终止它。

sudo kill -9 <PID>

如果你用远程实验平台，请用以下命令

kill <PID>

请将 <PID> 替换为实际的进程号。< >不要写。

如果你的端口号不是2600000，请检查 QEMU 启动命令：XV6 调试时 QEMU 需指定调试端口，命令通常为make qemu-gdb，其底层会执行类似qemu-system-riscv64 -gdb tcp::XXXX ...的指令。其中 XXXX 为实际调试端口号。

6.5 在远程实验平台GDB调试提示 .gdbinit:3: Error in sourced command file: could not connect: Connection timed out.

执行调试时出现连接超时错误，具体提示如下：

.gdbinit:3: Error in sourced command file: could not connect: Connection timed out.

image-20250926214442310

image-20250926214431898

在远程实验平台中，这位同学在执行调试操作时出现节点不匹配问题，可通过以下方式确认并处理：

首先查看命令行提示符确认当前节点(远程实验平台总共有8个节点，编号从0~7)：

  • 若显示 学号@comp0:~$，表示处于计算节点 comp0
  • 若显示 学号@comp1:~$，表示处于计算节点 comp1
  • ……

由于两个命令处于不同节点，导致 .gdbinit 配置文件中第 3 行的端口连接失败：

target remote 127.0.0.1:28093  # 不同节点间无法访问此端口

必须确保 make qemu-gdb CPUS=1 和 make gdb 在 同一计算节点 执行：

  1. 先打开第一个窗口，登录实验平台
  2. 立即打开第二个窗口，登录实验平台
  3. 在第一个窗口运行 make qemu-gdb CPUS=1；在第二个窗口中运行 make gdb

通过连续打开窗口的方式，系统会自动分配相同的计算节点，避免跨节点通信导致的端口连接失败问题。