* Mainpine IQ Express Rev3 problems beginning 2.6.36 @ 2010-12-08 23:55 Lee Howard 2010-12-09 6:42 ` Greg KH 0 siblings, 1 reply; 10+ messages in thread From: Lee Howard @ 2010-12-08 23:55 UTC (permalink / raw) To: linux-serial Hello everyone, A week ago I had a customer report to me that they were having problems using the Mainpine IQ Express Rev3 (multiport modem which uses the Oxsemi OXPCIe95x chipset) after updating their system from kernel 2.6.22.10 (which they patched because native support for the IQ Express didn't enter the kernel until 2.6.28) to kernel 2.6.36. As I had never used any 2.6.36 kernel, myself, I explained that I had experienced no problem with the 2.6.35.6 kernel (as found in Fedora 14) at which point they installed kernel 2.6.35.8 and reported back that this had resolved the problem for them. Following their report I then tested by installing the 2.6.37-rc4 kernel (using 'make oldconfig', taking .config from the Fedora 14 kernel that was working), and I was quickly able to determine that there were problems because simple communications with the modems were not working properly using 'minicom'. (I also have now tested with 2.6.37-rc5 with the same result.) Characters appear to be getting lost/dropped in the communication... for example, I *expect* the following on the minicom terminal screen when I start it up as it initializes the modem: ------------------- AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 OK ------------------- The blinking cursor will be on the line following the OK. This is what happens when using kernel 2.6.35. However, when I use 2.6.37-rc5 this is what I see: ------------------- AT S7=45 S0=0 L1 ------------------- Sometimes there is a character or two more on the screen but there will be no OK and the cursor will be blinking at the end of the line of commands... which leads me to believe that the modem did not see the CR+LF from the application. If I simply press enter on the terminal, then I'll see the OK as expected. So it seems to me that only the first bunch of characters are making it through and that the rest are getting dropped for some reason. setserial tells me the following about the port: # setserial -G /dev/ttyS4 /dev/ttyS4 uart 16950/954 port 0x0000 irq 18 baud_base 4000000 spd_normal skip_test I think I can say with confidence that the problem started with 2.6.36. What can I do to help solve the problem? Thanks, Lee. -- *Lee Howard* *Mainpine, Inc. Software Development Lead* Tel: +1 866 363 6680 | Fax: +1 360 462 8160 lee.howard@mainpine.com | www.mainpine.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Mainpine IQ Express Rev3 problems beginning 2.6.36 2010-12-08 23:55 Mainpine IQ Express Rev3 problems beginning 2.6.36 Lee Howard @ 2010-12-09 6:42 ` Greg KH 2010-12-12 0:36 ` Lee Howard 0 siblings, 1 reply; 10+ messages in thread From: Greg KH @ 2010-12-09 6:42 UTC (permalink / raw) To: Lee Howard; +Cc: linux-serial On Wed, Dec 08, 2010 at 03:55:29PM -0800, Lee Howard wrote: > Hello everyone, > > A week ago I had a customer report to me that they were having > problems using the Mainpine IQ Express Rev3 (multiport modem which > uses the Oxsemi OXPCIe95x chipset) after updating their system from > kernel 2.6.22.10 (which they patched because native support for the > IQ Express didn't enter the kernel until 2.6.28) to kernel 2.6.36. > > As I had never used any 2.6.36 kernel, myself, I explained that I > had experienced no problem with the 2.6.35.6 kernel (as found in > Fedora 14) at which point they installed kernel 2.6.35.8 and > reported back that this had resolved the problem for them. > > Following their report I then tested by installing the 2.6.37-rc4 > kernel (using 'make oldconfig', taking .config from the Fedora 14 > kernel that was working), and I was quickly able to determine that > there were problems because simple communications with the modems > were not working properly using 'minicom'. (I also have now tested > with 2.6.37-rc5 with the same result.) Characters appear to be > getting lost/dropped in the communication... for example, I *expect* > the following on the minicom terminal screen when I start it up as > it initializes the modem: > > ------------------- > AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 > OK > > ------------------- > > The blinking cursor will be on the line following the OK. This is > what happens when using kernel 2.6.35. However, when I use > 2.6.37-rc5 this is what I see: > > ------------------- > AT S7=45 S0=0 L1 > ------------------- > > Sometimes there is a character or two more on the screen but there > will be no OK and the cursor will be blinking at the end of the line > of commands... which leads me to believe that the modem did not see > the CR+LF from the application. If I simply press enter on the > terminal, then I'll see the OK as expected. So it seems to me that > only the first bunch of characters are making it through and that > the rest are getting dropped for some reason. > > setserial tells me the following about the port: > > # setserial -G /dev/ttyS4 > /dev/ttyS4 uart 16950/954 port 0x0000 irq 18 baud_base 4000000 > spd_normal skip_test > > I think I can say with confidence that the problem started with 2.6.36. > > What can I do to help solve the problem? What type of device is this? A pci card or something else? What driver controls it? Also, the best thing to do would be if you could run 'git bisect' to narrow the problem down to the specific patch that caused the problem. Any chance you could do that? thanks, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Mainpine IQ Express Rev3 problems beginning 2.6.36 2010-12-09 6:42 ` Greg KH @ 2010-12-12 0:36 ` Lee Howard 2010-12-12 16:52 ` Greg KH 0 siblings, 1 reply; 10+ messages in thread From: Lee Howard @ 2010-12-12 0:36 UTC (permalink / raw) To: 'Greg KH'; +Cc: linux-serial > From: Greg KH [mailto:greg@kroah.com] > Sent: Wednesday, December 08, 2010 10:43 PM > > On Wed, Dec 08, 2010 at 03:55:29PM -0800, Lee Howard wrote: > > Hello everyone, > > > > A week ago I had a customer report to me that they were having > > problems using the Mainpine IQ Express Rev3 (multiport modem which > > uses the Oxsemi OXPCIe95x chipset) after updating their system from > > kernel 2.6.22.10 (which they patched because native support > for the IQ > > Express didn't enter the kernel until 2.6.28) to kernel 2.6.36. > > > > As I had never used any 2.6.36 kernel, myself, I explained > that I had > > experienced no problem with the 2.6.35.6 kernel (as found in Fedora > > 14) at which point they installed kernel 2.6.35.8 and reported back > > that this had resolved the problem for them. > > > > Following their report I then tested by installing the 2.6.37-rc4 > > kernel (using 'make oldconfig', taking .config from the Fedora 14 > > kernel that was working), and I was quickly able to determine that > > there were problems because simple communications with the > modems were > > not working properly using 'minicom'. (I also have now tested with > > 2.6.37-rc5 with the same result.) Characters appear to be getting > > lost/dropped in the communication... for example, I *expect* the > > following on the minicom terminal screen when I start it up as it > > initializes the modem: > > > > ------------------- > > AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 > > OK > > > > ------------------- > > > > The blinking cursor will be on the line following the OK. This is > > what happens when using kernel 2.6.35. However, when I use > > 2.6.37-rc5 this is what I see: > > > > ------------------- > > AT S7=45 S0=0 L1 > > ------------------- > > > > Sometimes there is a character or two more on the screen but there > > will be no OK and the cursor will be blinking at the end of > the line > > of commands... which leads me to believe that the modem did not see > > the CR+LF from the application. If I simply press enter on the > > terminal, then I'll see the OK as expected. So it seems to me that > > only the first bunch of characters are making it through > and that the > > rest are getting dropped for some reason. > > > > setserial tells me the following about the port: > > > > # setserial -G /dev/ttyS4 > > /dev/ttyS4 uart 16950/954 port 0x0000 irq 18 baud_base 4000000 > > spd_normal skip_test > > > > I think I can say with confidence that the problem started > with 2.6.36. > > > > What can I do to help solve the problem? > > What type of device is this? A pci card or something else? The Mainpine IQ Express cards are multiport PCIe cards with modems attached to the serial ports. > What driver controls it? 8250 > Also, the best thing to do would be if you could run 'git > bisect' to narrow the problem down to the specific patch that > caused the problem. > Any chance you could do that? I've been at that for three days now. It's very tedious and cumbersome because, even starting with 'git bisect start -- drivers/serial' which narrows-down the anticipated number of runs to 6, it's very difficult to do because most of the kernel revisions that are being tested have some bug in them (they don't build at all, they have oopses, etc.) and I find myself spending a lot of time only to have to do a 'git bisect skip' if I don't want to try to work-around those problems. Eventually I found myself simply disabling modules in the build that I don't need to perform the test... And that worked better until I started running into other problems in the test that were not the same as the one I was having before... So when I'm doing 'git bisect' and come across a revision that doesn't work but doesn't have the same problems as the target problem, what do I do? Should I mark it "bad" or "skip" it? Thanks, Lee. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Mainpine IQ Express Rev3 problems beginning 2.6.36 2010-12-12 0:36 ` Lee Howard @ 2010-12-12 16:52 ` Greg KH 2010-12-14 19:49 ` Lee Howard 0 siblings, 1 reply; 10+ messages in thread From: Greg KH @ 2010-12-12 16:52 UTC (permalink / raw) To: Lee Howard; +Cc: linux-serial On Sat, Dec 11, 2010 at 04:36:07PM -0800, Lee Howard wrote: > > What type of device is this? A pci card or something else? > > The Mainpine IQ Express cards are multiport PCIe cards with modems attached > to the serial ports. > > > What driver controls it? > > 8250 > > > Also, the best thing to do would be if you could run 'git > > bisect' to narrow the problem down to the specific patch that > > caused the problem. > > Any chance you could do that? > > I've been at that for three days now. It's very tedious and cumbersome > because, even starting with 'git bisect start -- drivers/serial' which > narrows-down the anticipated number of runs to 6, it's very difficult to do > because most of the kernel revisions that are being tested have some bug in > them (they don't build at all, they have oopses, etc.) and I find myself > spending a lot of time only to have to do a 'git bisect skip' if I don't > want to try to work-around those problems. Eventually I found myself simply > disabling modules in the build that I don't need to perform the test... And > that worked better until I started running into other problems in the test > that were not the same as the one I was having before... So when I'm doing > 'git bisect' and come across a revision that doesn't work but doesn't have > the same problems as the target problem, what do I do? Should I mark it > "bad" or "skip" it? Don't limit yourself to changes in drivers/serial as there are lots of tty fixes in other parts of the kernel that could have caused issues with this. As for build issues, try to make a minimal working config for your system, using 'make localmodconfig'. That will speed up your build time immensely as well as reduce your chances of build and runtime problems with the intermediate kernels. best of luck, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Mainpine IQ Express Rev3 problems beginning 2.6.36 2010-12-12 16:52 ` Greg KH @ 2010-12-14 19:49 ` Lee Howard 2010-12-17 13:25 ` Lee Howard 0 siblings, 1 reply; 10+ messages in thread From: Lee Howard @ 2010-12-14 19:49 UTC (permalink / raw) To: 'Greg KH'; +Cc: linux-serial > -----Original Message----- > From: Greg KH [mailto:greg@kroah.com] > Sent: Sunday, December 12, 2010 8:52 AM > As for build issues, try to make a minimal working config for > your system, using 'make localmodconfig'. That will speed up > your build time immensely as well as reduce your chances of > build and runtime problems with the intermediate kernels. Thank-you, that did help immensely. Here's the 'git bisect' result... -------------- 7a56aa45982bb87bfca98a2832b5ae782c03364a is the first bad commit commit 7a56aa45982bb87bfca98a2832b5ae782c03364a Author: Yegor Yefremov <yegor_sub1@visionsystems.de> Date: Wed Jun 16 16:29:55 2010 +0200 serial: add UART_CAP_EFR and UART_CAP_SLEEP flags to 16C950 UARTs definition Adding UART_CAP_EFR and UART_CAP_SLEEP flags will enable sleep mode and automatic CTS flow control for 16C950 UARTs. It will also avoid capabilities detection warning like this: "ttyS0: detected caps 00000700 should be 00000100" Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> :040000 040000 1776ca8d5c653834363c0778b5b404ee52bd2d69 b81cfe4f302a674935181bd248641873820517e5 M drivers -------------- Indeed, if I remove the UART_CAP_EFR flag from later kernel revisions there is no problem. Here is the 'dmesg' output for 8250 after removing UART_CAP_EFR... -------------- [ 0.980209] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 1.245280] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A [ 1.266813] 00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A [ 1.266936] serial 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 1.266954] 1 ports detected on Oxford PCI Express device [ 1.267029] ttyS4: detected caps 00000700 should be 00000500 [ 1.267043] 0000:02:00.0: ttyS4 at MMIO 0xfd5fd000 (irq = 18) is a 16C950/954 [ 1.267095] serial 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 1.267105] 4 ports detected on Oxford PCI Express device [ 1.267175] ttyS5: detected caps 00000700 should be 00000500 [ 1.267180] 0000:03:00.0: ttyS5 at MMIO 0xfc9fd000 (irq = 16) is a 16C950/954 [ 1.267269] ttyS6: detected caps 00000700 should be 00000500 [ 1.267274] 0000:03:00.0: ttyS6 at MMIO 0xfc9fd200 (irq = 16) is a 16C950/954 [ 1.267362] ttyS7: detected caps 00000700 should be 00000500 [ 1.267366] 0000:03:00.0: ttyS7 at MMIO 0xfc9fd400 (irq = 16) is a 16C950/954 [ 1.267454] ttyS8: detected caps 00000700 should be 00000500 [ 1.267459] 0000:03:00.0: ttyS8 at MMIO 0xfc9fd600 (irq = 16) is a 16C950/954 [ 1.267505] serial 0000:04:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 1.267514] 2 ports detected on Oxford PCI Express device [ 1.267583] ttyS9: detected caps 00000700 should be 00000500 [ 1.267588] 0000:04:00.0: ttyS9 at MMIO 0xfcffd000 (irq = 18) is a 16C950/954 [ 1.267678] ttyS10: detected caps 00000700 should be 00000500 [ 1.267683] 0000:04:00.0: ttyS10 at MMIO 0xfcffd200 (irq = 18) is a 16C950/954 [ 1.267723] serial 0000:06:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 [ 1.288452] 0000:06:00.0: ttyS11 at I/O 0xcf00 (irq = 19) is a 16550A [ 1.309208] 0000:06:00.0: ttyS12 at I/O 0xcf08 (irq = 19) is a 16550A [ 1.329963] 0000:06:00.0: ttyS13 at I/O 0xcf10 (irq = 19) is a 16550A [ 1.350723] 0000:06:00.0: ttyS14 at I/O 0xcf18 (irq = 19) is a 16550A -------------- 00:09 is the on-board serial controller, so that's ttyS1 0000:02:00.0 is a 1-port Rev3 IQ Express, that's ttyS4 0000:03:00.0 is a 4-port Rev3 IQ Express, that's ttyS5-ttyS8 0000:04:00.0 is a 2-port Rev3 IQ Express, that's ttyS9-ttyS10 0000:06:00.0 is a 4-port Rev2 IQ Express, that's ttyS11-ttyS14 (these had no problem). Thanks, Lee. ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Mainpine IQ Express Rev3 problems beginning 2.6.36 2010-12-14 19:49 ` Lee Howard @ 2010-12-17 13:25 ` Lee Howard 2011-01-11 0:02 ` Greg KH 0 siblings, 1 reply; 10+ messages in thread From: Lee Howard @ 2010-12-17 13:25 UTC (permalink / raw) To: 'Greg KH'; +Cc: linux-serial > -----Original Message----- > From: linux-serial-owner@vger.kernel.org > [mailto:linux-serial-owner@vger.kernel.org] On Behalf Of Lee Howard > Sent: Tuesday, December 14, 2010 11:50 AM > To: 'Greg KH' > Cc: linux-serial@vger.kernel.org > Subject: RE: Mainpine IQ Express Rev3 problems beginning 2.6.36 > > > -----Original Message----- > > From: Greg KH [mailto:greg@kroah.com] > > Sent: Sunday, December 12, 2010 8:52 AM > > > As for build issues, try to make a minimal working config for your > > system, using 'make localmodconfig'. That will speed up your build > > time immensely as well as reduce your chances of build and runtime > > problems with the intermediate kernels. > > Thank-you, that did help immensely. > > Here's the 'git bisect' result... > > -------------- > 7a56aa45982bb87bfca98a2832b5ae782c03364a is the first bad > commit commit 7a56aa45982bb87bfca98a2832b5ae782c03364a > Author: Yegor Yefremov <yegor_sub1@visionsystems.de> > Date: Wed Jun 16 16:29:55 2010 +0200 > > serial: add UART_CAP_EFR and UART_CAP_SLEEP flags to > 16C950 UARTs definition > > Adding UART_CAP_EFR and UART_CAP_SLEEP flags will enable > sleep mode > and automatic CTS flow control for 16C950 UARTs. It will > also avoid > capabilities detection warning like this: > > "ttyS0: detected caps 00000700 should be 00000100" > > Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > :040000 040000 1776ca8d5c653834363c0778b5b404ee52bd2d69 > b81cfe4f302a674935181bd248641873820517e5 M drivers > -------------- > > Indeed, if I remove the UART_CAP_EFR flag from later kernel > revisions there is no problem. Greg, What's to be done? Thanks, Lee. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Mainpine IQ Express Rev3 problems beginning 2.6.36 2010-12-17 13:25 ` Lee Howard @ 2011-01-11 0:02 ` Greg KH 2011-01-11 19:16 ` Lee Howard 0 siblings, 1 reply; 10+ messages in thread From: Greg KH @ 2011-01-11 0:02 UTC (permalink / raw) To: Lee Howard; +Cc: linux-serial On Fri, Dec 17, 2010 at 05:25:19AM -0800, Lee Howard wrote: > > -----Original Message----- > > From: linux-serial-owner@vger.kernel.org > > [mailto:linux-serial-owner@vger.kernel.org] On Behalf Of Lee Howard > > Sent: Tuesday, December 14, 2010 11:50 AM > > To: 'Greg KH' > > Cc: linux-serial@vger.kernel.org > > Subject: RE: Mainpine IQ Express Rev3 problems beginning 2.6.36 > > > > > -----Original Message----- > > > From: Greg KH [mailto:greg@kroah.com] > > > Sent: Sunday, December 12, 2010 8:52 AM > > > > > As for build issues, try to make a minimal working config for your > > > system, using 'make localmodconfig'. That will speed up your build > > > time immensely as well as reduce your chances of build and runtime > > > problems with the intermediate kernels. > > > > Thank-you, that did help immensely. > > > > Here's the 'git bisect' result... > > > > -------------- > > 7a56aa45982bb87bfca98a2832b5ae782c03364a is the first bad > > commit commit 7a56aa45982bb87bfca98a2832b5ae782c03364a > > Author: Yegor Yefremov <yegor_sub1@visionsystems.de> > > Date: Wed Jun 16 16:29:55 2010 +0200 > > > > serial: add UART_CAP_EFR and UART_CAP_SLEEP flags to > > 16C950 UARTs definition > > > > Adding UART_CAP_EFR and UART_CAP_SLEEP flags will enable > > sleep mode > > and automatic CTS flow control for 16C950 UARTs. It will > > also avoid > > capabilities detection warning like this: > > > > "ttyS0: detected caps 00000700 should be 00000100" > > > > Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > > > :040000 040000 1776ca8d5c653834363c0778b5b404ee52bd2d69 > > b81cfe4f302a674935181bd248641873820517e5 M drivers > > -------------- > > > > Indeed, if I remove the UART_CAP_EFR flag from later kernel > > revisions there is no problem. > > Greg, > > What's to be done? Sorry for the delay, I think Pavel's posted patch will solve this issue for you, right? thanks, greg k-h ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Mainpine IQ Express Rev3 problems beginning 2.6.36 2011-01-11 0:02 ` Greg KH @ 2011-01-11 19:16 ` Lee Howard 2011-01-11 23:03 ` Greg KH 0 siblings, 1 reply; 10+ messages in thread From: Lee Howard @ 2011-01-11 19:16 UTC (permalink / raw) To: 'Greg KH'; +Cc: linux-serial > -----Original Message----- > From: Greg KH [mailto:greg@kroah.com] > Sent: Monday, January 10, 2011 4:03 PM > To: Lee Howard > Cc: linux-serial@vger.kernel.org > Subject: Re: Mainpine IQ Express Rev3 problems beginning 2.6.36 > > On Fri, Dec 17, 2010 at 05:25:19AM -0800, Lee Howard wrote: > > > -----Original Message----- > > > From: linux-serial-owner@vger.kernel.org > > > [mailto:linux-serial-owner@vger.kernel.org] On Behalf Of > Lee Howard > > > Sent: Tuesday, December 14, 2010 11:50 AM > > > To: 'Greg KH' > > > Cc: linux-serial@vger.kernel.org > > > Subject: RE: Mainpine IQ Express Rev3 problems beginning 2.6.36 > > > > > > > -----Original Message----- > > > > From: Greg KH [mailto:greg@kroah.com] > > > > Sent: Sunday, December 12, 2010 8:52 AM > > > > > > > As for build issues, try to make a minimal working > config for your > > > > system, using 'make localmodconfig'. That will speed up your > > > > build time immensely as well as reduce your chances of > build and > > > > runtime problems with the intermediate kernels. > > > > > > Thank-you, that did help immensely. > > > > > > Here's the 'git bisect' result... > > > > > > -------------- > > > 7a56aa45982bb87bfca98a2832b5ae782c03364a is the first bad commit > > > commit 7a56aa45982bb87bfca98a2832b5ae782c03364a > > > Author: Yegor Yefremov <yegor_sub1@visionsystems.de> > > > Date: Wed Jun 16 16:29:55 2010 +0200 > > > > > > serial: add UART_CAP_EFR and UART_CAP_SLEEP flags to 16C950 > > > UARTs definition > > > > > > Adding UART_CAP_EFR and UART_CAP_SLEEP flags will > enable sleep > > > mode > > > and automatic CTS flow control for 16C950 UARTs. It will also > > > avoid > > > capabilities detection warning like this: > > > > > > "ttyS0: detected caps 00000700 should be 00000100" > > > > > > Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> > > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > > > > > :040000 040000 1776ca8d5c653834363c0778b5b404ee52bd2d69 > > > b81cfe4f302a674935181bd248641873820517e5 M drivers > > > -------------- > > > > > > Indeed, if I remove the UART_CAP_EFR flag from later kernel > > > revisions there is no problem. > > > > Greg, > > > > What's to be done? > > Sorry for the delay, I think Pavel's posted patch will solve > this issue for you, right? I've looked in the linux-serial archives for posts by Pavel for the last month, but I don't see a patch. Please tell me where I can find this patch. Thanks, Lee. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Mainpine IQ Express Rev3 problems beginning 2.6.36 2011-01-11 19:16 ` Lee Howard @ 2011-01-11 23:03 ` Greg KH 2011-01-25 15:57 ` Lee Howard 0 siblings, 1 reply; 10+ messages in thread From: Greg KH @ 2011-01-11 23:03 UTC (permalink / raw) To: Lee Howard; +Cc: linux-serial [-- Attachment #1: Type: text/plain, Size: 2756 bytes --] On Tue, Jan 11, 2011 at 11:16:06AM -0800, Lee Howard wrote: > > > -----Original Message----- > > From: Greg KH [mailto:greg@kroah.com] > > Sent: Monday, January 10, 2011 4:03 PM > > To: Lee Howard > > Cc: linux-serial@vger.kernel.org > > Subject: Re: Mainpine IQ Express Rev3 problems beginning 2.6.36 > > > > On Fri, Dec 17, 2010 at 05:25:19AM -0800, Lee Howard wrote: > > > > -----Original Message----- > > > > From: linux-serial-owner@vger.kernel.org > > > > [mailto:linux-serial-owner@vger.kernel.org] On Behalf Of > > Lee Howard > > > > Sent: Tuesday, December 14, 2010 11:50 AM > > > > To: 'Greg KH' > > > > Cc: linux-serial@vger.kernel.org > > > > Subject: RE: Mainpine IQ Express Rev3 problems beginning 2.6.36 > > > > > > > > > -----Original Message----- > > > > > From: Greg KH [mailto:greg@kroah.com] > > > > > Sent: Sunday, December 12, 2010 8:52 AM > > > > > > > > > As for build issues, try to make a minimal working > > config for your > > > > > system, using 'make localmodconfig'. That will speed up your > > > > > build time immensely as well as reduce your chances of > > build and > > > > > runtime problems with the intermediate kernels. > > > > > > > > Thank-you, that did help immensely. > > > > > > > > Here's the 'git bisect' result... > > > > > > > > -------------- > > > > 7a56aa45982bb87bfca98a2832b5ae782c03364a is the first bad commit > > > > commit 7a56aa45982bb87bfca98a2832b5ae782c03364a > > > > Author: Yegor Yefremov <yegor_sub1@visionsystems.de> > > > > Date: Wed Jun 16 16:29:55 2010 +0200 > > > > > > > > serial: add UART_CAP_EFR and UART_CAP_SLEEP flags to 16C950 > > > > UARTs definition > > > > > > > > Adding UART_CAP_EFR and UART_CAP_SLEEP flags will > > enable sleep > > > > mode > > > > and automatic CTS flow control for 16C950 UARTs. It will also > > > > avoid > > > > capabilities detection warning like this: > > > > > > > > "ttyS0: detected caps 00000700 should be 00000100" > > > > > > > > Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > > > > > > > :040000 040000 1776ca8d5c653834363c0778b5b404ee52bd2d69 > > > > b81cfe4f302a674935181bd248641873820517e5 M drivers > > > > -------------- > > > > > > > > Indeed, if I remove the UART_CAP_EFR flag from later kernel > > > > revisions there is no problem. > > > > > > Greg, > > > > > > What's to be done? > > > > Sorry for the delay, I think Pavel's posted patch will solve > > this issue for you, right? > > I've looked in the linux-serial archives for posts by Pavel for the last > month, but I don't see a patch. Please tell me where I can find this patch. I've attached it below. thanks, greg k-h [-- Attachment #2: p --] [-- Type: text/x-pascal, Size: 3726 bytes --] >From pavel@ucw.cz Sat Jan 8 23:38:58 2011 Return-Path: <pavel@ucw.cz> X-OfflineIMAP-873005426-6772656752656d6f7465-746f646f: 1294595209-0154868123845-v6.2.0 Delivered-To: unknown Received: from imap.suse.de ([unix socket]) by imap-int (Cyrus v2.2.12) with LMTPA; Sun, 09 Jan 2011 08:38:58 +0100 X-Sieve: CMU Sieve 2.2 Received: from relay1.suse.de (relay1.suse.de [149.44.160.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "relay.suse.de", Issuer "CAcert Class 3 Root" (verified OK)) by imap.suse.de (Postfix) with ESMTPS id 7CCF63C539A9 for <gregkh@imap.suse.de>; Sun, 9 Jan 2011 08:38:58 +0100 (CET) Received: by relay1.suse.de (Postfix) id 6E027344BA65; Sun, 9 Jan 2011 08:38:58 +0100 (CET) Received: from relay1.suse.de (localhost [127.0.0.1]) by relay1.suse.de (Postfix) with ESMTP id 644B9344BA64 for <gregkh@suse.de>; Sun, 9 Jan 2011 08:38:58 +0100 (CET) Received: from relay1.suse.de ([127.0.0.1]) by relay1.suse.de (relay1.suse.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 01359-10 for <gregkh@suse.de>; Sun, 9 Jan 2011 08:38:58 +0100 (CET) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by relay1.suse.de (Postfix) with ESMTP id 18EB4344BA61 for <gregkh@suse.de>; Sun, 9 Jan 2011 08:38:58 +0100 (CET) Received: from atrey.karlin.mff.cuni.cz (ksp.mff.cuni.cz [195.113.26.206]) by mx2.suse.de (Postfix) with ESMTP id 0F1ED4844E for <gregkh@suse.de>; Sun, 9 Jan 2011 08:38:57 +0100 (CET) Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 7B4B8F01C3; Sun, 9 Jan 2011 08:38:57 +0100 (CET) Date: Sun, 9 Jan 2011 08:38:48 +0100 From: Pavel Machek <pavel@ucw.cz> To: Greg KH <gregkh@suse.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org, stable@kernel.org, stable-review@kernel.org, torvalds@linux-foundation.org, akpm@linux-foundation.org Subject: unbreak billionton CF card (was Re: [000/152] 2.6.36.3-stable review) Message-ID: <20110109073848.GA1553@ucw.cz> References: <20110106002500.GA3172@kroah.com> <20110106134254.68fa27ac@lxorguk.ukuu.org.uk> <20110106215705.GA30799@suse.de> <20110107150724.GA29082@atrey.karlin.mff.cuni.cz> <20110107183716.GA14895@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110107183716.GA14895@suse.de> User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: by amavisd-new at relay1.suse.de X-Spam-Status: No, score=-3.599 tagged_above=-20 required=5 tests=[BAYES_00=-2.599, MY_LINUX=-1] X-Spam-Score: -3.599 X-Spam-Level: Status: RO Content-Length: 1129 Unbreak Billionton CF bluetooth card. This actually fixes a regression on zaurus. Signed-off-by: Pavel Machek <pavel@ucw.cz> --- > > Flow control flag seems to be responsible. > > > > But... it hits me and then... me. So I'd like to see it resolved in > > devel tree, but it may not 100% vital for stable. > > Ok, care to make up a patch I can apply for Linus's tree first that > works for you? ./drivers/serial - ./drivers/serial.ofic diff -X /usr/src/linux/.gitignore -ur ./drivers/serial.ofic/8250.c ./drivers/serial/8250.c --- ./drivers/serial.ofic/8250.c 2011-01-02 21:25:29.000000000 +0100 +++ ./drivers/serial/8250.c 2011-01-09 08:10:39.000000000 +0100 @@ -236,7 +236,8 @@ .fifo_size = 128, .tx_loadsz = 128, .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, - .flags = UART_CAP_FIFO | UART_CAP_EFR | UART_CAP_SLEEP, + /* UART_CAP_EFR breaks billionon CF bluetooth card. */ + .flags = UART_CAP_FIFO | UART_CAP_SLEEP, }, [PORT_16654] = { .name = "ST16654", -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Mainpine IQ Express Rev3 problems beginning 2.6.36 2011-01-11 23:03 ` Greg KH @ 2011-01-25 15:57 ` Lee Howard 0 siblings, 0 replies; 10+ messages in thread From: Lee Howard @ 2011-01-25 15:57 UTC (permalink / raw) To: 'Greg KH'; +Cc: linux-serial > -----Original Message----- > From: Greg KH [mailto:greg@kroah.com] > Sent: Tuesday, January 11, 2011 3:03 PM > To: Lee Howard > Cc: linux-serial@vger.kernel.org > Subject: Re: Mainpine IQ Express Rev3 problems beginning 2.6.36 > > On Tue, Jan 11, 2011 at 11:16:06AM -0800, Lee Howard wrote: > > > > > -----Original Message----- > > > From: Greg KH [mailto:greg@kroah.com] > > > Sent: Monday, January 10, 2011 4:03 PM > > > To: Lee Howard > > > Cc: linux-serial@vger.kernel.org > > > Subject: Re: Mainpine IQ Express Rev3 problems beginning 2.6.36 > > > > > > On Fri, Dec 17, 2010 at 05:25:19AM -0800, Lee Howard wrote: > > > > > -----Original Message----- > > > > > From: linux-serial-owner@vger.kernel.org > > > > > [mailto:linux-serial-owner@vger.kernel.org] On Behalf Of > > > Lee Howard > > > > > Sent: Tuesday, December 14, 2010 11:50 AM > > > > > To: 'Greg KH' > > > > > Cc: linux-serial@vger.kernel.org > > > > > Subject: RE: Mainpine IQ Express Rev3 problems > beginning 2.6.36 > > > > > > > > > > > -----Original Message----- > > > > > > From: Greg KH [mailto:greg@kroah.com] > > > > > > Sent: Sunday, December 12, 2010 8:52 AM > > > > > > > > > > > As for build issues, try to make a minimal working > > > config for your > > > > > > system, using 'make localmodconfig'. That will > speed up your > > > > > > build time immensely as well as reduce your chances of > > > build and > > > > > > runtime problems with the intermediate kernels. > > > > > > > > > > Thank-you, that did help immensely. > > > > > > > > > > Here's the 'git bisect' result... > > > > > > > > > > -------------- > > > > > 7a56aa45982bb87bfca98a2832b5ae782c03364a is the first > bad commit > > > > > commit 7a56aa45982bb87bfca98a2832b5ae782c03364a > > > > > Author: Yegor Yefremov <yegor_sub1@visionsystems.de> > > > > > Date: Wed Jun 16 16:29:55 2010 +0200 > > > > > > > > > > serial: add UART_CAP_EFR and UART_CAP_SLEEP flags > to 16C950 > > > > > UARTs definition > > > > > > > > > > Adding UART_CAP_EFR and UART_CAP_SLEEP flags will > > > enable sleep > > > > > mode > > > > > and automatic CTS flow control for 16C950 UARTs. It will > > > > > also avoid > > > > > capabilities detection warning like this: > > > > > > > > > > "ttyS0: detected caps 00000700 should be 00000100" > > > > > > > > > > Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> > > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > > > > > > > > > :040000 040000 1776ca8d5c653834363c0778b5b404ee52bd2d69 > > > > > b81cfe4f302a674935181bd248641873820517e5 M drivers > > > > > -------------- > > > > > > > > > > Indeed, if I remove the UART_CAP_EFR flag from later kernel > > > > > revisions there is no problem. > > > > > > > > Greg, > > > > > > > > What's to be done? > > > > > > Sorry for the delay, I think Pavel's posted patch will solve this > > > issue for you, right? > > > > I've looked in the linux-serial archives for posts by Pavel for the > > last month, but I don't see a patch. Please tell me where > I can find this patch. > > I've attached it below. Thank you. Sorry for my delay in responding. Yes, the posted patch will solve the issue for me. I was going to look into whether UART_CAP_SLEEP was meaningful without UART_CAP_EFR because I thought I had read somewhere that it was not. But I just haven't managed to make time to do that. Thanks, Lee. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-01-25 15:58 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-12-08 23:55 Mainpine IQ Express Rev3 problems beginning 2.6.36 Lee Howard 2010-12-09 6:42 ` Greg KH 2010-12-12 0:36 ` Lee Howard 2010-12-12 16:52 ` Greg KH 2010-12-14 19:49 ` Lee Howard 2010-12-17 13:25 ` Lee Howard 2011-01-11 0:02 ` Greg KH 2011-01-11 19:16 ` Lee Howard 2011-01-11 23:03 ` Greg KH 2011-01-25 15:57 ` Lee Howard
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.