Linux Kernel Development How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It: An August 2009 Update
Greg Kroah-Hartman, SuSE Labs / Novell Inc.
Jonathan Corbet, LWN.net
Amanda McPherson, The Linux Foundation

Dentro del documento se puede ver porqué todo está funcionando sobre rieles en nuestro curso :)

Disculpas por mi despiste al sugerir que eso era un trimmer. Las excusas que se me ocurren son una más vergonzosa que la otra:

• pese a que tenía el aparato abierto sobre la mesa, al post lo escribí mirando la foto, en la que el conector no está bien iluminado,
• ese día no había traído los lentes, y es chiquitiiiito,
• sencillamente, no es buena idea dejar que un programador escriba acerca de hardware.

En todo caso, ¡gracias por la corrección, ExoUY!

[ 351.781090] Uhhuh. NMI received for unknown reason b1 on CPU 0.
[ 351.781090] You have some hardware problem, likely on the PCI bus.
[ 351.781090] Dazed and confused, but trying to continue
[ 351.781165] ehci_hcd 0000:00:1d.7: fatal error
[ 351.785054] ehci_hcd 0000:00:1d.7: HC died; cleaning up
[ 351.785108] usb 1-2: MESSAGE_REQUEST_BBREG failed, error -108.
[ 351.785139] vt6656: probe of 1-2:1.0 failed with error -108
[ 351.785158] usb 1-2: USB disconnect, address 4
[ 352.096076] usb 2-2: new full speed USB device using uhci_hcd and address 2
[ 352.295147] usb 2-2: not running at top speed; connect to a high speed hub
[ 352.326289] usb 2-2: configuration #1 chosen from 1 choice
[ 352.331143] usb 2-2: current firmware found.
[ 352.331204] uhci_hcd 0000:00:1d.0: host system error, PCI problems?
[ 352.331211] uhci_hcd 0000:00:1d.0: host controller halted, very bad!
[ 352.331236] uhci_hcd 0000:00:1d.0: HC died; cleaning up
[ 352.832036] usb 2-2: MESSAGE_REQUEST_BBREG failed, error -110.
[ 352.832071] vt6656: probe of 2-2:1.0 failed with error -110
[ 352.832380] usb 2-2: USB disconnect, address 2

I was the only one in the class having this problem with exactly the same device driver code and the same kernel.

I spent the long weekend looking for the root cause of the problem.
On Monday at 4am after having traced the whole kernel’s USB communication stack and having read chapter 13 of the book Linux Device Drivers for the 3rd time, I found the root cause of the problem.

Basically, the problem is that eventually we call function usb_control_msg() to send a message through a control endpoint to the USB device and when we call this function we pass a pointer to a table declared as static. usb_control_msg() internally, at some point calls usb_fill_control_urb() to fill a newly allocated urb that is to be asynchornously sent to the USB device. Then, the table ptr is directly assigned to urb->transfer_buffer.

Later down in the stack urb->transfer_buffer is used for streaming DMA mapping to pass the data to the USB device through the PCI controller.

On Monday at 4 am I read again the URB fields in the book Linux Device Driver and I realized that you cannot pass data declared as static or in the stack through DMA. We were passing a pointer to a static array to usb_control_msg(). You need to dynamically allocate a bounce buffer (with kmalloc()) to be passed to a controller for DMA transfer.

Some PCI controllers fail (mine) and some not (all others). I have a Lenovo Thinkpad T60, I don’t know the PCI controller.

From what I read in Google many people with Lenovo had a similar problem and I could not find a clear solution to the problem.

An interesting point regarding usb_control_msg() is that it is supposed to make life easier for device driver developers and you should not have to know that internally DMA transfer occurs. We should check that usb_bulk_msg() does not have the same problem (at least for Lenovo users).
Finally I’ve developed the patch for solving this problem. Now we dynamically allocate a bounce buffer, copy the table content to this bounce buffer and the ptr is passed to usb_control_msg().
I hope this solution is useful for others as well.

Durante este encuentro, nos dedicamos esencialmente a cargar el firmware en la placa, de modo que pueda efectivamente funcionar. Para eso, Christoph nos provee del archivo vt6656.fw, un montón de código binario que no sabemos qué hace (¡GRRR!), pero que debemos enviar al dongle en sucesivos mensajes de control. Para que request_firmware() pueda proveernos este firmware cuando inicializamos el driver, tenemos que poner el archivo en el directorio /lib/firmware.

Una vez que cargamos el firmware con éxito en la tarjeta, por fin podemos bootearla con otro mensaje de control, y tenemos ya una placa de red funcional. Ahora podemos preguntarle cosas como la versión de firmware, o la dirección MAC, o el contenido de la memoria EEPROM del dispositivo (en la que guarda datos persistentes) ¡y nos contesta! De hecho, podemos incluso escribir en la memoria EEPROM, y de esa manera cambiar la dirección MAC de la tarjeta de forma permanente.

Todavía nos falta inicializarla correctamente, configurarla y aprender a enviar y recibir datos antes de que podamos conectarnos a la red, y para que todo eso funcione tenemos que construir las estructuras de datos necesarias para poder pasar información de ida vuelta entre la pila mac80211 y el protocolo USB del firmware.

A menudo, una de esas reglas es que la comunicación debe ser en Inglés. Independientemente de que nos guste o no, el Inglés es la lingua franca de la informática, así como el Francés lo es de las ciencias sociales. De hecho, la comunicación entre el docente y los estudiantes de este taller sería imposible sin capacidad de entender Inglés, y al menos expresarse rudimentariamente en ese idioma. Así, teniendo en cuenta que nuestro objetivo es lograr que el módulo sea incorporado en un proyecto en el que contribuyen cientos de programadores de todo el mundo, parte del contenido del curso es aprender a comportarse como un buen desarrollador en una lista de correo electrónico.

A través de la interacción que se está dando en la lista de correos del proyecto intentamos aprender a través de la experiencia, en un ambiente en el que todos sabemos que estamos aprendiendo. Esto es importante, porque las reglas de “buena educación” en algunos proyectos de software libre pueden ser bastante diferentes de las del mundo real. Por ejemplo, si bien es importante tratar de ser cordial y respetuoso de los demás, probablemente sea más importante el desarrollar la capacidad de no ofenderse cuando otros no lo son: en listas muy técnicas, como las del kernel, es bastante común que algunas personas se comporten de manera descortés, y sobre todo que critiquen el trabajo de otros de manera muy agresiva. Lo peor que uno puede hacer en estos casos es ofenderse y responder a la agresión, lo mejor es tomárselo con calma, quizás incluso tomarse un día entero para calmarse, y recién después contestar a los puntos técnicos, dejando de lado la potencial ofensa personal.

Mientras tanto, vamos aprendiendo otras reglas del arte de la comunicación en grandes proyectos. Por ejemplo: nunca “relatar” cómo cambiaría uno el código, lo mejor es sencillamente cambiarlo y enviar un parche para que otros puedan verlo. El parche es la unidad elemental de intercambio de código entre desarrolladores, y hay una serie de reglas para enviarlos. Algunas de las reglas que vamos aprendiendo:

1. Un parche debe ser la solución completa a un problema. No es bueno que en un parche se solucione más de un error o se introduzca más que una unidad funcional, ni que hagan flata varios parches para solucionar un único problema.
3. No se debe enviar más de un parche por mail. Es muy probable que haya una discusión del parche, y si tenemos varios en un mail, es muy fácil perder el hilo de la discusión, y que se mezclen los comentarios.
4. Los mails que contienen parches deben tener una línea de asunto que permita identificarlo como tal, y darse una idea de para qué sirve el parche. La costumbre dicta que esa línea debe tener la forma comenzar con la etiqueta “[PATCH]”, y seguir con una descripción breve del problema que el patch soluciona.
5. En el caso del kernel, los parches que son contribuidos al proyecto deben contener una linea Signed-off-by:, que esencialmente es una declaración por parte del desarrollador de que el código es de su autoría, y por lo tanto tiene el poder de decisión de contribuirlo. Esto es para evitar que luego un tercero se queje de que hay código de él en el kernel, sin que él diera permiso.
6. Antes de enviar un patch, pasalo primero por scripts/checkpatch.pl, para asegurarte de que respeta las convenciones de codificación del kernel.

En la cara que queda para arriba cuando se enchufa el dongle en una máquina pueden verse el VT6656 y la antena. El aparato de radio está, pero no se ve porque está debajo del blindaje. Entre el blindaje y la antena hay un trimmer de función desconocida.

La cara “de arriba” de la placa

La cara “de abajo” de la placa

Ubicación de nuestro driver en el kernel

Estamos programando un driver para un dispositivo USB, de modo que usaremos la pila USB del kernel para comunicarnos con el dongle. Como además se trata de un dispositivo de red, la función esencial de nuestro driver será proveer los servicios necesarios para que la pila mac80211 del kernel, que se encarga de implementar el protocolo 802.11 independientemente del hardware, pueda utiliza el dongle como interfaz de red.

Pero todavía estamos muy lejos de poder ofrecer tanto: hoy nos damos por contentos con bastante menos: queremos que el kernel se dé cuenta, cuando alguien enchufe uno de nuestros dongles, de que nuestro driver es el que se ocupa de ese dispositivo, y lo invoque para inicializarlo. También queremos que invoque a nuestro driver para eliminar el dispositivo cuando el usuario lo quita del bus USB, y durante el tiempo al medio estaría bueno si pudiéramos al menos leer algo (un parámetro, cualquier cosa) desde el dongle. En otras palabras: el trabajo durante el encuentro se concentra en la interfaz entre nuestro driver y la pila USB.

La creación y eliminación del dispositivo cuando el usuario enchufa/desenchufa funciona sin mayores dificultades, según podemos ver en el syslog gracias a sentencias printk() que respectivamente nos dan la bienvenida o se despiden de nosotros conforme enchufamos o desenchufamos.

Nuestro intento de leer algún parámetro falla, “inexplicablemente”, hasta que nos damos cuenta de algo fundamental: la placa no nos va a contestar a nada que le preguntemos si no le cargamos antes el firmware. Esto es algo bastante común en los dispositivos USB modernos: son pequeñas computadoras en sí, y como tales necesitan software. En vez de poner ese software en ROM, lo que lo haría probablemente más caro y dificultaría el upgrade, los fabricantes los diseñan de tal manera que, cuando uno los enciende, apenas si saben encenderse y esperar a que les enviemos el software que necesitan a través de la misma conexión USB.

Como preparación para cargar el firmware en el próximo encuentro, experimentamos con la función del kernel request_firmware(), que se encarga de cargar el firmware desde un archivo en el disco a un lugar en memoria desde el que se lo podemos pasar al dispositivo.

Como tarea queda estudiar nuestra interfaz “hacia arriba” e implementar una interfaz de red trucha que no haga nada, pero que sea visible para mac82011 y reporte una dirección MAC inventada.