Hi there

I have a problem with this repo. First I clone it locally:

root@debian:/usr/local/src/raspi.orig# git clone https://github.com/raspberrypi/linux.gitCloning into linux...
remote: Counting objects: 2275163, done.
remote: Compressing objects: 100% (354613/354613), done.
remote: Total 2275163 (delta 1901476), reused 2268622 (delta 1898739)
Receiving objects: 100% (2275163/2275163), 465.59 MiB | 1.13 MiB/s, done.
Resolving deltas: 100% (1901476/1901476), done.
root@debian:/usr/local/src/raspi.orig# cd linux
root@debian:/usr/local/src/raspi.orig/linux# git pull origin master
From https://github.com/raspberrypi/linux

• branch master -> FETCH_HEAD
  warning: too many files (created: 2074 deleted: 1981), skipping inexact rename detection

[.... long list of stuff .... }

CONFLICT (content): Merge conflict in net/sched/sch_teql.c
Auto-merging net/sctp/associola.c
Auto-merging net/sctp/outqueue.c
Auto-merging net/sctp/protocol.c
Auto-merging net/sctp/socket.c
Auto-merging net/sunrpc/auth_gss/auth_gss.c
Auto-merging net/sunrpc/rpc_pipe.c
Auto-merging net/sunrpc/xprtsock.c
Auto-merging net/wireless/nl80211.c
Auto-merging net/wireless/reg.c
Auto-merging net/xfrm/xfrm_policy.c
Auto-merging scripts/kconfig/menu.c
CONFLICT (content): Merge conflict in scripts/kconfig/menu.c
Removing security/integrity/ima/ima_iint.c
Removing security/keys/encrypted.c
Removing security/keys/encrypted.h
Auto-merging security/tomoyo/realpath.c
Removing sound/pci/hda/alc268_quirks.c
CONFLICT (delete/modify): sound/pci/hda/alc269_quirks.c deleted in 645fd9b and modified in HEAD. Version HEAD of sound/pci/hda/alc269_quirks.c left in tree.
Removing sound/pci/hda/alc662_quirks.c
Removing sound/pci/hda/alc680_quirks.c
Removing sound/pci/hda/alc861_quirks.c
Removing sound/pci/hda/alc861vd_quirks.c
Auto-merging sound/pci/hda/hda_codec.c
CONFLICT (content): Merge conflict in sound/pci/hda/hda_codec.c
Auto-merging sound/pci/hda/hda_eld.c
CONFLICT (content): Merge conflict in sound/pci/hda/hda_eld.c
Auto-merging sound/pci/hda/hda_intel.c
Auto-merging sound/pci/hda/patch_cirrus.c
Auto-merging sound/pci/hda/patch_conexant.c
CONFLICT (content): Merge conflict in sound/pci/hda/patch_conexant.c
Auto-merging sound/pci/hda/patch_hdmi.c
CONFLICT (content): Merge conflict in sound/pci/hda/patch_hdmi.c
Auto-merging sound/pci/hda/patch_realtek.c
CONFLICT (content): Merge conflict in sound/pci/hda/patch_realtek.c
Auto-merging sound/pci/hda/patch_sigmatel.c
CONFLICT (content): Merge conflict in sound/pci/hda/patch_sigmatel.c
Auto-merging sound/pci/hda/patch_via.c
Auto-merging sound/pci/lx6464es/lx_core.c
Auto-merging sound/pci/sis7019.c
Removing sound/soc/atmel/playpaq_wm8510.c
Removing sound/soc/codecs/ads117x.h
Auto-merging sound/soc/codecs/ak4535.c
CONFLICT (content): Merge conflict in sound/soc/codecs/ak4535.c
Auto-merging sound/soc/codecs/ak4642.c
CONFLICT (content): Merge conflict in sound/soc/codecs/ak4642.c
Auto-merging sound/soc/codecs/sta32x.c
Auto-merging sound/soc/codecs/wm8711.c
Auto-merging sound/soc/codecs/wm8731.c
Auto-merging sound/soc/codecs/wm8741.c
Auto-merging sound/soc/codecs/wm8753.c
Auto-merging sound/soc/codecs/wm8904.c
Auto-merging sound/soc/codecs/wm8940.c
Auto-merging sound/soc/codecs/wm8962.c
Auto-merging sound/soc/codecs/wm8994.c
Auto-merging sound/soc/codecs/wm8996.c
Auto-merging sound/soc/fsl/fsl_ssi.c
Removing sound/soc/omap/mcpdm.c
Removing sound/soc/omap/mcpdm.h
Auto-merging sound/soc/soc-utils.c
Auto-merging sound/usb/misc/ua101.c
Auto-merging sound/usb/mixer.c
CONFLICT (content): Merge conflict in sound/usb/mixer.c
Removing sound/usb/urb.c
Removing sound/usb/urb.h
Auto-merging tools/perf/util/trace-event-parse.c
Removing tools/perf/util/ui/browsers/top.c
Automatic merge failed; fix conflicts and then commit the result.
root@debian:/usr/local/src/raspi.orig/linux#

I'm not sure since I haven't read the full source yet but it looks to me like var->green.length could leave the function here without being initialized.

Everytime when mmcqd/0 eating CPU (about 12% CPU) I have short sound stutters.

I've tested various options:

• the same problem was when I've played music on mpd / mpg123 / aplay / pulseaudio stream from LAN
• the same problem on internal and external card (via usbaudio.ko). When playing music on two cards, the hang was in the same time on both cards (when mmcqd worked)
• tested on low / high cpu usage/load, on various snd quality (44100, 22050Hz)

I have Kingston SDHC 8GB Class10 (SD10G2/8GB) and default .asoundrc

Could the bootloader set up the PL011 UART before it hands over to the kernel? Currently I have code in bootc/linux@a91fe13 that sets up the serial port during the kernel decompression stage so that it can be used during decompression and then during early printk.

It would really be ideal if that was done outside the kernel as is more customary, and would mean you could boot compressed or uncompressed kernels and get the same behaviour.

trying to unzip the current zip ( downloaded from the "zip" link on main page ) fails with this error :
( more exactly dowloaded from https://github.com/raspberrypi/linux/zipball/rpi-patches )

unzip raspberrypi-linux-b683e89.zip

finishing deferred symbolic links:
raspberrypi-linux-b683e89/arch/microblaze/boot/dts/system.dts -> ../../platform/generic/system.dts
raspberrypi-linux-b683e89/drivers/scsi/aacraid/linit.c -> /^J *^IAdaptec AAC series RAID controller driver^J *^I(c) Copyright 2001 Red Hat Inc.^J *^J * based on the old aacraid driver that is..^J * Adaptec aacraid device driver for Linux.^J *^J * Copyright (c) 2000-2010 Adaptec, Inc.^J * 2010 PMC-Sierra, Inc. ([email protected])^J *^J * This program is free software; you can redistribute it and/or modify^J * it under the terms of the GNU General Public License as published by^J * the Free Software Foundation; either version 2, or (at your option)^J * any later version.^J *^J * This program is distributed in the hope that it will be useful,^J * but WITHOUT ANY WARRANTY; without even the implied warranty of^J * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the^J * GNU General Public License for more details.^J *^J * You should have received a copy of the GNU General Public License^J * along with this program; see the file COPYING. If not, write to^J * the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.^J *^J * Module Name:^J * linit.c^J *^J * Abstract: Linux Driver entry module for Adaptec RAID Array Controller^J */^J^J^J#include <linux/compat.h>^J#include <linux/blkdev.h>^J#include <linux/completion.h>^J#include <linux/init.h>^J#include <linux/interrupt.h>^J#include <linux/kernel.h>^J#include <linux/module.h>^J#include <linux/moduleparam.h>^J#include <linux/pci.h>^J#include <linux/pci-aspm.h>^J#include <linux/slab.h>^J#include <linux/mutex.h>^J#include <linux/spinlock.h>^J#include <linux/syscalls.h>^J#include <linux/delay.h>^J#include <linux/kthread.h>^J^J#include <scsi/scsi.h>^J#include <scsi/scsi_cmnd.h>^J#include <scsi/scsi_device.h>^J#include <scsi/scsi_host.h>^J#include <scsi/scsi_tcq.h>^J#include <scsi/scsicam.h>^J#include <scsi/scsi_eh.h>^J^J#include "aacraid.h"^J^J#define AAC_DRIVER_VERSION^I^I"1.1-7"^J#ifndef AAC_DRIVER_BRANCH^J#define AAC_DRIVER_BRANCH^I^I""^J#endif^J#define AAC_DRIVERNAME^I^I^I"aacraid"^J^J#ifdef AAC_DRIVER_BUILD^J#define str(x) #x^J#define str(x) str(x)^J#define AAC_DRIVER_FULL_VERSION^IAAC_DRIVER_VERSION "[" str(AAC_DRIVER_BUILD) "]" AAC_DRIVER_BRANCH^J#else^J#define AAC_DRIVER_FULL_VERSION^IAAC_DRIVER_VERSION AAC_DRIVER_BRANCH^J#endif^J^JMODULE_AUTHOR("Red Hat Inc and Adaptec");^JMODULE_DESCRIPTION("Dell PERC2, 2/Si, 3/Si, 3/Di, "^J^I^I "Adaptec Advanced Raid Products, "^J^I^I "HP NetRAID-4M, IBM ServeRAID & ICP SCSI driver");^JMODULE_LICENSE("GPL");^JMODULE_VERSION(AAC_DRIVER_FULL_VERSION);^J^Jstatic DEFINE_MUTEX(aac_mutex);^Jstatic LIST_HEAD(aac_devices);^Jstatic int aac_cfg_major = -1;^Jchar aac_driver_version[] = AAC_DRIVER_FULL_VERSION;^J^J/^J * Because of the way Linux names scsi devices, the order in this table has^J * become important. Check for on-board Raid first, add-in cards second.^J ^J * Note: The last field is used to index into aac_drivers below.^J */^J#ifdef DECLARE_PCI_DEVICE_TABLE^Jstatic DECLARE_PCI_DEVICE_TABLE(aac_pci_tbl) = {^J#elif defined(__devinitconst)^Jstatic const struct pci_device_id aac_pci_tbl[] _devinitconst = {^J#else^Jstatic const struct pci_device_id aac_pci_tbl[] devinitdata = {^J#endif^J^I{ 0x1028, 0x0001, 0x1028, 0x0001, 0, 0, 0 }, / PERC 2/Si (Iguana/PERC2Si) /^J^I{ 0x1028, 0x0002, 0x1028, 0x0002, 0, 0, 1 }, / PERC 3/Di (Opal/PERC3Di) /^J^I{ 0x1028, 0x0003, 0x1028, 0x0003, 0, 0, 2 }, / PERC 3/Si (SlimFast/PERC3Si /^J^I{ 0x1028, 0x0004, 0x1028, 0x00d0, 0, 0, 3 }, / PERC 3/Di (Iguana FlipChip/PERC3DiF /^J^I{ 0x1028, 0x0002, 0x1028, 0x00d1, 0, 0, 4 }, / PERC 3/Di (Viper/PERC3DiV) /^J^I{ 0x1028, 0x0002, 0x1028, 0x00d9, 0, 0, 5 }, / PERC 3/Di (Lexus/PERC3DiL) /^J^I{ 0x1028, 0x000a, 0x1028, 0x0106, 0, 0, 6 }, / PERC 3/Di (Jaguar/PERC3DiJ) /^J^I{ 0x1028, 0x000a, 0x1028, 0x011b, 0, 0, 7 }, / PERC 3/Di (Dagger/PERC3DiD) /^J^I{ 0x1028, 0x000a, 0x1028, 0x0121, 0, 0, 8 }, / PERC 3/Di (Boxster/PERC3DiB) /^J^I{ 0x9005, 0x0283, 0x9005, 0x0283, 0, 0, 9 }, / catapult /^J^I{ 0x9005, 0x0284, 0x9005, 0x0284, 0, 0, 10 }, / tomcat /^J^I{ 0x9005, 0x0285, 0x9005, 0x0286, 0, 0, 11 }, / Adaptec 2120S (Crusader) /^J^I{ 0x9005, 0x0285, 0x9005, 0x0285, 0, 0, 12 }, / Adaptec 2200S (Vulcan) /^J^I{ 0x9005, 0x0285, 0x9005, 0x0287, 0, 0, 13 }, / Adaptec 2200S (Vulcan-2m) /^J^I{ 0x9005, 0x0285, 0x17aa, 0x0286, 0, 0, 14 }, / Legend S220 (Legend Crusader) /^J^I{ 0x9005, 0x0285, 0x17aa, 0x0287, 0, 0, 15 }, / Legend S230 (Legend Vulcan) /^J^J^I{ 0x9005, 0x0285, 0x9005, 0x0288, 0, 0, 16 }, / Adaptec 3230S (Harrier) /^J^I{ 0x9005, 0x0285, 0x9005, 0x0289, 0, 0, 17 }, / Adaptec 3240S (Tornado) /^J^I{ 0x9005, 0x0285, 0x9005, 0x028a, 0, 0, 18 }, / ASR-2020ZCR SCSI PCI-X ZCR (Skyhawk) /^J^I{ 0x9005, 0x0285, 0x9005, 0x028b, 0, 0, 19 }, / ASR-2025ZCR SCSI SO-DIMM PCI-X ZCR (Terminator) /^J^I{ 0x9005, 0x0286, 0x9005, 0x028c, 0, 0, 20 }, / ASR-2230S + ASR-2230SLP PCI-X (Lancer) /^J^I{ 0x9005, 0x0286, 0x9005, 0x028d, 0, 0, 21 }, / ASR-2130S (Lancer) /^J^I{ 0x9005, 0x0286, 0x9005, 0x029b, 0, 0, 22 }, / AAR-2820SA (Intruder) /^J^I{ 0x9005, 0x0286, 0x9005, 0x029c, 0, 0, 23 }, / AAR-2620SA (Intruder) /^J^I{ 0x9005, 0x0286, 0x9005, 0x029d, 0, 0, 24 }, / AAR-2420SA (Intruder) /^J^I{ 0x9005, 0x0286, 0x9005, 0x029e, 0, 0, 25 }, / ICP9024RO (Lancer) /^J^I{ 0x9005, 0x0286, 0x9005, 0x029f, 0, 0, 26 }, / ICP9014RO (Lancer) /^J^I{ 0x9005, 0x0286, 0x9005, 0x02a0, 0, 0, 27 }, / ICP9047MA (Lancer) /^J^I{ 0x9005, 0x0286, 0x9005, 0x02a1, 0, 0, 28 }, / ICP9087MA (Lancer) /^J^I{ 0x9005, 0x0286, 0x9005, 0x02a3, 0, 0, 29 }, / ICP5445AU (Hurricane44) /^J^I{ 0x9005, 0x0285, 0x9005, 0x02a4, 0, 0, 30 }, / ICP9085LI (Marauder-X) /^J^I{ 0x9005, 0x0285, 0x9005, 0x02a5, 0, 0, 31 }, / ICP5085BR (Marauder-E) /^J^I{ 0x9005, 0x0286, 0x9005, 0x02a6, 0, 0, 32 }, / ICP9067MA (Intruder-6) /^J^I{ 0x9005, 0x0287, 0x9005, 0x0800, 0, 0, 33 }, / Themisto Jupiter Platform /^J^I{ 0x9005, 0x0200, 0x9005, 0x0200, 0, 0, 33 }, / Themisto Jupiter Platform /^J^I{ 0x9005, 0x0286, 0x9005, 0x0800, 0, 0, 34 }, / Callisto Jupiter Platform /^J^I{ 0x9005, 0x0285, 0x9005, 0x028e, 0, 0, 35 }, / ASR-2020SA SATA PCI-X ZCR (Skyhawk) /^J^I{ 0x9005, 0x0285, 0x9005, 0x028f, 0, 0, 36 }, / ASR-2025SA SATA SO-DIMM PCI-X ZCR (Terminator) /^J^I{ 0x9005, 0x0285, 0x9005, 0x0290, 0, 0, 37 }, / AAR-2410SA PCI SATA 4ch (Jaguar II) /^J^I{ 0x9005, 0x0285, 0x1028, 0x0291, 0, 0, 38 }, / CERC SATA RAID 2 PCI SATA 6ch (DellCorsair) /^J^I{ 0x9005, 0x0285, 0x9005, 0x0292, 0, 0, 39 }, / AAR-2810SA PCI SATA 8ch (Corsair-8) /^J^I{ 0x9005, 0x0285, 0x9005, 0x0293, 0, 0, 40 }, / AAR-21610SA PCI SATA 16ch (Corsair-16) /^J^I{ 0x9005, 0x0285, 0x9005, 0x0294, 0, 0, 41 }, / ESD SO-DIMM PCI-X SATA ZCR (Prowler) /^J^I{ 0x9005, 0x0285, 0x103C, 0x3227, 0, 0, 42 }, / AAR-2610SA PCI SATA 6ch /^J^I{ 0x9005, 0x0285, 0x9005, 0x0296, 0, 0, 43 }, / ASR-2240S (SabreExpress) /^J^I{ 0x9005, 0x0285, 0x9005, 0x0297, 0, 0, 44 }, / ASR-4005 /^J^I{ 0x9005, 0x0285, 0x1014, 0x02F2, 0, 0, 45 }, / IBM 8i (AvonPark) /^J^I{ 0x9005, 0x0285, 0x1014, 0x0312, 0, 0, 45 }, / IBM 8i (AvonPark Lite) /^J^I{ 0x9005, 0x0286, 0x1014, 0x9580, 0, 0, 46 }, / IBM 8k/8k-l8 (Aurora) /^J^I{ 0x9005, 0x0286, 0x1014, 0x9540, 0, 0, 47 }, / IBM 8k/8k-l4 (Aurora Lite) /^J^I{ 0x9005, 0x0285, 0x9005, 0x0298, 0, 0, 48 }, / ASR-4000 (BlackBird) /^J^I{ 0x9005, 0x0285, 0x9005, 0x0299, 0, 0, 49 }, / ASR-4800SAS (Marauder-X) /^J^I{ 0x9005, 0x0285, 0x9005, 0x029a, 0, 0, 50 }, / ASR-4805SAS (Marauder-E) /^J^I{ 0x9005, 0x0286, 0x9005, 0x02a2, 0, 0, 51 }, / ASR-3800 (Hurricane44) /^J^J^I{ 0x9005, 0x0285, 0x1028, 0x0287, 0, 0, 52 }, / Perc 320/DC/^J^I{ 0x1011, 0x0046, 0x9005, 0x0365, 0, 0, 53 }, / Adaptec 5400S (Mustang)/^J^I{ 0x1011, 0x0046, 0x9005, 0x0364, 0, 0, 54 }, / Adaptec 5400S (Mustang)/^J^I{ 0x1011, 0x0046, 0x9005, 0x1364, 0, 0, 55 }, /_ Dell PERC2/QC /^J^I{ 0x1011, 0x0046, 0x103c, 0x10c2, 0, 0, 56 }, / HP NetRAID-4M /^J^J^I{ 0x9005, 0x0285, 0x1028, PCI_ANY_ID, 0, 0, 57 }, / Dell Catchall /^J^I{ 0x9005, 0x0285, 0x17aa, PCI_ANY_ID, 0, 0, 58 }, / Legend Catchall /^J^I{ 0x9005, 0x0285, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 59 }, / Adaptec Catch All /^J^I{ 0x9005, 0x0286, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 60 }, / Adaptec Rocket Catch All /^J^I{ 0x9005, 0x0288, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 61 }, / Adaptec NEMER/ARK Catch All /^J^I{ 0x9005, 0x028b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 62 }, / Adaptec PMC Catch All /^J^I{ 0,}^J};^JMODULE_DEVICE_TABLE(pci, aac_pci_tbl);^J^J/^J * dmb - For now we add the number of channels to this structure.^J * In the future we should add a fib that reports the number of channels^J * for the card. At that time we can remove the channels from here^J /^Jstatic struct aac_driver_ident aac_drivers[] = {^J^I{ aac_rx_init, "percraid", "DELL ", "PERCRAID ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / PERC 2/Si (Iguana/PERC2Si) /^J^I{ aac_rx_init, "percraid", "DELL ", "PERCRAID ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / PERC 3/Di (Opal/PERC3Di) /^J^I{ aac_rx_init, "percraid", "DELL ", "PERCRAID ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / PERC 3/Si (SlimFast/PERC3Si /^J^I{ aac_rx_init, "percraid", "DELL ", "PERCRAID ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / PERC 3/Di (Iguana FlipChip/PERC3DiF /^J^I{ aac_rx_init, "percraid", "DELL ", "PERCRAID ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / PERC 3/Di (Viper/PERC3DiV) /^J^I{ aac_rx_init, "percraid", "DELL ", "PERCRAID ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / PERC 3/Di (Lexus/PERC3DiL) /^J^I{ aac_rx_init, "percraid", "DELL ", "PERCRAID ", 1, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / PERC 3/Di (Jaguar/PERC3DiJ) /^J^I{ aac_rx_init, "percraid", "DELL ", "PERCRAID ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / PERC 3/Di (Dagger/PERC3DiD) /^J^I{ aac_rx_init, "percraid", "DELL ", "PERCRAID ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / PERC 3/Di (Boxster/PERC3DiB) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "catapult ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / catapult /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "tomcat ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / tomcat /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "Adaptec 2120S ", 1, AAC_QUIRK_31BIT | AAC_QUIRK_34SG },^I^I / Adaptec 2120S (Crusader) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "Adaptec 2200S ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG },^I^I / Adaptec 2200S (Vulcan) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "Adaptec 2200S ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / Adaptec 2200S (Vulcan-2m) /^J^I{ aac_rx_init, "aacraid", "Legend ", "Legend S220 ", 1, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / Legend S220 (Legend Crusader) /^J^I{ aac_rx_init, "aacraid", "Legend ", "Legend S230 ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / Legend S230 (Legend Vulcan) /^J^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "Adaptec 3230S ", 2 }, / Adaptec 3230S (Harrier) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "Adaptec 3240S ", 2 }, / Adaptec 3240S (Tornado) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "ASR-2020ZCR ", 2 }, / ASR-2020ZCR SCSI PCI-X ZCR (Skyhawk) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "ASR-2025ZCR ", 2 }, / ASR-2025ZCR SCSI SO-DIMM PCI-X ZCR (Terminator) /^J^I{ aac_rkt_init, "aacraid", "ADAPTEC ", "ASR-2230S PCI-X ", 2 }, / ASR-2230S + ASR-2230SLP PCI-X (Lancer) /^J^I{ aac_rkt_init, "aacraid", "ADAPTEC ", "ASR-2130S PCI-X ", 1 }, / ASR-2130S (Lancer) /^J^I{ aac_rkt_init, "aacraid", "ADAPTEC ", "AAR-2820SA ", 1 }, / AAR-2820SA (Intruder) /^J^I{ aac_rkt_init, "aacraid", "ADAPTEC ", "AAR-2620SA ", 1 }, / AAR-2620SA (Intruder) /^J^I{ aac_rkt_init, "aacraid", "ADAPTEC ", "AAR-2420SA ", 1 }, / AAR-2420SA (Intruder) /^J^I{ aac_rkt_init, "aacraid", "ICP ", "ICP9024RO ", 2 }, / ICP9024RO (Lancer) /^J^I{ aac_rkt_init, "aacraid", "ICP ", "ICP9014RO ", 1 }, / ICP9014RO (Lancer) /^J^I{ aac_rkt_init, "aacraid", "ICP ", "ICP9047MA ", 1 }, / ICP9047MA (Lancer) /^J^I{ aac_rkt_init, "aacraid", "ICP ", "ICP9087MA ", 1 }, / ICP9087MA (Lancer) /^J^I{ aac_rkt_init, "aacraid", "ICP ", "ICP5445AU ", 1 }, / ICP5445AU (Hurricane44) /^J^I{ aac_rx_init, "aacraid", "ICP ", "ICP9085LI ", 1 }, / ICP9085LI (Marauder-X) /^J^I{ aac_rx_init, "aacraid", "ICP ", "ICP5085BR ", 1 }, / ICP5085BR (Marauder-E) /^J^I{ aac_rkt_init, "aacraid", "ICP ", "ICP9067MA ", 1 }, / ICP9067MA (Intruder-6) /^J^I{ NULL , "aacraid", "ADAPTEC ", "Themisto ", 0, AAC_QUIRK_SLAVE }, / Jupiter Platform /^J^I{ aac_rkt_init, "aacraid", "ADAPTEC ", "Callisto ", 2, AAC_QUIRK_MASTER }, / Jupiter Platform /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "ASR-2020SA ", 1 }, / ASR-2020SA SATA PCI-X ZCR (Skyhawk) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "ASR-2025SA ", 1 }, / ASR-2025SA SATA SO-DIMM PCI-X ZCR (Terminator) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "AAR-2410SA SATA ", 1, AAC_QUIRK_17SG }, / AAR-2410SA PCI SATA 4ch (Jaguar II) /^J^I{ aac_rx_init, "aacraid", "DELL ", "CERC SR2 ", 1, AAC_QUIRK_17SG }, / CERC SATA RAID 2 PCI SATA 6ch (DellCorsair) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "AAR-2810SA SATA ", 1, AAC_QUIRK_17SG }, / AAR-2810SA PCI SATA 8ch (Corsair-8) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "AAR-21610SA SATA", 1, AAC_QUIRK_17SG }, / AAR-21610SA PCI SATA 16ch (Corsair-16) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "ASR-2026ZCR ", 1 }, / ESD SO-DIMM PCI-X SATA ZCR (Prowler) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "AAR-2610SA ", 1 }, / SATA 6Ch (Bearcat) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "ASR-2240S ", 1 }, / ASR-2240S (SabreExpress) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "ASR-4005 ", 1 }, / ASR-4005 /^J^I{ aac_rx_init, "ServeRAID","IBM ", "ServeRAID 8i ", 1 }, / IBM 8i (AvonPark) /^J^I{ aac_rkt_init, "ServeRAID","IBM ", "ServeRAID 8k-l8 ", 1 }, / IBM 8k/8k-l8 (Aurora) /^J^I{ aac_rkt_init, "ServeRAID","IBM ", "ServeRAID 8k-l4 ", 1 }, / IBM 8k/8k-l4 (Aurora Lite) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "ASR-4000 ", 1 }, / ASR-4000 (BlackBird & AvonPark) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "ASR-4800SAS ", 1 }, / ASR-4800SAS (Marauder-X) /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "ASR-4805SAS ", 1 }, / ASR-4805SAS (Marauder-E) /^J^I{ aac_rkt_init, "aacraid", "ADAPTEC ", "ASR-3800 ", 1 }, / ASR-3800 (Hurricane44) /^J^J^I{ aac_rx_init, "percraid", "DELL ", "PERC 320/DC ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG }, / Perc 320/DC_/^J^I{ aac_sa_init, "aacraid", "ADAPTEC ", "Adaptec 5400S ", 4, AAC_QUIRK_34SG }, /_ Adaptec 5400S (Mustang)/^J^I{ aac_sa_init, "aacraid", "ADAPTEC ", "AAC-364 ", 4, AAC_QUIRK_34SG }, / Adaptec 5400S (Mustang)/^J^I{ aac_sa_init, "percraid", "DELL ", "PERCRAID ", 4, AAC_QUIRK_34SG }, / Dell PERC2/QC /^J^I{ aac_sa_init, "hpnraid", "HP ", "NetRAID ", 4, AAC_QUIRK_34SG }, / HP NetRAID-4M /^J^J^I{ aac_rx_init, "aacraid", "DELL ", "RAID ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / Dell Catchall /^J^I{ aac_rx_init, "aacraid", "Legend ", "RAID ", 2, AAC_QUIRK_31BIT | AAC_QUIRK_34SG | AAC_QUIRK_SCSI_32 }, / Legend Catchall /^J^I{ aac_rx_init, "aacraid", "ADAPTEC ", "RAID ", 2 }, / Adaptec Catch All /^J^I{ aac_rkt_init, "aacraid", "ADAPTEC ", "RAID ", 2 }, / Adaptec Rocket Catch All /^J^I{ aac_nark_init, "aacraid", "ADAPTEC ", "RAID ", 2 }, / Adaptec NEMER/ARK Catch All /^J^I{ aac_src_init, "aacraid", "ADAPTEC ", "RAID ", 2 } / Adaptec PMC Catch All _/^J};^J^J/__^J *^Iaac_queuecommand^I-^Iqueue a SCSI command^J *^I@cmd:^I^ISCSI command to queue^J *^I@done:^I^IFunction to call on command completion^J *^J *^IQueues a command for execution by the associated Host Adapter.^J *^J *^ITODO: unify with aac_scsi_cmd().^J */^J^Jstatic int aac_queuecommand_lck(struct scsi_cmnd *cmd, void (_done)(struct scsi_cmnd *)...
symlink error: File name too long

I'm trying to chainload boot from the kernel on the SD card to a rootFS stored on a USB stick (for better read/write speeds, but also because my rootFS needs to be on a GPT-formatted disk).

It appears a module required to use a USB stick with the Pi is only compiled as a module: ./3.1.9+/kernel/drivers/usb/storage/uas.ko

Can this be changed in the default config, and therefore in the binaries provided in the firmware repo?

INFO:: periodic_channel_available: Total channels: 8, Periodic: 6, Non-periodic: 2

INFO:: schedule_periodic: No host channel available for periodic transfer.

ERROR::dwc_otg_hcd_urb_enqueue:518: DWC OTG HCD URB Enqueue failed adding QTD. Error status -4008

When I try connect my keyboard (hub with power, with on it: usb<->network adapter + my keyboard)

Could you provide an explanation of the workaround that references JIRA SW-5991?

diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 5900cd5..952736d 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -73,10 +73,19 @@ ENDPROC(cpu_v6_reset)
  *
  * IRQs are already disabled.
  */
+
+/* See jira SW-5991 for details of this workaround */
 ENTRY(cpu_v6_do_idle)
-   mov r1, #0
-   mcr p15, 0, r1, c7, c10, 4      @ DWB - WFI may enter a low-power mode
-   mcr p15, 0, r1, c7, c0, 4       @ wait for interrupt
+   .align 5
+   mov     r1, #2
+1: subs    r1, #1
+   nop
+   mcreq   p15, 0, r1, c7, c10, 4      @ DWB - WFI may enter a low-power mode
+   mcreq   p15, 0, r1, c7, c0, 4       @ wait for interrupt
+   nop
+   nop
+   nop
+   bne 1b
    mov pc, lr

 ENTRY(cpu_v6_dcache_clean_area)

This issue shows up with Scratch and the Picoboard on Raspbian. I am not sure how general it is.

I have a PicoBoard plugged directly into the Pi (and a keyboard and mouse running through a powered hub.) When I boot into Debian 'squeeze', Scratch instantly recognizes the board, the Scratch sensor watcher reports values, and scripts relying on the board work properly.

When I shutdown, swap out the SD card, and boot into Raspbian 'wheezy' with the identical physical setup, Scratch does not recognize the Pico Board, the sensor watcher reports only 0 values, and Picoboard reliant scripts don't run.

Under Raspbian, dmesg reports recognizing an FTDI device on a USB hub:

[ 9.475632] usbcore: registered new interface driver usbserial
[ 9.646934] USB Serial support registered for generic
[ 9.914046] usbcore: registered new interface driver usbserial_generic
[ 10.370135] usbserial: USB Serial Driver core
[ 10.815102] USB Serial support registered for FTDI USB Serial Device
[ 11.107379] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[ 11.277210] usb 1-1.2: Detected FT232RL
[ 11.386922] usb 1-1.2: Number of endpoints 2
[ 11.496964] usb 1-1.2: Endpoint 1 MaxPacketSize 64
[ 11.586897] usb 1-1.2: Endpoint 2 MaxPacketSize 64
[ 11.662464] usb 1-1.2: Setting MaxPacketSize 64
[ 11.731847] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 11.769734] usbcore: registered new interface driver ftdi_sio
[ 11.790153] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

Running 'sudo modprobe ftdi_sio', as per this earlier thread about the Picoboard (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=47&t=5327&p=73828&hilit=picoboard#p73828) produces no change in the recognition of FTDI devices.

redhat version...download url?

Was wondering if USB video class support (universal protocol that most modern webcams use) could be added to the default configuration.
So that people wanting to play with webcams do not have to build their own kernel modules.

From menuconfig select:

"device drivers" -> "multimedia support" -> "video for linux"
"device drivers" -> "multimedia support" -> "video for linux" -> "video capture adapters" -> "V4L usb devices" -> "USB video class (UVC)"

Generates the following options:

CONFIG_MEDIA_SUPPORT=y
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L2_COMMON=m
CONFIG_VIDEO_MEDIA=m
CONFIG_VIDEO_V4L2=m
CONFIG_VIDEO_CAPTURE_DRIVERS=y
CONFIG_V4L_USB_DRIVERS=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y

There are some issues with booting kernels using kexec (it doesn't work). It would be great if someone could look into it. I know there's lots of interest in being able to select kernels and rootfs without modifying files and kexec is probably the simplest, so it's definitely worth fixing, I think.

https://github.com/raspberrypi/linux/blob/rpi-patches/arch/arm/mach-bcm2708/vc_mem.c

Looks like a copy/paste bug in case VC_MEM_IOC_MEM_BASE.
mm_vc_mem_size is returned, not mm_vc_mem_base. Plus the comments are the same as the other case statement.

This in on a self-compiled kernel, but on your source with just a minor patch which was already accepted on kernel.org.

the kernel i built is 94fbbc4, i just added this tiny patch from the upstream kernel:
torvalds/linux@9ab2393

i also use the latest firmware, 87a04c0. I'm using the 192Mb configuration.

I compiled the kernel on ubuntu 12.04.

Here is the kernel.img i'm booting on:
http://dl.dropbox.com/u/22600720/rpi/kernel.img

and the .config file I used:
http://dl.dropbox.com/u/22600720/rpi/.config

Compared to the default .config i have added I2C and pvrusb2 and such drivers. I'm plugging a Hauppage HVR-1900 on the pi for TV recording.

The problem occured after about 1h 10 minutes of recording from the device. Concretely it means streaming ~1Mb/s from the USB to the SD card. The CPU is relatively OK when doing that, like at 15%.

Because I have seen frame drops doing that, I am using two processes for the recording, one of which runs at realtime scheduling priority, using that flywheel program described there:
http://www.isely.net/pipermail/pvrusb2/2011-March/003037.html

So after about 1h I get that kernel error. I have had that same problem several times now, the previous time with the same kernel but the original firmware that came with the debian image, but then I didn't get a log in the kern.log, unlike this time.

and here is the full stack trace:

Jun 3 16:24:22 raspberrypi kernel: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT
Jun 3 16:24:22 raspberrypi kernel: Modules linked in: ipv6 fuse tda10048 tda18271 tda8290 tuner cx25840 pvrusb2 dvb_core cx2341x tveeprom v4l2_common videodev i2c_core
Jun 3 16:24:22 raspberrypi kernel: CPU: 0 Not tainted (3.1.9 #2)
Jun 3 16:24:22 raspberrypi kernel: pc : [] lr : [] psr: 60000013
Jun 3 16:24:22 raspberrypi kernel: sp : c8893ea0 ip : 00000000 fp : c8893ecc
Jun 3 16:24:22 raspberrypi kernel: r10: c0388594 r9 : 00000000 r8 : 00000001
Jun 3 16:24:22 raspberrypi kernel: r7 : 00000000 r6 : 00000001 r5 : 00000010 r4 : c8893f78
Jun 3 16:24:22 raspberrypi kernel: r3 : 00000000 r2 : 00000001 r1 : 00000002 r0 : ffffffea
Jun 3 16:24:22 raspberrypi kernel: Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Jun 3 16:24:22 raspberrypi kernel: Control: 00c5387d Table: 0bb64008 DAC: 00000015
Jun 3 16:24:22 raspberrypi kernel: Process top (pid: 1748, stack limit = 0xc8892268)
Jun 3 16:24:22 raspberrypi kernel: Stack: (0xc8893ea0 to 0xc8894000)
Jun 3 16:24:22 raspberrypi kernel: 3ea0: c009ffc0 c885fc40 c009ffc0 c885fc40 00000000 00000000 00000000 c8893f78
Jun 3 16:24:22 raspberrypi kernel: 3ec0: c8893f1c c8893ed0 c00e2cc8 c009ffcc 00000000 00000000 00000001 00000000
Jun 3 16:24:22 raspberrypi kernel: 3ee0: 00000004 00000004 c009ffc0 c03e0970 cb4085b8 c885fc40 c009ffc0 c8893f78
Jun 3 16:24:22 raspberrypi kernel: 3f00: 00000000 cb403d88 c8892000 c8893f78 c8893f2c c8893f20 c00e2f10 c00e2c6c
Jun 3 16:24:22 raspberrypi kernel: 3f20: c8893f4c c8893f30 c00dd464 c00e2ef0 c00dd43c c885fc40 cb403dec c009ffc0
Jun 3 16:24:22 raspberrypi kernel: 3f40: c8893f74 c8893f50 c00a03c0 c00dd448 00008000 c885fc40 00000000 00a02350
Jun 3 16:24:22 raspberrypi kernel: 3f60: c000e148 00000000 c8893fa4 c8893f78 c00a04b0 c00a0348 00a02350 00000000
Jun 3 16:24:22 raspberrypi kernel: 3f80: 00008000 ffffffea 00a02350 0000000b 00a02338 0000008d 00000000 c8893fa8
Jun 3 16:24:22 raspberrypi kernel: 3fa0: c000dfa0 c00a0454 00a02350 0000000b 00000007 00a02350 00008000 00a02350
Jun 3 16:24:22 raspberrypi kernel: 3fc0: 00a02350 0000000b 00a02338 0000008d 00000000 00000000 00000000 bee6270c
Jun 3 16:24:22 raspberrypi kernel: 3fe0: 402da5c8 bee626b8 4037cf80 4037d634 60000010 00000007 00000000 00000000
Jun 3 16:24:22 raspberrypi kernel: Backtrace:
Jun 3 16:24:22 raspberrypi kernel: Function entered at [] from []
Jun 3 16:24:22 raspberrypi kernel: Function entered at [] from []
Jun 3 16:24:22 raspberrypi kernel: Function entered at [] from []
Jun 3 16:24:22 raspberrypi kernel: Function entered at [] from []
Jun 3 16:24:22 raspberrypi kernel: r6:c009ffc0 r5:cb403dec r4:c885fc40 r3:c00dd43c
Jun 3 16:24:22 raspberrypi kernel: Function entered at [] from []
Jun 3 16:24:22 raspberrypi kernel: Function entered at [] from []
Jun 3 16:24:22 raspberrypi kernel: r7:0000008d r6:00a02338 r5:0000000b r4:00a02350
Jun 3 16:24:22 raspberrypi kernel: Code: e1a01fe1 e3a03000 e1530009 01520008 (0c06d0f6)
Jun 3 16:24:22 raspberrypi kernel: ---[ end trace 034411e662b4c9d9 ]---

I have also put the full kern.log there:
http://dl.dropbox.com/u/22600720/rpi/kern.log

Was using (lirc) usb remote with my pi. Everything works fine but it will kernel opps if I

1. unplug the usb remote when there is a lirc client connected
2. any lirc client disconnects from lircd

If I unload the relevant kernel module first however the kernel oops does not happen. When kernel oops does happen the screen, network and everything seems to freeze and the serial console (tail -f /var/log/kernel.log) was flooded was error messages and I was not able to exit the tail by holding ctrl+c. I had to power cycle it get it back.

Here is the kernel.log message when I unplugged the usb remote

http://db.tt/11UZWZJW

kernel messages when I stop lircd with active lirc client

http://db.tt/V26UHG2e

kernel messages when lirc client disconnects from lircd
http://db.tt/PNR9P1Jy

Could the bootloader be changed to load kernel.img at 0x8000 and provide the instructions and data for the first 32K itself?

Alternatively it could load a separate file for the first 32K and then kernel.bin at 0x8000?

Then there's no need to put extra data on the start of the kernel image every time.

setting CONFIG_FRAMEBUFFER_CONSOLE=n results in not working frambuffer.

bcm2708_fb_set_par doesn't get called.

[ 124.796663] BCM2708FB: registering framebuffer (656x416@16)
[ 124.802794] BCM2708FB: register framebuffer (0)

fbset -g 656 416 656 416 16 -fb /dev/fb0

dd if=/dev/zero of=/dev/fb0

dd: writing '/dev/fb0': No such device

Hi there,

I'm using the BCM DMA functions from inside a kernel module.
I'm having a run-time link error as it appears that bcm_dma_wait_idle symbol is not exported. All the other interesting DMA functions are. Is this by design, or is this just an omission?

If it is by design, what is the best way of waiting for a DMA to finish? (IRQ?)

Kind regards,
Simon

RPi usb problems

I'm using the official Raspbian image from the Foundation. This means with the following kernel:

$ uname -a
Linux raspberrypi 3.1.9+ #168 PREEMPT Sat Jul 14 18:56:31 BST 2012 armv6l GNU/Linux

Let me start with what works:

• Plugging my two USB wireless transceivers directly into the Pi (these two devices are from a Logitech K360 keyboard and a Logitech M570 mouse, both have the same IDs of 046d:c52b)
• using a Logilink 7 port USB hub (2x Genesys Logic chipset, 05e3:0608, which is on the known good USB hub list on http://elinux.org/RPi_VerifiedPeripherals#Working_USB_Hubs) which is plugged on one of the Pi's USB ports. Then plugging in one of the two mentioned wireless transceivers.

What doesn't work:

• using both of these wireless transceivers on the hub
• using the hub and plugging one of the transceivers on the hub, the other on the Pi itself
  In both of these cases the network connection has quite some problems and breaks down:

Jul 19 18:52:09 raspberrypi kernel: [ 2476.241913] usb 1-1.2.2: new full speed USB device number 8 using dwc_otg
Jul 19 18:52:10 raspberrypi kernel: [ 2476.345837] usb 1-1.2.2: New USB device found, idVendor=046d, idProduct=c52f
Jul 19 18:52:10 raspberrypi kernel: [ 2476.345883] usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jul 19 18:52:10 raspberrypi kernel: [ 2476.345905] usb 1-1.2.2: Product: USB Receiver
Jul 19 18:52:10 raspberrypi kernel: [ 2476.345921] usb 1-1.2.2: Manufacturer: Logitech
Jul 19 18:52:10 raspberrypi kernel: [ 2476.365082] input: Logitech USB Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.0/input/input2
Jul 19 18:52:10 raspberrypi kernel: [ 2476.368645] generic-usb 0003:046D:C52F.0004: input: USB HID v1.11 Mouse [Logitech USB Receiver] on usb-bcm2708_usb-1.2.2/input0
Jul 19 18:52:10 raspberrypi kernel: [ 2476.384890] input: Logitech USB Receiver as /devices/platform/bcm2708_usb/usb1/1-1/1-1.2/1-1.2.2/1-1.2.2:1.1/input/input3
Jul 19 18:52:10 raspberrypi kernel: [ 2476.386935] generic-usb 0003:046D:C52F.0005: input,hiddev0: USB HID v1.11 Device [Logitech USB Receiver] on usb-bcm2708_usb-1.2.2/input1
Jul 19 18:52:20 raspberrypi kernel: [ 2486.391748] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
Jul 19 18:52:26 raspberrypi kernel: [ 2492.401868] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
Jul 19 18:52:31 raspberrypi kernel: [ 2497.401969] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 18:52:38 raspberrypi kernel: [ 2504.432119] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 18:52:38 raspberrypi kernel: [ 2504.432156] smsc95xx 1-1.1:1.0: eth0: MII is busy in smsc95xx_mdio_read
Jul 19 18:52:43 raspberrypi kernel: [ 2509.502198] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
Jul 19 18:52:48 raspberrypi kernel: [ 2514.662035] usb 1-1.2.2: USB disconnect, device number 8

Another tested wireless transceiver from a Logitech M185 (as shown) with 046d:c52f shows the same behaviour.
If both of these transceivers are already plugged in when the Pi boots, the LAN chip isn't working at all ("RTNETLINK answers: Unknown error 4008" when running "dhclient eth0")!

As soon as I unplug one of the two USB wireless transceivers, everything gets back to normal:

Jul 19 19:08:44 raspberrypi kernel: [ 3470.294650] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
Jul 19 19:08:49 raspberrypi kernel: [ 3475.294761] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:08:54 raspberrypi kernel: [ 3480.294904] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
Jul 19 19:08:59 raspberrypi kernel: [ 3485.295015] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:04 raspberrypi kernel: [ 3490.295129] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000114
Jul 19 19:09:09 raspberrypi kernel: [ 3495.295251] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:14 raspberrypi kernel: [ 3500.295384] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000118
Jul 19 19:09:19 raspberrypi kernel: [ 3505.295515] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:33 raspberrypi kernel: [ 3519.395813] smsc95xx 1-1.1:1.0: eth0: Failed to write register index 0x00000008
Jul 19 19:09:33 raspberrypi kernel: [ 3519.395896] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:39 raspberrypi kernel: [ 3525.405978] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:44 raspberrypi kernel: [ 3531.146107] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:09:51 raspberrypi kernel: [ 3537.416253] smsc95xx 1-1.1:1.0: eth0: Failed to read register index 0x00000114
Jul 19 19:10:01 raspberrypi kernel: [ 3547.309062] usb 1-1.2.3.1: USB disconnect, device number 10
Jul 19 19:10:01 raspberrypi kernel: [ 3547.315758] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
Jul 19 19:10:01 raspberrypi kernel: [ 3547.350002] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1

I'm using a RPi from RS Online with their 1.2 A power supply. Please let me know if you need any further information.

Hi:
Using rtorrent or tranmission gives me a kernel panic, Can't find the kernel dump.

/proc/vc-mem won't be accepted into the mainline kernel because it's not what /proc is for - this could become a problem if userspace libraries need to access it and it disappears in a future kernel.

It's a mix of textual information and a memory mmap device, so the text/ioctl information can be moved to sysfs attributes.

These are virtual text files in /sys that contain a single value, e.g. /sys/devices/vc_mem.N/mem_base, /sys/devices/vc_mem.N/mem_size, /sys/devices/vc_mem.N/mem_phys_addr (the name "vc_mem.N" would vary based on how it's specified in the device tree, e.g. "vc_mem.2" if it's the third device without an io/memory base). They could be populated from device tree so the GPU bootloader could change them, although making them properly addressable when it's not simply overlapping the ARM memory could be complicated.

Could mmapping /dev/mem be used instead of mmapping /proc/vc-mem?
If you know the memory base you know where to access it in /dev/mem.

Suggestion for property/value message passing interface from ARM to GPU.

We have a generic message passing structure. The first word is always the property of interest (could be small integers or fourcc codes).
The remainder of the structure is property specific data whose length depends on the property. This data is used for both input and output data.

define MBOX_CHAN_GETPROP 8

define MBOX_CHAN_SETPROP 9

// generic property structure
struct property_s {
uint32_t property;
uint32_t data[];
}

// get property
void *property = <>
uint32_t success;
mbox_write(MBOX_CHAN_GETPROP, property);
mbox_read(MBOX_CHAN_GETPROP, &success);

// set property
void *property = <>
uint32_t success;
mbox_write(MBOX_CHAN_SETPROP, property);
mbox_read(MBOX_CHAN_SETPROP, &success);

Example:

define CLOCK_EMMC 1

struct property_one_word_s {
uint32_t property;
uint32_t value;
} *emmc_clock;

uint32_t success;
emmc_clock =
emmc_clock->property = CLOCK_EMMC;
emmc_clock->value = 50000000;
_wmb();
mbox_write(MBOX_CHAN_SETPROP, emmc_clock);
mbox_read(MBOX_CHAN_SETPROP, &success);
_rmb();

We could also use this to handle the existing framebuffer allocation and power control in a more consistent way.

Any config.txt properties can be retrieved with this mechanism. E.g.
struct property_one_word_one_string_s {
uint32_t property;
uint32_t value;
uint8_t string[MAX_STRING];
} *config_txt;

Similarly cmdline.txt and other ATAGs (e.g. memory size) can be got.

Properties that can be got or set:
CLOCK_EMMC
CLOCK_UART
CLOCK_ARM
CLOCK_CORE
CLOCK_V3D
CLOCK_H264
CLOCK_ISP
POWER_CONTROL
FRAMEBUFFER

Properties that can be got:
CMDLINE
CONFIG_STRING
SERIAL_NUM
BOARD_REV
MAC_ADDRESS
DISPLAY_WIDTH
DISPLAY_HEIGHT
DISPLAY_DEPTH
DMA_CHANS
MEMORY_SIZE

Any additional suggestions?

Running a program under 'X' with:

/usr/bin/xinit /usr/sbin/xinitrc -- /usr/bin/Xfbdev
/usr/bin/xinit /usr/sbin/xinitrc /usr/bin/Xfbdev
resulted in the following when I used Ctrl-C to exit:

[  137.795994] bcm2708_fb_check_var info(c78e9400) 1024x768 (1024x768), 1572864, 16
[  137.796035] bcm2708_fb_check_var var(c7a49d98) 1024x768 (1024x768), 16, 786432
[  137.796060] bcm2708_fb_set_par info(c78e9400) 1024x768 (1024x768), 1572864, 16
[  137.796148] ------------[ cut here ]------------
[  137.796201] WARNING: at arch/arm/mm/ioremap.c:207 __arm_ioremap_pfn_caller+0x1a4/0x1bc()
[  137.796216] Modules linked in:
[  137.796278] [<c0014ee4>] (unwind_backtrace+0x0/0xfc) from [<c03eb968>] (dump_stack+0x20/0x24)
[  137.796320] [<c03eb968>] (dump_stack+0x20/0x24) from [<c002e8c0>] (warn_slowpath_common+0x5c/0x74)
[  137.796357] [<c002e8c0>] (warn_slowpath_common+0x5c/0x74) from [<c002e904>] (warn_slowpath_null+0x2c/0x34)
[  137.796421] [<c002e904>] (warn_slowpath_null+0x2c/0x34) from [<c0019714>] (__arm_ioremap_pfn_caller+0x1a4/0x1bc)
[  137.796463] [<c0019714>] (__arm_ioremap_pfn_caller+0x1a4/0x1bc) from [<c00197bc>] (__arm_ioremap_caller+0x68/0x70)
[  137.796517] [<c00197bc>] (__arm_ioremap_caller+0x68/0x70) from [<c00197e0>] (__arm_ioremap+0x1c/0x20)
[  137.796565] [<c00197e0>] (__arm_ioremap+0x1c/0x20) from [<c026ac28>] (bcm2708_fb_set_par+0x11c/0x190)
[  137.796624] [<c026ac28>] (bcm2708_fb_set_par+0x11c/0x190) from [<c025d91c>] (fb_set_var+0x13c/0x2a8)
[  137.796684] [<c025d91c>] (fb_set_var+0x13c/0x2a8) from [<c025ddbc>] (do_fb_ioctl+0x334/0x610)
[  137.796720] [<c025ddbc>] (do_fb_ioctl+0x334/0x610) from [<c025e0e4>] (fb_ioctl+0x4c/0x5c)
[  137.796780] [<c025e0e4>] (fb_ioctl+0x4c/0x5c) from [<c0105918>] (do_vfs_ioctl+0x8c/0x5a8)
[  137.796818] [<c0105918>] (do_vfs_ioctl+0x8c/0x5a8) from [<c0105e7c>] (sys_ioctl+0x48/0x6c)
[  137.796861] [<c0105e7c>] (sys_ioctl+0x48/0x6c) from [<c000dd80>] (ret_fast_syscall+0x0/0x48)
[  137.796902] ---[ end trace 671f3d1a61f80c7a ]---
[  137.955733] kernel BUG at drivers/video/bcm2708_fb.c:251!
[  137.966062] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[  137.974847] pgd = c6d20000
[  137.977602] [00000000] *pgd=06ddd831, *pte=00000000, *ppte=00000000
[  137.984472] Internal error: Oops: 817 [#1] PREEMPT

This is my own build (using Yocto Project), but I don't think that's the cause given the point of failure.

1. Your struct fbinfo_s uses int but in fact needs the bytes to precisely match the firmware interface. Also the values are in practice unsigned anyway, so use u32 to be clear
2. Volatile - this wrecks your code generation and gcc in some releases has been known to get it rather wrong. If the firmware updates the block only when you ask it then you just need to add wmb(); before it and rmb(); after it to cover compiler temporaries. They provide write and read barriers instead of the mess the C language volatile makes.
3. The code appears derived from the cirrusfb driver. That driver is copyrighted yet the copyright credits for the original have been stripped. We take such things very seriously, and stripping authorship credit is a GPL violation so this really wants a 'derived from ... etc' putting in by Broadcom. Nothing wrong with it being derived from and still GPL but the credit matters.
4. ioremap on the screen base can fail. It's not clear what you should do in that case but it probably should at least BUG(), otherwise you'll have a screen at NULL so anyone making it fail can now patch low physical memory at will
5. If you want the PI logo to get into the upstream you'll need to do it differently to hacking the existing logo
6. You set various HWACCEL bits you don't have HWACCEL for ?
7. General style - // comments, lots of printks that can go but appear to be still needed debug, pr_info etc not printk() and where possible dev_dbg() etc. lower case for the module arguments. Usually mundanities basically.

Older games that operate in 8 bpp 256 colors mode, expect to be able to choose which colors they want in their palette.
However setting colors does not seem to be implemented. ( bcm2708_fb_setcolreg( ) does nothing for color numbers over 16?)

Is this something that might be added to a future version, or is this not supported by the hardware?

I have two USB devices that fail to work when plugged into any of the onboard USB ports. The following appears in dmesg:

DEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACK

One is the aluminum Apple USB keyboard, the other is a realtek wifi adapter. Both of the devices work if plugged into a powered USB hub (I haven't tried when the hub is not AC powered.) Some folks are suggesting that this is not a power problem though, that it could be a USB issue that is inadvertently solved when a hub is used.

So - is this a power issue or a USB timing issue?

I'm building from source (Yocto Project) and the latest kernels just give me the 'four-colour' screen.

1. I'm using the latest firmware (raspberrypi/firmware@9308c7e);
2. 3fc65f9 is the last kernel that I can get to run.

Is there something new that I need to add to config.txt or similar?

I am seeing extreme packet loss/networking issues when launching X/LXDE, but not at the console. In an attempt to rule out an issue with my power supply setup, I have gone through the troubleshooting steps below.

Hardware configuration:
-Pi Power Supply -> HP Touchpad 5.3V/2A supply, 24AWG USB A to Micro B cable
-Pi Storage -> SandDisk Extreme HD Video 4GB 20MB/s Class 6 SDHC Card
-Ethernet connected directly to router
-USB Hub -> Belkin F5U307 w/PS0538 5V 3.5A power supply
--USB Mouse (connected to hub) -> Logitech Wireless, 100mA receiver
--Keyboard Adapter (connected to hub) -> Belkin F5U119vE PS/2 to USB Adapter
--PS/2 Keyboard (connected to keyboard adapter) -> IBM KPD8923
-Pi Monitor - Lenovo L220x connected via HDMI->DVI Cable

Software Configurations:
I used the latest Debian Squeeze image, with the latest kernel (PREEMPT #89) installed via rpi-update and the Debian system fully updated using apt-get upgrade.

I did the following:

1. On another machine on the network - Used "python -m http.server" in Python 3.2.2 to create an http server. Picked a random ~90MB file on the machine as a test download over http
2. On the Pi - Installed the 'stress' utility using apt-get. Used "stress -c 15" to load the Pis CPU to 100%. Started htop at the console
3. On the other machine on the network - SSHed into the Pi and ran wget in the ssh terminal to download the 90MB test.zip onto the Pi using http over the local network. Download speeds ~2.9-3.0 MB/s. ssh window responsiveness is stable. Repeated over a period of 10 minutes to allow the Pis CPU to reach a steady state temperature/power draw at 100% CPU load. Started a final instance of the download
4. On the Pi (do this while the download is running in the ssh window!) - Exited htop. Ran "Startx"
5. On the other machine - Observed that the download running in the ssh window on the Pi slowed from ~3MB/s to ~44KB/s as soon as X/LXDE loaded . (The 'stress' command is still running in the background, loading the CPU to the same constant 100% as with the console download tests in Step 3)
6. On the Pi - Exited X/LXDE ("Logout")
7. On the other machine - Observed that the download returned to its original ~3MB/s speed as soon as the system returned to the console.
8. On the Pi - Observed that there are error messages in the dmesg log releated to the eth0 driver - see http://paste.debian.net/172123

I do not believe this is solely a power related issue, as others on this forum have repeatedly stated when users have asked about it. I can peg my Pis CPU at 100% for > 10 minutes at the console and Ethernet works just find until I start X/LXDE (with the same stress programs still running). Only then does the Ethernet drop out. No change in hardware configuration between the two cases (100% CPU at console, 100% CPU with X/LXDE running).

Other reports of similar issues on the Raspberry Pi forums:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=6928
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=6042
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=6827#p87855
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=6677
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=7075
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=7445
http://forum.stmlabs.com/showthread.php?tid=441&pid=3258#pid3258

This will need splitting up - eg big chunks of it are for the USB driver and that is probably a "no hope" item in itself.

1. Platform code references stuff that doesn't seem PI relevant or included (eg touchscreen)
2. Minor style stuff - usual plus strip out LINUX_VERSION_CODE checks when upstreaming
3. DMA manager - you assume there is only one, so you should check that in bcm_dmaman_probe()
4. General - bound to get asked if you can not use devicetree for all the device and IRQ description rather than yet more platform files.
5. Some bits (eg pcm_power) need a fairly serious revisit and exposing via the properly kernel power interfaces eventually. Also lose the semaphores for mutexes as they are not counting. Otherwise you muck up real time.
6. vc_mem.c - LOG_xxx crap - and in general a nop hoper that needs major work (so again best split out)
7. MMC - split this off because it needs major work to get anywhere upstream and probably to be done in small steps beginning with PIO. For MMC I think a lot of it may well look better as of 3.2 because MMC/SDHC now has a proper power infrastructure

For this I think you've got a good chance of getting the various quirks, basic board bits upstream easily. A lot of the other more driver-ish stuff is going to need stuff addressing.

http://blog.zx2c4.com/749
your fs/proc/base.c is vulnerable too

What's the correct device model to reference as the machine type and in any device drivers?

Hi,

While my 'pi was doing real work for me it crashed 15 minutes after I had left. :-(

It produced the attached "ooops" (provided I can find how to attach files) .

It's reading from an SD card (microSD to be exact), and writing the data over a TPC connection to a server. This is progressing at 300k/sec. (with 32G total, that is expected tot take 29 hours).

It has now been running since this morning: about 14 hours.

Could you clarify which devices can be powered on or off?

It looks like only the bits for the SD card and USB host have any effect. USB is currently left powered on all the time, so is there any significant benefit to powering down the SD card? Can USB be powered down with devices attached or will they be reset when this happens? (Linux can can handle determining when it is safe to do this.)

There appears to be no way to query for what is currently powered on so I can't see this integrating well with the kernel's power management unless everything is turned off at boot, otherwise as soon as one of either the SD or USB host devices is registered it's going to turn that on and turn everything else off.

I'm able to send any of bits 0..27 set to 1 to the power mailbox channel and it'll respond with the list of powered devices. Sending all bits 0 results in no response. Is there anything else I've missed available in its API? Is everything off at boot? It has just loaded everything from the SD card so that may still be powered on.

Hello, I rsync the folder on the sd card (normal folder /usr/portage/), it use the intensive the network and sd card. After 10min of work all it crashed, I need hard reboot. I'm under console, and the linux put the back screen after inactivity, I can't press key board my keyboard not work (see the previous reported bug).
But I have noted lot of similar problem of stability when you use the sd card (read + write). My sd card is kingstone class 4 of 16GB.
Freeze mean for me: no responds to the ping.

Well, by default the Linux kernel (libc) has a file size limit in 2Gb. If someone want to use RPi as Samba server, would need it.

Hello, with the last compression to try fix the compression:
arch/arm/mach-bcm2708/include/mach/uncompress.h:61 error: UART0_CLOCK underclared

When running wmii-hg on Arch Linux Arm on the Raspberry Pi with my favourite wmiirc, the window decoration colours are modified in a bizarre way I have yet to identify.

Screenshots:
distortion: pi (photo)
expected: arch x86 box (photo)

What's weird about this (and what leads me to believe it's a low-level issue) is that when run in a tightvnc x server, the colours load and render fine. Additionally, everything else under the broken wmii instances works fine — images, webpages, etc. render perfectly. I assume this means it's a bug in whatever system wmii uses to initially select its colours.

If this doesn't belong here, I apologise and will be willing to resubmit elsewehere.

Can the FS files for the emergency kernel be made public? They're referred to as ../target_fs in the emergency kernel config, but are nowhere to be found in the repo.

I'm trying to build something that runs entirely out of a ramdisk, and I'm having trouble getting /anything/ running in a ramdisk, so it'd be nice to be able to use the emergency one as a reference.

The Linux kernel has options for CPU_V6K , but your kernel patches force CPU_V6 only. The kernel overrides your toolchain so that kernel modules are being built for v6 not v6k

This one actually looks fine.

We are moving to a watchdog class so a lot of the code can go eventually but nothing here beyond minor style (pr_ etc) and the already marked incomplete bits

The Linux kernel supports setting the hardware address by ioctl

ifconfig eth0 down
ifconfig eth0 hw aa:bb:cc:dd:ee:ff
ifconfig eth0 up

So this patch can be dropped and has no chance of going upstream

I have been using omxplayer to play video from Windows samba drives on Arch Linux for some time without any problems. Yesterday I did a system upgrade including linux-raspberrypi 3.1.9-28 -> 3.1.9-30. Since then the movie playback has frozen once in each of the two movies I've watched. /var/log/everything.log gives:

kernel: CIFS VFS: Send error in read = -512

After this, I cannot unmount (umount: device is busy) and playback can only be resumed after a reboot.

cifs-utils has not been updated since installation and I believe that the error originates from the kernel update. In addition to the CIFS errors, I have also experienced an unexpected ssh client disconnection (RPI was host).

if i enable CONFIG_MMC_BCM2708 i get:

CC drivers/mmc/host/bcm2708_mci.o
drivers/mmc/host/bcm2708_mci.c: In function 'bcm2708_mci_get_cd':
drivers/mmc/host/bcm2708_mci.c:477:117: error: 'GP_LEV0' undeclared (first use in this function)
drivers/mmc/host/bcm2708_mci.c:477:117: note: each undeclared identifier is reported only once for each function it appears in
make[4]: *** [drivers/mmc/host/bcm2708_mci.o] Error 1
make[3]: *** [drivers/mmc/host] Error 2
make[2]: *** [drivers/mmc] Error 2
make[1]: *** [drivers] Error 2

'GP_LEV0' is only used in drivers/mmc/host/bcm2708_mci.c and not declared.

I updated my R-Pi kernel to #125.

I have a USB serial device (ID: 0403:6001) and I have a python code doing all the read/write. After a while the program stop working and generated kernel panic. The message is as follows:

Unable to handle kernel paging request at virtual address1757d280
pgd = caf14000
[1757d280] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT

Entering kdb (current=0xcaf605c0, pid 1142) Oops: (null)
due to oops @ 0xbf0118e4

Pid: 1142, comm: python
CPU: 0 Not tainted (3.1.9+ #1225)
PC is at ftdi_process_read_urb+0x9c/0x320[ftdi_sio]
LR is at tty_port_tty_get+0x58/0x8c
pc : [] lr: []psr: 20000193
sp: caf45c60 ip: caf45c50 fp: caf45cb4
....
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user

Since it's a picture I took a picture and type most of it.

Thanks

By the way is there a better way to capture the kernel panic event?

Any possibility to add PPP options to support GSM modems?

Example template .dts: http://s85.org/6o9R3Ev2:view
Example compiled .dtb: http://s85.org/6A9h2c6X:raw

Could you automatically populate the following fields in the device tree file?

/memreserve/ (u32 offset, u32 size of VideoCore memory - this is not a normal attribute)
/memory/reg with the u32 memory range (e.g. 0x0 0x10000000 for 256MB)
/chosen/bootargs with the contents of the command line file (without any additional arguments)

/system/revision with the u32 system revision
/system/serial with the high u32 followed by the low u32 of the serial number

/axi/usb/hub/ethernet/mac-address with the system mac address (this is six u8 bytes in network byte order, e.g. 00:11:22:33:44:55)

/axi/dma/broadcom,channels with the u32 mask of allowed channels (this is currently on the command line as dma.dmachans)

/axi/sdhci/clock-frequency with the u32 clock frequency in Hz
/axi/uart0/clock-frequency with the u32 clock frequency in Hz

/display/broadcom,width with the u32 display pixel width (this is currently on the command line as bcm2708_fb.fbwidth)
/display/broadcom,height with the u32 display pixel height (this is currently on the command line as bcm2708_fb.fbheight)
/display/broadcom,depth with the u32 display bit depth (this is currently on the command line as bcm2708_fb.fbdepth)

If there's anything you think I've missed let me know (the setting for dwc_otg.lpm_enable=0 can be put in the static template so the GPU doesn't need to provide it).

There's a definition of __VCCOREVER__ in drivers/misc/vc04_services/Makefile used by drivers/misc/vc04_services/interface/vchi/vchi_cfg.h included by sound/arm/Makefile that isn't in sound/arm/Makefile

Given that the onboard sound system can't be changed, wouldn't it make sense for the sound driver to be built-in module? It seems as if this would make sound easier to use for less experienced users.

One thing I have noticed if it is configured as built-in, it currently loads after the ALSA system and therefore isn't ready soon enough at boot time.

I tried the serial port on Rpi to run expEYES and everything is working fine. Whenever the '/dev/ttyAMA0' is opened , one byte (value = 0xF8) is send to the connected device. I just added a work around in the expEYES code on the uC. The code used for testing it is attached. The byte send is tracked on the uC end using a debugger.

Ajith
========================== code used =================================

include <fcntl.h>

include <termios.h>

include <stdio.h>

include <stdlib.h>

include <string.h>

include <unistd.h>

int fd;

int main()
{
char ss[10];
char c;

fd = open ("/dev/ttyAMA0", O_RDWR | O_NOCTTY);
if (fd < 0)
{
fprintf(stderr,"ERROR opening AMA0\n");
exit(0);
}
return 0;
}

Tried to communicate to a serial device using the MCP2200 converter. It works well if there are only 2 USB devices in total. If both keyboard and mouse are plugged in it gives error but works perfectly is only one of them are present.

The problem can be tested using an MCP2200 breakout board, like

http://dangerousprototypes.com…..b-built-6/

by shorting the Rx and Tx pins, and running the following program.

————————————————————————–

import serial, time
fd = serial.Serial('/dev/ttyACM0', 38400, stopbits=1,
timeout = 1.0, parity=serial.PARITY_EVEN)
fd.flush()

for k in range(256):
fd.write(chr(k))
time.sleep(0.01) #some delay
res = fd.read()
if ord(res) != k:
print 'ERROR ', k, ord(res)

——————————————————————————-
The kernel error massage is:

Apr 17 14:52:11 raspberrypi kernel:
Apr 17 14:52:11 raspberrypi kernel: INFO:: periodic_channel_available: Total channels: 8, Periodic: 6, Non-periodic: 2
Apr 17 14:52:11 raspberrypi kernel:
Apr 17 14:52:11 raspberrypi kernel: INFO:: schedule_periodic: No host channel available for periodic transfer.
Apr 17 14:52:11 raspberrypi kernel:
Apr 17 14:52:11 raspberrypi kernel: ERROR::dwc_otg_hcd_urb_enqueue:487: DWC OTG HCD URB Enqueue failed adding QTD. Error status -4008

Ajith

http://www.raspberrypi.org/forum/troubleshooting/usb-cdc-device-mcp2200-error?value=mcp2200&type=1&include=1&search=1&ret=all