TS464 IT8528 not found #3
Comments
|
Can you please provide the following:
#include <stdio.h>
#include <sys/io.h>
void main(void) {
unsigned short ec_id;
if (!ioperm(0x2e, 2, 1)) {
outb(0x20, 0x2e);
printf("First ID byte: 0x%x\n", inb(0x2f));
outb(0x21, 0x2e);
printf("Second ID byte: 0x%x\n", inb(0x2f));
ioperm(0x2e, 2, 0);
return;
}
printf("ioperm error\n");
}(I should really print this in the logs when the error occurs, will add) |
|
Also, if possible, can you statically compile the small program (if needed) and run it directly on the host without a container? |
I ran the same binary (since host does not have gcc) and got the same result as step 3 on the host |
|
I also have the decompiled dsdt if that helps in any way. |
|
Unfortunately, the output of /proc/ioports is missing, (all ranges are If the device uses the IT8528 the first and second ID bytes should be All these are the configuration files for various TS-464 devices, nothing else but IT8528: It's not as "safe", but you can try to force load the module using Please report back, and attach any output from the module so I can have it as a reference. |
|
Whoops, here is the ioports from the host (it is the same in the container, not sure where I copied the previous one from :)) Tried force loading the ko in the container, failed as below. Could not insmod on the host since the host does not have insmod. I did try adding it to modules.dep and modprobing it (without skip hardware check) before, and that failed in the same way too. |
|
This is a bit silly, but I'm not sure where that return value is coming from. Can you edit the code and initialize |
Originally, this was |
|
Same output . I replaced every single instance of Edit: Actually your code returns |
|
This feels like a good candidate for the place of the problem https://github.com/0xGiddi/qnap8528/blob/master/src/qnap8528.c#L1162 |
|
Agreed, I can only guess right now that this is the result of the Maybe try replacing with To see if they are indeed empty. I was just double checking that the code is consistent and not a random value. |
|
They are indeed empty. |
|
If you think it will help, I can try live booting ubuntu and running this kernel module to see if this is something to do with trueNAS as a last resort (tomorrow maybe), although trueNAS scale is also based on Debian. |
|
Hmmm... they should not be empty. I was thinking the same thing about reboot into a known system and then with direct access on the host test fore more possibilities. I will also write later a small C program that will dump the VPD tables, see if we can get any data out of them (if they exist). I will post it here, but it will not be in the next few hours. |
|
I printed the return value that sets those buffers and we are hitting this: https://github.com/0xGiddi/qnap8528/blob/master/src/qnap8528.c#L464 and getting I ask because |
|
Its breaking up the VPD entry value into the table/offset/length components (See https://github.com/0xGiddi/qnap8528/blob/v1.1/src/qnap8528.h#L27 ) and sending them to the EC for reading, it's not using a filesystem at all, all If its getting EBUSY, it might mean that the read operations are stuck at waiting for the input buffer or output buffer of the chip to empty (which is either not happening, or not happening in time). You can try and change the delay to 1000 for example and the retries to 5000 to see if its a timeout issue in (See https://github.com/0xGiddi/qnap8528/blob/v1.1/src/qnap8528.h#L14 ) Also, if you reboot, try going into the BIOS and checking if you can see information about the EC, it usually is displayed there (at least a version number) |
|
In addition to making the retries 5000 and the sleep 1000, you might want to try this: Here Line 463 in 5a38cc3 |
|
Try this branch https://github.com/0xGiddi/qnap8528/tree/ts-464 it only has the delay updates, I also set to skip the HW check by default |
|
That is crazy because it works now! The delay was all it needed (and skipping the hardware check, I wonder if there needs to be a delay for that too somewhere). A huge thanks to you for working through this! Notes from my testing:
Here are some data I was exploring, let me know if you would like to see something specific. VPD: root@qnas:/sys/devices/platform/qnap8528/vpd# ls | xargs -I{} bash -c 'echo {}; cat {}; echo'
backplane_date
2023-11-29 14:07:00
backplane_manufacturer
QNAP Systems
backplane_model
70-1Q08F0110
backplane_name
LF-SATA-BP
backplane_serial
72311015743
backplane_vendor
QNAP Systems
enclosure_nickname
enclosure_serial
Q23BF095953
mainboard_date
mainboard_manufacturer
QNAP Systems
mainboard_model
70-0Q07R1130
mainboard_name
STAT-6G-MB
mainboard_serial
72311014208
mainboard_vendor
QNAP SystemsEuP root@qnas:/sys/devices/platform/qnap8528/ec# ls
cpld_version fw_version
root@qnas:/sys/devices/platform/qnap8528/ec# cat cpld_version ; echo
0x2
root@qnas:/sys/devices/platform/qnap8528/ec# cat fw_version ; echo
Q07RL008Buttons info root@qnas:/sys/devices/platform/qnap8528/input/input6/capabilities# ls | xargs -I{} bash -c 'echo {}; cat {}'
abs
0
ev
3
ff
0
key
7 0 0 0 0
led
0
msc
0
rel
0
snd
0
sw
0
root@qnas:/sys/devices/platform/qnap8528/input/input6# cat properties
0
root@qnas:/sys/devices/platform/qnap8528/input/input6# cat min
0
root@qnas:/sys/devices/platform/qnap8528/input/input6# cat max
100
root@qnas:/sys/devices/platform/qnap8528/input/input6# cat name
qnap8528
root@qnas:/sys/devices/platform/qnap8528/input/input6# cat phys
qnap8528/input0
root@qnas:/sys/devices/platform/qnap8528/input/input6# cat poll
100
root@qnas:/sys/devices/platform/qnap8528/input/input6# cat poll
100
root@qnas:/sys/devices/platform/qnap8528/input/input6# cat uevent
PRODUCT=19/0/0/0
NAME="qnap8528"
PHYS="qnap8528/input0"
PROP=0
EV=3
KEY=7 0 0 0 0
MODALIAS=input:b0019v0000p0000e0000-e0,1,k100,101,102,ramlsfw
root@qnas:/sys/devices/platform/qnap8528/input/input6/power# ls | xargs -I{} bash -c 'echo {}; cat {}'
autosuspend_delay_ms
cat: autosuspend_delay_ms: Input/output error
control
auto
runtime_active_time
0
runtime_status
unsupported
runtime_suspended_time
0
root@qnas:/sys/devices/platform/qnap8528/input/input6/id# ls | xargs -I{} bash -c 'echo {}; cat {}'
bustype
0019
product
0000
vendor
0000
version
0000Button test root@qnas:/# evtest /host/dev/input/event6
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "qnap8528"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 256 (BTN_0)
Event code 257 (BTN_1)
Event code 258 (BTN_2)
Properties:
Testing ... (interrupt to exit)
Event: time 1732197325.242336, type 1 (EV_KEY), code 258 (BTN_2), value 1
Event: time 1732197325.242336, -------------- SYN_REPORT ------------
Event: time 1732197325.554340, type 1 (EV_KEY), code 258 (BTN_2), value 0
Event: time 1732197325.554340, -------------- SYN_REPORT ------------Fan Control root@qnas:/sys/class/hwmon/hwmon4# cat fan1_input
1126
root@qnas:/sys/class/hwmon/hwmon4# cat pwm1
94
root@qnas:/sys/class/hwmon/hwmon4# echo 100 > pwm1
root@qnas:/sys/class/hwmon/hwmon4# cat pwm1
99
root@qnas:/sys/class/hwmon/hwmon4# cat fan1_input
1154
root@qnas:/sys/class/hwmon/hwmon4# echo 50 > pwm1
root@qnas:/sys/class/hwmon/hwmon4# cat pwm1
48
root@qnas:/sys/class/hwmon/hwmon4# cat fan1_input
562
root@qnas:/sys/class/hwmon/hwmon4# echo 94 > pwm1
root@qnas:/sys/class/hwmon/hwmon4# ls temp* | xargs -I{} bash -c 'echo {}; cat {}'
temp11_input
2000
temp12_input
2000
temp1_input
42000
temp6_input
34000LED |
Amazing, Did you add any additional delays like I commented or did you use the ts-464 branch? Just so I know what exact delays and where worked.
Reset is the pinhole button (on my model), I have not checked if power button is reported at all.
This might happen, as they are enumerated dynamically (any channel with a temperature between
Yes, the brightness reported back from the kernel is entirely software based (part of the led subsystem), so initially they will all be 0.
LED blinking is done with standard Linux triggers ( Maybe I should add a custom attribute to set the HW blink even if not triggers are available?
From the information you provided, your codes are The LEDs are a pain for the brain, currently, they only way to get them back would be to restart the NAS. I will push another change to TS-464 branch that will try and set the green LED even if does not exist, maybe this is a mistake in QNAPs config I was parsing.
There is no (known) interface for the network LED, it seems to be hardwired as far as I can tell. Thank you for the data much appreciated. |
|
Please pull the latest TS-464 branch (https://github.com/0xGiddi/qnap8528/tree/ts-464) and check if you can set the LEDs to green. More info about the change: Compare that to my device for example: You can see the missing For now, I have just added the green LED into the config, so would "support" green slot LEDs, but I dont know if this is OK since QNAP specifically omitted it from the config. But its worth the test. A reset of the device should set all LEDs back yo their default state. Changes made to qnap8528 config: |
Note to self: This seems to be device with ENE ECs https://nascompares.com/review/qnap-ts-464-nas-drive-review-hardware-heavy/ |
|
Update: I think I found the bug: |
|
Please pull https://github.com/0xGiddi/qnap8528/tree/ts-464 and try again |
|
There was a hardware refresh beginning of 2024. That might be when it changed. I can try the changes later today and report back. |
|
I have pushed all the changed to master branch and tag v1.2 if you want to work with the changed I'm adding to see if it will now work with no extra debugging steps. |
I was using the branch.
Oh I see, that makes sense. I expected something else to be exposed since I saw the bicolor_blink. This is fine for me. With v1.2: It still does not pass the initial probe with: I have not restarted the NAS after the previous testing. Currently, echoing 0 to the HDD LED caused it to go back to like it was before (green and blinking) and 1 caused it to go red. I think that is how it is intended and works well. Was there anything else you wanted me to test? Outside of needed to skip the hardware check, I am resolved with this issue. I'll leave the issue open to see if you needed any further follow ups/tests from me. |
|
I did not remove the ec check from the main branch, I will add more information in the supported models table and the install process for exceptions like the ts-464. Im happy everything is resolved, nothing else for now, I’ll keep the issue open just to remind me to go over everything and check that I have covered all things that came up either documentation. feel free to open another for any other problem and thank you for all the feedback. |
I was trying to build and install this on TrueNAS. I am using a privileged ubuntu docker container to build and
insmodthis driver.Once I build the
qnap8528.ko, I try toinsmod qnap8528.ko. This fails withDoes this mean the QNAP TS-464 does not use the embedded chip?
The text was updated successfully, but these errors were encountered: