|
|||||||
|
|
|
 |
|
|
Strumenti |
31-10-2012, 11:58
|
#1 |
|
Senior Member
Iscritto dal: Jan 2003
Città: Ostia (mare de Roma) ---------------------- Transazioni: tante ! FeedBack: 100%
Messaggi: 6016
|
Caricamento di un modulo compilato manda in freeze il sistema. Suggerimenti?
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 
__________________
- cu - |
|
|
|
31-10-2012, 20:51
|
#2 | |
|
Senior Member
![L'Avatar di Gimli[2BV!2B]](customavatars/avatar128392_3.gif){kind=avatar}
Iscritto dal: Feb 2006
Città: Parma
Messaggi: 3008
|
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.
Quote:
__________________
~Breve riferimento ai comandi GNU/Linux (ormai non molto breve...) |
|
|
|
|
|
31-10-2012, 21:43
|
#3 | |
|
Senior Member
Iscritto dal: Jan 2003
Città: Ostia (mare de Roma) ---------------------- Transazioni: tante ! FeedBack: 100%
Messaggi: 6016
|
Quote:
__________________
- cu - |
|
|
|
|
|
01-11-2012, 20:26
|
#4 | |
|
Senior Member
Iscritto dal: Jan 2003
Città: Ostia (mare de Roma) ---------------------- Transazioni: tante ! FeedBack: 100%
Messaggi: 6016
|
ecco il log da seriale dal caricamento del modulo al kernel panic
Quote:
__________________
- cu - |
|
|
|
|
|
02-11-2012, 01:53
|
#5 |
|
Senior Member
Iscritto dal: Feb 2006
Città: Parma
Messaggi: 3008
|
Versione del kernel? Possibilità di aggiornamento?
Prima di scatenare l'errore, potresti provare ad aumentare la verbosità dell'output a KERN_DEBUG? Codice:
echo 8 > /proc/sys/kernel/printk 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... Codice:
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_;
}
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.
__________________
~Breve riferimento ai comandi GNU/Linux (ormai non molto breve...) |
|
|
|
|
02-11-2012, 06:27
|
#6 | |
|
Senior Member
Iscritto dal: Jan 2003
Città: Ostia (mare de Roma) ---------------------- Transazioni: tante ! FeedBack: 100%
Messaggi: 6016
|
Quote:
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.
__________________
- cu - |
|
|
|
|
|
02-11-2012, 13:31
|
#7 | |
|
Senior Member
Iscritto dal: Feb 2006
Città: Parma
Messaggi: 3008
|
Quote:
__________________
~Breve riferimento ai comandi GNU/Linux (ormai non molto breve...) |
|
|
|
|
|
02-11-2012, 16:46
|
#8 |
|
Senior Member
Iscritto dal: Jan 2003
Città: Ostia (mare de Roma) ---------------------- Transazioni: tante ! FeedBack: 100%
Messaggi: 6016
|
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
__________________
- cu - |
|
|
|
|
03-11-2012, 15:06
|
#9 |
|
Senior Member
Iscritto dal: Jan 2003
Città: Ostia (mare de Roma) ---------------------- Transazioni: tante ! FeedBack: 100%
Messaggi: 6016
|
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!
__________________
- cu - |
|
|
|
|
03-11-2012, 16:02
|
#10 |
|
Senior Member
Iscritto dal: Feb 2006
Città: Parma
Messaggi: 3008
|
Analizzando con più attenzione la definizione di RT_TRACE
Codice:
#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
Codice:
/* * Debug Related Config */ //#define CONFIG_DEBUG_RTL871X #define DBG 0 #define CONFIG_DEBUG_RTL819X Codice:
/* * Debug Related Config */ #define CONFIG_DEBUG_RTL871X #define DBG 0 #define CONFIG_DEBUG_RTL819X
__________________
~Breve riferimento ai comandi GNU/Linux (ormai non molto breve...) |
|
|
|
|
03-11-2012, 16:33
|
#11 | |
|
Senior Member
Iscritto dal: Jan 2003
Città: Ostia (mare de Roma) ---------------------- Transazioni: tante ! FeedBack: 100%
Messaggi: 6016
|
Quote:
__________________
- cu - |
|
|
|
|
|
04-11-2013, 17:25
|
#12 |
|
Member
Iscritto dal: Nov 2012
Messaggi: 34
|
qualcuno utilizza ancora questo decoder? sto cercando disperatamente un telecomando...
|
|
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 02:16.
