[Bug 15621] BUG: unable to handle kernel paging request - comm: pccardd
https://bugzilla.kernel.org/show_bug.cgi?id=15621 --- Comment #1 from Ozgur Yuksel 2010-03-24 10:09:07 --- Created an attachment (id=25680) --> (https://bugzilla.kernel.org/attachment.cgi?id=25680) Dump for first failure -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 15621] BUG: unable to handle kernel paging request - comm: pccardd
https://bugzilla.kernel.org/show_bug.cgi?id=15621 --- Comment #2 from Ozgur Yuksel 2010-03-24 10:09:43 --- Created an attachment (id=25681) --> (https://bugzilla.kernel.org/attachment.cgi?id=25681) Recurring failures that follow -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 15621] New: BUG: unable to handle kernel paging request - comm: pccardd
https://bugzilla.kernel.org/show_bug.cgi?id=15621 Summary: BUG: unable to handle kernel paging request - comm: pccardd Product: Drivers Version: 2.5 Kernel Version: 2.6.34-rc2 ae6be51ed01d6c4aaf249a207b4434bc7785853b Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PCMCIA AssignedTo: linux-pcmcia@lists.infradead.org ReportedBy: ozgur.yuk...@oracle.com Regression: Yes After building ae6be51ed01d6c4aaf249a207b4434bc7785853b, bootup gives out: [ 75.245698] BUG: unable to handle kernel paging request at 746f7274 [ 75.249007] IP: [] iomem_map_sanity_check+0x70/0x170 [ 75.249007] *pdpt = 2371c001 *pde = [ 75.249007] Oops: [#1] SMP [ 75.249007] last sysfs file: /sys/devices/pnp0/00:0e/id [ 75.272054] Modules linked in: sbp2 ip_tables snd yenta_socket ppdev psmouse soundcort [ 75.272054] [ 75.272054] Pid: 998, comm: pccardd Not tainted 2.6.34-rc2 #1 0KU184/Latitude D630 [ 75.306331] EIP: 0060:[] EFLAGS: 00010202 CPU: 1 [ 75.306331] EIP is at iomem_map_sanity_check+0x70/0x170 [ 75.306331] EAX: 746f7270 EBX: 000f4800 ECX: 01100018 EDX: 746f7270 [ 75.306331] ESI: EDI: 1000 EBP: e4701d34 ESP: e4701cd0 [ 75.306331] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 75.306331] Process pccardd (pid: 998, ti=e470 task=e36f3fc0 task.ti=e470) [ 75.306331] Stack: [ 75.359751] c04a0f5c 0004 0002 28172cf5 e47d4390 0013 [ 75.359751] <0> e4701d04 f4800fff 000f4800 000f4800 000 [ 75.359751] <0> f480 f4800fff f4801000 f480 000 [ 75.359751] Call Trace: [ 75.359751] [] ? raw_pci_write+0x7c/0x80 [ 75.359751] [] ? __ioremap_caller+0xae/0x3f0 [ 75.359751] [] ? kmem_cache_alloc_notrace+0x6b/0xb0 [ 75.421337] [] ? __request_region+0x1e/0x210 [ 75.421337] [] ? usb_hcd_pci_probe+0x17b/0x3f0 [ 75.436059] [] ? ioremap_nocache+0x1a/0x20 [ 75.436059] [] ? usb_hcd_pci_probe+0x17b/0x3f0 [ 75.436059] [] ? usb_hcd_pci_probe+0x17b/0x3f0 [ 75.436059] [] ? sysfs_add_one+0x18/0x100 [ 75.436059] [] ? sysfs_new_dirent+0x67/0x100 [ 75.436059] [] ? local_pci_probe+0xe/0x10 [ 75.436059] [] ? pci_device_probe+0x60/0x80 [ 75.436059] [] ? driver_probe_device+0x69/0x150 [ 75.436059] [] ? __device_attach+0x41/0x50 [ 75.436059] [] ? bus_for_each_drv+0x48/0x70 [ 75.436059] [] ? device_attach+0x6d/0x80 [ 75.436059] [] ? __device_attach+0x0/0x50 [ 75.436059] [] ? bus_probe_device+0x1d/0x40 [ 75.436059] [] ? device_add+0x48a/0x560 [ 75.436059] [] ? pci_set_cacheline_size+0x8e/0xe0 [ 75.436059] [] ? pci_bus_add_device+0x17/0x40 [ 75.436059] [] ? pci_bus_add_devices+0x40/0x120 [ 75.436059] [] ? cb_alloc+0xca/0xe0 [pcmcia_core] [ 75.436059] [] ? socket_insert+0xd9/0x100 [pcmcia_core] [ 75.436059] [] ? pccardd+0x309/0x400 [pcmcia_core] [ 75.436059] [] ? pccardd+0x0/0x400 [pcmcia_core] [ 75.436059] [] ? kthread+0x6c/0x80 [ 75.436059] [] ? kthread+0x0/0x80 [ 75.436059] [] ? kernel_thread_helper+0x6/0x10 [ 75.436059] Code: 55 ec 89 4d d8 8b 4d f0 89 5d dc 89 75 e0 83 c2 ff 83 d1 ff 89 55 c [ 75.436059] EIP: [] iomem_map_sanity_check+0x70/0x170 SS:ESP 0068:e4701cd0 [ 75.436059] CR2: 746f7274 [ 75.439957] ---[ end trace c9fcf1971e726fcf ]--- But kernel continues to boot .. But unfortunately fails with below later on: [ 141.736006] BUG: soft lockup - CPU#0 stuck for 61s! [modprobe:573] [ 141.736006] Modules linked in: auth_rpcgss iwl3945(+) snd_timer uinput snd_seq_devicet [ 141.736006] Modules linked in: auth_rpcgss iwl3945(+) snd_timer uinput snd_seq_devicet [ 141.736006] [ 141.736006] Pid: 573, comm: modprobe Tainted: G D 2.6.34-rc2 #1 0KU184/Latitu [ 141.736006] EIP: 0060:[] EFLAGS: 0287 CPU: 0 [ 141.736006] EIP is at __write_lock_failed+0xc/0x20 [ 141.736006] EAX: c077e2e4 EBX: fe8f ECX: e4713240 EDX: e4713240 [ 141.736006] ESI: EDI: c077e2c0 EBP: e454bd70 ESP: e454bd70 [ 141.736006] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 141.736006] Process modprobe (pid: 573, ti=e454a000 task=e3425940 task.ti=e454a000) [ 141.736006] Stack: [ 141.736006] e454bd78 c0590151 e454bda8 c014ebc9 000d e4713240 c04a0f5c [ 141.736006] <0> 000d 0040 e4713240 1000 e454bdf0 c0339c8 [ 141.736006] <0> 1000 f87b3d33 fe8f 100 [ 141.736006] Call Trace: [ 141.736006] [] ? _raw_write_lock+0x11/0x20 [ 141.736006] [] ? __request_region+0x79/0x210 [ 141.736006] [] ? raw_pci_write+0x7c/0x80 [ 141.736006] [] ? __pci_request_region+0x158/0x1c0 [ 141.736006] [] ? __pci_request_selected_regions+0x37/0x70 [ 141.736006] [] ? pci_request_selected_regions+0x12/0x20 [ 141.73600
[Bug 15621] BUG: unable to handle kernel paging request - comm: pccardd
https://bugzilla.kernel.org/show_bug.cgi?id=15621 --- Comment #3 from Andrew Morton 2010-03-24 14:14:17 --- (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 24 Mar 2010 10:07:54 GMT bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=15621 > >Summary: BUG: unable to handle kernel paging request - comm: > pccardd >Product: Drivers >Version: 2.5 > Kernel Version: 2.6.34-rc2 ae6be51ed01d6c4aaf249a207b4434bc7785853b > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: PCMCIA > AssignedTo: linux-pcmcia@lists.infradead.org > ReportedBy: ozgur.yuk...@oracle.com > Regression: Yes It looks like the iomem_resource tree got wrecked. Has anyone been changing anything in there lately? > > After building ae6be51ed01d6c4aaf249a207b4434bc7785853b, bootup gives out: > [ 75.245698] BUG: unable to handle kernel paging request at 746f7274 > [ 75.249007] IP: [] iomem_map_sanity_check+0x70/0x170 > [ 75.249007] *pdpt = 2371c001 *pde = > [ 75.249007] Oops: [#1] SMP > [ 75.249007] last sysfs file: /sys/devices/pnp0/00:0e/id > [ 75.272054] Modules linked in: sbp2 ip_tables snd yenta_socket ppdev > psmouse > soundcort > [ 75.272054] > [ 75.272054] Pid: 998, comm: pccardd Not tainted 2.6.34-rc2 #1 > 0KU184/Latitude D630 > [ 75.306331] EIP: 0060:[] EFLAGS: 00010202 CPU: 1 > [ 75.306331] EIP is at iomem_map_sanity_check+0x70/0x170 > [ 75.306331] EAX: 746f7270 EBX: 000f4800 ECX: 01100018 EDX: 746f7270 > [ 75.306331] ESI: EDI: 1000 EBP: e4701d34 ESP: e4701cd0 > [ 75.306331] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > [ 75.306331] Process pccardd (pid: 998, ti=e470 task=e36f3fc0 > task.ti=e470) > [ 75.306331] Stack: > [ 75.359751] c04a0f5c 0004 0002 28172cf5 e47d4390 > 0013 > [ 75.359751] <0> e4701d04 f4800fff 000f4800 > 000f4800 000 > [ 75.359751] <0> f480 f4800fff f4801000 > f480 000 > [ 75.359751] Call Trace: > [ 75.359751] [] ? raw_pci_write+0x7c/0x80 > [ 75.359751] [] ? __ioremap_caller+0xae/0x3f0 > [ 75.359751] [] ? kmem_cache_alloc_notrace+0x6b/0xb0 > [ 75.421337] [] ? __request_region+0x1e/0x210 > [ 75.421337] [] ? usb_hcd_pci_probe+0x17b/0x3f0 > [ 75.436059] [] ? ioremap_nocache+0x1a/0x20 > [ 75.436059] [] ? usb_hcd_pci_probe+0x17b/0x3f0 > [ 75.436059] [] ? usb_hcd_pci_probe+0x17b/0x3f0 > [ 75.436059] [] ? sysfs_add_one+0x18/0x100 > [ 75.436059] [] ? sysfs_new_dirent+0x67/0x100 > [ 75.436059] [] ? local_pci_probe+0xe/0x10 > [ 75.436059] [] ? pci_device_probe+0x60/0x80 > [ 75.436059] [] ? driver_probe_device+0x69/0x150 > [ 75.436059] [] ? __device_attach+0x41/0x50 > [ 75.436059] [] ? bus_for_each_drv+0x48/0x70 > [ 75.436059] [] ? device_attach+0x6d/0x80 > [ 75.436059] [] ? __device_attach+0x0/0x50 > [ 75.436059] [] ? bus_probe_device+0x1d/0x40 > [ 75.436059] [] ? device_add+0x48a/0x560 > [ 75.436059] [] ? pci_set_cacheline_size+0x8e/0xe0 > [ 75.436059] [] ? pci_bus_add_device+0x17/0x40 > [ 75.436059] [] ? pci_bus_add_devices+0x40/0x120 > [ 75.436059] [] ? cb_alloc+0xca/0xe0 [pcmcia_core] > [ 75.436059] [] ? socket_insert+0xd9/0x100 [pcmcia_core] > [ 75.436059] [] ? pccardd+0x309/0x400 [pcmcia_core] > [ 75.436059] [] ? pccardd+0x0/0x400 [pcmcia_core] > [ 75.436059] [] ? kthread+0x6c/0x80 > [ 75.436059] [] ? kthread+0x0/0x80 > [ 75.436059] [] ? kernel_thread_helper+0x6/0x10 > [ 75.436059] Code: 55 ec 89 4d d8 8b 4d f0 89 5d dc 89 75 e0 83 c2 ff 83 d1 > ff 89 55 c > [ 75.436059] EIP: [] iomem_map_sanity_check+0x70/0x170 SS:ESP > 0068:e4701cd0 > [ 75.436059] CR2: 746f7274 > [ 75.439957] ---[ end trace c9fcf1971e726fcf ]--- > > But kernel continues to boot .. But unfortunately fails with below later on: > > [ 141.736006] BUG: soft lockup - CPU#0 stuck for 61s! [modprobe:573] > [ 141.736006] Modules linked in: auth_rpcgss iwl3945(+) snd_timer uinput > snd_seq_devicet > [ 141.736006] Modules linked in: auth_rpcgss iwl3945(+) snd_timer uinput > snd_seq_devicet > [ 141.736006] > [ 141.736006] Pid: 573, comm: modprobe Tainted: G D 2.6.34-rc2 #1 > 0KU184/Latitu > [ 141.736006] EIP: 0060:[] EFLAGS: 0287 CPU: 0 > [ 141.736006] EIP is at __write_lock_failed+0xc/0x20 > [ 141.736006] EAX: c077e2e4 EBX: fe8f ECX: e4713240 EDX: e4713240 > [ 141.736006] ESI: EDI: c077e2c0 EBP: e454bd70 ESP: e454bd70 > [ 141.736006] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > [ 141.736006] Process modprobe (pid: 573, ti=e454a000 task=e3425940 > task.ti=e454a000) > [ 141.736006] Stack: > [ 141.736006] e454bd78 c
Re: [PATCH v2] pcmcia: db1xxx-ss: suspend/resume fix
Dominik, On Tue, Mar 23, 2010 at 11:02 PM, Rafael J. Wysocki wrote: > On Tuesday 23 March 2010, Manuel Lauss wrote: >> Howdy, >> >> On Mon, Mar 22, 2010 at 9:58 PM, Dominik Brodowski >> wrote: >> > Hm, what about using two commits currently in my tree for 2.6.36 instead, >> > which should fix all socket drivers? >> > >> > power: support _noirq actions on device types and classes >> > pcmcia: use dev_pm_ops for class pcmcia_socket_class >> > >> > Manuel: Could you try whether they also solve these issues? If so, I'd >> >> Yes it does, works on my MIPS test systems. > > I don't seem to have received the original message, so sorry for the lack of > response. > >> > propose pushing both patches already for 2.6.36. Rafael: do you concur? > > I do. The patches look good and if they fix things for people right now, > that's a good reason to push them for .34. > >> I hope you meant 2.6.34 > > I think Dominik meant .35 actually. Okay, can we apply my v2 patch to 2.6.34? I'd like to have PM working when it gets out. Manuel ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: pci_bus_for_each_resource, transparent bridges and rsrc_nonstatic.c
On Tue, 2010-03-23 at 19:02 +0100, Dominik Brodowski wrote: > > If you make PCMCIA smart enough to avoid these low ports, do we still > > need these &ioport_resource and &iomem_resource checks? Having two > > mechanisms will lead to more complicated behavior and more special > > cases. > > Well, it aren't only the low ports (<0x100) I'm concerned about, it's also > (and especially on pre-2008 systems) ports in higher areas > (0x100 < x < 0x). If we don't use _CRS, we need to be more careful to > avoid accidentally hitting wrong I/O-ports. > From: Dominik Brodowski > Date: Tue, 23 Mar 2010 16:05:00 +0100 > Subject: [PATCH] pcmcia: do not use ioports < 0x100 on x86 > > On x86 systems using ACPI _CRS information -- now the default for > post-2008 systems -- the PCI root bus no longer pretends to be > offering the root ioport_resource. To avoid accidentally hitting > some platform / system device, use only I/O ports >= 0x100 for > PCMCIA devices on x86. > > Reported-by: Komuro > CC: Bjorn Helgaas > Signed-off-by: Dominik Brodowski > > diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c > index 4663b3f..dcc6021 100644 > --- a/drivers/pcmcia/rsrc_nonstatic.c > +++ b/drivers/pcmcia/rsrc_nonstatic.c > @@ -810,6 +810,13 @@ static int adjust_io(struct pcmcia_socket *s, unsigned > int action, unsigned long > unsigned long size = end - start + 1; > int ret = 0; > > +#if defined(CONFIG_X86) > + /* on x86, avoid anything < 0x100 for it is often used for > + * legacy platform devices */ > + if (start < 0x100) > + start = 0x100; > +#endif This looks OK to me (but we've already established that I don't know anything about PCMCIA :)). I do wonder whether we should have a generic mechanism to define areas we should avoid, along the lines of PCIBIOS_MIN_IO and PCIBIOS_MIN_CARDBUS_IO. PNP should probably avoid the same areas. Which reminds me, what little I gleaned from the MindShare PCMCIA book suggests that PCMCIA devices are similar to PNPBIOS devices in some ways -- you get a list of possible resource assignments from CIS, sometimes those assignments are fixed, other times they're programmable, and then you pick something that works. I wonder if there'd be any point in integrating PNP and PCMCIA somehow. Bjorn > if (end < start) > return -EINVAL; > ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [linux-pm] [PATCH v2] pcmcia: db1xxx-ss: suspend/resume fix
Hey, On Wed, Mar 24, 2010 at 06:04:50PM +0100, Manuel Lauss wrote: > Dominik, > > On Tue, Mar 23, 2010 at 11:02 PM, Rafael J. Wysocki wrote: > > On Tuesday 23 March 2010, Manuel Lauss wrote: > >> Howdy, > >> > >> On Mon, Mar 22, 2010 at 9:58 PM, Dominik Brodowski > >> wrote: > >> > Hm, what about using two commits currently in my tree for 2.6.36 instead, > >> > which should fix all socket drivers? > >> > > >> > power: support _noirq actions on device types and classes > >> > pcmcia: use dev_pm_ops for class pcmcia_socket_class > >> > > >> > Manuel: Could you try whether they also solve these issues? If so, I'd > >> > >> Yes it does, works on my MIPS test systems. > > > > I don't seem to have received the original message, so sorry for the lack of > > response. > > > >> > propose pushing both patches already for 2.6.36. Rafael: do you concur? > > > > I do. The patches look good and if they fix things for people right now, > > that's a good reason to push them for .34. > > > >> I hope you meant 2.6.34 > > > > I think Dominik meant .35 actually. > > Okay, can we apply my v2 patch to 2.6.34? I'd like to have PM working when > it gets out. Actually I meant .34. I'll push out my patch in the next days, if you concur. Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [linux-pm] [PATCH v2] pcmcia: db1xxx-ss: suspend/resume fix
On Wed, Mar 24, 2010 at 8:18 PM, Dominik Brodowski wrote: > Hey, > > On Wed, Mar 24, 2010 at 06:04:50PM +0100, Manuel Lauss wrote: >> Dominik, >> >> On Tue, Mar 23, 2010 at 11:02 PM, Rafael J. Wysocki wrote: >> > On Tuesday 23 March 2010, Manuel Lauss wrote: >> >> Howdy, >> >> >> >> On Mon, Mar 22, 2010 at 9:58 PM, Dominik Brodowski >> >> wrote: >> >> > Hm, what about using two commits currently in my tree for 2.6.36 >> >> > instead, >> >> > which should fix all socket drivers? >> >> > >> >> > power: support _noirq actions on device types and classes >> >> > pcmcia: use dev_pm_ops for class pcmcia_socket_class >> >> > >> >> > Manuel: Could you try whether they also solve these issues? If so, I'd >> >> >> >> Yes it does, works on my MIPS test systems. >> > >> > I don't seem to have received the original message, so sorry for the lack >> > of >> > response. >> > >> >> > propose pushing both patches already for 2.6.36. Rafael: do you concur? >> > >> > I do. The patches look good and if they fix things for people right now, >> > that's a good reason to push them for .34. >> > >> >> I hope you meant 2.6.34 >> > >> > I think Dominik meant .35 actually. >> >> Okay, can we apply my v2 patch to 2.6.34? I'd like to have PM working when >> it gets out. > > Actually I meant .34. I'll push out my patch in the next days, if you > concur. Great, I'm all for upstreaming your patch. Thanks! Manuel Lauss ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 15621] BUG: unable to handle kernel paging request - comm: pccardd
https://bugzilla.kernel.org/show_bug.cgi?id=15621 Rafael J. Wysocki changed: What|Removed |Added CC||r...@sisk.pl Blocks||15310 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [linux-pm] [PATCH v2] pcmcia: db1xxx-ss: suspend/resume fix
On Wednesday 24 March 2010, Manuel Lauss wrote: > On Wed, Mar 24, 2010 at 8:18 PM, Dominik Brodowski > wrote: > > Hey, > > > > On Wed, Mar 24, 2010 at 06:04:50PM +0100, Manuel Lauss wrote: > >> Dominik, > >> > >> On Tue, Mar 23, 2010 at 11:02 PM, Rafael J. Wysocki wrote: > >> > On Tuesday 23 March 2010, Manuel Lauss wrote: > >> >> Howdy, > >> >> > >> >> On Mon, Mar 22, 2010 at 9:58 PM, Dominik Brodowski > >> >> wrote: > >> >> > Hm, what about using two commits currently in my tree for 2.6.36 > >> >> > instead, > >> >> > which should fix all socket drivers? > >> >> > > >> >> >power: support _noirq actions on device types and classes > >> >> >pcmcia: use dev_pm_ops for class pcmcia_socket_class > >> >> > > >> >> > Manuel: Could you try whether they also solve these issues? If so, I'd > >> >> > >> >> Yes it does, works on my MIPS test systems. > >> > > >> > I don't seem to have received the original message, so sorry for the > >> > lack of > >> > response. > >> > > >> >> > propose pushing both patches already for 2.6.36. Rafael: do you > >> >> > concur? > >> > > >> > I do. The patches look good and if they fix things for people right now, > >> > that's a good reason to push them for .34. > >> > > >> >> I hope you meant 2.6.34 > >> > > >> > I think Dominik meant .35 actually. > >> > >> Okay, can we apply my v2 patch to 2.6.34? I'd like to have PM working when > >> it gets out. > > > > Actually I meant .34. I'll push out my patch in the next days, if you > > concur. > > Great, I'm all for upstreaming your patch. Agreed. Rafael ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 7304] no PCI irq, Cardbus support disabled
https://bugzilla.kernel.org/show_bug.cgi?id=7304 --- Comment #80 from Thomas Nemeth 2010-03-24 20:08:56 --- Created an attachment (id=25689) --> (https://bugzilla.kernel.org/attachment.cgi?id=25689) Boot messages for 2.6.34-rc2 with IRQ forced to 11. As you requested I compiled a 2.6.34-rc2 kernel with the irqs forced to 11. The configuration file displays: $ grep CONFIG_DMI linux-2.6.34-rc2/.config CONFIG_DMI=y CONFIG_DMIID=y It was the same with the 2.6.33 :( I booted and configuered the eth card in the working slot, tested it (ok) and then put it in the other (non-working) slot. It could get an IP address through DHCP but ping didn't work. dmidecode gave the same results as previouly. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[Bug 7304] no PCI irq, Cardbus support disabled
https://bugzilla.kernel.org/show_bug.cgi?id=7304 --- Comment #81 from Thomas Nemeth 2010-03-24 20:16:34 --- Ooops wrong. I didn't get an IP address through DHCP on the non-working slot. I just forgot to ifconfig down the interface before switching slots. The non-working slot still doesn't work. Regarding the dmidecode output, could it be that my computer is too old ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[PATCH 2/2] ARM: pcmcia: fix checkpatch.pl issues in soc_common.c
This patch fixes checkpatch.pl issues in soc_common.c.
Signed-off-by: Marcelo Roberto Jimenez
---
drivers/pcmcia/soc_common.c | 129 +++
1 files changed, 69 insertions(+), 60 deletions(-)
diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index fd4c25a..22af8d2 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -31,20 +31,20 @@
==*/
-#include
-#include
+#include
#include
+#include
+#include
+#include
#include
-#include
#include
+#include
+#include
#include
-#include
-#include
#include
-#include
+#include
#include
-#include
#include
#include "soc_common.h"
@@ -69,7 +69,8 @@ EXPORT_SYMBOL(soc_pcmcia_debug);
#endif
-#define to_soc_pcmcia_socket(x)container_of(x, struct
soc_pcmcia_socket, socket)
+#define to_soc_pcmcia_socket(x)\
+ container_of(x, struct soc_pcmcia_socket, socket)
static unsigned short
calc_speed(unsigned short *spds, int num, unsigned short dflt)
@@ -86,11 +87,15 @@ calc_speed(unsigned short *spds, int num, unsigned short
dflt)
return speed;
}
-void soc_common_pcmcia_get_timing(struct soc_pcmcia_socket *skt, struct
soc_pcmcia_timing *timing)
+void soc_common_pcmcia_get_timing(struct soc_pcmcia_socket *skt,
+ struct soc_pcmcia_timing *timing)
{
- timing->io = calc_speed(skt->spd_io, MAX_IO_WIN, SOC_PCMCIA_IO_ACCESS);
- timing->mem = calc_speed(skt->spd_mem, MAX_WIN,
SOC_PCMCIA_3V_MEM_ACCESS);
- timing->attr = calc_speed(skt->spd_attr, MAX_WIN,
SOC_PCMCIA_3V_MEM_ACCESS);
+ timing->io =
+ calc_speed(skt->spd_io, MAX_IO_WIN, SOC_PCMCIA_IO_ACCESS);
+ timing->mem =
+ calc_speed(skt->spd_mem, MAX_WIN, SOC_PCMCIA_3V_MEM_ACCESS);
+ timing->attr =
+ calc_speed(skt->spd_attr, MAX_WIN, SOC_PCMCIA_3V_MEM_ACCESS);
}
EXPORT_SYMBOL(soc_common_pcmcia_get_timing);
@@ -132,8 +137,8 @@ static unsigned int soc_common_pcmcia_skt_state(struct
soc_pcmcia_socket *skt)
*
* Convert PCMCIA socket state to our socket configure structure.
*/
-static int
-soc_common_pcmcia_config_skt(struct soc_pcmcia_socket *skt, socket_state_t
*state)
+static int soc_common_pcmcia_config_skt(
+ struct soc_pcmcia_socket *skt, socket_state_t *state)
{
int ret;
@@ -145,7 +150,8 @@ soc_common_pcmcia_config_skt(struct soc_pcmcia_socket *skt,
socket_state_t *stat
*/
if (skt->irq_state != 1 && state->io_irq) {
skt->irq_state = 1;
- set_irq_type(skt->socket.pci_irq,
IRQ_TYPE_EDGE_FALLING);
+ set_irq_type(skt->socket.pci_irq,
+ IRQ_TYPE_EDGE_FALLING);
} else if (skt->irq_state == 1 && state->io_irq == 0) {
skt->irq_state = 0;
set_irq_type(skt->socket.pci_irq, IRQ_TYPE_NONE);
@@ -299,24 +305,25 @@ soc_common_pcmcia_get_status(struct pcmcia_socket *sock,
unsigned int *status)
* of power configuration, reset, &c. We also record the value of
* `state' in order to regurgitate it to the PCMCIA core later.
*/
-static int
-soc_common_pcmcia_set_socket(struct pcmcia_socket *sock, socket_state_t *state)
+static int soc_common_pcmcia_set_socket(
+ struct pcmcia_socket *sock, socket_state_t *state)
{
struct soc_pcmcia_socket *skt = to_soc_pcmcia_socket(sock);
- debug(skt, 2, "mask: %s%s%s%s%s%sflags: %s%s%s%s%s%sVcc %d Vpp %d irq
%d\n",
- (state->csc_mask==0)?" ":"",
- (state->csc_mask&SS_DETECT)?"DETECT ":"",
- (state->csc_mask&SS_READY)?"READY ":"",
- (state->csc_mask&SS_BATDEAD)?"BATDEAD ":"",
- (state->csc_mask&SS_BATWARN)?"BATWARN ":"",
- (state->csc_mask&SS_STSCHG)?"STSCHG ":"",
- (state->flags==0)?" ":"",
- (state->flags&SS_PWR_AUTO)?"PWR_AUTO ":"",
- (state->flags&SS_IOCARD)?"IOCARD ":"",
- (state->flags&SS_RESET)?"RESET ":"",
- (state->flags&SS_SPKR_ENA)?"SPKR_ENA ":"",
- (state->flags&SS_OUTPUT_ENA)?"OUTPUT_ENA ":"",
+ debug(skt, 2, "mask: %s%s%s%s%s%s "
+ "flags: %s%s%s%s%s%s Vcc %d Vpp %d irq %d\n",
+ (state->csc_mask == 0) ? " " : "",
+ (state->csc_mask & SS_DETECT) ? "DETECT " : "",
+ (state->csc_mask & SS_READY)? "READY " :"",
+ (state->csc_mask & SS_BATDEAD) ? "BATDEAD " : "",
+ (state->csc_mask & SS_BATWARN) ? "BATWARN " : "",
+ (state->csc_mask & SS_STSCHG) ? "STSCHG " : "",
+ (state->flags == 0
[PATCH 1/2] ARM: pcmcia: Fix for building DEBUG with sa11xx_base.c as a module.
This patch fixes a compilation issue when compiling PCMCIA SA1100 support as a module with PCMCIA_DEBUG enabled. The symbol soc_pcmcia_debug was not beeing exported. Signed-off-by: Marcelo Roberto Jimenez --- drivers/pcmcia/soc_common.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c index 6f1a86b..fd4c25a 100644 --- a/drivers/pcmcia/soc_common.c +++ b/drivers/pcmcia/soc_common.c @@ -65,6 +65,7 @@ void soc_pcmcia_debug(struct soc_pcmcia_socket *skt, const char *func, va_end(args); } } +EXPORT_SYMBOL(soc_pcmcia_debug); #endif -- 1.7.0.3 ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH 2/2] ARM: pcmcia: fix checkpatch.pl issues in soc_common.c
On Wed, Mar 24, 2010 at 08:04:58PM -0300, Marcelo Roberto Jimenez wrote: > - debug(skt, 2, "mask: %s%s%s%s%s%sflags: %s%s%s%s%s%sVcc %d Vpp %d irq > %d\n", > - (state->csc_mask==0)?" ":"", > - (state->csc_mask&SS_DETECT)?"DETECT ":"", > - (state->csc_mask&SS_READY)?"READY ":"", > - (state->csc_mask&SS_BATDEAD)?"BATDEAD ":"", > - (state->csc_mask&SS_BATWARN)?"BATWARN ":"", > - (state->csc_mask&SS_STSCHG)?"STSCHG ":"", > - (state->flags==0)?" ":"", > - (state->flags&SS_PWR_AUTO)?"PWR_AUTO ":"", > - (state->flags&SS_IOCARD)?"IOCARD ":"", > - (state->flags&SS_RESET)?"RESET ":"", > - (state->flags&SS_SPKR_ENA)?"SPKR_ENA ":"", > - (state->flags&SS_OUTPUT_ENA)?"OUTPUT_ENA ":"", > + debug(skt, 2, "mask: %s%s%s%s%s%s " > + "flags: %s%s%s%s%s%s Vcc %d Vpp %d irq %d\n", NAK. Breaking kernel messages across multiple lines makes them impossible to grep for. checkpatch.pl is wrong on this one. ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [PATCH 2/2] ARM: pcmcia: fix checkpatch.pl issues in soc_common.c
On Wed, Mar 24, 2010 at 20:07, Russell King - ARM Linux wrote: > On Wed, Mar 24, 2010 at 08:04:58PM -0300, Marcelo Roberto Jimenez wrote: >> - debug(skt, 2, "mask: %s%s%s%s%s%sflags: %s%s%s%s%s%sVcc %d Vpp %d irq >> %d\n", >> - (state->csc_mask==0)?" ":"", >> - (state->csc_mask&SS_DETECT)?"DETECT ":"", >> - (state->csc_mask&SS_READY)?"READY ":"", >> - (state->csc_mask&SS_BATDEAD)?"BATDEAD ":"", >> - (state->csc_mask&SS_BATWARN)?"BATWARN ":"", >> - (state->csc_mask&SS_STSCHG)?"STSCHG ":"", >> - (state->flags==0)?" ":"", >> - (state->flags&SS_PWR_AUTO)?"PWR_AUTO ":"", >> - (state->flags&SS_IOCARD)?"IOCARD ":"", >> - (state->flags&SS_RESET)?"RESET ":"", >> - (state->flags&SS_SPKR_ENA)?"SPKR_ENA ":"", >> - (state->flags&SS_OUTPUT_ENA)?"OUTPUT_ENA ":"", >> + debug(skt, 2, "mask: %s%s%s%s%s%s " >> + "flags: %s%s%s%s%s%s Vcc %d Vpp %d irq %d\n", > > NAK. Breaking kernel messages across multiple lines makes them impossible > to grep for. checkpatch.pl is wrong on this one. I will redo it, no problem. But just for my information, in that particular case, is it usefull to grep using format specifiers? ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[PATCH 2/2] ARM: pcmcia: fix checkpatch.pl issues in soc_common.c
This patch fixes checkpatch.pl issues in soc_common.c.
Signed-off-by: Marcelo Roberto Jimenez
---
drivers/pcmcia/soc_common.c | 128 +++
1 files changed, 68 insertions(+), 60 deletions(-)
diff --git a/drivers/pcmcia/soc_common.c b/drivers/pcmcia/soc_common.c
index fd4c25a..25c5b50 100644
--- a/drivers/pcmcia/soc_common.c
+++ b/drivers/pcmcia/soc_common.c
@@ -31,20 +31,20 @@
==*/
-#include
-#include
+#include
#include
+#include
+#include
+#include
#include
-#include
#include
+#include
+#include
#include
-#include
-#include
#include
-#include
+#include
#include
-#include
#include
#include "soc_common.h"
@@ -69,7 +69,8 @@ EXPORT_SYMBOL(soc_pcmcia_debug);
#endif
-#define to_soc_pcmcia_socket(x)container_of(x, struct
soc_pcmcia_socket, socket)
+#define to_soc_pcmcia_socket(x)\
+ container_of(x, struct soc_pcmcia_socket, socket)
static unsigned short
calc_speed(unsigned short *spds, int num, unsigned short dflt)
@@ -86,11 +87,15 @@ calc_speed(unsigned short *spds, int num, unsigned short
dflt)
return speed;
}
-void soc_common_pcmcia_get_timing(struct soc_pcmcia_socket *skt, struct
soc_pcmcia_timing *timing)
+void soc_common_pcmcia_get_timing(struct soc_pcmcia_socket *skt,
+ struct soc_pcmcia_timing *timing)
{
- timing->io = calc_speed(skt->spd_io, MAX_IO_WIN, SOC_PCMCIA_IO_ACCESS);
- timing->mem = calc_speed(skt->spd_mem, MAX_WIN,
SOC_PCMCIA_3V_MEM_ACCESS);
- timing->attr = calc_speed(skt->spd_attr, MAX_WIN,
SOC_PCMCIA_3V_MEM_ACCESS);
+ timing->io =
+ calc_speed(skt->spd_io, MAX_IO_WIN, SOC_PCMCIA_IO_ACCESS);
+ timing->mem =
+ calc_speed(skt->spd_mem, MAX_WIN, SOC_PCMCIA_3V_MEM_ACCESS);
+ timing->attr =
+ calc_speed(skt->spd_attr, MAX_WIN, SOC_PCMCIA_3V_MEM_ACCESS);
}
EXPORT_SYMBOL(soc_common_pcmcia_get_timing);
@@ -132,8 +137,8 @@ static unsigned int soc_common_pcmcia_skt_state(struct
soc_pcmcia_socket *skt)
*
* Convert PCMCIA socket state to our socket configure structure.
*/
-static int
-soc_common_pcmcia_config_skt(struct soc_pcmcia_socket *skt, socket_state_t
*state)
+static int soc_common_pcmcia_config_skt(
+ struct soc_pcmcia_socket *skt, socket_state_t *state)
{
int ret;
@@ -145,7 +150,8 @@ soc_common_pcmcia_config_skt(struct soc_pcmcia_socket *skt,
socket_state_t *stat
*/
if (skt->irq_state != 1 && state->io_irq) {
skt->irq_state = 1;
- set_irq_type(skt->socket.pci_irq,
IRQ_TYPE_EDGE_FALLING);
+ set_irq_type(skt->socket.pci_irq,
+ IRQ_TYPE_EDGE_FALLING);
} else if (skt->irq_state == 1 && state->io_irq == 0) {
skt->irq_state = 0;
set_irq_type(skt->socket.pci_irq, IRQ_TYPE_NONE);
@@ -299,24 +305,24 @@ soc_common_pcmcia_get_status(struct pcmcia_socket *sock,
unsigned int *status)
* of power configuration, reset, &c. We also record the value of
* `state' in order to regurgitate it to the PCMCIA core later.
*/
-static int
-soc_common_pcmcia_set_socket(struct pcmcia_socket *sock, socket_state_t *state)
+static int soc_common_pcmcia_set_socket(
+ struct pcmcia_socket *sock, socket_state_t *state)
{
struct soc_pcmcia_socket *skt = to_soc_pcmcia_socket(sock);
- debug(skt, 2, "mask: %s%s%s%s%s%sflags: %s%s%s%s%s%sVcc %d Vpp %d irq
%d\n",
- (state->csc_mask==0)?" ":"",
- (state->csc_mask&SS_DETECT)?"DETECT ":"",
- (state->csc_mask&SS_READY)?"READY ":"",
- (state->csc_mask&SS_BATDEAD)?"BATDEAD ":"",
- (state->csc_mask&SS_BATWARN)?"BATWARN ":"",
- (state->csc_mask&SS_STSCHG)?"STSCHG ":"",
- (state->flags==0)?" ":"",
- (state->flags&SS_PWR_AUTO)?"PWR_AUTO ":"",
- (state->flags&SS_IOCARD)?"IOCARD ":"",
- (state->flags&SS_RESET)?"RESET ":"",
- (state->flags&SS_SPKR_ENA)?"SPKR_ENA ":"",
- (state->flags&SS_OUTPUT_ENA)?"OUTPUT_ENA ":"",
+ debug(skt, 2, "mask: %s%s%s%s%s%s flags: %s%s%s%s%s%s Vcc %d Vpp %d irq
%d\n",
+ (state->csc_mask == 0) ? " " : "",
+ (state->csc_mask & SS_DETECT) ? "DETECT " : "",
+ (state->csc_mask & SS_READY)? "READY " :"",
+ (state->csc_mask & SS_BATDEAD) ? "BATDEAD " : "",
+ (state->csc_mask & SS_BATWARN) ? "BATWARN " : "",
+ (state->csc_mask & SS_STSCHG) ? "STSCHG " : "",
+ (state->flags == 0) ? " " : "",
