Activity log for bug #1328746

Date Who What changed Old value New value Message
2014-06-11 02:28:10 Mark Haidekker bug added bug
2014-06-11 02:30:10 Brad Figg linux (Ubuntu): status New Incomplete
2014-06-11 02:34:32 Mark Haidekker description This bug has been around for a while. I have seen it in the forums circa 2007, and I have provided a solution in 2009. Since the modified code never found its way into the mainstream kernels, I am issuing the fix as a bug report. The bug concerns the Soundblaster Audigy cards with the emu10k1 chip in both i386 and amd64 architectures, in any kernel (standard, RT etc). They have on-board joystick MIDI. There is an optional front-panel module, which provides its own MIDI UART. Under Liunux, the front MIDI does not work. People wuth dual-boot systems have reported that booting Windows first, then rebooting into Linux makes the UART function properly. The cause for the bug lies in the fact that the front panel MIDI is routed through a microcontroller (resides in the front panel module), and this microcontroller needs a defined reset signal. Up to this point, the GPIO _levels_ are initialized correctly, but the reset pulse is never issued. The bug can be fixed in the file linux-source-3.13.0/sound/pci/emu10k1/emumpu401.c in the function snd_emu10k1_audigy_midi(). The proposed patch follows right after the present initialization of the second UART: int snd_emu10k1_audigy_midi(struct snd_emu10k1 *emu) { struct snd_emu10k1_midi *midi; int err; unsigned int val; /* Needed in GPOUT2 pulse initialization */ midi = &emu->midi; if ((err = emu10k1_midi_init(emu, midi, 0, "Audigy MPU-401 (UART)")) < 0) return err; midi->tx_enable = INTE_MIDITXENABLE; midi->rx_enable = INTE_MIDIRXENABLE; midi->port = A_MUDATA1; midi->ipr_tx = IPR_MIDITRANSBUFEMPTY; midi->ipr_rx = IPR_MIDIRECVBUFEMPTY; midi->interrupt = snd_emu10k1_midi_interrupt; midi = &emu->midi2; if ((err = emu10k1_midi_init(emu, midi, 1, "Audigy MPU-401 #2")) < 0) return err; midi->tx_enable = INTE_A_MIDITXENABLE2; midi->rx_enable = INTE_A_MIDIRXENABLE2; midi->port = A_MUDATA2; midi->ipr_tx = IPR_A_MIDITRANSBUFEMPTY2; midi->ipr_rx = IPR_A_MIDIRECVBUFEMPTY2; midi->interrupt = snd_emu10k1_midi_interrupt2; /*** NEW CODE *** Pulse reset line for the second UART */ val = inl(emu->port + A_IOCFG); outl (val | A_IOCFG_GPOUT2, emu->port + A_IOCFG); udelay(10); /* udelay is a bad kludge, but remember that this is called only once on startup */ outl (val, emu->port + A_IOCFG); return 0; } I suspect that my use of udelay would make a real kernel hacker cringe, but the level of GPOUT2 needs to remain high for a few microseconds to provide a stable RESET signal. Anyway, this fixes the problem. I have applied the patch for pretty much every major upgrade of the kernel. It is sufficient to compile the module snd-emu10k1.ko and replace it in the module tree. This bug has been around for a while. I have seen it in the forums circa 2007, and I have provided a solution in 2009. Since the modified code never found its way into the mainstream kernels, I am issuing the fix as a bug report. The bug concerns the Soundblaster Audigy cards with the emu10k1 chip in both i386 and amd64 architectures, in any kernel (standard, RT etc). They have on-board joystick MIDI. There is an optional front-panel module, which provides its own MIDI UART. Under Linux, the front MIDI does not work. People with dual-boot systems have reported that booting Windows first, then rebooting into Linux makes the UART function properly. The cause for the bug lies in the fact that the front panel MIDI is routed through a microcontroller (resides in the front panel module), and this microcontroller needs a defined reset signal once after power-up. Up to this point, the GPIO _levels_ are initialized correctly, but the reset _pulse_ is never issued. Essentially, the emu10k1 chip's GPIO2 needs to be pulled high for a brief interval. The bug can be fixed in the file linux-source-3.13.0/sound/pci/emu10k1/emumpu401.c in the function snd_emu10k1_audigy_midi(). The proposed patch follows right after the present initialization of the second UART (note the added variable "val" to store the GPIO bits): int snd_emu10k1_audigy_midi(struct snd_emu10k1 *emu) {  struct snd_emu10k1_midi *midi;  int err;  unsigned int val; /* Needed in GPOUT2 pulse initialization */  midi = &emu->midi;  if ((err = emu10k1_midi_init(emu, midi, 0, "Audigy MPU-401 (UART)")) < 0)   return err;  midi->tx_enable = INTE_MIDITXENABLE;  midi->rx_enable = INTE_MIDIRXENABLE;  midi->port = A_MUDATA1;  midi->ipr_tx = IPR_MIDITRANSBUFEMPTY;  midi->ipr_rx = IPR_MIDIRECVBUFEMPTY;  midi->interrupt = snd_emu10k1_midi_interrupt;  midi = &emu->midi2;  if ((err = emu10k1_midi_init(emu, midi, 1, "Audigy MPU-401 #2")) < 0)   return err;  midi->tx_enable = INTE_A_MIDITXENABLE2;  midi->rx_enable = INTE_A_MIDIRXENABLE2;  midi->port = A_MUDATA2;  midi->ipr_tx = IPR_A_MIDITRANSBUFEMPTY2;  midi->ipr_rx = IPR_A_MIDIRECVBUFEMPTY2;  midi->interrupt = snd_emu10k1_midi_interrupt2;  /*** NEW CODE *** Pulse reset line for the second UART */  val = inl(emu->port + A_IOCFG);  outl (val | A_IOCFG_GPOUT2, emu->port + A_IOCFG);  udelay(10); /* udelay is a bad kludge, but remember that this is called only once on startup */  outl (val, emu->port + A_IOCFG);  return 0; } I suspect that my use of udelay would make a real kernel hacker cringe, but the level of GPOUT2 needs to remain high for a few microseconds to provide a stable RESET signal. Anyway, this fixes the problem. I have applied the patch for pretty much every major upgrade of the kernel. It is sufficient to compile the module snd-emu10k1.ko and replace it in the module tree.
2014-06-11 03:19:25 Mark Haidekker tags apport-collected trusty
2014-06-11 03:19:27 Mark Haidekker description This bug has been around for a while. I have seen it in the forums circa 2007, and I have provided a solution in 2009. Since the modified code never found its way into the mainstream kernels, I am issuing the fix as a bug report. The bug concerns the Soundblaster Audigy cards with the emu10k1 chip in both i386 and amd64 architectures, in any kernel (standard, RT etc). They have on-board joystick MIDI. There is an optional front-panel module, which provides its own MIDI UART. Under Linux, the front MIDI does not work. People with dual-boot systems have reported that booting Windows first, then rebooting into Linux makes the UART function properly. The cause for the bug lies in the fact that the front panel MIDI is routed through a microcontroller (resides in the front panel module), and this microcontroller needs a defined reset signal once after power-up. Up to this point, the GPIO _levels_ are initialized correctly, but the reset _pulse_ is never issued. Essentially, the emu10k1 chip's GPIO2 needs to be pulled high for a brief interval. The bug can be fixed in the file linux-source-3.13.0/sound/pci/emu10k1/emumpu401.c in the function snd_emu10k1_audigy_midi(). The proposed patch follows right after the present initialization of the second UART (note the added variable "val" to store the GPIO bits): int snd_emu10k1_audigy_midi(struct snd_emu10k1 *emu) {  struct snd_emu10k1_midi *midi;  int err;  unsigned int val; /* Needed in GPOUT2 pulse initialization */  midi = &emu->midi;  if ((err = emu10k1_midi_init(emu, midi, 0, "Audigy MPU-401 (UART)")) < 0)   return err;  midi->tx_enable = INTE_MIDITXENABLE;  midi->rx_enable = INTE_MIDIRXENABLE;  midi->port = A_MUDATA1;  midi->ipr_tx = IPR_MIDITRANSBUFEMPTY;  midi->ipr_rx = IPR_MIDIRECVBUFEMPTY;  midi->interrupt = snd_emu10k1_midi_interrupt;  midi = &emu->midi2;  if ((err = emu10k1_midi_init(emu, midi, 1, "Audigy MPU-401 #2")) < 0)   return err;  midi->tx_enable = INTE_A_MIDITXENABLE2;  midi->rx_enable = INTE_A_MIDIRXENABLE2;  midi->port = A_MUDATA2;  midi->ipr_tx = IPR_A_MIDITRANSBUFEMPTY2;  midi->ipr_rx = IPR_A_MIDIRECVBUFEMPTY2;  midi->interrupt = snd_emu10k1_midi_interrupt2;  /*** NEW CODE *** Pulse reset line for the second UART */  val = inl(emu->port + A_IOCFG);  outl (val | A_IOCFG_GPOUT2, emu->port + A_IOCFG);  udelay(10); /* udelay is a bad kludge, but remember that this is called only once on startup */  outl (val, emu->port + A_IOCFG);  return 0; } I suspect that my use of udelay would make a real kernel hacker cringe, but the level of GPOUT2 needs to remain high for a few microseconds to provide a stable RESET signal. Anyway, this fixes the problem. I have applied the patch for pretty much every major upgrade of the kernel. It is sufficient to compile the module snd-emu10k1.ko and replace it in the module tree. This bug has been around for a while. I have seen it in the forums circa 2007, and I have provided a solution in 2009. Since the modified code never found its way into the mainstream kernels, I am issuing the fix as a bug report. The bug concerns the Soundblaster Audigy cards with the emu10k1 chip in both i386 and amd64 architectures, in any kernel (standard, RT etc). They have on-board joystick MIDI. There is an optional front-panel module, which provides its own MIDI UART. Under Linux, the front MIDI does not work. People with dual-boot systems have reported that booting Windows first, then rebooting into Linux makes the UART function properly. The cause for the bug lies in the fact that the front panel MIDI is routed through a microcontroller (resides in the front panel module), and this microcontroller needs a defined reset signal once after power-up. Up to this point, the GPIO _levels_ are initialized correctly, but the reset _pulse_ is never issued. Essentially, the emu10k1 chip's GPIO2 needs to be pulled high for a brief interval. The bug can be fixed in the file linux-source-3.13.0/sound/pci/emu10k1/emumpu401.c in the function snd_emu10k1_audigy_midi(). The proposed patch follows right after the present initialization of the second UART (note the added variable "val" to store the GPIO bits): int snd_emu10k1_audigy_midi(struct snd_emu10k1 *emu) {  struct snd_emu10k1_midi *midi;  int err;  unsigned int val; /* Needed in GPOUT2 pulse initialization */  midi = &emu->midi;  if ((err = emu10k1_midi_init(emu, midi, 0, "Audigy MPU-401 (UART)")) < 0)   return err;  midi->tx_enable = INTE_MIDITXENABLE;  midi->rx_enable = INTE_MIDIRXENABLE;  midi->port = A_MUDATA1;  midi->ipr_tx = IPR_MIDITRANSBUFEMPTY;  midi->ipr_rx = IPR_MIDIRECVBUFEMPTY;  midi->interrupt = snd_emu10k1_midi_interrupt;  midi = &emu->midi2;  if ((err = emu10k1_midi_init(emu, midi, 1, "Audigy MPU-401 #2")) < 0)   return err;  midi->tx_enable = INTE_A_MIDITXENABLE2;  midi->rx_enable = INTE_A_MIDIRXENABLE2;  midi->port = A_MUDATA2;  midi->ipr_tx = IPR_A_MIDITRANSBUFEMPTY2;  midi->ipr_rx = IPR_A_MIDIRECVBUFEMPTY2;  midi->interrupt = snd_emu10k1_midi_interrupt2;  /*** NEW CODE *** Pulse reset line for the second UART */  val = inl(emu->port + A_IOCFG);  outl (val | A_IOCFG_GPOUT2, emu->port + A_IOCFG);  udelay(10); /* udelay is a bad kludge, but remember that this is called only once on startup */  outl (val, emu->port + A_IOCFG);  return 0; } I suspect that my use of udelay would make a real kernel hacker cringe, but the level of GPOUT2 needs to remain high for a few microseconds to provide a stable RESET signal. Anyway, this fixes the problem. I have applied the patch for pretty much every major upgrade of the kernel. It is sufficient to compile the module snd-emu10k1.ko and replace it in the module tree. --- ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC2: mhaidekk 2321 F.... pulseaudio /dev/snd/controlC1: mhaidekk 2321 F.... pulseaudio /dev/snd/controlC0: mhaidekk 2321 F.... pulseaudio CRDA: Error: [Errno 2] No such file or directory CurrentDesktop: KDE DistroRelease: Ubuntu 14.04 EcryptfsInUse: Yes HibernationDevice: RESUME=UUID=b15a827a-7aa7-4add-a9b4-cb68262cfddd InstallationDate: Installed on 2013-12-31 (161 days ago) InstallationMedia: Kubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130822) IwConfig: eth1 no wireless extensions. lo no wireless extensions. MachineType: BIOSTAR Group TA970 NonfreeKernelModules: fglrx Package: linux (not installed) ProcFB: 0 VESA VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-29-generic root=UUID=11a18cc0-0c2e-4ce8-9acd-44c5bb8820e2 ro ProcVersionSignature: Ubuntu 3.13.0-29.53-generic 3.13.11.2 RelatedPackageVersions: linux-restricted-modules-3.13.0-29-generic N/A linux-backports-modules-3.13.0-29-generic N/A linux-firmware 1.127.2 RfKill: Tags: trusty Uname: Linux 3.13.0-29-generic x86_64 UpgradeStatus: Upgraded to trusty on 2014-06-07 (3 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 01/14/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.4 dmi.board.asset.tag: None dmi.board.name: TA970 dmi.board.vendor: BIOSTAR Group dmi.chassis.asset.tag: None dmi.chassis.type: 3 dmi.chassis.vendor: BIOSTAR Group dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.4:bd01/14/2013:svnBIOSTARGroup:pnTA970:pvr:rvnBIOSTARGroup:rnTA970:rvr:cvnBIOSTARGroup:ct3:cvr: dmi.product.name: TA970 dmi.sys.vendor: BIOSTAR Group
2014-06-11 03:19:28 Mark Haidekker attachment added AlsaInfo.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129343/+files/AlsaInfo.txt
2014-06-11 03:19:30 Mark Haidekker attachment added BootDmesg.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129344/+files/BootDmesg.txt
2014-06-11 03:19:31 Mark Haidekker attachment added CurrentDmesg.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129345/+files/CurrentDmesg.txt
2014-06-11 03:19:33 Mark Haidekker attachment added Lspci.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129346/+files/Lspci.txt
2014-06-11 03:19:35 Mark Haidekker attachment added Lsusb.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129347/+files/Lsusb.txt
2014-06-11 03:19:36 Mark Haidekker attachment added ProcCpuinfo.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129348/+files/ProcCpuinfo.txt
2014-06-11 03:19:38 Mark Haidekker attachment added ProcEnviron.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129349/+files/ProcEnviron.txt
2014-06-11 03:19:40 Mark Haidekker attachment added ProcInterrupts.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129350/+files/ProcInterrupts.txt
2014-06-11 03:19:42 Mark Haidekker attachment added ProcModules.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129351/+files/ProcModules.txt
2014-06-11 03:19:44 Mark Haidekker attachment added PulseList.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129352/+files/PulseList.txt
2014-06-11 03:19:47 Mark Haidekker attachment added UdevDb.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129353/+files/UdevDb.txt
2014-06-11 03:19:50 Mark Haidekker attachment added UdevLog.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129354/+files/UdevLog.txt
2014-06-11 03:19:52 Mark Haidekker attachment added WifiSyslog.txt https://bugs.launchpad.net/bugs/1328746/+attachment/4129355/+files/WifiSyslog.txt
2014-06-11 03:21:50 Mark Haidekker linux (Ubuntu): status Incomplete Confirmed
2014-06-11 10:43:50 penalvch description This bug has been around for a while. I have seen it in the forums circa 2007, and I have provided a solution in 2009. Since the modified code never found its way into the mainstream kernels, I am issuing the fix as a bug report. The bug concerns the Soundblaster Audigy cards with the emu10k1 chip in both i386 and amd64 architectures, in any kernel (standard, RT etc). They have on-board joystick MIDI. There is an optional front-panel module, which provides its own MIDI UART. Under Linux, the front MIDI does not work. People with dual-boot systems have reported that booting Windows first, then rebooting into Linux makes the UART function properly. The cause for the bug lies in the fact that the front panel MIDI is routed through a microcontroller (resides in the front panel module), and this microcontroller needs a defined reset signal once after power-up. Up to this point, the GPIO _levels_ are initialized correctly, but the reset _pulse_ is never issued. Essentially, the emu10k1 chip's GPIO2 needs to be pulled high for a brief interval. The bug can be fixed in the file linux-source-3.13.0/sound/pci/emu10k1/emumpu401.c in the function snd_emu10k1_audigy_midi(). The proposed patch follows right after the present initialization of the second UART (note the added variable "val" to store the GPIO bits): int snd_emu10k1_audigy_midi(struct snd_emu10k1 *emu) {  struct snd_emu10k1_midi *midi;  int err;  unsigned int val; /* Needed in GPOUT2 pulse initialization */  midi = &emu->midi;  if ((err = emu10k1_midi_init(emu, midi, 0, "Audigy MPU-401 (UART)")) < 0)   return err;  midi->tx_enable = INTE_MIDITXENABLE;  midi->rx_enable = INTE_MIDIRXENABLE;  midi->port = A_MUDATA1;  midi->ipr_tx = IPR_MIDITRANSBUFEMPTY;  midi->ipr_rx = IPR_MIDIRECVBUFEMPTY;  midi->interrupt = snd_emu10k1_midi_interrupt;  midi = &emu->midi2;  if ((err = emu10k1_midi_init(emu, midi, 1, "Audigy MPU-401 #2")) < 0)   return err;  midi->tx_enable = INTE_A_MIDITXENABLE2;  midi->rx_enable = INTE_A_MIDIRXENABLE2;  midi->port = A_MUDATA2;  midi->ipr_tx = IPR_A_MIDITRANSBUFEMPTY2;  midi->ipr_rx = IPR_A_MIDIRECVBUFEMPTY2;  midi->interrupt = snd_emu10k1_midi_interrupt2;  /*** NEW CODE *** Pulse reset line for the second UART */  val = inl(emu->port + A_IOCFG);  outl (val | A_IOCFG_GPOUT2, emu->port + A_IOCFG);  udelay(10); /* udelay is a bad kludge, but remember that this is called only once on startup */  outl (val, emu->port + A_IOCFG);  return 0; } I suspect that my use of udelay would make a real kernel hacker cringe, but the level of GPOUT2 needs to remain high for a few microseconds to provide a stable RESET signal. Anyway, this fixes the problem. I have applied the patch for pretty much every major upgrade of the kernel. It is sufficient to compile the module snd-emu10k1.ko and replace it in the module tree. --- ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC2: mhaidekk 2321 F.... pulseaudio /dev/snd/controlC1: mhaidekk 2321 F.... pulseaudio /dev/snd/controlC0: mhaidekk 2321 F.... pulseaudio CRDA: Error: [Errno 2] No such file or directory CurrentDesktop: KDE DistroRelease: Ubuntu 14.04 EcryptfsInUse: Yes HibernationDevice: RESUME=UUID=b15a827a-7aa7-4add-a9b4-cb68262cfddd InstallationDate: Installed on 2013-12-31 (161 days ago) InstallationMedia: Kubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130822) IwConfig: eth1 no wireless extensions. lo no wireless extensions. MachineType: BIOSTAR Group TA970 NonfreeKernelModules: fglrx Package: linux (not installed) ProcFB: 0 VESA VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-29-generic root=UUID=11a18cc0-0c2e-4ce8-9acd-44c5bb8820e2 ro ProcVersionSignature: Ubuntu 3.13.0-29.53-generic 3.13.11.2 RelatedPackageVersions: linux-restricted-modules-3.13.0-29-generic N/A linux-backports-modules-3.13.0-29-generic N/A linux-firmware 1.127.2 RfKill: Tags: trusty Uname: Linux 3.13.0-29-generic x86_64 UpgradeStatus: Upgraded to trusty on 2014-06-07 (3 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 01/14/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.4 dmi.board.asset.tag: None dmi.board.name: TA970 dmi.board.vendor: BIOSTAR Group dmi.chassis.asset.tag: None dmi.chassis.type: 3 dmi.chassis.vendor: BIOSTAR Group dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.4:bd01/14/2013:svnBIOSTARGroup:pnTA970:pvr:rvnBIOSTARGroup:rnTA970:rvr:cvnBIOSTARGroup:ct3:cvr: dmi.product.name: TA970 dmi.sys.vendor: BIOSTAR Group This bug has been around for a while. I have seen it in the forums circa 2007, and I have provided a solution in 2009. Since the modified code never found its way into the mainstream kernels, I am issuing the fix as a bug report. The bug concerns the Soundblaster Audigy cards with the emu10k1 chip in both i386 and amd64 architectures, in any kernel (standard, RT etc). They have on-board joystick MIDI. There is an optional front-panel module, which provides its own MIDI UART. Under Linux, the front MIDI does not work. People with dual-boot systems have reported that booting Windows first, then rebooting into Linux makes the UART function properly. The cause for the bug lies in the fact that the front panel MIDI is routed through a microcontroller (resides in the front panel module), and this microcontroller needs a defined reset signal once after power-up. Up to this point, the GPIO _levels_ are initialized correctly, but the reset _pulse_ is never issued. Essentially, the emu10k1 chip's GPIO2 needs to be pulled high for a brief interval. WORKAROUND: The bug can be fixed in the file linux-source-3.13.0/sound/pci/emu10k1/emumpu401.c in the function snd_emu10k1_audigy_midi(). The proposed patch follows right after the present initialization of the second UART (note the added variable "val" to store the GPIO bits): int snd_emu10k1_audigy_midi(struct snd_emu10k1 *emu) {  struct snd_emu10k1_midi *midi;  int err;  unsigned int val; /* Needed in GPOUT2 pulse initialization */  midi = &emu->midi;  if ((err = emu10k1_midi_init(emu, midi, 0, "Audigy MPU-401 (UART)")) < 0)   return err;  midi->tx_enable = INTE_MIDITXENABLE;  midi->rx_enable = INTE_MIDIRXENABLE;  midi->port = A_MUDATA1;  midi->ipr_tx = IPR_MIDITRANSBUFEMPTY;  midi->ipr_rx = IPR_MIDIRECVBUFEMPTY;  midi->interrupt = snd_emu10k1_midi_interrupt;  midi = &emu->midi2;  if ((err = emu10k1_midi_init(emu, midi, 1, "Audigy MPU-401 #2")) < 0)   return err;  midi->tx_enable = INTE_A_MIDITXENABLE2;  midi->rx_enable = INTE_A_MIDIRXENABLE2;  midi->port = A_MUDATA2;  midi->ipr_tx = IPR_A_MIDITRANSBUFEMPTY2;  midi->ipr_rx = IPR_A_MIDIRECVBUFEMPTY2;  midi->interrupt = snd_emu10k1_midi_interrupt2;  /*** NEW CODE *** Pulse reset line for the second UART */  val = inl(emu->port + A_IOCFG);  outl (val | A_IOCFG_GPOUT2, emu->port + A_IOCFG);  udelay(10); /* udelay is a bad kludge, but remember that this is called only once on startup */  outl (val, emu->port + A_IOCFG);  return 0; } I suspect that my use of udelay would make a real kernel hacker cringe, but the level of GPOUT2 needs to remain high for a few microseconds to provide a stable RESET signal. Anyway, this fixes the problem. I have applied the patch for pretty much every major upgrade of the kernel. It is sufficient to compile the module snd-emu10k1.ko and replace it in the module tree. --- ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 AudioDevicesInUse:  USER PID ACCESS COMMAND  /dev/snd/controlC2: mhaidekk 2321 F.... pulseaudio  /dev/snd/controlC1: mhaidekk 2321 F.... pulseaudio  /dev/snd/controlC0: mhaidekk 2321 F.... pulseaudio CRDA: Error: [Errno 2] No such file or directory CurrentDesktop: KDE DistroRelease: Ubuntu 14.04 EcryptfsInUse: Yes HibernationDevice: RESUME=UUID=b15a827a-7aa7-4add-a9b4-cb68262cfddd InstallationDate: Installed on 2013-12-31 (161 days ago) InstallationMedia: Kubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130822) IwConfig:  eth1 no wireless extensions.  lo no wireless extensions. MachineType: BIOSTAR Group TA970 NonfreeKernelModules: fglrx Package: linux (not installed) ProcFB: 0 VESA VGA ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-29-generic root=UUID=11a18cc0-0c2e-4ce8-9acd-44c5bb8820e2 ro ProcVersionSignature: Ubuntu 3.13.0-29.53-generic 3.13.11.2 RelatedPackageVersions:  linux-restricted-modules-3.13.0-29-generic N/A  linux-backports-modules-3.13.0-29-generic N/A  linux-firmware 1.127.2 RfKill: Tags: trusty Uname: Linux 3.13.0-29-generic x86_64 UpgradeStatus: Upgraded to trusty on 2014-06-07 (3 days ago) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 01/14/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.4 dmi.board.asset.tag: None dmi.board.name: TA970 dmi.board.vendor: BIOSTAR Group dmi.chassis.asset.tag: None dmi.chassis.type: 3 dmi.chassis.vendor: BIOSTAR Group dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.4:bd01/14/2013:svnBIOSTARGroup:pnTA970:pvr:rvnBIOSTARGroup:rnTA970:rvr:cvnBIOSTARGroup:ct3:cvr: dmi.product.name: TA970 dmi.sys.vendor: BIOSTAR Group
2014-06-11 10:44:46 penalvch linux (Ubuntu): importance Undecided Low
2014-06-11 10:44:46 penalvch linux (Ubuntu): status Confirmed Incomplete
2014-06-11 20:23:38 Mark Haidekker attachment added emumpu401.c https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328746/+attachment/4129882/+files/emumpu401.c
2014-06-11 20:26:03 Mark Haidekker attachment added Attchment contains solution; is replacement file https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328746/+attachment/4129883/+files/emumpu401.c
2014-06-11 20:27:47 Mark Haidekker tags apport-collected trusty kernel-bug-exists-upstream kernel-bug-exists-upstream-3.15.0
2014-06-11 20:27:59 Mark Haidekker linux (Ubuntu): status Incomplete Confirmed
2014-06-11 20:44:03 Mark Haidekker attachment removed emumpu401.c https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1328746/+attachment/4129882/+files/emumpu401.c
2014-06-12 00:08:03 penalvch tags kernel-bug-exists-upstream kernel-bug-exists-upstream-3.15.0 apport-collected kernel-bug-exists-upstream kernel-bug-exists-upstream-3.15 trusty
2014-06-12 00:08:54 penalvch linux (Ubuntu): status Confirmed Triaged
2014-06-12 11:34:32 penalvch bug added subscriber Ubuntu Audio Team
2014-06-12 11:34:43 penalvch tags apport-collected kernel-bug-exists-upstream kernel-bug-exists-upstream-3.15 trusty apport-collected kernel-bug-exists-upstream kernel-bug-exists-upstream-3.15 kernel-sound trusty