Caricamento di un modulo compilato manda in freeze il sistema. Suggerimenti?

[Homer314]

Ciao ragazzi,

ho un decoder su piattaforma mips (unixbox hd1) di cui il produttore ha rilasciato i sorgenti. Ho compilato il modulo da caricare per far girare una mia chiavetta wi-fi ASUS n13 basata sul rlt8192cu.

La compilazione avviene senza errori, ma:

- con chiavetta collegata, carico il modulo tramite insmod ed il sistema freeza dopo pochi secondi

- con chiavetta scollegata, carico il modulo, dmesg dice che il driver è caricato senza problemi, ma collegando la chiavetta il sistema freeza.

Avete suggerimenti in merito ?

Il sistema è molto minimale, non so nemmeno come fare debug per ottenere informazioni dopo il freeze

Grazie :)

[Gimli[2BV!2B]]

Se ti colleghi al sistema tramite ssh e non vedi nessun messaggio potresti riuscire ad ottenere qualche informazione in più collegandoti alla seriale mentre il kernel si pianta.il decoder ha una porta seriale RS-232 a 9 pin con lo stesso pinout di quella di un PC (e’ quindi richiesto l’uso di un cavo null-modem), sulla quale e’ girato l’output del bootloader (U-Boot) e del kernel. (http://www.hacklabproject.org/blog/2012/09/unixbox-hd1/)Qui sono elencati i parametri di connessione: (http://www.eurosat-online.it/articoli/0,1254,39_ART_9493,00.html)

Collegare il ricevitore al PC tramite cavo nullmodem.
Lanciare il programma Hyperterminal e impostare una comunicazione seriale sulla porta dove è collegato il cavo null-modem con i seguenti parametri:

Bit per secondo: 115200
Bit di dati: 8
Parità: nessuno
Bit di stop: 1
Controllo di flusso: nessuno.

[Homer314]

;38399521']Se ti colleghi al sistema tramite ssh e non vedi nessun messaggio potresti riuscire ad ottenere qualche informazione in più collegandoti alla seriale mentre il kernel si pianta.[/URL][URL="http://www.eurosat-online.it/articoli/0,1254,39_ART_9493,00.html"]Qui sono elencati i parametri di connessione: (http://www.hacklabproject.org/blog/2012/09/unixbox-hd1/)

Collegare il ricevitore al PC tramite cavo nullmodem.
Lanciare il programma Hyperterminal e impostare una comunicazione seriale sulla porta dove è collegato il cavo null-modem con i seguenti parametri:

Bit per secondo: 115200
Bit di dati: 8
Parità: nessuno
Bit di stop: 1
Controllo di flusso: nessuno.



Gentilissimo, domani proverò se rimedio un cavo seriale :D

[Homer314]

ecco il log da seriale dal caricamento del modulo al kernel panic


rtw driver version=v3.4.4_xxxx.20120730
Build at: Nov 1 2012 10:22:38
usbcore: registered new interface driver rtl8192cu
usb 1-1.3: new high speed USB device using pnx833x-ehci and address 3
usb 1-1.3: configuration #1 chosen from 1 choice
CHIP TYPE: RTL8188C_8192C

usb_endpoint_descriptor(0):
bLength=7
bDescriptorType=5
bEndpointAddress=81
wMaxPacketSize=200
bInterval=0
RT_usb_endpoint_is_bulk_in = 1

usb_endpoint_descriptor(1):
bLength=7
bDescriptorType=5
bEndpointAddress=2
wMaxPacketSize=200
bInterval=0
RT_usb_endpoint_is_bulk_out = 2

usb_endpoint_descriptor(2):
bLength=7
bDescriptorType=5
bEndpointAddress=3
wMaxPacketSize=200
bInterval=0
RT_usb_endpoint_is_bulk_out = 3

usb_endpoint_descriptor(3):
bLength=7
bDescriptorType=5
bEndpointAddress=84
wMaxPacketSize=40
bInterval=1
RT_usb_endpoint_is_int_in = 4, Interval = 1
nr_endpoint=4, in_num=2, out_num=2

USB_SPEED_HIGH
Chip Version ID: VERSION_NORMAL_TSMC_CHIP_92C.
RF_Type is 2!!
EEPROM type is E-FUSE
====> ReadAdapterInfo8192C
Boot from EFUSE, Autoload OK !
EEPROMVID = 0x0b05
EEPROMPID = 0x17ab
EEPROMCustomerID : 0x00
EEPROMSubCustomerID: 0x00
RT_CustomerID: 0x00
_ReadMACAddress MAC Address from EFUSE = 30:85:a9:37:0d:42
EEPROMRegulatory = 0x0
_ReadBoardType(0)
BT Coexistance = disable
RT_ChannelPlan: 0x02
_ReadPSSetting...bHWPwrPindetect(0)-bHWPowerdown(0) ,bSupportRemoteWakeup(0)
### PS params=> power_mgnt(1),usbss_enable(0) ###
### AntDivCfg(0)
readAdapterInfo_8192CU(): REPLACEMENT = 1
<==== ReadAdapterInfo8192C in 576 ms
rtw_macaddr_cfg MAC Address = 30:85:a9:37:0d:42
MAC Address from pnetdev->dev_addr= 30:85:a9:37:0d:42
bDriverStopped:1, bSurpriseRemoved:0, bup:0, hw_init_completed:0
+871x_drv - drv_open, bup=0
===> FirmwareDownload91C() fw:Rtl819XFwImageArray_TSMC
FirmwareDownload92C accquire FW from embedded image
fw_ver=v80, fw_subver=0, sig=0x88c0
fw download ok!
Set RF Chip ID to RF_6052 and RF type to 2.
IQK:Start!!!
Path A IQK Success!!
Path B IQK Success!!
Path A IQK Success!!
Path B IQK Success!!
IQK: final_candidate is 0
IQK: RegE94=ff RegE9C=4 RegEA4=f9 RegEAC=3 RegEB4=103 RegEBC=d RegEC4=f9 RegECC=0
Path A IQ Calibration Success !
Path B IQ Calibration Success !
pdmpriv->TxPowerTrackControl = 1
MAC Address from REG_MACID = 30:85:a9:37:0d:42
rtl8192cu_hal_init in 1112ms
MAC Address = 30:85:a9:37:0d:42
-871x_drv - drv_open, bup=1
skb_over_panic: text:8473e948 len:290 put:290 head:846e8008 data:846e8010 tail:0x846e8010 end:0x846e8fc0 dev:wlan0
Break instruction in kernel code[#1]:
Cpu 0
$ 0 : 00000000 80380000 00000076 00000001
$ 4 : 8900b488 89019f8c 00000c31 00000067
$ 8 : 00000000 8038dad0 feced300 ffffffff
$12 : 35a5d200 00000067 8038dab0 00000001
$16 : c01bc410 c01bc370 c01bb000 85400e00
$20 : a9189200 a9186398 891576d0 00000001
$24 : 8038dad0 0000086f
$28 : 80348000 80349cc0 a918924c 8021c9e8
Hi : 0000086f
Lo : 724c6000
epc : 8021c9e8 skb_over_panic+0x50/0x98 Tainted: P
ra : 8021c9e8 skb_over_panic+0x50/0x98
Status: 10009002 KERNEL EXL
Cause : 10800024
PrId : 00019068 (MIPS 4KEc)
Modules linked in: 8192cu fuse usbhid hid tda10024 phStbDemux833x(P) phStbDemux dvb_core tda10071p(P) cx24116p(P) tda10048 phStbAlsa snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_page_alloc snd_mixer_oss snd soundcore tntfs(P) phStbRtc rtc_core phStbSmc(P) 8712u rt3070sta phStbWmdrmPd(P) phStbKey phStbIR phStbRCProtocol(P) phStbGpio(P) phStbFB phStbVo(P) phStbVideoRenderer(P) phStbDraw(P) phStbMmio phStbRSServer(P) phStbCore(P) phStbIpc tda9983(P) phStbHdmi zd1211rw ieee80211softmac ieee80211 ieee80211_crypt rt73usb rt2x00usb rt2x00lib crc_ccitt crc_itu_t mac80211 cfg80211 rfkill_backport compat_firmware_class compat phStbNetDev phStbKBufMgr(P) phStbOsal phKernelIfce phStbDbg evdev
Process swapper (pid: 0, threadinfo=80348000, task=8034a160)
Stack : 893978c0 8473e948 00000122 00000122 846e8008 846e8010 846e8010 846e8fc0
8574fc00 87cd1208 8473e960 87cd1214 8001cb28 00000000 00000001 29be53ad
846e6000 00000000 846e6000 00000000 a9189200 a9186398 801e838c 00000004
90000000 8001e744 00000001 8038da80 89157600 00000000 801f8a10 88629ea4
0000001c 89362e90 00000000 00000816 a9186300 a91862a0 846e6080 801f9f18
...
Call Trace:
[<8021c9e8>] skb_over_panic+0x50/0x98
[<8473e960>] usb_read_port_complete+0x11c/0x304 [8192cu]
[<801e838c>] usb_hcd_giveback_urb+0x54/0x120
[<801f8a10>] ehci_urb_done+0x90/0xf0
[<801f9f18>] qh_completions+0x98/0x4dc
[<801fa678>] ehci_work+0x31c/0x9a0
[<801fe6b0>] ehci_irq+0x1dc/0x280
[<801e9fc4>] usb_hcd_irq+0x4c/0xf8
[<800566c4>] handle_IRQ_event+0x5c/0xb4
[<80058520>] handle_simple_irq+0x9c/0x134
[<80001fa8>] pic_dispatch+0x94/0x194
[<80003260>] ret_from_irq+0x0/0x4
[<80002d38>] r4k_wait+0x4/0xc
[<80005688>] cpu_idle+0x40/0x78
[<80367c34>] start_kernel+0x2f4/0x354


Code: afa8001c 0c009349 afa30020 <0200000d> 8fbf0028 03e00008 27bd0030 3c028032 3c048033
......tmdlAudioIO IsrIdle, I2S_0, data in [0] ? pOut->pCur=0x8568b790 pOut->pNxt=0x8568b890 pCur->size=0x6000 pNxt->size=0x7020
......tmdlAudioIO IsrIdle, I2S_0, data in [1] ? pOut->pCur=0x8568b790 pOut->pNxt=0x8568b890 pCur->size=0x6000 pNxt->size=0x7020
Kernel panic - not syncing: Fatal exception in interrupt


Che ne dite ?

[Gimli[2BV!2B]]

Versione del kernel? Possibilità di aggiornamento?

Prima di scatenare l'errore, potresti provare ad aumentare la verbosità dell'output a KERN_DEBUG?echo 8 > /proc/sys/kernel/printkNel codice vedo varie righe che dovrebbero dare informazioni di debug.
Potresti ottenere molto output.

Ciò che lancia il panic sembra essere l'handler contenuto nel driver (usb_read_port_complete in hal/rtl8192c/usb/usb_ops_linux.c) a cui viene dato il controllo alla fine di una lettura sulla porta USB.
Diversa cosa è capire cosa lo provoca...static void usb_read_port_complete(struct urb *purb, struct pt_regs *regs)
{
struct recv_buf *precvbuf = (struct recv_buf *)purb->context;
_adapter *padapter =(_adapter *)precvbuf->adapter;
struct recv_priv *precvpriv = &padapter->recvpriv;

RT_TRACE(_module_hci_ops_os_c_,_drv_err_,("usb_read_port_complete!!!\n"));

precvpriv->rx_pending_cnt --;

if(padapter->bSurpriseRemoved || padapter->bDriverStopped||padapter->bReadPortCancel)
{
RT_TRACE(_module_hci_ops_os_c_,_drv_err_,("usb_read_port_complete:bDriverStopped(%d) OR bSurpriseRemoved(%d)\n", padapter->bDriverStopped, padapter->bSurpriseRemoved));

goto exit;
}

if(purb->status==0)//SUCCESS
{
if ((purb->actual_length > MAX_RECVBUF_SZ) || (purb->actual_length < RXDESC_SIZE))
{
RT_TRACE(_module_hci_ops_os_c_,_drv_err_,("usb_read_port_complete: (purb->actual_length > MAX_RECVBUF_SZ) || (purb->actual_length < RXDESC_SIZE)\n"));

rtw_read_port(padapter, precvpriv->ff_hwaddr, 0, (unsigned char *)precvbuf);
}
else
{
rtw_reset_continual_urb_error(&padapter->dvobjpriv);

precvbuf->transfer_len = purb->actual_length;

//rtw_enqueue_rx_transfer_buffer(precvpriv, rx_transfer_buf);
rtw_enqueue_recvbuf(precvbuf, &precvpriv->recv_buf_pending_queue);

tasklet_schedule(&precvpriv->recv_tasklet);
}
}
else
{
RT_TRACE(_module_hci_ops_os_c_,_drv_err_,("usb_read_port_complete : purb->status(%d) != 0 \n", purb->status));

DBG_8192C("###=> usb_read_port_complete => urb status(%d)\n", purb->status);

if(rtw_inc_and_chk_continual_urb_error(&padapter->dvobjpriv) == _TRUE ){
padapter->bSurpriseRemoved = _TRUE;
}

switch(purb->status) {
case -EINVAL:
case -EPIPE:
case -ENODEV:
case -ESHUTDOWN:
//padapter->bSurpriseRemoved=_TRUE;
RT_TRACE(_module_hci_ops_os_c_,_drv_err_,("usb_read_port_complete:bSurpriseRemoved=TRUE\n"));
case -ENOENT:
padapter->bDriverStopped=_TRUE;
RT_TRACE(_module_hci_ops_os_c_,_drv_err_,("usb_read_port_complete:bDriverStopped=TRUE\n"));
break;
case -EPROTO:
#ifdef DBG_CONFIG_ERROR_DETECT
{
HAL_DATA_TYPE *pHalData = GET_HAL_DATA(padapter);
pHalData->srestpriv.Wifi_Error_Status = USB_READ_PORT_FAIL;
}
#endif
rtw_read_port(padapter, precvpriv->ff_hwaddr, 0, (unsigned char *)precvbuf);
break;
case -EINPROGRESS:
DBG_8192C("ERROR: URB IS IN PROGRESS!/n");
break;
default:
break;
}

}

exit:

_func_exit_;

}Con verbosità debug ogni RT_TRACE dovrebbe stampare il relativo messaggio.
Leggiucchiando il codice direi che potrebbero essere andate storte molte cose... a meno che non sia uno stupido errore che avviene nella stessa funzione a scatenare il disastro.

[Homer314]

;38405665']Versione del kernel? Possibilità di aggiornamento?

Prima di scatenare l'errore, potresti provare ad aumentare la verbosità dell'output a KERN_DEBUG?


Con verbosità debug ogni RT_TRACE dovrebbe stampare il relativo messaggio.
Leggiucchiando il codice direi che potrebbero essere andate storte molte cose... a meno che non sia uno stupido errore che avviene nella stessa funzione a scatenare il disastro.

Per prima cosa grazie mille per il supporto, purtroppo sulla gestione e debug del kernel non sono proprio ferrato.

La macchina è un decoder con kernel 2.6.24.7 su piattaforma nxp (mips) di cui il produttore ha rilasciato i sorgenti solo per la versione sopra citata. Non vorrei addentrarmi nel flash di un kernel da me compilato per paura di brickare il dispositivo.

In serata effettuerò una nuova prova con il debug del kernel abilitato.

Grazie mille nuovamente.

[Gimli[2BV!2B]]

La macchina è un decoder con kernel 2.6.24.7 su piattaforma nxp (mips) di cui il produttore ha rilasciato i sorgenti solo per la versione sopra citata. Non vorrei addentrarmi nel flash di un kernel da me compilato per paura di brickare il dispositivo.Immaginavo. Per lo meno la versione rientra nel range che alla Realtek dichiarano supportato: 2.6.18 ~ 2.6.38 and kernel 3.0.8 (nel file ReleaseNotes.pdf)

[Homer314]

Si per fortuna avevo già verificato, seguiranno aggiornamenti domenica quando avrò modo di maltrattare nuovamente la macchina.

Nuovamente grazie mille per il supporto!

Inviato dal mio Galaxy Nexus con Tapatalk 2

[Homer314]

Peccato, il log generato dopo aver attivato i messaggi di debug come suggerito è esattamente identico, sintomo che il kernel è stato compilato senza implementare appunto la funzione di "traduzione degli errori" immagino vero ?

Se non esiste altro modo di capire la causa del problema proverò a compilare il kernel abilitando il debugging

Grazie mille nuovamente per il supporto!

[Gimli[2BV!2B]]

Analizzando con più attenzione la definizione di RT_TRACE#if defined (_dbgdump) && defined (_MODULE_DEFINE_)

#undef RT_TRACE
#define RT_TRACE(_Comp, _Level, Fmt)\
do {\
if((_Comp & GlobalDebugComponents) && (_Level <= GlobalDebugLevel)) {\
_dbgdump("%s [0x%08x,%d]", RTL871X_MODULE_NAME, (unsigned int)_Comp, _Level);\
_dbgdump Fmt; \
}\
}while(0)

#endif(passando poi per core/rtw_debug.c, dove le due variabili evidenziate sono valorizzate) credo di averne tracciato l'abilitazione ad un solo particolare define da abilitare nel file include/autoconf.h, alla riga 256:
/*
* Debug Related Config
*/
//#define CONFIG_DEBUG_RTL871X

#define DBG 0
#define CONFIG_DEBUG_RTL819XDovresti togliere i due slash che lo precedono per attivarlo:/*
* Debug Related Config
*/
#define CONFIG_DEBUG_RTL871X

#define DBG 0
#define CONFIG_DEBUG_RTL819XDopodiché occorrerà ricompilare il driver, reinstallarlo e riprovare con il livello di debug della console ad 8.

[Homer314]

;38414799']Analizzando con più attenzione la definizione di RT_TRACE#if defined (_dbgdump) && defined (_MODULE_DEFINE_)

#undef RT_TRACE
#define RT_TRACE(_Comp, _Level, Fmt)\
do {\
if((_Comp & GlobalDebugComponents) && (_Level <= GlobalDebugLevel)) {\
_dbgdump("%s [0x%08x,%d]", RTL871X_MODULE_NAME, (unsigned int)_Comp, _Level);\
_dbgdump Fmt; \
}\
}while(0)

#endif(passando poi per core/rtw_debug.c, dove le due variabili evidenziate sono valorizzate) credo di averne tracciato l'abilitazione ad un solo particolare define da abilitare nel file include/autoconf.h, alla riga 256:
/*
* Debug Related Config
*/
//#define CONFIG_DEBUG_RTL871X

#define DBG 0
#define CONFIG_DEBUG_RTL819XDovresti togliere i due slash che lo precedono per attivarlo:/*
* Debug Related Config
*/
#define CONFIG_DEBUG_RTL871X

#define DBG 0
#define CONFIG_DEBUG_RTL819XDopodiché occorrerà ricompilare il driver, reinstallarlo e riprovare con il livello di debug della console ad 8.

quindi responsabile della verbosità dell'output è anche il componente caricato...ottimo. Provvedo a ricompilare e domani ri-uccido l'apparato :D

[rinoronie]

qualcuno utilizza ancora questo decoder? sto cercando disperatamente un telecomando...