Bug 17061

Will try 2.6.36-rc2 in few hours...

Does /proc/ioport or /proc/iomem change between 2.6.35 an 2.6.36-rc[12]? Also, what about lspcmcia -vvv?

In addition, it'd be great if you could enable dynamic debug for the PCMCIA core, and eject/insert the card:

$ echo "module pcmcia +p" > /sys/kernel/debug/dynamic_debug/control
$ pccardctl eject
$ pccardctl insert

Created attachment 28401 [details]
And even though I think this issue is unrelated, here's a bugfix to serial_cs.c ...

lspcmcia -vvv did not change. Diff for /proc/iport/mem:

diff -ur debug.2.6.35/iomem debug.2.6.36-rc2/iomem
--- debug.2.6.35/iomem	2010-08-30 07:58:26.000000000 +0200
+++ debug.2.6.36-rc2/iomem	2010-08-30 09:05:31.000000000 +0200
@@ -1,4 +1,3 @@
-00000000-007fffff : physmap-flash
 08800040-08800fff : sharp-scoop.1
 0c000000-0c000fff : sharpsl-nand
 10800000-10800fff : sharp-scoop.0
@@ -20,6 +19,8 @@
 40900000-4090003b : pxa-rtc
 40b00000-40b0001f : pxa27x-pwm.0
 40c00000-40c0001f : pxa27x-pwm.1
+40f00180-40f001a3 : pxa2xx-i2c.1
+  40f00180-40f001a3 : pxa2xx-i2c.1
 41000000-4100003f : pxa27x-ssp.0
   41000000-4100003f : pxa27x-ssp
 41100000-41100fff : pxa2xx-mci.0
@@ -30,7 +31,6 @@
   41900000-4190003f : pxa27x-ssp
 44000000-4400ffff : pxa2xx-fb
   44000000-4400ffff : pxa2xx-fb
-4c000000-4c00ff6f : pxa27x-ohci
 a0000000-a3ffffff : System RAM
-  a0021000-a043afff : Kernel text
-  a0452000-a04a3470 : Kernel data
+  a0021000-a0445fff : Kernel text
+  a045e000-a04b08d4 : Kernel data
diff -ur debug.2.6.35/ioports debug.2.6.36-rc2/ioports
--- debug.2.6.35/ioports	2010-08-30 07:50:17.000000000 +0200
+++ debug.2.6.36-rc2/ioports	2010-08-30 09:05:27.000000000 +0200
@@ -1,3 +1,3 @@
-c48202f8-c48202ff : serial
-c4840000-c4840007 : ide-cs
-c484000e-c484000e : ide-cs
+c48402f8-c48402ff : serial
+c4860000-c4860007 : ide-cs
+c486000e-c486000e : ide-cs


lspcmcia:

Socket 0 Bridge:   	[pxa2xx-pcmcia] 	(bus ID: pxa2xx-pcmcia)
	Configuration:	state: on	ready: yes
			Voltage: 3.3V Vcc: 3.3V Vpp: 0.0V
			Available IRQs: none
Socket 0 Device 0:	[serial_cs]		(bus ID: 0.0)
	Configuration:	state: on
	Product Name:   Compact Flash Bluetooth Card 
	Identification:	manf_id: 0x0279	card_id: 0x950b
			function: 2 (serial)
			prod_id(1): "Compact Flash" (0x95521410)
			prod_id(2): "Bluetooth Card" (0x7664fb1d)
			prod_id(3): --- (---)
			prod_id(4): --- (---)
Socket 1 Bridge:   	[pxa2xx-pcmcia] 	(bus ID: pxa2xx-pcmcia)
	Configuration:	state: on	ready: yes
			Voltage: 3.3V Vcc: 3.3V Vpp: 0.0V
			Available IRQs: none
Socket 1 Device 0:	[ide-cs]		(bus ID: 1.0)
	Configuration:	state: on
	Product Name:   HITACHI microdrive 
	Identification:	manf_id: 0x0319	card_id: 0x0000
			function: 4 (fixed disk)
			prod_id(1): "HITACHI" (0xf4f43949)
			prod_id(2): "microdrive" (0xa6d76178)
			prod_id(3): --- (---)
			prod_id(4): --- (---)

I tried kind-of bisect, and it seemed bluetooth subsystem was not responsible. 

The same card works in x86 notebook, even with latest kernels.

I'm now doing full bisect.


pavel@amd:/data/l/linux-z$ cat .git/BISECT_LOG 
git bisect start
# bad: [ffc96d628b651b69b39909fc3e9e8f465df1eed3] Merge branch 'nommu-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/nommu-2.6
git bisect bad ffc96d628b651b69b39909fc3e9e8f465df1eed3
# bad: [ffc96d628b651b69b39909fc3e9e8f465df1eed3] Merge branch 'nommu-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/nommu-2.6
git bisect bad ffc96d628b651b69b39909fc3e9e8f465df1eed3
# good: [9fe6206f400646a2322096b56c59891d530e8d51] Linux 2.6.35
git bisect good 9fe6206f400646a2322096b56c59891d530e8d51
# bad: [da5cabf80e2433131bf0ed8993abc0f7ea618c73] Linux 2.6.36-rc1
git bisect bad da5cabf80e2433131bf0ed8993abc0f7ea618c73
# good: [0f477dd0851bdcee82923da66a7fc4a44cb1bc3d] Merge branch 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect good 0f477dd0851bdcee82923da66a7fc4a44cb1bc3d
# good: [0f477dd0851bdcee82923da66a7fc4a44cb1bc3d] Merge branch 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect good 0f477dd0851bdcee82923da66a7fc4a44cb1bc3d
# good: [f6cec0ae58c17522a7bc4e2f39dae19f199ab534] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
git bisect good f6cec0ae58c17522a7bc4e2f39dae19f199ab534
pavel@amd:/data/l/linux-z$

This one is very very suspect:


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>

(I'd like to add Greg and Yegor to cc, but can't figure out how :-().

*** Bug 26122 has been marked as a duplicate of this bug. ***

First-Bad-Commit : 7a56aa45982bb87bfca98a2832b5ae782c03364a

Hi Pavel, Greg, 

what's the status of this?

On Sun, Jan 30, 2011 at 11:41:50AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> what's the status of this?

Now sent to Linus to be resolved.

There is no commit to drivers/serial/8250.c since 2011/01/30 .. how has this been resolved? Is this still a problem?