redox issueshttps://gitlab.redox-os.org/redox-os/redox/-/issues2024-01-05T15:20:39Zhttps://gitlab.redox-os.org/redox-os/redox/-/issues/1422(Bug) The boot randomly hangs with a large number of CPU cores2024-01-05T15:20:39ZRibbon(Bug) The boot randomly hangs with a large number of CPU coresThe boot hangs on random parts of the boot if you use more than 2 CPU cores on QEMU.
### How to reproduce
- Verify if the `mk/qemu.mk` file is using 2 CPU cores or more (`QEMUFLAGS+=-smp x -m 2048`)
- Start QEMU and verify
- If the bug...The boot hangs on random parts of the boot if you use more than 2 CPU cores on QEMU.
### How to reproduce
- Verify if the `mk/qemu.mk` file is using 2 CPU cores or more (`QEMUFLAGS+=-smp x -m 2048`)
- Start QEMU and verify
- If the bug doesn't happen, add more CPU cores on the QEMU configurationhttps://gitlab.redox-os.org/redox-os/redox/-/issues/1350Reading from rand: stalls the rest of the system in the meantime2023-11-25T09:43:47ZseamasteruwuReading from rand: stalls the rest of the system in the meantime<!-- Thank you for taking the time to submit an issue! By following these comments and filling out the sections below, you can help the developers get the necessary information to fix your issue. Please provide a single issue per report....<!-- Thank you for taking the time to submit an issue! By following these comments and filling out the sections below, you can help the developers get the necessary information to fix your issue. Please provide a single issue per report. You can also preview this report before submitting it. Feel free to modify/remove sections to fit the nature of your issue. -->
<!-- Please search to check that your issue has not been created already. By preventing duplicate issues, you can help keep the repository organized. If your current issue has already been created and is still unresolved, you can contribute by commenting there. -->
<!-- Replace the empty checkbox [ ] below with a checked one [x] if you have already searched for your issue. -->
- [X] I agree that I have searched opened and closed issues to prevent duplicates.
--------------------
## Description
<!-- Briefly summarize/describe the issue that you are experiencing below. -->
Executing "less /dev/random" freezes Redox and even after 10 minutes it doesn't unfreeze.
## Environment info
<!-- To understand where your issue originates, please include some relevant information about your environment. -->
<!-- If you are using a pre-built release of Redox, please specify the release version below. -->
- Redox OS Release:
0.6.0
## Steps to reproduce
<!-- If possible, please list the steps to reproduce ("trigger") your issue below. Being detailed definitely helps speed up bug fixes. -->
1. Open the terminal.
2. Write "less /dev/random" and hit enter
## Behavior
<!-- It may seem obvious to know what to expect, but isolating the behavior from everything else simplifies the development process. Remember to provide a single issue in this report. You can use the References section below to link your issues together. -->
<!-- Describe the behavior you expect your steps should yield (i.e., correct behavior). -->
- **Expected behavior**:
It should output random stuff to the shell.
<!-- Describe the behavior you observed when running your steps (i.e., buggy behavior). -->
- **Actual behavior**:
The whole system freezed.
<!-- **Logs?** Posting a log can help developers find your particular issue more easily. Please wrap your code in code blocks using triple back-ticks ``` to increase readability. -->
```
kernel::log:INFO -- Logger initialized.
kernel::arch::x86_64::start:INFO -- Redox OS starting...
kernel::arch::x86_64::start:INFO -- Kernel: 100000:A50BA8
kernel::arch::x86_64::start:INFO -- Stack: FFFF800000080000:FFFF80000009F000
kernel::arch::x86_64::start:INFO -- Env: FFFF80000009EFB0:FFFF80000009F000
kernel::arch::x86_64::start:INFO -- RSDPs: 0:0
kernel_end: A51000
bump_offset: 9F0000
MemoryArea { base: PhysicalAddress(0), size: 9F000 }
MemoryArea { base: PhysicalAddress(100000), size: 3FEDE000 }
Memory: 1024 MB
Table: A51000
256: A52003
511: 8000000000A51003
Permanently used: 12236 KB
kernel::acpi:INFO -- RSDP: RSDP { signature: [82, 83, 68, 32, 80, 84, 82, 32], checksum: 173, oemid: [66, 79, 67, 72, 83, 32], revision: 0, rsdt_address: 1073619526, length: 0, xsdt_address: 0, extended_checksum: 95, reserved: [83, 77, 95] }
RSDT:
FACP: 3FFE0040
APIC: FEE00000: 1
XAPIC 0: FFFF8000FEE00000
LocalApic(MadtLocalApic { processor: 0, id: 0, flags: 1 })
This is my local APIC
LocalApic(MadtLocalApic { processor: 1, id: 1, flags: 1 })
AP 1: IPI... SIPI... Wait... Trampoline... Ready
LocalApic(MadtLocalApic { processor: 2, id: 2, flags: 1 })
AP 2: IPI... SIPI... Wait... Trampoline... Ready
LocalApic(MadtLocalApic { processor: 3, id: 3, flags: 1 })
AP 3: IPI... SIPI... Wait... Trampoline... Ready
IoApic(MadtIoApic { id: 0, reserved: 0, address: 4273995776, gsi_base: 0 })
IntSrcOverride(MadtIntSrcOverride { bus_source: 0, irq_source: 0, gsi_base: 2, flags: 0 })
IntSrcOverride(MadtIntSrcOverride { bus_source: 0, irq_source: 5, gsi_base: 5, flags: 13 })
IntSrcOverride(MadtIntSrcOverride { bus_source: 0, irq_source: 9, gsi_base: 9, flags: 13 })
IntSrcOverride(MadtIntSrcOverride { bus_source: 0, irq_source: 10, gsi_base: 10, flags: 13 })
IntSrcOverride(MadtIntSrcOverride { bus_source: 0, irq_source: 11, gsi_base: 11, flags: 13 })
Unknown(4)
Unable to find DMAR
HPET: 0
DSDT: Parsed
HPET used as system timer
kernel:INFO -- AP 1: Ok(ContextId(1))
kernel:INFO -- AP 2: Ok(ContextId(4))
kernel:INFO -- AP 3: Ok(ContextId(3))
kernel:INFO -- BSP: Ok(ContextId(2)) 4
kernel:INFO -- Env: Ok("REDOXFS_BLOCK=0000000000000100\nREDOXFS_UUID=f0052344-6b8a-432e-9933-18c066acd791")
########## Redox OS ##########
# Login with the following: #
# `user` #
# `root`:`password` #
##############################
redox login: todo: clone grant using fmap: Grant { region: 0x40000010000..0x400001e5000 (0x1d5000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(18), number: 5, flags: 458752 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(18), number: 5, flags: 458752 }}, cloexec: true }
todo: clone grant using fmap: Grant { region: 0x40000152000..0x40000178000 (0x26000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 2, flags: 65956 }}, cloexec: true }) }
todo: clone grant using fmap: Grant { region: 0x40000178000..0x4000018b000 (0x13000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 3, flags: 65956 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 2, flags: 65956 }}, cloexec: true }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 3, flags: 65956 }}, cloexec: true }
todo: clone grant using fmap: Grant { region: 0x40000152000..0x40000178000 (0x26000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 2, flags: 65956 }}, cloexec: true }) }
todo: clone grant using fmap: Grant { region: 0x40000178000..0x4000018b000 (0x13000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 3, flags: 65956 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 2, flags: 65956 }}, cloexec: true }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 3, flags: 65956 }}, cloexec: true }
todo: clone grant using fmap: Grant { region: 0x40000071000..0x4000019d000 (0x12c000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }
todo: clone grant using fmap: Grant { region: 0x40000071000..0x4000019d000 (0x12c000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }
todo: clone grant using fmap: Grant { region: 0x40000071000..0x4000019d000 (0x12c000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }
todo: clone grant using fmap: Grant { region: 0x40000071000..0x4000019d000 (0x12c000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }
todo: clone grant using fmap: Grant { region: 0x40000071000..0x4000019d000 (0x12c000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }
todo: clone grant using fmap: Grant { region: 0x40000071000..0x4000019d000 (0x12c000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }
todo: clone grant using fmap: Grant { region: 0x40000071000..0x4000019d000 (0x12c000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 5, flags: 65956 }}, cloexec: true }
todo: clone grant using fmap: Grant { region: 0x40000152000..0x40000178000 (0x26000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 2, flags: 65956 }}, cloexec: true }) }
todo: clone grant using fmap: Grant { region: 0x40000178000..0x4000018b000 (0x13000 long), flags: PRESENT | WRITABLE | USER_ACCESSIBLE | NO_EXECUTE, mapped: true, owned: false, desc_opt: Some(FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 3, flags: 65956 }}, cloexec: true }) }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 2, flags: 65956 }}, cloexec: true }
Grant::unmap: close desc FileDescriptor { description: RwLock { data: FileDescription { namespace: SchemeNamespace(1), scheme: SchemeId(36), number: 3, flags: 65956 }}, cloexec: true }
```
The thing above is what qemu showed in the terminal
<!-- **Solution?** Have a solution in mind? Propose your solution below. -->
<!-- **Screenshots?** Make it easier to get your point across with screenshots. You can drag & drop or paste your images below. -->
<!-- If you have found issues or pull requests that are related to or blocking this issue, please link them below. See https://help.github.com/articles/autolinked-references-and-urls/ for more options. You can also link related code snippets by providing the permalink. See https://help.github.com/articles/creating-a-permanent-link-to-a-code-snippet/ for more information. -->
## Optional extras
<!-- If you have other relevant information not found in other sections, you can include it below. -->
When I did "more /dev/random" it diden't freeze. Trying to open it with the file manager freezed it for 2~3 secounds but it unfreezed.
<!-- **Code?** Awesome! You can also create a pull request with a reference to this issue. -->
<!-- **Files?** Attach your relevant files by dragging & dropping or pasting them below. -->
<!-- You also can preview your report before submitting it. Thanks for contributing to Redox! -->https://gitlab.redox-os.org/redox-os/redox/-/issues/1413HPET instability when running with qemu2023-10-30T14:50:46ZWill AngenentHPET instability when running with qemuWhen running the desktop build, compiled under ubuntu linux, with qemu 7.2.0 installed with brew, under MacOS 12.2, intel CPU, I get random crashes like these:
- [1.log](/uploads/29fadace825f9c6f9e526c1b2043bccc/1.log)
- [2.log](/upload...When running the desktop build, compiled under ubuntu linux, with qemu 7.2.0 installed with brew, under MacOS 12.2, intel CPU, I get random crashes like these:
- [1.log](/uploads/29fadace825f9c6f9e526c1b2043bccc/1.log)
- [2.log](/uploads/992d70d981db3a47eb5e9ce1a40c38d3/2.log)
- [3.log](/uploads/7d0a6b848b2758650bd1d53e8cbea666/3.log)
- [4.log](/uploads/8732e27ed04a27211f8b60c4e211efe9/4.log)
- [5.log](/uploads/1c5193aa6372b4c565fbbccfad04bfa5/5.log)
It appears that `period_fs` [here](https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/arch/x86_64/time.rs#L19) is becoming zero.
When adding this debug print:
```
// Calculate divisor
if period_fs == 0 {
let capability2 = unsafe { hpet.base_address.read_u64(hpet::CAPABILITY_OFFSET) };
println!(
"hpet={:?} capability={:?} capability2={:?}",
hpet, capability, capability2
);
}
```
I managed to get this output:
```
capability=10164 capability2=42949675116306945
```
By the way:
42949675116306945 translates to 0x9896808086A201.
0x9896808086A201 >> 32 is 0x989680. In decimal, this is 10000000, the clock period.
The contents of hpet struct is the same in good & bad boots.https://gitlab.redox-os.org/redox-os/redox/-/issues/1359Terminal Doesn't Display Correct Directory2023-10-27T13:48:41ZKtoksTerminal Doesn't Display Correct Directory<!-- Thank you for taking the time to submit an issue! By following these comments and filling out the sections below, you can help the developers get the necessary information to fix your issue. Please provide a single issue per report....<!-- Thank you for taking the time to submit an issue! By following these comments and filling out the sections below, you can help the developers get the necessary information to fix your issue. Please provide a single issue per report. You can also preview this report before submitting it. Feel free to modify/remove sections to fit the nature of your issue. -->
<!-- Please search to check that your issue has not been created already. By preventing duplicate issues, you can help keep the repository organized. If your current issue has already been created and is still unresolved, you can contribute by commenting there. -->
<!-- Replace the empty checkbox [ ] below with a checked one [x] if you have already searched for your issue. -->
- [x] I agree that I have searched opened and closed issues to prevent duplicates.
--------------------
## Description
<!-- Briefly summarize/describe the issue that you are experiencing below. -->
Upon opening and navigating the terminal, the display doesn't show the current directory
## Environment info
<!-- To understand where your issue originates, please include some relevant information about your environment. -->
<!-- If you are using a pre-built release of Redox, please specify the release version below. -->
- Redox OS Release:
0.7.0
<!-- If you have built Redox OS yourself, please provide the following information: -->
- Operating system:
Pop! OS
- `uname -a`:
`Linux pop-os 5.18.10-76051810-generic #202207071639~1659108431~22.04~c9172fb SMP PREEMPT_DYNAMIC Fri J x86_64 x86_64 x86_64 GNU/Linux`
- `rustc -V`:
`rustc 1.62.1 (e092d0b6b 2022-07-16)`
- `git rev-parse HEAD`:
`git rev-parse HEAD`
<!-- Depending on your issue, additional information about your environment (network config, package versions, dependencies, etc.) can also help. You can list that below. -->
## Steps to reproduce
<!-- If possible, please list the steps to reproduce ("trigger") your issue below. Being detailed definitely helps speed up bug fixes. -->
1. Log in
2. Open terminal - doesn't display starting here
3. `cd` - terminal displays correctly
4. `cd ..` - terminal doesn't display change in current directory
## Behavior
<!-- It may seem obvious to know what to expect, but isolating the behavior from everything else simplifies the development process. Remember to provide a single issue in this report. You can use the References section below to link your issues together. -->
<!-- Describe the behavior you expect your steps should yield (i.e., correct behavior). -->
- **Expected behavior**:
Whenever the terminal is opened, it should display the current dir
Whenever one navigates, it should show the updated current dir
<!-- Describe the behavior you observed when running your steps (i.e., buggy behavior). -->
- **Actual behavior**:
The current dir updates only when you `cd` to home, but otherwise, it doesn't update.
Upon further observation - the display does update as you go to child directories, but it doesn't update when you `cd` back.
<!-- **Logs?** Posting a log can help developers find your particular issue more easily. Please wrap your code in code blocks using triple back-ticks ``` to increase readability. -->
```
Unfortunately there are no logs worth mentioning
```
<!-- **Solution?** Have a solution in mind? Propose your solution below. -->
- **Proposed solution**:
I believe this could be fixed by displaying the output of `pwd` to the terminal dir output, but I'm sure that has already been considered.
After further observing, it seems to just not update when going to parent directories. As you branch out - it updates, as you return toward the trunk, it does not - I assume this is just a simple misplaced update of the displayed directory
<!-- **Screenshots?** Make it easier to get your point across with screenshots. You can drag & drop or paste your images below. -->
![Screenshot_from_2022-08-02_23-28-26](/uploads/60e36aed498ec2ed55ba8e0aa0b37268/Screenshot_from_2022-08-02_23-28-26.png)
![Screenshot_from_2022-08-02_23-28-49](/uploads/611cc13531ca6b5d74de1403f2923676/Screenshot_from_2022-08-02_23-28-49.png)
![image](/uploads/9be5a4bd5b5dd14ab39253636b5e1119/image.png)
## Optional references
<!-- If you have found issues or pull requests that are related to or blocking this issue, please link them below. See https://help.github.com/articles/autolinked-references-and-urls/ for more options. You can also link related code snippets by providing the permalink. See https://help.github.com/articles/creating-a-permanent-link-to-a-code-snippet/ for more information. -->
## Optional extras
<!-- If you have other relevant information not found in other sections, you can include it below. -->
<!-- **Code?** Awesome! You can also create a pull request with a reference to this issue. -->
<!-- **Files?** Attach your relevant files by dragging & dropping or pasting them below. -->
<!-- You also can preview your report before submitting it. Thanks for contributing to Redox! -->https://gitlab.redox-os.org/redox-os/redox/-/issues/1082Closing menu pressing redox icon2023-10-27T13:45:32ZJeremy SollerClosing menu pressing redox icon*Created by: pharaone*
## Description
<!-- Briefly summarize/describe the issue that you are experiencing below. -->
I don't know if it's a bug or a feature request XD
## Environment info
Virtual box
- Redox OS Release:
0.3.4
##...*Created by: pharaone*
## Description
<!-- Briefly summarize/describe the issue that you are experiencing below. -->
I don't know if it's a bug or a feature request XD
## Environment info
Virtual box
- Redox OS Release:
0.3.4
## Steps to reproduce
Press the redox icon(bottom left) to open the menu, now press it again
<!-- Describe the behavior you expect your steps should yield (i.e., correct behavior). -->
- **Expected behavior**:
The menu closes
<!-- Describe the behavior you observed when running your steps (i.e., buggy behavior). -->
- **Actual behavior**:
The menu disappears for some milliseconds and then reappearshttps://gitlab.redox-os.org/redox-os/redox/-/issues/824Launching more than one getty on vesad causes hang2023-10-27T13:27:28ZJeremy SollerLaunching more than one getty on vesad causes hangAfter changing `init` to use `dup2`, launching more than one `getty` on `display:2` and `display:3` causes hangs.
Master will only launch one getty on `display:2` to prevent this from being an issue for the time beingAfter changing `init` to use `dup2`, launching more than one `getty` on `display:2` and `display:3` causes hangs.
Master will only launch one getty on `display:2` to prevent this from being an issue for the time beinghttps://gitlab.redox-os.org/redox-os/redox/-/issues/1410cd :: && mkdir myscheme2023-10-27T13:25:42ZPramod V Ucd :: && mkdir myscheme--------------------
## Description
<!-- Briefly summarize/describe the issue that you are experiencing below. -->
I `cd ::`, which navigates to the apparent directory of schemes.
`ls` is very slow here.
The issue here occures rarely and...--------------------
## Description
<!-- Briefly summarize/describe the issue that you are experiencing below. -->
I `cd ::`, which navigates to the apparent directory of schemes.
`ls` is very slow here.
The issue here occures rarely and randomly, about once in four tries.
Also, the main issue occurs when using the CLI from the host, not orbterm, in which case an entirely different issue occurs:
```
ion: prompt expansion failed: pipeline execution error: command error: Operation not permitted (os error 1)
```
In the external CLI, I `mkdir :myscheme`,`myscheme:`,`myscheme`,`:myscheme:`.
If the issue occurs, the entire system freezes. If the issue doesn't occur:
```
mkdir: thread 'main' panicked at src/uucore/src/lib/mods/error.rs:534:22:
Unexpected io error: Bad file number (os error 9)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
(Even after `let RUST_BACKTRACE=1` within redox)
## Environment info
<!-- To understand where your issue originates, please include some relevant information about your environment. -->
<!-- If you are using a pre-built release of Redox, please specify the release version below. -->
<!-- Redox OS Release: 0.0.0 -->
<!-- If you have built Redox OS yourself, please provide the following information: -->
- Operating system:
Replace me
- `uname -a`:
```
Linux pvu-inspiron3511 6.5.8-4-MANJARO #1 SMP PREEMPT_DYNAMIC Wed Oct 25 05:14:18 UTC 2023 x86_64 GNU/Linux
```
- `rustc -V`:
```
rustc 1.74.0-nightly (e3abbd499 2023-09-06)
```
- `git rev-parse HEAD`:
```
234dc596395f873f69b65e2bdea714f0bf9b0bc1
```
<!-- Depending on your issue, additional information about your environment (network config, package versions, dependencies, etc.) can also help. You can list that below. -->
- `qemu -version`:
```
QEMU emulator version 8.1.2
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers
```
## Steps to reproduce
<!-- If possible, please list the steps to reproduce ("trigger") your issue below. Being detailed definitely helps speed up bug fixes. -->
0. Minimize the qemu window, and use the CLI where you started the qemu instance.
1. `cd ::` to the apparent directory of schemes.
2. `mkdir` `:myscheme`,`myscheme:`,`myscheme`,`:myscheme:`, one of them will randomly work.
## Behavior
<!-- It may seem obvious to know what to expect, but isolating the behavior from everything else simplifies the development process. Remember to provide a single issue in this report. You can use the References section below to link your issues together. -->
In orbterm:
```
ion: prompt expansion failed: pipeline execution error: command error: Operation not permitted (os error 1)
```
In external CLI, if the issue doesn't work:
```
mkdir: thread 'main' panicked at src/uucore/src/lib/mods/error.rs:534:22:
Unexpected io error: Bad file number (os error 9)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
(I *have* `let RUST_BACKTRACE=1`, still...)
When the issue occurs, the entire redox system freezes
[Full output of `script`](/uploads/ab955f78e21f63e0d5f84f95dece1765/redox.script-out.txt)
[`grep`ed contents with mkdir](/uploads/6542ee67e382667681b706fd44f8136d/mkdirscheme.log)
<!-- Describe the behavior you expect your steps should yield (i.e., correct behavior). -->
<!-- **Expected behavior**: -->
<!-- Replace me -->
<!-- Describe the behavior you observed when running your steps (i.e., buggy behavior). -->
<!-- **Actual behavior**: -->
<!-- **Logs?** Posting a log can help developers find your particular issue more easily. Please wrap your code in code blocks using triple back-ticks ``` to increase readability. -->
Logs are attached.
<!-- **Solution?** Have a solution in mind? Propose your solution below. -->
<!-- **Proposed solution**: -->
<!-- **Screenshots?** Make it easier to get your point across with screenshots. You can drag & drop or paste your images below. -->
<!-- ## Optional references -->
<!-- If you have found issues or pull requests that are related to or blocking this issue, please link them below. See https://help.github.com/articles/autolinked-references-and-urls/ for more options. You can also link related code snippets by providing the permalink. See https://help.github.com/articles/creating-a-permanent-link-to-a-code-snippet/ for more information. -->
<!-- Related to: -->
<!-- Blocked by: -->
<!-- ## Optional extras -->
<!-- If you have other relevant information not found in other sections, you can include it below. -->
<!-- **Code?** Awesome! You can also create a pull request with a reference to this issue. -->
<!-- **Files?** Attach your relevant files by dragging & dropping or pasting them below. -->
<!-- You also can preview your report before submitting it. Thanks for contributing to Redox! -->https://gitlab.redox-os.org/redox-os/redox/-/issues/1371Open of "rand:" fails when acpid tries to use toml::to_string()2023-10-27T11:09:37ZRon WilliamsOpen of "rand:" fails when acpid tries to use toml::to_string()After user login, in `acpid`, I attempted to serialize `derive`d data using `toml::to_string()`. This caused the rand.rs method `fill_bytes` to be called. `fill_bytes` attempted to open `rand:`, failing with error code 19, "No such devic...After user login, in `acpid`, I attempted to serialize `derive`d data using `toml::to_string()`. This caused the rand.rs method `fill_bytes` to be called. `fill_bytes` attempted to open `rand:`, failing with error code 19, "No such device". However, other uses of `rand:` seem to work fine.https://gitlab.redox-os.org/redox-os/redox/-/issues/1365dmesg displays redox-log messages incorrectly2023-06-13T01:09:48ZRon Williamsdmesg displays redox-log messages incorrectlydmesg is not correctly displaying messages written by redox-log. The text of the message is not visible. cat sys:/log > msg.log produces correct results. The problem seems to be with `less` mangling the ANSI escape sequences.dmesg is not correctly displaying messages written by redox-log. The text of the message is not visible. cat sys:/log > msg.log produces correct results. The problem seems to be with `less` mangling the ANSI escape sequences.https://gitlab.redox-os.org/redox-os/redox/-/issues/1367ls file:/* does not match anything2023-06-13T01:07:20ZRon Williamsls file:/* does not match anything`ls /*` works as expected. `ls file:/*` reports `No such file or directory``ls /*` works as expected. `ls file:/*` reports `No such file or directory`https://gitlab.redox-os.org/redox-os/redox/-/issues/1374aarch64 boot on qemu fails with redoxfs panic2023-06-13T00:40:37ZWill Angenentaarch64 boot on qemu fails with redoxfs panicWhen booting on qemu, redoxfs fails with [redoxfs-crash-log](/uploads/3b53e2fd01431ff0c3a8cc0ab2469675/redoxfs-crash-log).
`ELR_EL1` points at a BRK instruction. `ESR_EL1`, when decoded with something like
```
println!(
"ESR_EL1: {:...When booting on qemu, redoxfs fails with [redoxfs-crash-log](/uploads/3b53e2fd01431ff0c3a8cc0ab2469675/redoxfs-crash-log).
`ELR_EL1` points at a BRK instruction. `ESR_EL1`, when decoded with something like
```
println!(
"ESR_EL1: {:>016X} ISS={:>06X} instr len={:?} class={:>02X}", done in an idiomatic way, hardcode strings?
{ self.esr_el1 },
{ self.esr_el1 & 0xffffff },
{ self.esr_el1 >> 25 & 1 },
{ self.esr_el1 >> 26 & 0x3f }
);
```
in [dump](https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/arch/aarch64/interrupt/handler.rs#L99) reveals
```
ISS=000001 instr len=1 class=3C
```
`0x3c` is BRK instruction execution from AArch64 state.
Manually dissecting the backtrace shows that the addresses correspond to the backtrace printing code, not the code that failed.
Early on, a fork happens, and the parent & child both panic. Looks like the child has this in [`src/bin/mount.rs`](https://gitlab.redox-os.org/redox-os/redoxfs/-/blob/master/src/bin/mount.rs#L373).
```
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { kind: UnexpectedEof, message: "failed to fill whole buffer" }', src/bin/mount.rs:373:39
```
And the parent has
```
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /Users/wangenent/code/redox/mac/rust/library/alloc/src/collections/btree/navigate.rs:588:48
```
Some notes from conversations in the chat
- @4lDO2 mentioned that problems the btree is often caused by memory corruption.
- @microcolonel suggested checking the fork/context switching code. Audit the process creation, fork and context switch code. Come up with tests to stress this part. Tests that do not depend on an initfs or a livedisk etc.
- @rw_van suggested it's probably memory corruption or a race condition
An interesting observation, is that if redoxfs is built with `-O0` in a custom profile, e.g.
```
[profile.will-debug]
inherits = "release"
opt-level = 0
```
then the problem doesn't manifest itself and redox boots fine.