[FreeBSD 5.4] kernel panic avec mon lecteur mp3/clé usb

In article <43468961$0$5380$8fcfb975@news.wanadoo.fr>, batyann811 wrote:

Bonjour,

Je viens d'installer FreeBSD 5.4 et impossible de faire fonctionner mon
lecteur mp3 usb. Dés que je le branche j'ai droit à une série de
messages comme celle-ci :

[snip]

Auriez vous une solution ?

Ben ... aller regarder du côté de

http://www.root.org/~nate/freebsd/quirks.html

En particulier les quirks pour scsi_da.c ...

C'est moche, mais ... par contre, moi avec une 5.4 (enfin une stable
de juste après la release) je n'ai plus les kernel panic (sauf avec
l'usb 2, mais les conditions de tests sont mauvaises ... )

--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)

Patrick Lamaizière wrote:

J'essaierais un quirk dans le genre de :
static struct da_quirk_entry da_quirk_table[] > {
[...]
{
/*
Quirk USB2.0 (FS) FLASH DISK 1.00
*/
{T_DIRECT, SIP_MEDIA_REMOVABLE, "USB2.0 (FS)" , "FLASH DISK",
"*"},
/*quirks*/ DA_Q_NO_SYNC_CACHE
},
[...]

Merci à toi et à Marwan Burelle pour vos réponses.

J'ai essayé ton bout de code mais ça ne change rien. Je vais encore
mener quelques essais avec le autres valeurs possibles pour le 'quirks'.
Mais vu qu'il y a 4 constantes à combiner ça fait beaucoup de
possibilités... Et en plus si ça se trouve il faut aussi toucher au
'umass.c'. J'y ai jetté un oeil vite fait et ça à l'air moins facile à
bidouiller. Le pire c'est que je ne suis même pas sûr que la
modification soit prise en compte vu que les messages du noyau sont
strictement les mêmes. Bref j'ai peur que ce ne soit pas gagné...

Patrick Lamaizière wrote:

Je me suis peut-être gouré dans la chaine, pour voir si le quirk pour
scci_da.c correspond tu peux mettre un espion pour être sûr.

Effectivement tu t'étais gouré dans la chaîne mais bon c'est un peu de ma
faute j'avais raté un double espace.

En tout cas pour mieux voir la chaîne j'ai ajouté ce code au moment de la
détection :

match = cam_quirkmatch((caddr_t)&cgd->inq_data,
(caddr_t)da_quirk_table,
sizeof(da_quirk_table)/sizeof(*da_quirk_table),
sizeof(*da_quirk_table), scsi_inquiry_match);

+++ printf("*** QUIRK !!! ***n");
+++ printf("vendor : <%s>n",(caddr_t)&cgd->inq_data.vendor);
+++ printf("product : <%s>n",(caddr_t)&cgd->inq_data.product);
+++ printf("revision : <%s>n",(caddr_t)&cgd->inq_data.revision);

+++ if (match != NULL) printf("*** DETECTE !!! ***n");

if (match != NULL)
softc->quirks = ((struct da_quirk_entry *)match)->quirks;
else
softc->quirks = DA_Q_NONE;

Cela m'a permis de récupérer les chaines permettant la reconnaissance de la
clé.

Et donc le code à rajouter est celui-ci :

/*
* Mpman MP-FUB30
*
*/
{T_DIRECT, SIP_MEDIA_REMOVABLE, "USB2.0*" ,
"(FS) FLASH DISK*", "*"},
/*quirks*/ DA_Q_NO_SYNC_CACHE

Et à présent ça marche.

Merci beaucoup.

In article <Xns56C9C6D8FF151plam@nulle.invalid>, Patrick Lamaizière wrote:

J'ai essayé en faisant une liste de quirks dynamiques et j'ajoute une
entrée qui match le périphérique avec un DA_Q_NO_SYNC_CACHE. L'ajout se
fait dans les "synchronized cache failed".

Hum, bonne idée et bonne nouvelle ;)

Donc la première fois ça ne marche pas, puis le quirk étant activé ça
marche après. Mais la machine est instable, j'ai l'impression que le
bus usb/scsi/cam est plus ou moins dans les choux après le premier
échec.

Sur quelle version ? Il y a déjà eu des progrès entre 5.3 et 5.4 (ou
5-STABLE peut de temps après je sais pas j'ai sauté la case 5.4), plus
de panic à l'ajout de la clef (sans le quirk), il y a peut être eu
d'autre amélioration (au hazard en 6 ?)

Sinon, d'ailleurs, des personnes ont eu des expériences positives en
USB 2 (en vrai usb 2, hein avec le support dans le noyeau est un
périph qui ne ment pas sur son débit comme mon lecteur de mp3) ?

Pour l'instant, j'ai soit mount qui ne rend jamais la main, soit
toujours mount mais qui provoque un reboot violent sans laisser de
trace derrière lui (le fourbe !) la seule différence entre les 2 cas,
c'est 3 ou 4 essaie en tant qu'utilisateur qui bloquaient suivie d'un
essaie en tant que root qui provoquait le reboot ... (5-STABLE juste
après 5.4, pas encore eu le temps de faire un cvsup ... )

--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)