Activity log for bug #280821

Date Who What changed Old value New value Message
2008-10-09 16:07:22 pbeeson bug added bug
2008-10-09 16:07:22 pbeeson bug added attachment '8250-deadlock.patch' (8250-deadlock.patch)
2008-10-09 16:12:38 pbeeson description Binary package hint: linux-image-2.6.24-19-generic Upon switching from Dapper to Hardy, I noticed one of my systems kept getting serial timeouts. Upon further investigation, it seems that there is a serial deadlock issue in kernels < 2.6.27, where machine with multiple processors and multiple serial devices can call the serial interrupt handler at the same time and become deadlocked. This was fixed in 2.6.27 with 4 lines of code. I have created a patch with the same four line based on the linux-source-2.6.24.tbz (from installing linux-source package) and tested it. My problems go away. Given that this is such a fundamental bug (deadlock in interrupt handlers), I feel it is necessary to apply this to the LTS kernels in Hardy. Binary package hint: linux-image-2.6.24-19-generic Upon switching from Dapper to Hardy, I noticed one of my systems kept getting serial timeouts. Upon further investigation, it seems that there is a serial deadlock issue in kernels < 2.6.27, where machine with multiple processors and multiple serial devices can call the serial interrupt handler at the same time and become deadlocked. This was fixed in 2.6.27 with 4 lines of code. I have created a patch with the same four line based on the linux-source-2.6.24.tbz (from installing linux-source package) and tested it. My problems go away. Given that this is such a fundamental bug (deadlock in interrupt handlers), I feel it is necessary to apply this to the LTS kernels in Hardy. The original discussion of this bug and the patch (by the usual kernel programmers) is at: http://kerneltrap.org/mailarchive/linux-kernel/2008/7/1/2313364 Note, that the final fix in 2.6.27 keeps the lock and unlock lines as they were (the original discussion at the thread above changed them). My patch does not change them (as in the final 2.6.27 patch for this problem).
2008-10-09 16:15:31 pbeeson description Binary package hint: linux-image-2.6.24-19-generic Upon switching from Dapper to Hardy, I noticed one of my systems kept getting serial timeouts. Upon further investigation, it seems that there is a serial deadlock issue in kernels < 2.6.27, where machine with multiple processors and multiple serial devices can call the serial interrupt handler at the same time and become deadlocked. This was fixed in 2.6.27 with 4 lines of code. I have created a patch with the same four line based on the linux-source-2.6.24.tbz (from installing linux-source package) and tested it. My problems go away. Given that this is such a fundamental bug (deadlock in interrupt handlers), I feel it is necessary to apply this to the LTS kernels in Hardy. The original discussion of this bug and the patch (by the usual kernel programmers) is at: http://kerneltrap.org/mailarchive/linux-kernel/2008/7/1/2313364 Note, that the final fix in 2.6.27 keeps the lock and unlock lines as they were (the original discussion at the thread above changed them). My patch does not change them (as in the final 2.6.27 patch for this problem). Binary package hint: linux-image-2.6.24-19-generic Upon switching from Dapper to Hardy, I noticed one of my systems kept getting serial timeouts. Upon further investigation, it seems that there is a serial deadlock issue in kernels < 2.6.27, where machines with multiple processors and multiple serial devices can call the serial interrupt handler at the same time and become deadlocked. This was fixed in 2.6.27 with 4 lines of code. I have created a patch with the same four line based on the linux-source-2.6.24.tbz (from installing linux-source package), and I have tested it with many serial deives talking at once. My problems go away. Given that this is such a fundamental bug (deadlock in interrupt handlers), I feel it is necessary to apply this to the LTS kernels in Hardy. The original discussion of this bug and the patch (by the usual kernel programmers) is at: http://kerneltrap.org/mailarchive/linux-kernel/2008/7/1/2313364 Note, that the final fix in 2.6.27 keeps the lock and unlock lines as they were (the original discussion at the thread above changed them). My patch does not change them (as in the final 2.6.27 patch for this problem).
2008-10-09 16:18:00 pbeeson bug added subscriber Jack O'Quin
2008-10-10 19:11:38 Leann Ogasawara linux: status New Triaged
2008-10-10 19:11:38 Leann Ogasawara linux: assignee ubuntu-kernel-team
2008-10-10 19:11:38 Leann Ogasawara linux: importance Undecided High
2008-10-10 19:11:38 Leann Ogasawara linux: statusexplanation
2008-10-10 19:12:13 Leann Ogasawara linux: status New Fix Released
2008-10-10 19:12:13 Leann Ogasawara linux: statusexplanation I've marked this as "Triaged" for Hardy and am setting this to "Fix Released" for Intrepid. Thanks.
2009-02-09 12:53:54 Andy Whitcroft linux: status Triaged In Progress
2009-02-09 12:53:54 Andy Whitcroft linux: assignee apw
2009-02-09 13:53:58 Andy Whitcroft linux: importance Undecided High
2009-02-09 13:53:58 Andy Whitcroft linux: statusexplanation I've marked this as "Triaged" for Hardy and am setting this to "Fix Released" for Intrepid. Thanks.
2009-03-02 16:37:43 Andy Whitcroft description Binary package hint: linux-image-2.6.24-19-generic Upon switching from Dapper to Hardy, I noticed one of my systems kept getting serial timeouts. Upon further investigation, it seems that there is a serial deadlock issue in kernels < 2.6.27, where machines with multiple processors and multiple serial devices can call the serial interrupt handler at the same time and become deadlocked. This was fixed in 2.6.27 with 4 lines of code. I have created a patch with the same four line based on the linux-source-2.6.24.tbz (from installing linux-source package), and I have tested it with many serial deives talking at once. My problems go away. Given that this is such a fundamental bug (deadlock in interrupt handlers), I feel it is necessary to apply this to the LTS kernels in Hardy. The original discussion of this bug and the patch (by the usual kernel programmers) is at: http://kerneltrap.org/mailarchive/linux-kernel/2008/7/1/2313364 Note, that the final fix in 2.6.27 keeps the lock and unlock lines as they were (the original discussion at the thread above changed them). My patch does not change them (as in the final 2.6.27 patch for this problem). Binary package hint: linux-image-2.6.24-19-generic Upon switching from Dapper to Hardy, I noticed one of my systems kept getting serial timeouts. Upon further investigation, it seems that there is a serial deadlock issue in kernels < 2.6.27, where machines with multiple processors and multiple serial devices can call the serial interrupt handler at the same time and become deadlocked. This was fixed in 2.6.27 with 4 lines of code. I have created a patch with the same four line based on the linux-source-2.6.24.tbz (from installing linux-source package), and I have tested it with many serial deives talking at once. My problems go away. Given that this is such a fundamental bug (deadlock in interrupt handlers), I feel it is necessary to apply this to the LTS kernels in Hardy. The original discussion of this bug and the patch (by the usual kernel programmers) is at: http://kerneltrap.org/mailarchive/linux-kernel/2008/7/1/2313364 Note, that the final fix in 2.6.27 keeps the lock and unlock lines as they were (the original discussion at the thread above changed them). My patch does not change them (as in the final 2.6.27 patch for this problem). === SRU Justification Justification: Systems with multiple serial ports on the will deadlock losing serial output. Impact: Systems may lose serial output including console output, particularly serious on servers. Fix Description: Cherry-picked the upstream fixes for this, which introduces proper locking. Patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=45485c71ce3099b7c7349f6c32dadc53087794cf http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=6dc468aa85f0cf60ab1b8897143226203510efe8 Risks: This has been tested by the affected users to good effect. Risk should be low for normal use. TEST CASE: See bug report.
2009-03-02 16:38:06 Andy Whitcroft bug added subscriber Ubuntu Stable Release Updates Team
2009-03-18 15:35:32 Stefan Bader linux: status In Progress Fix Committed
2009-05-04 09:35:17 Launchpad Janitor linux (Ubuntu Hardy): status Fix Committed Fix Released
2009-05-04 09:35:17 Launchpad Janitor cve linked 2008-4307
2009-05-04 09:35:17 Launchpad Janitor cve linked 2008-6107
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0028
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0031
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0065
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0269
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0322
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0675
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0676
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0745
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0746
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0834
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0835
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-0859
2009-05-04 09:35:17 Launchpad Janitor cve linked 2009-1046