Open briansune opened 4 weeks ago
dubhater
commented
4 weeks ago Sadly Larry died this summer.
[ 4208.021498] rtw_8723du 1-1:1.2: failed to allocate rx_skb
This is an old problem that only recently got an error message. A patch is available here: https://github.com/lwfinger/rtw88/issues/205#issuecomment-2437776828
For the random "failed to get tx report from firmware", try to load rtw_core with debug_mask=0x10. This may add some useful information to the log.
briansune
commented
3 weeks ago @dubhater
I don't even notice Larry referring to lwfinger had passed away. Sad, although we were not able to resolve the blank-chip firmware issue at the pass, yet he is still a very nice guy on assisting.
I will give it a try and pass out some logs.
Thanks again.
briansune
commented
3 weeks ago @dubhater
No luck, the memory stress test immediately trigger the issue
briansune
commented
3 weeks ago @dubhater
Good news is that the driver didn't crash and ping can keep run after those fail reports. I had undergo another short test dmesg as follows:
dubhater
commented
3 weeks ago The timing here is interesting:
[ 8856.551252] rtw_8723du 1-1:1.2: recv C2H, id=0x03, seq=0x24, len=8
[ 8857.061876] rtw_8723du 1-1:1.2: failed to get tx report from firmware[ 8911.866562] rtw_8723du 1-1:1.2: recv C2H, id=0x03, seq=0x44, len=8
...
[ 8912.388721] rtw_8723du 1-1:1.2: failed to get tx report from firmwareC2H with id=0x03 is the TX report. "failed to get tx report from firmware" is a bit misleading. It's possible the firmware did send the TX report but the driver received it earlier than expected. I think this can happen with rtw_usb. We need more information:
diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
index 215bfd731235..8994f316f367 100644
--- a/drivers/net/wireless/realtek/rtw88/tx.c
+++ b/drivers/net/wireless/realtek/rtw88/tx.c
@@ -181,11 +181,12 @@ void rtw_tx_report_purge_timer(struct timer_list *t)
struct rtw_dev *rtwdev = from_timer(rtwdev, t, tx_report.purge_timer);
struct rtw_tx_report *tx_report = &rtwdev->tx_report;
unsigned long flags;
+ u32 len = skb_queue_len(&tx_report->queue);
- if (skb_queue_len(&tx_report->queue) == 0)
+ if (len == 0)
return;
- rtw_warn(rtwdev, "failed to get tx report from firmware\n");
+ rtw_warn(rtwdev, "still have %u unprocessed tx report requests\n", len);
spin_lock_irqsave(&tx_report->q_lock, flags);
skb_queue_purge(&tx_report->queue);
@@ -214,6 +215,7 @@ void rtw_tx_report_enqueue(struct rtw_dev *rtwdev, struct sk_buff *skb, u8 sn)
/* pass sn to tx report handler through driver data */
drv_data = (u8 *)IEEE80211_SKB_CB(skb)->status.status_driver_data;
*drv_data = sn;
+pr_err("queueing tx report request with sn %d\n", sn);
spin_lock_irqsave(&tx_report->q_lock, flags);
__skb_queue_tail(&tx_report->queue, skb);
@@ -256,6 +258,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
sn = GET_CCX_REPORT_SEQNUM_V1(c2h->payload);
st = GET_CCX_REPORT_STATUS_V1(c2h->payload);
}
+pr_err("received tx report with sn %d\n", sn);
spin_lock_irqsave(&tx_report->q_lock, flags);
skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
You don't need debug_mask anymore.
briansune
commented
3 weeks ago @dubhater
It feels like the TX issue had gone, if I am understanding correctly the message is just a timing issue.
After a very short test it feels like the "failed to allocate rx_skb #" still can trigger easily.
How I am triggering this is undergo a system stress test on main-memory. Always can trigger this on running stressapptest
ubuntu@briansune:~$ cat ./tests.sh
#!/bin/bash
echo "start tests"
while true
do
ping -c 4 8.8.8.8
free -h
stressapptest -s 60
free -h
sudo memtester 200M 1
doneThe main-memory is:
total used free shared buff/cache available
Mem: 487Mi 70Mi 256Mi 0.0Ki 159Mi 404Mi
Swap: 1.0Gi 0B 1.0Gi@dubhater
Bad news, I just discover a couples of TX issue.
dubhater
commented
3 weeks ago After a very short test it feels like the "failed to allocate rx_skb #" still can trigger easily.
Yes, that's normal. The memory allocation sometimes fails, but it's retried. I will remove the message eventually.
This latest log makes me think you're seeing the same bug I ran into and fixed recently. I haven't published the fix yet. But to confirm, you should apply that patch I gave you above and let it run for a while.
briansune
commented
3 weeks ago @dubhater
Those two dmesg had already applied the patch you gave me from It is recompiled and replaced accordingly.
The timing here is interesting:
[ 8856.551252] rtw_8723du 1-1:1.2: recv C2H, id=0x03, seq=0x24, len=8 [ 8857.061876] rtw_8723du 1-1:1.2: failed to get tx report from firmware[ 8911.866562] rtw_8723du 1-1:1.2: recv C2H, id=0x03, seq=0x44, len=8 ... [ 8912.388721] rtw_8723du 1-1:1.2: failed to get tx report from firmwareC2H with id=0x03 is the TX report. "failed to get tx report from firmware" is a bit misleading. It's possible the firmware did send the TX report but the driver received it earlier than expected. I think this can happen with rtw_usb. We need more information:
diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c index 215bfd731235..8994f316f367 100644 --- a/drivers/net/wireless/realtek/rtw88/tx.c +++ b/drivers/net/wireless/realtek/rtw88/tx.c @@ -181,11 +181,12 @@ void rtw_tx_report_purge_timer(struct timer_list *t) struct rtw_dev *rtwdev = from_timer(rtwdev, t, tx_report.purge_timer); struct rtw_tx_report *tx_report = &rtwdev->tx_report; unsigned long flags; + u32 len = skb_queue_len(&tx_report->queue); - if (skb_queue_len(&tx_report->queue) == 0) + if (len == 0) return; - rtw_warn(rtwdev, "failed to get tx report from firmware\n"); + rtw_warn(rtwdev, "still have %u unprocessed tx report requests\n", len); spin_lock_irqsave(&tx_report->q_lock, flags); skb_queue_purge(&tx_report->queue); @@ -214,6 +215,7 @@ void rtw_tx_report_enqueue(struct rtw_dev *rtwdev, struct sk_buff *skb, u8 sn) /* pass sn to tx report handler through driver data */ drv_data = (u8 *)IEEE80211_SKB_CB(skb)->status.status_driver_data; *drv_data = sn; +pr_err("queueing tx report request with sn %d\n", sn); spin_lock_irqsave(&tx_report->q_lock, flags); __skb_queue_tail(&tx_report->queue, skb); @@ -256,6 +258,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src) sn = GET_CCX_REPORT_SEQNUM_V1(c2h->payload); st = GET_CCX_REPORT_STATUS_V1(c2h->payload); } +pr_err("received tx report with sn %d\n", sn); spin_lock_irqsave(&tx_report->q_lock, flags); skb_queue_walk_safe(&tx_report->queue, cur, tmp) {You don't need debug_mask anymore.
briansune
commented
3 weeks ago @dubhater
I had run a longer test the log is attached here:
dubhater
commented
3 weeks ago But you didn't apply the patch with the extra logging. It changes "failed to get tx report from firmware" into a different message.
briansune
commented
3 weeks ago @dubhater
Real sorry didn't notice the clean is missing at the beginning of the build and result in such situation.
The new log is attached. I didn't run any scripts or action and had suddenly burst a lot of TX reports
briansune
commented
3 weeks ago @dubhater
Attaching a longer dmesg with stressapptest and memtester and ping running.
briansune
commented
3 weeks ago @dubhater
Had successfully trigger the "still have error" message. I run ping /w 500ms to 8.8.8.8 and concurrently run the stressapptest or memtester background.
dubhater
commented
3 weeks ago As I suspected, that's the bug I fixed recently. The firmware can't always handle many TX report requests in a short time. I pushed the fix.
briansune
commented
3 weeks ago @dubhater
Yes after the study on the log it feels like the get and give is out of order when messed up and even get lossed ordering. How do you fixed this? Increase the buffer size or making a pending state?
briansune
commented
3 weeks ago @dubhater
This is the log after modifying those area you had committed. Looks like no more missing requests.
But the "tw_8723du 1-1:1.2: failed to allocate rx_skb #" is still problematic. What do rx_skb really related to?
dubhater
commented
3 weeks ago It's a buffer for the RX data. The problem seems to be that it's kinda large (32 KiB) and the system doesn't always have that much contiguous memory. So when the allocation fails it tries again a little later.
briansune
commented
3 weeks ago @dubhater
Do you suggesting I need to increase the kernel cma settings?
briansune
commented
3 weeks ago @dubhater
I guess this log explain a lot why it is happening
Before driver load:
ubuntu@briansune:~$ cat /proc/meminfo | grep -i cma CmaTotal: 131072 kB CmaFree: 130688 kB
Once I boot the system and loaded the driver.
ubuntu@briansune:~$ cat /proc/meminfo | grep -i cma CmaTotal: 131072 kB CmaFree: 123928 kB
Do stressapptest
ubuntu@briansune:~$ cat /proc/meminfo | grep -i cma CmaTotal: 131072 kB CmaFree: 0 kB
[ 187.249028] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.282255] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.282676] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.283374] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.283998] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.284413] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.462890] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.522025] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.522637] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.523249] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.528736] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.529277] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.627282] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.638228] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.640132] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.640322] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.640488] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.640746] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.641155] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 187.659589] rtw_8723du 1-1:1.2: failed to allocate rx_skb 0 [ 187.660307] rtw_8723du 1-1:1.2: failed to allocate rx_skb 0 [ 187.661244] rtw_8723du 1-1:1.2: failed to allocate rx_skb 0 [ 187.662094] rtw_8723du 1-1:1.2: failed to allocate rx_skb 0 [ 187.662990] rtw_8723du 1-1:1.2: failed to allocate rx_skb 0 [ 187.663722] rtw_8723du 1-1:1.2: failed to allocate rx_skb 0 [ 187.664481] rtw_8723du 1-1:1.2: failed to allocate rx_skb 0 [ 187.665299] rtw_8723du 1-1:1.2: failed to allocate rx_skb 0 [ 187.666069] rtw_8723du 1-1:1.2: failed to allocate rx_skb 0 [ 187.668687] rtw_8723du 1-1:1.2: failed to allocate rx_skb 0 [ 188.274820] rtw_8723du 1-1:1.2: failed to allocate rx_skb 3 [ 188.477803] rtw_8723du 1-1:1.2: failed to allocate rx_skb 1 [ 188.618862] rtw_8723du 1-1:1.2: failed to allocate rx_skb 2 [ 188.619015] rtw_8723du 1-1:1.2: failed to allocate rx_skb 2
So the question now back to why the CMA memory is not locked by the driver and allowing other application to use more than it allows?
Or at the state after the driver load it only use i.e. X size of memory and after other application is loaded Y size of memory is used. Turns out X+Y=MAX memory, however at that moment the driver request more than X and X+Y<=MAX so the rx_skb shows up?
dubhater
commented
3 weeks ago I don't think you need to do anything at this point. It's a problem in the driver. There is another problem which requires a small redesign of the RX code, so I will try to fix both at the same time.
dubhater
commented
3 weeks ago I pushed a fix for "failed to allocate rx_skb". I'm curious how it works with your stress tests.
briansune
commented
3 weeks ago @dubhater
Appreciate the great works. See the comments. I will schedule a test plane ASAP. Handout the testresult once it is completed.
Again speed and great work. =]
briansune
commented
3 weeks ago @dubhater
A quick compile shows:
/home/tg5/drr/rtw88/usb.c: In function 'rtw_usb_init_rx': ./include/linux/workqueue.h:241:17: error: assignment from incompatible pointer type [-Werror=incompatible-pointer-types] (_work)->func = (_func); \ ^ ./include/linux/workqueue.h:246:2: note: in expansion of macro '__INIT_WORK' __INIT_WORK((_work), (_func), 0) ^
~~/home/tg5/drr/rtw88/usb.c:956:2: note: in expansion of macro 'INIT_WORK' INIT_WORK(&rtwusb->rx_work, rtw_usb_rx_handler); ^~~~~ cc1: some warnings being treated as errors
dubhater
commented
3 weeks ago Oh, I forgot to disable that INIT_WORK. I'll fix it tomorrow.
briansune
commented
3 weeks ago @dubhater
Waiting on the instruction of the INIT_WORK. Thank you.
dubhater
commented
3 weeks ago I fixed it.
briansune
commented
3 weeks ago @dubhater
Had successfully build t he driver. Sounds like it is just a kernel version switch case for those lines. Pending on the hardware full stress test.
briansune
commented
3 weeks ago @dubhater
According to the previous repeatable fail skb behavior. It will always trigger on boot up with stressapptest immediately running and holds up all CMA memory.
As for the new push, Good result! Running both ping and memory stressapptest concurrently backgroundly. Doesn't trigger any RX skb fail and TX fail also no longer showing with a short test. Enclosing dmesg for reference.
Appreciate all the fixes. =]
briansune
commented
2 weeks ago @dubhater
Do you think the issue is settled? If so you can close this issue with a happy ending =]
dubhater
commented
2 weeks ago Yes, I think it's fixed.
briansune
commented
2 weeks ago @dubhater
I have a small following up question not sure why this is the case. Why the wlan name always replace as the mac?
dmesg
[ 14.872193] wlx90de80882cf1: authenticate with f8:6f:b0:0e:ae:e5 [ 14.872251] wlx90de80882cf1: 80 MHz not supported, disabling VHT [ 16.408568] wlx90de80882cf1: send auth to f8:6f:b0:0e:ae:e5 (try 1/3) [ 16.414224] wlx90de80882cf1: authenticated [ 16.415931] wlx90de80882cf1: associate with f8:6f:b0:0e:ae:e5 (try 1/3) [ 16.487030] wlx90de80882cf1: RX AssocResp from f8:6f:b0:0e:ae:e5 (capab=0x1411 status=0 aid=5) [ 16.505341] wlx90de80882cf1: associated [ 16.617380] wlx90de80882cf1: Limiting TX power to 35 (35 - 0) dBm as advertised by f8:6f:b0:0e:ae:e5
I have no idea is this related to the driver setting or not?
briansune
commented
2 weeks ago @dubhater
I am sorry that to reopen this issue due to today testing shows a puzzling TX dmesg "rtw_8723du 1-1:1.2: failed to get tx report from firmware" This issue is back and bayme excited on Christmas is coming soon =] Background info (only ping is kept pinging 8.8.8.8) No any memory stress test is running.
dubhater
commented
2 weeks ago The interface name is not related to the driver. It's renamed by udev, I think. Some distros configure it to use the MAC address, others the hardware location.
I wonder if you are somehow using an older version of the driver?
When you use debug_mask=0x10 how many c2h with ID 0x03 appear in a row?
briansune
commented
2 weeks ago @dubhater
Q1: I wonder if you are somehow using an older version of the driver? A1: No, I had clone the latest repository and compile (CLEAN).
T1: When you use debug_mask=0x10 how many c2h with ID 0x03 appear in a row? Will conduct and post the result ASAP.
briansune
commented
2 weeks ago @dubhater
I have no clue how to add the debug_mask=0x10. I need more guidance please. The different between previous test and current test is the driver is not a module based driver. I am compiling the kernel with a RTW88[y ] configuration from the make menuconfig. How could I add the flag to the make or kconfig file?
Thank you
dubhater
commented
2 weeks ago You can add it to the kernel's command line:
rtw_core.debug_mask=0x10 rtw88_core.debug_mask=0x10Add both versions because I'm not sure which is the right one when compiled in.
Since this is not a PC, I'm not sure exactly how to do it.
briansune
commented
2 weeks ago @dubhater
May I ask these flag is putting inside the RTW88 Makefile? Deep sorry only know very little kernel driver stuffs.
dubhater
commented
2 weeks ago The easier solution is to change the source code:
diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index 5e8baac2dfba..6d6038815c5a 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -23,7 +23,7 @@
bool rtw_disable_lps_deep_mode;
EXPORT_SYMBOL(rtw_disable_lps_deep_mode);
bool rtw_bf_support = true;
-unsigned int rtw_debug_mask;
+unsigned int rtw_debug_mask = 0x10;
EXPORT_SYMBOL(rtw_debug_mask);
/* EDCCA is enabled during normal behavior. For debugging purpose in
* a noisy environment, it can be disabled via edcca debugfs. Because@dubhater
Yes I do tried this method you posted the driver will not showup after doing such way. That's why I am asking how to do it in the makefile.
My message is a bit misleading. What I meant is the driver don't create those message like
sudo insmod core.ko debug_mask=0x10
dubhater
commented
2 weeks ago Sorry, I don't know.
briansune
commented
2 weeks ago @dubhater
I will try to make those message out. Not sure I can make that happen or not but try as much as I can. If I got those debug message out I will handout the dmesg. Again appreciate the help
briansune
commented
2 weeks ago @dubhater
I had successfully compile the kernel with the debug message. Modify the below is only part of the debug need to include those debug flags inside the makefile.
unsigned int rtw_debug_mask = 0x10;
I am reading those debug message and waiting on the fail message.
briansune
commented
2 weeks ago @dubhater
When the debug message is turned on and background is running ping the "failed to get tx report from firmware" not showing up at short test.
It appears that 3 repeated id 0x03.
briansune
commented
2 weeks ago @dubhater
Repeatable: I will describe as such. The system do not run any user task and just let it sit there after bootup. Then after a while the TX fail message comes out. If debug flag is turned on it will "NOT" able to trigger such behavior.
briansune
commented
2 weeks ago @dubhater
OK, I finally can grep it with a debug mask is turned on. When the debug mask flag is turned on it is very very very hard to trigger it and waited hours.
$ dmesg | grep fail [ 6319.638828] rtw_8723du 1-1:1.2: failed to get tx report from firmware [ 6389.460913] rtw_8723du 1-1:1.2: failed to get tx report from firmware [ 6495.698101] rtw_8723du 1-1:1.2: failed to get tx report from firmware [ 6608.335223] rtw_8723du 1-1:1.2: failed to get tx report from firmware [ 6619.598950] rtw_8723du 1-1:1.2: failed to get tx report from firmware [ 6658.509951] rtw_8723du 1-1:1.2: failed to get tx report from firmware [ 6718.316471] rtw_8723du 1-1:1.2: failed to get tx report from firmware [ 6727.340245] rtw_8723du 1-1:1.2: failed to get tx report from firmware [ 6729.324203] rtw_8723du 1-1:1.2: failed to get tx report from firmware
dubhater
commented
2 weeks ago Okay, so my fix is not enough. I will report the problem and we'll see what happens.
If you don't need to support roaming, you can disable the "bgscan" performed by wpa_supplicant. That will do a better job avoiding the problem than my fix did.
briansune
commented
2 weeks ago @dubhater
Would it possible to explain what is happening behind this issue? Sound like this is not what you can control. Because the system is completely sitting there doing nothing and turning out this would show up from time to time. Thank you
dubhater
commented
1 week ago Every five minutes wpa_supplicant triggers a scan, I assume to see if there are better APs available. During these scans mac80211 transmits many QoS Null frames in quick succession. Because these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88 asks the firmware to report the TX ACK status for each of these frames. Sometimes the firmware can't process the TX status requests quickly enough, they add up, it only processes some of them, and it permanently messes up the internal sequence number assigned to each TX status report. Then the firmware marks every subsequent TX status report with the wrong number, so rtw88 ignores them and prints a warning instead of reporting the TX status back to mac80211.
If the device is going to be connected to just one AP, you can disable the "bgscan" in wpa_supplicant.
briansune
commented
1 week ago @dubhater
Thank you for the explanation learn a lot =]
I may not have good enough knowledge to understand all the theory behind.
If my understand correctly: If the device using this driver need to move around such as in a office or some large area. The WIFI setup must undergo a numbers of AP on top of my head. Every time I move around the zone AP(1) ->AP(2) but the WIFI is still using the same SSID PASSWORD etc. So that what roaming you are meaning?
However, if the device using this driver is stationary and the same WIFI AP is the only one it is using. Then
bgscan
is not needed and it is completely fine to remove it.
Hope I am getting this correctly =]
@lwfinger @dubhater
We are using RTL8723DU USB dongle on UBUNTU LTS 20.04.2 LTS There are a lot of report on failed to get tx report from firmware. How could we resolve this issue? We do also see there are cases that the driver will crash.
What we had done to repeat the crash is undergo a memory stress test command.
While the fail to get tx report is randomly happened.
Attaching dmesg report below. Thank you
dmesg
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd040] [ 0.000000] Linux version 6.1.54-rt15 (tg5@tg5) (aarch64-linux-gnu-gcc (Linaro GCC 7.5-2019.12) 7.5.0, GNU ld (Linaro_Binutils-2019.12) 2.28.2.20170706) #8 SMP PREEMPT Thu Oct 31 07:04:49 HKT 2024 [ 0.000000] Machine model: Anlogic, DR1M90 FPSoc [ 0.000000] earlycon: uart0 at MMIO32 0x00000000f8401000 (options '') [ 0.000000] printk: bootconsole [uart0] enabled [ 0.000000] efi: UEFI not found. [ 0.000000] Reserved memory: created CMA memory pool at 0x0000000016400000, size 128 MiB [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000001fffffff] [ 0.000000] DMA32 empty [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x000000001fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000001fffffff] [ 0.000000] psci: probing for conduit method from DT. [ 0.000000] psci: PSCIv0.2 detected in firmware. [ 0.000000] psci: Using standard PSCI v0.2 function IDs [ 0.000000] psci: MIGRATE_INFO_TYPE not supported. [ 0.000000] percpu: Embedded 21 pages/cpu s46248 r8192 d31576 u86016 [ 0.000000] pcpu-alloc: s46248 r8192 d31576 u86016 alloc=21*4096 [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [ 0.000000] Detected VIPT I-cache on CPU0 [ 0.000000] CPU features: detected: GIC system register CPU interface [ 0.000000] alternatives: applying boot alternatives [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 129024 [ 0.000000] Kernel command line: console=ttyS0,115200n8 earlycon=uart,mmio32,0xf8401000 loglevel=8 root=/dev/mmcblk0p2 rootwait rootfstype=ext4 rw [ 0.000000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes, linear) [ 0.000000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Memory: 366092K/524288K available (10048K kernel code, 1384K rwdata, 3168K rodata, 1536K init, 581K bss, 27124K reserved, 131072K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [ 0.000000] rcu: Preemptible hierarchical RCU implementation. [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=2. [ 0.000000] Trampoline variant of Tasks RCU enabled. [ 0.000000] Tracing variant of Tasks RCU enabled. [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2 [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 [ 0.000000] GICv3: 160 SPIs implemented [ 0.000000] GICv3: 0 Extended SPIs implemented [ 0.000000] Root IRQ handler: gic_handle_irq [ 0.000000] GICv3: GICv3 features: 16 PPIs [ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x00000000dd040000 [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. [ 0.000000] arch_timer: cp15 timer(s) running at 33.33MHz (virt). [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x7b00c4bad, max_idle_ns: 440795202744 ns [ 0.000000] sched_clock: 56 bits at 33MHz, resolution 30ns, wraps every 2199023255551ns [ 0.008198] Console: colour dummy device 80x25 [ 0.012667] Calibrating delay loop (skipped), value calculated using timer frequency.. 66.66 BogoMIPS (lpj=133333) [ 0.022986] pid_max: default: 32768 minimum: 301 [ 0.027761] Mount-cache hash table entries: 1024 (order: 1, 8192 bytes, linear) [ 0.035057] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes, linear) [ 0.044141] cblist_init_generic: Setting adjustable number of callback queues. [ 0.051376] cblist_init_generic: Setting shift to 1 and lim to 1. [ 0.057515] cblist_init_generic: Setting adjustable number of callback queues. [ 0.064725] cblist_init_generic: Setting shift to 1 and lim to 1. [ 0.070953] rcu: Hierarchical SRCU implementation. [ 0.075743] rcu: Max phase no-delay instances is 1000. [ 0.081236] EFI services will not be available. [ 0.086013] smp: Bringing up secondary CPUs ... [ 0.091020] Detected VIPT I-cache on CPU1 [ 0.091113] GICv3: CPU1: found redistributor 1 region 0:0x00000000dd060000 [ 0.091159] CPU1: Booted secondary processor 0x0000000001 [0x411fd040] [ 0.091270] smp: Brought up 1 node, 2 CPUs [ 0.112735] SMP: Total of 2 processors activated. [ 0.117431] CPU features: detected: 32-bit EL0 Support [ 0.122575] CPU features: detected: CRC32 instructions [ 0.127769] CPU: All CPU(s) started at EL1 [ 0.131856] alternatives: applying system-wide alternatives [ 0.138336] devtmpfs: initialized [ 0.145713] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.155442] futex hash table entries: 512 (order: 3, 32768 bytes, linear) [ 0.167006] DMI not present or invalid. [ 0.171516] NET: Registered PF_NETLINK/PF_ROUTE protocol family [ 0.178488] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations [ 0.185604] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations [ 0.193421] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations [ 0.201378] audit: initializing netlink subsys (disabled) [ 0.206938] audit: type=2000 audit(0.136:1): state=initialized audit_enabled=0 res=1 [ 0.207409] thermal_sys: Registered thermal governor 'fair_share' [ 0.214666] thermal_sys: Registered thermal governor 'bang_bang' [ 0.220741] thermal_sys: Registered thermal governor 'step_wise' [ 0.227030] ASID allocator initialised with 65536 entries [ 0.253509] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages [ 0.260318] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page [ 0.266570] HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages [ 0.273339] HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page [ 0.279589] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages [ 0.286352] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page [ 0.292600] HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages [ 0.299364] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page [ 0.306597] dw_dmac f804d000.ahb_dma: WARN: Device release is not defined so it is not safe to unbind this driver while in use [ 0.318459] dw_dmac f804d000.ahb_dma: DesignWare DMA Controller, 8 channels [ 0.326107] SCSI subsystem initialized [ 0.330081] usbcore: registered new interface driver usbfs [ 0.335609] usbcore: registered new interface driver hub [ 0.340940] usbcore: registered new device driver usb [ 0.346791] pps_core: LinuxPPS API ver. 1 registered [ 0.351747] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti