Bonjour à tous,
Voila j'ai deux petits problèmes de devices sous FreeBSD 5.3.
Tout d'abord après avoir ajouté le son à mon pc portable avec les
drivers snd_ich j'ai eu des problèmes avec Kmid. Celui ci m'indiquant
des problèmes avec /dev/sequencer.
J'ai vérifié et je n'ai pas cette device : dois-je la créer (comment
faire sous fbsd-5), ais-je manqué une étapes pour ma carte son.
Le deuxième problème et pour mon baladeur mp3 : une fois raccodé à mon
pc celui ne crée pas de device /dev/da0s* alors que dmesg m'affiche
qu'il reconnait le périphériques.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marwan Burelle
In article , Patrick Lamaizière wrote:
Le deuxième problème et pour mon baladeur mp3 : une fois raccodé à mon pc celui ne crée pas de device /dev/da0s* alors que dmesg m'affiche qu'il reconnait le périphériques.
Faut faire comme pour une clef USB si c'est un périphérique umass http://www.lri.fr/~burelle/BSD/USBKey-FreeBSD.html
(merci pour la pub ;)
Pour l'histoire de device, il y a un petit détail : certaines clefs ont une "vraie" table de partition et donc un da0s1 (en général), mais pas toutes, notamment les lecteurs mp3. Dans ce cas là il y a juste une device da0 (un peu comme pour un cd.)
C'est d'ailleurs très énervant, parce que si par mégarde on tente de monter da0 alors qu'il y a un da0s1, le système recrée les devices (en tout cas da0s1) et si on a utilisé les "bidouilles" décrites dans ma doc avec devfs.conf et devd.conf, on perd les droits sur le device ...
Il se peut que ça ne marche pas, j'ai une clef usb mp3 avec laquelle la machine panique à l'insertion sur une 5.3 et au montage sur la 5.4
Pour la 5.3, je penses avoir ta réponse. Ta clef fait partie de ces foutues clefs qui ne supportent pas certaines commandes, il faut ajouter le quirk correspondant dans sys/cam/scsi/scsi_da.c (en général DA_Q_NO_SYNC_CACHE le fait ... )
Pour plus d'info voir : http://www.root.org/~nate/freebsd/quirks.html
(euh, j'en parlais pas dans ma doc de ce truc, d'ailleurs ? ah, non, je vais rapidement corriger ça ... )
Pour la 5.4, je sais pas, pour l'instant je n'ai pas eu le temps de rebouter pour faire l'upgrade (le noyeau et le monde sont compilés et tout, mais bon boulot tout ça ... )
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <XnsE79B7F7BE2AA1plam@nulle.invalid>, Patrick Lamaizière wrote:
Le deuxième problème et pour mon baladeur mp3 : une fois raccodé à mon
pc celui ne crée pas de device /dev/da0s* alors que dmesg m'affiche
qu'il reconnait le périphériques.
Faut faire comme pour une clef USB si c'est un périphérique umass
http://www.lri.fr/~burelle/BSD/USBKey-FreeBSD.html
(merci pour la pub ;)
Pour l'histoire de device, il y a un petit détail : certaines clefs
ont une "vraie" table de partition et donc un da0s1 (en général), mais
pas toutes, notamment les lecteurs mp3. Dans ce cas là il y a juste
une device da0 (un peu comme pour un cd.)
C'est d'ailleurs très énervant, parce que si par mégarde on tente de
monter da0 alors qu'il y a un da0s1, le système recrée les devices (en
tout cas da0s1) et si on a utilisé les "bidouilles" décrites dans ma
doc avec devfs.conf et devd.conf, on perd les droits sur le device ...
Il se peut que ça ne marche pas, j'ai une clef usb mp3 avec laquelle la
machine panique à l'insertion sur une 5.3 et au montage sur la 5.4
Pour la 5.3, je penses avoir ta réponse. Ta clef fait partie de ces
foutues clefs qui ne supportent pas certaines commandes, il faut
ajouter le quirk correspondant dans sys/cam/scsi/scsi_da.c (en général
DA_Q_NO_SYNC_CACHE le fait ... )
Pour plus d'info voir : http://www.root.org/~nate/freebsd/quirks.html
(euh, j'en parlais pas dans ma doc de ce truc, d'ailleurs ? ah, non,
je vais rapidement corriger ça ... )
Pour la 5.4, je sais pas, pour l'instant je n'ai pas eu le temps de
rebouter pour faire l'upgrade (le noyeau et le monde sont compilés et
tout, mais bon boulot tout ça ... )
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Le deuxième problème et pour mon baladeur mp3 : une fois raccodé à mon pc celui ne crée pas de device /dev/da0s* alors que dmesg m'affiche qu'il reconnait le périphériques.
Faut faire comme pour une clef USB si c'est un périphérique umass http://www.lri.fr/~burelle/BSD/USBKey-FreeBSD.html
(merci pour la pub ;)
Pour l'histoire de device, il y a un petit détail : certaines clefs ont une "vraie" table de partition et donc un da0s1 (en général), mais pas toutes, notamment les lecteurs mp3. Dans ce cas là il y a juste une device da0 (un peu comme pour un cd.)
C'est d'ailleurs très énervant, parce que si par mégarde on tente de monter da0 alors qu'il y a un da0s1, le système recrée les devices (en tout cas da0s1) et si on a utilisé les "bidouilles" décrites dans ma doc avec devfs.conf et devd.conf, on perd les droits sur le device ...
Il se peut que ça ne marche pas, j'ai une clef usb mp3 avec laquelle la machine panique à l'insertion sur une 5.3 et au montage sur la 5.4
Pour la 5.3, je penses avoir ta réponse. Ta clef fait partie de ces foutues clefs qui ne supportent pas certaines commandes, il faut ajouter le quirk correspondant dans sys/cam/scsi/scsi_da.c (en général DA_Q_NO_SYNC_CACHE le fait ... )
Pour plus d'info voir : http://www.root.org/~nate/freebsd/quirks.html
(euh, j'en parlais pas dans ma doc de ce truc, d'ailleurs ? ah, non, je vais rapidement corriger ça ... )
Pour la 5.4, je sais pas, pour l'instant je n'ai pas eu le temps de rebouter pour faire l'upgrade (le noyeau et le monde sont compilés et tout, mais bon boulot tout ça ... )
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
F. Senault
Marwan Burelle écrivait :
Pour la 5.4, je sais pas, pour l'instant je n'ai pas eu le temps de rebouter pour faire l'upgrade (le noyeau et le monde sont compilés et tout, mais bon boulot tout ça ... )
Je suis en 5.4. Ça m'a l'air un peu foireux la manière de les spécifier, enfin bon ça marche.
En fait, d'après ce que j'ai compris des discussions sur les mailing-lists, un soir, un développeur à trouvé que c'était vraiment trop le brin dans le code autour de ça, et il a supprimé toutes les exceptions (les fameux quirks), en annonçant qu'il les rebrancherait au fur et à mesure en fonction des besoins.
Fred -- Give a man a computer program and you give him a headache, but teach him to program computers and you give him the power to create headaches for others for the rest of his life... (R. B. Forest)
Marwan Burelle écrivait :
Pour la 5.4, je sais pas, pour l'instant je n'ai pas eu le temps de
rebouter pour faire l'upgrade (le noyeau et le monde sont compilés et
tout, mais bon boulot tout ça ... )
Je suis en 5.4. Ça m'a l'air un peu foireux la manière de les spécifier,
enfin bon ça marche.
En fait, d'après ce que j'ai compris des discussions sur les
mailing-lists, un soir, un développeur à trouvé que c'était vraiment
trop le brin dans le code autour de ça, et il a supprimé toutes les
exceptions (les fameux quirks), en annonçant qu'il les rebrancherait au
fur et à mesure en fonction des besoins.
Fred
--
Give a man a computer program and you give him a headache, but teach
him to program computers and you give him the power to create headaches
for others for the rest of his life... (R. B. Forest)
Pour la 5.4, je sais pas, pour l'instant je n'ai pas eu le temps de rebouter pour faire l'upgrade (le noyeau et le monde sont compilés et tout, mais bon boulot tout ça ... )
Je suis en 5.4. Ça m'a l'air un peu foireux la manière de les spécifier, enfin bon ça marche.
En fait, d'après ce que j'ai compris des discussions sur les mailing-lists, un soir, un développeur à trouvé que c'était vraiment trop le brin dans le code autour de ça, et il a supprimé toutes les exceptions (les fameux quirks), en annonçant qu'il les rebrancherait au fur et à mesure en fonction des besoins.
Fred -- Give a man a computer program and you give him a headache, but teach him to program computers and you give him the power to create headaches for others for the rest of his life... (R. B. Forest)
Marwan Burelle
In article <1r84uy2nx7cbj$, F. Senault wrote:
En fait, d'après ce que j'ai compris des discussions sur les mailing-lists, un soir, un développeur à trouvé que c'était vraiment trop le brin dans le code autour de ça, et il a supprimé toutes les exceptions (les fameux quirks), en annonçant qu'il les rebrancherait au fur et à mesure en fonction des besoins.
Il serait vraiment temps de régler cette histoire d'ailleurs. Les quirks n'étaient pas génant tant qu'ils étaient exceptionnels. Mais maintenant avec la prolifération des clefs OEM toutes basées sur les mêmes composants mais qui s'annonce avec des identifiants différents on doit rajouter un quirk (en général DA_Q_NO_SYNC_CACHE) à chaque fois. C'est plutôt gênant.
Je me demande si on ne ferait pas mieux de lister le matériel qui n'a pas besoin de ce quirk ...
Euh, d'ailleurs sans troll, il n'y a pas ce problème sous nunux, ils n'ont pas implanter toutes les commandes scsi, où ils ont trouvé une vraie solution ?
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <1r84uy2nx7cbj$.dlg@ballantines.lacave.local>, F. Senault wrote:
En fait, d'après ce que j'ai compris des discussions sur les
mailing-lists, un soir, un développeur à trouvé que c'était vraiment
trop le brin dans le code autour de ça, et il a supprimé toutes les
exceptions (les fameux quirks), en annonçant qu'il les rebrancherait au
fur et à mesure en fonction des besoins.
Il serait vraiment temps de régler cette histoire d'ailleurs. Les
quirks n'étaient pas génant tant qu'ils étaient exceptionnels. Mais
maintenant avec la prolifération des clefs OEM toutes basées sur les
mêmes composants mais qui s'annonce avec des identifiants différents
on doit rajouter un quirk (en général DA_Q_NO_SYNC_CACHE) à chaque
fois. C'est plutôt gênant.
Je me demande si on ne ferait pas mieux de lister le matériel qui n'a
pas besoin de ce quirk ...
Euh, d'ailleurs sans troll, il n'y a pas ce problème sous nunux, ils
n'ont pas implanter toutes les commandes scsi, où ils ont trouvé une
vraie solution ?
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
En fait, d'après ce que j'ai compris des discussions sur les mailing-lists, un soir, un développeur à trouvé que c'était vraiment trop le brin dans le code autour de ça, et il a supprimé toutes les exceptions (les fameux quirks), en annonçant qu'il les rebrancherait au fur et à mesure en fonction des besoins.
Il serait vraiment temps de régler cette histoire d'ailleurs. Les quirks n'étaient pas génant tant qu'ils étaient exceptionnels. Mais maintenant avec la prolifération des clefs OEM toutes basées sur les mêmes composants mais qui s'annonce avec des identifiants différents on doit rajouter un quirk (en général DA_Q_NO_SYNC_CACHE) à chaque fois. C'est plutôt gênant.
Je me demande si on ne ferait pas mieux de lister le matériel qui n'a pas besoin de ce quirk ...
Euh, d'ailleurs sans troll, il n'y a pas ce problème sous nunux, ils n'ont pas implanter toutes les commandes scsi, où ils ont trouvé une vraie solution ?
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Il serait vraiment temps de régler cette histoire d'ailleurs. Les quirks n'étaient pas génant tant qu'ils étaient exceptionnels. Mais maintenant avec la prolifération des clefs OEM toutes basées sur les mêmes composants mais qui s'annonce avec des identifiants différents on doit rajouter un quirk (en général DA_Q_NO_SYNC_CACHE) à chaque fois. C'est plutôt gênant.
J'ai un mini-dique USB2 (LaCie) qui monte très bien si je le branche lorsque la machine fonctionne. Mais si je redémarre en laissant le disque branché, j'ai un droit à un plantage du kernel.
Ce problème pourrait-il avoir un rapport avec ce que vous évoqué ?
Ou dois-je me fendre d'un bug report (en recopiant à la main les insultes du kernel lorsqu'il plante) ?
Merci.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Il serait vraiment temps de régler cette histoire d'ailleurs. Les
quirks n'étaient pas génant tant qu'ils étaient exceptionnels. Mais
maintenant avec la prolifération des clefs OEM toutes basées sur les
mêmes composants mais qui s'annonce avec des identifiants différents
on doit rajouter un quirk (en général DA_Q_NO_SYNC_CACHE) à chaque
fois. C'est plutôt gênant.
J'ai un mini-dique USB2 (LaCie) qui monte très bien si je le branche lorsque
la machine fonctionne. Mais si je redémarre en laissant le disque branché,
j'ai un droit à un plantage du kernel.
Ce problème pourrait-il avoir un rapport avec ce que vous évoqué ?
Ou dois-je me fendre d'un bug report (en recopiant à la main les insultes du
kernel lorsqu'il plante) ?
Merci.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Il serait vraiment temps de régler cette histoire d'ailleurs. Les quirks n'étaient pas génant tant qu'ils étaient exceptionnels. Mais maintenant avec la prolifération des clefs OEM toutes basées sur les mêmes composants mais qui s'annonce avec des identifiants différents on doit rajouter un quirk (en général DA_Q_NO_SYNC_CACHE) à chaque fois. C'est plutôt gênant.
J'ai un mini-dique USB2 (LaCie) qui monte très bien si je le branche lorsque la machine fonctionne. Mais si je redémarre en laissant le disque branché, j'ai un droit à un plantage du kernel.
Ce problème pourrait-il avoir un rapport avec ce que vous évoqué ?
Ou dois-je me fendre d'un bug report (en recopiant à la main les insultes du kernel lorsqu'il plante) ?
Merci.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
F. Senault
Ou dois-je me fendre d'un bug report (en recopiant à la main les insultes du kernel lorsqu'il plante) ?
Il me semble avoir déjà lu ça quelque part dans les mailing lists, mais je ne saurais pas dire si ça a été corrigé ou pas.
Sinon, au sujet de ta parenthèse, si c'est aussi facile à reproduire et que tu peux te permettre de la replanter une fois de plus pour la science (tm), il est plutôt conseillé d'obtenir un crashdump et de l'analyser post-mortem.
Pour ça, de mémoire, il te faut plus de swap que de mémoire physique, renseigner le device de swap dans rc.conf, variable dumpdev (ou mettre AUTO s'il n'y a qu'un partition de swap) et un endroit du disque dur où planquer le crashdump, dans la variable dumpdir.
D'une manière ou d'une autre, je pense aussi qu'un kernel avec les options de debuggage (makeoptions DEBUG=-g dans le fichier de conf du kernel) est fortement recommandé.
...
Bon, tout ça est peut-être plus long que d'écrire sur un bout de papier le message de panic, mais c'est tellement low-tech, le papier ! :)
Merci.
Fred -- I am subversion I never was a part of you Burn Secret desire I never was a part of you Burn I am your future I never was a part of you Burn Swallow down all that fire (Nine Inch Nails, Burn)
Ou dois-je me fendre d'un bug report (en recopiant à la main les insultes du
kernel lorsqu'il plante) ?
Il me semble avoir déjà lu ça quelque part dans les mailing lists, mais
je ne saurais pas dire si ça a été corrigé ou pas.
Sinon, au sujet de ta parenthèse, si c'est aussi facile à reproduire et
que tu peux te permettre de la replanter une fois de plus pour la
science (tm), il est plutôt conseillé d'obtenir un crashdump et de
l'analyser post-mortem.
Pour ça, de mémoire, il te faut plus de swap que de mémoire physique,
renseigner le device de swap dans rc.conf, variable dumpdev (ou mettre
AUTO s'il n'y a qu'un partition de swap) et un endroit du disque dur où
planquer le crashdump, dans la variable dumpdir.
D'une manière ou d'une autre, je pense aussi qu'un kernel avec les
options de debuggage (makeoptions DEBUG=-g dans le fichier de conf du
kernel) est fortement recommandé.
...
Bon, tout ça est peut-être plus long que d'écrire sur un bout de papier
le message de panic, mais c'est tellement low-tech, le papier ! :)
Merci.
Fred
--
I am subversion I never was a part of you Burn
Secret desire I never was a part of you Burn
I am your future I never was a part of you Burn
Swallow down all that fire (Nine Inch Nails, Burn)
Ou dois-je me fendre d'un bug report (en recopiant à la main les insultes du kernel lorsqu'il plante) ?
Il me semble avoir déjà lu ça quelque part dans les mailing lists, mais je ne saurais pas dire si ça a été corrigé ou pas.
Sinon, au sujet de ta parenthèse, si c'est aussi facile à reproduire et que tu peux te permettre de la replanter une fois de plus pour la science (tm), il est plutôt conseillé d'obtenir un crashdump et de l'analyser post-mortem.
Pour ça, de mémoire, il te faut plus de swap que de mémoire physique, renseigner le device de swap dans rc.conf, variable dumpdev (ou mettre AUTO s'il n'y a qu'un partition de swap) et un endroit du disque dur où planquer le crashdump, dans la variable dumpdir.
D'une manière ou d'une autre, je pense aussi qu'un kernel avec les options de debuggage (makeoptions DEBUG=-g dans le fichier de conf du kernel) est fortement recommandé.
...
Bon, tout ça est peut-être plus long que d'écrire sur un bout de papier le message de panic, mais c'est tellement low-tech, le papier ! :)
Merci.
Fred -- I am subversion I never was a part of you Burn Secret desire I never was a part of you Burn I am your future I never was a part of you Burn Swallow down all that fire (Nine Inch Nails, Burn)
Sinon, au sujet de ta parenthèse, si c'est aussi facile à reproduire et que tu peux te permettre de la replanter une fois de plus pour la science (tm), il est plutôt conseillé d'obtenir un crashdump et de l'analyser post-mortem.
Pour ça, de mémoire, il te faut plus de swap que de mémoire physique, renseigner le device de swap dans rc.conf, variable dumpdev (ou mettre AUTO s'il n'y a qu'un partition de swap) et un endroit du disque dur où planquer le crashdump, dans la variable dumpdir.
D'une manière ou d'une autre, je pense aussi qu'un kernel avec les options de debuggage (makeoptions DEBUG=-g dans le fichier de conf du kernel) est fortement recommandé.
...
Bon, tout ça est peut-être plus long que d'écrire sur un bout de papier le message de panic, mais c'est tellement low-tech, le papier ! :)
Petit problème : le kernel plante lors de la détection des disques (dont celui en USB qui fait tout planter). Donc pas encore de disque, pas encore de swap et donc pour le crash dump, c'est dur ;-)
Il faudrait que j'essaie avec une kernel en mode DEBUG (je n'ai jamais fait ça sur FreeBSD).
C'est sûr que le papier c'est « low-tech » mais on n'en a jamais plus utilisé que depuis que les ordinateurs existent ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Sinon, au sujet de ta parenthèse, si c'est aussi facile à reproduire et
que tu peux te permettre de la replanter une fois de plus pour la
science (tm), il est plutôt conseillé d'obtenir un crashdump et de
l'analyser post-mortem.
Pour ça, de mémoire, il te faut plus de swap que de mémoire physique,
renseigner le device de swap dans rc.conf, variable dumpdev (ou mettre
AUTO s'il n'y a qu'un partition de swap) et un endroit du disque dur où
planquer le crashdump, dans la variable dumpdir.
D'une manière ou d'une autre, je pense aussi qu'un kernel avec les
options de debuggage (makeoptions DEBUG=-g dans le fichier de conf du
kernel) est fortement recommandé.
...
Bon, tout ça est peut-être plus long que d'écrire sur un bout de papier
le message de panic, mais c'est tellement low-tech, le papier ! :)
Petit problème : le kernel plante lors de la détection des disques (dont celui
en USB qui fait tout planter). Donc pas encore de disque, pas encore de swap
et donc pour le crash dump, c'est dur ;-)
Il faudrait que j'essaie avec une kernel en mode DEBUG (je n'ai jamais fait ça
sur FreeBSD).
C'est sûr que le papier c'est « low-tech » mais on n'en a jamais plus utilisé
que depuis que les ordinateurs existent ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Sinon, au sujet de ta parenthèse, si c'est aussi facile à reproduire et que tu peux te permettre de la replanter une fois de plus pour la science (tm), il est plutôt conseillé d'obtenir un crashdump et de l'analyser post-mortem.
Pour ça, de mémoire, il te faut plus de swap que de mémoire physique, renseigner le device de swap dans rc.conf, variable dumpdev (ou mettre AUTO s'il n'y a qu'un partition de swap) et un endroit du disque dur où planquer le crashdump, dans la variable dumpdir.
D'une manière ou d'une autre, je pense aussi qu'un kernel avec les options de debuggage (makeoptions DEBUG=-g dans le fichier de conf du kernel) est fortement recommandé.
...
Bon, tout ça est peut-être plus long que d'écrire sur un bout de papier le message de panic, mais c'est tellement low-tech, le papier ! :)
Petit problème : le kernel plante lors de la détection des disques (dont celui en USB qui fait tout planter). Donc pas encore de disque, pas encore de swap et donc pour le crash dump, c'est dur ;-)
Il faudrait que j'essaie avec une kernel en mode DEBUG (je n'ai jamais fait ça sur FreeBSD).
C'est sûr que le papier c'est « low-tech » mais on n'en a jamais plus utilisé que depuis que les ordinateurs existent ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
