thread 'main' panicked at 'failed to parse port: ParseIntError { kind: InvalidDigit }', src/libcore/result.rs:999:5
Opened this issue · 11 comments
[id:~/.dev/borealis] master(+2/-0) ± cargo run 120 0 120
Finished dev [unoptimized + debuginfo] target(s) in 0.01s
Running `target/debug/borealis 120 0 120`
smbus: /sys/bus/pci/devices/0000:00:1f.4
thread 'main' panicked at 'failed to parse port: ParseIntError { kind: InvalidDigit }', src/libcore/result.rs:999:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[id:~/.dev/borealis] master(+2/-0) 101 ± RUST_BACKTRACE=1 cargo run 120 0 120
Finished dev [unoptimized + debuginfo] target(s) in 0.01s
Running `target/debug/borealis 120 0 120`
smbus: /sys/bus/pci/devices/0000:00:1f.4
thread 'main' panicked at 'failed to parse port: ParseIntError { kind: InvalidDigit }', src/libcore/result.rs:999:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: rust_begin_unwind
7: core::panicking::panic_fmt
8: core::result::unwrap_failed
at /usr/src/rustc-1.36.0/src/libcore/macros.rs:18
9: core::result::Result<T,E>::expect
at /usr/src/rustc-1.36.0/src/libcore/result.rs:827
10: borealis::i2c::find_i2c_adapters
at src/i2c.rs:53
11: borealis::main
at src/main.rs:35
12: std::rt::lang_start::{{closure}}
at /usr/src/rustc-1.36.0/src/libstd/rt.rs:64
13: std::panicking::try::do_call
14: __rust_maybe_catch_panic
15: std::rt::lang_start_internal
16: std::rt::lang_start
at /usr/src/rustc-1.36.0/src/libstd/rt.rs:64
17: main
18: __libc_start_main
19: _start
[id:~/.dev/borealis] master(+2/-0) 101 ± sudo modprobe i2c-dev
[id:~/.dev/borealis] master(+2/-0) ± cargo run 120 0 120
Finished dev [unoptimized + debuginfo] target(s) in 0.01s
Running `target/debug/borealis 120 0 120`
smbus: /sys/bus/pci/devices/0000:00:1f.4
thread 'main' panicked at 'failed to parse port: ParseIntError { kind: InvalidDigit }', src/libcore/result.rs:999:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
[id:~/.dev/borealis] master(+2/-0) 101 ± Same here :S
zorin@zorin:~/Downloads/Tools/borealis$ sudo cargo run 127 0 127
Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Running target/debug/borealis 127 0 127
smbus: /sys/bus/pci/devices/0000:00:14.0
i2c-sys: /dev/i2c-0
thread 'main' panicked at 'failed to locate auxiliary controller for MB Aura', src/libcore/option.rs:1036:5
note: Run with RUST_BACKTRACE=1 environment variable to display a backtrace.
@fultus that's not the same error, at all
@dreamcat4, looks like the program makes assumptions about the contents of that name virtual file in sysfs in the i2c subdirectory
I have the same error as @Fultos (on Manjaro):
$ cargo run 127 0 127
Finished dev [unoptimized + debuginfo] target(s) in 0.00s
Running `target/debug/borealis 127 0 127`
smbus: /sys/bus/pci/devices/0000:00:1f.4
thread 'main' panicked at 'failed to parse port: ParseIntError { kind: InvalidDigit }', src/libcore/result.rs:1084:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
This is what I get on Arch Linux:
$ RUST_BACKTRACE=1 cargo run 0 0 255
Finished dev [unoptimized + debuginfo] target(s) in 0.03s
Running `target/debug/borealis 0 0 255`
smbus: /sys/bus/pci/devices/0000:00:1f.4
thread 'main' panicked at 'failed to parse port: ParseIntError { kind: InvalidDigit }', src/libcore/result.rs:1084:5
stack backtrace:
0: std::panicking::default_hook::{{closure}}
1: std::panicking::default_hook
2: std::panicking::rust_panic_with_hook
3: std::panicking::continue_panic_fmt
4: rust_begin_unwind
5: core::panicking::panic_fmt
6: core::result::unwrap_failed
7: core::result::Result<T,E>::expect
at /build/rust/src/rustc-1.38.0-src/src/libcore/result.rs:879
8: borealis::i2c::find_i2c_adapters
at src/i2c.rs:53
9: borealis::main
at src/main.rs:35
10: std::rt::lang_start::{{closure}}
at /build/rust/src/rustc-1.38.0-src/src/libstd/rt.rs:64
11: std::panicking::try::do_call
12: __rust_maybe_catch_panic
13: std::rt::lang_start_internal
14: std::rt::lang_start
at /build/rust/src/rustc-1.38.0-src/src/libstd/rt.rs:64
15: main
16: __libc_start_main
17: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
And with full backtrace:
$ RUST_BACKTRACE=full cargo run 0 0 255
Finished dev [unoptimized + debuginfo] target(s) in 0.03s
Running `target/debug/borealis 0 0 255`
smbus: /sys/bus/pci/devices/0000:00:1f.4
thread 'main' panicked at 'failed to parse port: ParseIntError { kind: InvalidDigit }', src/libcore/result.rs:1084:5
stack backtrace:
0: 0x564353e2e72b - std::panicking::default_hook::{{closure}}::hd4d730f4b49280ac
1: 0x564353e2e406 - std::panicking::default_hook::h15ad337e082b11af
2: 0x564353e2eded - std::panicking::rust_panic_with_hook::h1ae6f71213bb644c
3: 0x564353e2e972 - std::panicking::continue_panic_fmt::h7260e5946830995a
4: 0x564353e2e856 - rust_begin_unwind
5: 0x564353e400ed - core::panicking::panic_fmt::h0f33ccf7fc2a1201
6: 0x564353e401e7 - core::result::unwrap_failed::h5f2f3948a0c719bd
7: 0x564353e15396 - core::result::Result<T,E>::expect::h42ed45c748a840b0
at /build/rust/src/rustc-1.38.0-src/src/libcore/result.rs:879
8: 0x564353e007be - borealis::i2c::find_i2c_adapters::h248f76647a02ed42
at src/i2c.rs:53
9: 0x564353e16a85 - borealis::main::hdebf3bafbcd8e960
at src/main.rs:35
10: 0x564353dfe375 - std::rt::lang_start::{{closure}}::h89ba34680ff1cc4a
at /build/rust/src/rustc-1.38.0-src/src/libstd/rt.rs:64
11: 0x564353e2e843 - std::panicking::try::do_call::h1a7d28594960023a
12: 0x564353e30b4a - __rust_maybe_catch_panic
13: 0x564353e2f2fd - std::rt::lang_start_internal::h271ffb92208ca4b2
14: 0x564353dfe349 - std::rt::lang_start::hfb9ee18497471fe2
at /build/rust/src/rustc-1.38.0-src/src/libstd/rt.rs:64
15: 0x564353e179ca - main
16: 0x7f8a7a6f4153 - __libc_start_main
17: 0x564353df90ce - _start
18: 0x0 - <unknown>
Hi,
Sorry, I haven't worked on Borealis at all lately (busy with other stuff, unfortunately); that being said, this is an interesting issue.
Can someone who's experiencing this issue please add the following line after line 51?
println!("{}", name_str);
It should look like this:
let name_str = String::from_utf8_lossy(&name_buf);
println!("{}", name_str)
let name_components: Vec<_> = name_str.trim().split(' ').collect();This should print out what the name it's getting is, which should help me diagnose why it's in a different format. Cheers!
[edited] @philpax
The string is:
SMBus I801 adapter at f000
including a newline (empty 2nd line) after it
I've pushed up a commit that skips over non-PIIX4 adapters, but this might still fail if your system doesn't use PIIX4. Can you give it a shot and see what happens?
Thank you for taking the time and looking into this. Pulled and build the latest from master, and seems to be getting a new error message now, which is:
id:~/.dev/borealis] master ± cargo run 127 0 127
Finished dev [unoptimized + debuginfo] target(s) in 0.01s
Running `target/debug/borealis 127 0 127`
smbus: /sys/bus/pci/devices/0000:00:1f.4
thread 'main' panicked at 'failed to locate AMD system SMBus', src/libcore/option.rs:1034:5The full log is here.
I should also mention that this product is the: ASUS Maximus IX (or X) Apex hardware. If there is any other commands I can run to gather more information on the i2c / smbus. Very happy to do that, and delve a little deeper.
Hey @philpax I have just found today another project, where the intel boards are documented you can see here:
https://gitlab.com/CalcProgrammer1/OpenAuraSDK
So it's definately have to be going through the SMBus I801 adapter at f000 as was reported back previously. According to that information over there, I need to load up some custom kernel module etc. Hopefully this clarifies the situation in regards to all of the Intel motherboards.
Ah yep, I've had a quick look. Based on Adam's research, I think this should be as straight-forward as simply writing to the I801 or NCT67xx (after his patch), but I don't really have an easy way of testing that.
I'm pretty busy right now, but I'll see if I can hack together something at some point in the future that isn't as tied to my particular system; hopefully everything will "just work" once it's pointed in the right direction.
Before I do that, though, I should probably chat to Adam and see how he's faring; both of our projects are doing very similar things, after all, and I don't want to step on his toes. Have you tried using OpenAuraSDK and seeing if it works for you?
@philpax hey sure man! I encourage you to talk to Adam over there and try to co-operate / support both each other's projects.
Even if there is some duplication of efforts, your code still can be very useful specficially as a library in rust, to support other rust programs (providing them an API for rgb control).
It is also a nice example application for rust, for people trying to get into the language a do something that is 'useful' or practical. And it gives a very pleasing interaction of seeing the RGB lights fire up / etc. Which is a great way to get hooked from that perspective of learning a new language.