Linux v2.6.17

Linus Torvalds

unread,

Jun 17, 2006, 10:00:25 PM6/17/06

to Linux Kernel Mailing List

Not a lot of changes since the last -rc, the bulk is actually some
last-minute MIPS updates and s390 futex changes, the rest tend to be
various very small fixes that trickled in over the last week.

Have fun with it,

Linus

---

Aki M Nyrhinen:
[TCP]: continued: reno sacked_out count fix

Andrea Bittau:
[DCCP] Ackvec: fix soft lockup in ackvec handling code

Andrew Morton:
powernow-k8 crash workaround
PCI: fix pciehp compile issue when CONFIG_ACPI is not enabled

Andy Currid:
Fix HPET operation on 32-bit NVIDIA platforms
Fix HPET operation on 64-bit NVIDIA platforms

Arnd Bergmann:
powerpc: Fix cell blade detection
powerpc: Fix 64k pages on non-partitioned machines
powerpc: enable CPU_FTR_CI_LARGE_PAGE for cell

Auke Kok:
e1000: fix ethtool test irq alloc as "probe"
e1000: remove risky prefetch on next_skb->data

Benjamin Herrenschmidt:
powerpc: Fix call to ibm,client-architecture-support

Christoph Lameter:
typo in vmscan.c

Dave Jones:
PCI: Improve PCI config space writeback

David Howells:
Further alterations for memory barrier document

David S. Miller:
[SPARC64]: Dump local cpu registers in sun4v_log_error()
[TG3]: Handle Sun onboard tg3 chips more correctly.
[SPARC64]: Avoid JBUS errors on some Niagara systems.
[SPARC64]: Set appropriate max_cache_size.
[SPARC64]: Do not double-export sys_close() when CONFIG_SOLARIS_EMUL_MODULE

Jean Delvare:
PCI: Error handling on PCI device resume

Jens Axboe:
elevator switching race
debugfs inode leak
cfq-iosched: fix crash in do_div()
fix cdrom open
Fix missing ret assignment in __bio_map_user() error path

Kirill Korotaev:
Return error in case flock_lock_file failure

Krzysztof Helt:
[SPARC]: Migration cost tune up in sparc smp.

Lennert Buytenhek:
ep93xx build fix

Linus Torvalds:
[sky2] Fix sky2 network driver suspend/resume
Linux v2.6.17

Malcom Parsons:
fbcon: fix limited scroll in SCROLL_PAN_REDRAW mode

Mark Lord:
sata_mv: grab host lock inside eng_timeout

Markus Lidel:
I2O: Bugfixes to get I2O working again

Martin Schwidefsky:
s390: fix in-user atomic futex operation.

Matt Reimer:
[ARM] 3546/1: PATCH: subtle lost interrupts bug on i.MX

Michael Buesch:
bcm43xx: add DMA rx poll workaround to DMA4

Milton Miller:
powerpc: console_initcall ordering issues

Oleg Nesterov:
check_process_timers: fix possible lockup
run_posix_cpu_timers: remove a bogus BUG_ON()
arm_timer: remove a racy and obsolete PF_EXITING check

Paul Mackerras:
powerpc: Fix machine check problem on 32-bit kernels
Fix for the PPTP hangs that have been reported

Ralf Baechle:
Fix mempolicy.h build error

Randy Dunlap:
alpha: generic hweight build fix

Richard Purdie:
[ARM] 3547/1: PXA-OHCI: Allow platforms to specify a power budget

Robin H. Johnson:
tmpfs: time granularity fix for [acm]time going backwards

Russell King:
[ARM] Fix Neponset IRQ handling
[ARM] Fix Integrator and Versatile interrupt initialisation

Sergey Vlasov:
tmpfs: Decrement i_nlink correctly in shmem_rmdir()

Stephen Hemminger:
sky2: set_power_state should be void
sky2: don't hard code number of ports
sky2: fix hotplug detect during poll
sky2: save/restore base hardware irq during suspend/resume
sky2: stop/start hardware idle timer on suspend/resume
sky2: netconsole suspend/resume interaction

Tom "spot" Callaway:
[FUSION]: Fix mptspi.c build with CONFIG_PM not set.

Weidong:
[IPV4]: Increment ipInHdrErrors when TTL expires.

Yu, Luming:
PCI: reverse pci config space restore order

Linus Torvalds

unread,

Jun 17, 2006, 10:06:48 PM6/17/06

to Linux Kernel Mailing List

On Sat, 17 Jun 2006, Linus Torvalds wrote:
>
> Not a lot of changes since the last -rc, the bulk is actually some
> last-minute MIPS updates and s390 futex changes, the rest tend to be
> various very small fixes that trickled in over the last week.

Btw, one thing that I was planning to ask people - does anybody find the
full-format ChangeLog's that I produce at all useful?

You can get the exact same information directly from git, and the full
changelog (as opposed to the shortlog) tends to be pretty rough to read,
so I suspect that most people who do want to delve into the details are
actually much more likely to look it up using git instead (at which point
you can obviously get much better information - graphical history, diffs,
etc)

I'm not going to stop doing the incremental shortlogs, since those are
easy to read and I usually post them with the release announcement unless
they end up being too large (usually -rc1 has a _lot_ of changes as a
result of the merge window), but I'm just wondering if anybody finds the
full logs useful at all?

They're easy for me to generate, but if nobody uses them, I don't see much
of a point..

Linus

Brice Goglin

unread,

Jun 17, 2006, 11:32:52 PM6/17/06

to Linus Torvalds, Linux Kernel Mailing List

Linus Torvalds wrote:
> Btw, one thing that I was planning to ask people - does anybody find the
> full-format ChangeLog's that I produce at all useful?
>
> You can get the exact same information directly from git, and the full
> changelog (as opposed to the shortlog) tends to be pretty rough to read,
> so I suspect that most people who do want to delve into the details are
> actually much more likely to look it up using git instead (at which point
> you can obviously get much better information - graphical history, diffs,
> etc)
>
> I'm not going to stop doing the incremental shortlogs, since those are
> easy to read and I usually post them with the release announcement unless
> they end up being too large (usually -rc1 has a _lot_ of changes as a
> result of the merge window), but I'm just wondering if anybody finds the
> full logs useful at all?
>

I actually like having the full changelog of every kernels and grep in
all them at once when I want to quickly find out where something has
been added/modified without knowing the exact name of the function or
file that I am looking for.
I guess I could use git to generate the full changelog once a new
release and keep it for later...

Regards,
Brice

Linus Torvalds

unread,

Jun 17, 2006, 11:47:54 PM6/17/06

to Brice Goglin, Linux Kernel Mailing List

On Sat, 17 Jun 2006, Brice Goglin wrote:
>
> I guess I could use git to generate the full changelog once a new
> release and keep it for later...

Well, if you are already a git user (or willing to become one), there's no
point in even keeping it for later.

[torvalds@g5 linux]$ time git log v2.6.16..v2.6.17 > /dev/null

real 0m0.484s
user 0m0.448s
sys 0m0.036s

ie the logfile generation really is almost free. And yes, that's the
_full_ big log (all 92 _thousand_ lines of it, from the 6113 commits in
the 2.6.16->17 case) being generated in under half a second.

Doing the shortlog (which sort and group by author in perl) is only
fractionally more expensive.

The added benefit of doing it with git and generating it each time is that
then you can also ask for logs just for a specific subsystem.

I don't know of anything but git that can efficiently do things like

git log v2.6.16..v2.6.17 drivers/usb/

and it will show the log for all the commits that changed things under
drivers/usb. And yeah, that can be slightly more expensive, but usually
it's not noticeably so (history pruning at least in that case makes up for
the extra work it has to do to figure out which commits changed that
subsystem).

The point being that the dynamically generated data is often a lot more
useful and readable.

Linus

Michael Buesch

unread,

Jun 18, 2006, 6:57:09 AM6/18/06

to Greg KH, Linus Torvalds, Linux Kernel Mailing List, Chris Wright, bcm43...@lists.berlios.de

On Sunday 18 June 2006 03:59, Linus Torvalds wrote:
> Not a lot of changes since the last -rc, the bulk is actually some
> last-minute MIPS updates and s390 futex changes, the rest tend to be
> various very small fixes that trickled in over the last week.

D'oh, please queue the following patch for -stable, Greg. ;)

--

Place the Init-vs-IRQ workaround before any card register
access, because we might not have the wireless core mapped
at all times in init. So this will result in a Machine Check
caused by a bus error.

Signed-off-by: Michael Buesch <m...@bu3sch.de>

Index: wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- wireless-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-17 15:06:38.000000000 +0200
+++ wireless-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-17 15:17:49.000000000 +0200
@@ -1885,6 +1885,15 @@

spin_lock(&bcm->irq_lock);

+ /* Only accept IRQs, if we are initialized properly.
+ * This avoids an RX race while initializing.
+ * We should probably not enable IRQs before we are initialized
+ * completely, but some careful work is needed to fix this. I think it
+ * is best to stay with this cheap workaround for now... .
+ */
+ if (unlikely(bcm43xx_status(bcm) != BCM43xx_STAT_INITIALIZED))
+ goto out;
+
reason = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
if (reason == 0xffffffff) {
/* irq not for us (shared irq) */
@@ -1906,19 +1915,11 @@

bcm43xx_interrupt_ack(bcm, reason);

- /* Only accept IRQs, if we are initialized properly.
- * This avoids an RX race while initializing.
- * We should probably not enable IRQs before we are initialized
- * completely, but some careful work is needed to fix this. I think it
- * is best to stay with this cheap workaround for now... .
- */
- if (likely(bcm43xx_status(bcm) == BCM43xx_STAT_INITIALIZED)) {
- /* disable all IRQs. They are enabled again in the bottom half. */
- bcm->irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
- /* save the reason code and call our bottom half. */
- bcm->irq_reason = reason;
- tasklet_schedule(&bcm->isr_tasklet);
- }
+ /* disable all IRQs. They are enabled again in the bottom half. */
+ bcm->irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
+ /* save the reason code and call our bottom half. */
+ bcm->irq_reason = reason;
+ tasklet_schedule(&bcm->isr_tasklet);

out:
mmiowb();

--
Greetings Michael.

Adrian Bunk

unread,

Jun 18, 2006, 9:50:53 AM6/18/06

to Linus Torvalds, Linux Kernel Mailing List

On Sat, Jun 17, 2006 at 07:06:17PM -0700, Linus Torvalds wrote:
>
>
> On Sat, 17 Jun 2006, Linus Torvalds wrote:
> >
> > Not a lot of changes since the last -rc, the bulk is actually some
> > last-minute MIPS updates and s390 futex changes, the rest tend to be
> > various very small fixes that trickled in over the last week.
>
> Btw, one thing that I was planning to ask people - does anybody find the
> full-format ChangeLog's that I produce at all useful?
>
> You can get the exact same information directly from git, and the full
> changelog (as opposed to the shortlog) tends to be pretty rough to read,
> so I suspect that most people who do want to delve into the details are
> actually much more likely to look it up using git instead (at which point
> you can obviously get much better information - graphical history, diffs,
> etc)
>
> I'm not going to stop doing the incremental shortlogs, since those are
> easy to read and I usually post them with the release announcement unless
> they end up being too large (usually -rc1 has a _lot_ of changes as a
> result of the merge window), but I'm just wondering if anybody finds the
> full logs useful at all?
>
> They're easy for me to generate, but if nobody uses them, I don't see much
> of a point..

I like to read the shortlog for getting an overview of the changes
containing a bit more detail than your verbal summary at the top.

I need git for getting more detail and I could generate them myself. But
if it wasn't there, I might not generate it myself, and might therefore
not ask "Why did this patch get into -rc6?" or become curious enough for
using git to check the contents of a commit.

> Linus

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

Linus Torvalds

unread,

Jun 18, 2006, 12:45:39 PM6/18/06

to Adrian Bunk, Linux Kernel Mailing List

On Sun, 18 Jun 2006, Adrian Bunk wrote:
>
> I like to read the shortlog for getting an overview of the changes
> containing a bit more detail than your verbal summary at the top.

Right. I always generate the shortlog for my own usage anyway. It's really
the full long log that I'm asking whether people actually care about.

Linus

Andre Tomt

unread,

Jun 18, 2006, 12:47:34 PM6/18/06

to Michael Buesch, Greg KH, Linus Torvalds, Linux Kernel Mailing List, Chris Wright, bcm43...@lists.berlios.de

Michael Buesch wrote:
> On Sunday 18 June 2006 03:59, Linus Torvalds wrote:
>> Not a lot of changes since the last -rc, the bulk is actually some
>> last-minute MIPS updates and s390 futex changes, the rest tend to be
>> various very small fixes that trickled in over the last week.
>
> D'oh, please queue the following patch for -stable, Greg. ;)

I'm unable to apply it on top a clean 2.6.17 using patch -p1 < mailfile.

Hunk #2 FAILED at 1900.
1 out of 2 hunks FAILED -- saving rejects to file
drivers/net/wireless/bcm43xx/bcm43xx_main.c.rej

Michael Buesch

unread,

Jun 18, 2006, 1:06:54 PM6/18/06

to Greg KH, Andre Tomt, Linus Torvalds, Linux Kernel Mailing List, Chris Wright, bcm43...@lists.berlios.de

On Sunday 18 June 2006 18:47, Andre Tomt wrote:
> Michael Buesch wrote:
> > On Sunday 18 June 2006 03:59, Linus Torvalds wrote:
> >> Not a lot of changes since the last -rc, the bulk is actually some
> >> last-minute MIPS updates and s390 futex changes, the rest tend to be
> >> various very small fixes that trickled in over the last week.
> >
> > D'oh, please queue the following patch for -stable, Greg. ;)
>
> I'm unable to apply it on top a clean 2.6.17 using patch -p1 < mailfile.
>
> Hunk #2 FAILED at 1900.
> 1 out of 2 hunks FAILED -- saving rejects to file
> drivers/net/wireless/bcm43xx/bcm43xx_main.c.rej

Ok, I'm sorry. The patch was from wireless-dev.
Here's the adjusted patch:

--

Place the Init-vs-IRQ workaround before any card register
access, because we might not have the wireless core mapped
at all times in init. So this will result in a Machine Check
caused by a bus error.

Signed-off-by: Michael Buesch <m...@bu3sch.de>

Index: tmp/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===================================================================
--- tmp.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-18 18:51:48.000000000 +0200
+++ tmp/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-06-18 19:02:19.000000000 +0200
@@ -1870,6 +1870,15 @@

spin_lock(&bcm->_lock);

+ /* Only accept IRQs, if we are initialized properly.
+ * This avoids an RX race while initializing.
+ * We should probably not enable IRQs before we are initialized
+ * completely, but some careful work is needed to fix this. I think it
+ * is best to stay with this cheap workaround for now... .
+ */

+ if (unlikely(!bcm->initialized))

+ goto out;
+
reason = bcm43xx_read32(bcm, BCM43xx_MMIO_GEN_IRQ_REASON);
if (reason == 0xffffffff) {
/* irq not for us (shared irq) */

@@ -1891,20 +1900,11 @@

bcm43xx_interrupt_ack(bcm, reason);

- /* Only accept IRQs, if we are initialized properly.
- * This avoids an RX race while initializing.
- * We should probably not enable IRQs before we are initialized
- * completely, but some careful work is needed to fix this. I think it
- * is best to stay with this cheap workaround for now... .
- */

- if (likely(bcm->initialized)) {

- /* disable all IRQs. They are enabled again in the bottom half. */
- bcm->irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
- /* save the reason code and call our bottom half. */
- bcm->irq_reason = reason;
- tasklet_schedule(&bcm->isr_tasklet);
- }
-
+ /* disable all IRQs. They are enabled again in the bottom half. */
+ bcm->irq_savedstate = bcm43xx_interrupt_disable(bcm, BCM43xx_IRQ_ALL);
+ /* save the reason code and call our bottom half. */
+ bcm->irq_reason = reason;
+ tasklet_schedule(&bcm->isr_tasklet);
out:
mmiowb();

spin_unlock(&bcm->_lock);

--
Greetings Michael.

Petr Baudis

unread,

Jun 18, 2006, 10:32:25 PM6/18/06

to Linus Torvalds, Brice Goglin, Linux Kernel Mailing List

Dear diary, on Sun, Jun 18, 2006 at 05:47:27AM CEST, I got a letter
where Linus Torvalds <torv...@osdl.org> said that...

> On Sat, 17 Jun 2006, Brice Goglin wrote:
> >
> > I guess I could use git to generate the full changelog once a new
> > release and keep it for later...
>
> Well, if you are already a git user (or willing to become one), there's no
> point in even keeping it for later.
>
> [torvalds@g5 linux]$ time git log v2.6.16..v2.6.17 > /dev/null
>
> real 0m0.484s
> user 0m0.448s
> sys 0m0.036s
>
> ie the logfile generation really is almost free. And yes, that's the
> _full_ big log (all 92 _thousand_ lines of it, from the 6113 commits in
> the 2.6.16->17 case) being generated in under half a second.

I assume that this is with hot cache, which is something you shouldn't
assume for a use like this - you likely aren't in the middle of doing
stuff with the repository but just want to peek at the changes list.

Anyway, the nice thing about the Changelog files MIGHT be Google - it's
nice when googling around about your kernel problem ends up yielding
a changelog entry indicating that it's already fixed in a newer kernel
version. That is, if only Google crawled the changelogs. Does it stay
away of them because they have no extension?

--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

li...@horizon.com

unread,

Jun 19, 2006, 3:42:24 AM6/19/06

to linux-...@vger.kernel.org, pa...@suse.cz

>> [torvalds@g5 linux]$ time git log v2.6.16..v2.6.17 > /dev/null
>>
>> real 0m0.484s
>> user 0m0.448s
>> sys 0m0.036s
>>
>> ie the logfile generation really is almost free. And yes, that's the
>> _full_ big log (all 92 _thousand_ lines of it, from the 6113 commits in
>> the 2.6.16->17 case) being generated in under half a second.

> I assume that this is with hot cache, which is something you shouldn't
> assume for a use like this - you likely aren't in the middle of doing
> stuff with the repository but just want to peek at the changes list.

Okay, a laptop with a cold cache:

$ time git log v2.6.16..v2.6.17 > /dev/null

real 0m2.815s
user 0m1.264s
sys 0m0.044s

And, just for fun, having warmed the cache with that:

$ time git log v2.6.12..v2.6.17 > /dev/null

real 0m2.343s
user 0m1.656s
sys 0m0.068s

All 368519 lines (14 MB) of it. I have to hand it to Linus,
when you say "git", it gits.

(On a not very related point having to do with git and the kernel,
I usually edit the root Makefile to set INSTALL_PATH to where I want
"make bzlilo" to put it, but this results in my kernels being named
v.2.6.17-dirty. I can set INSTALL_PATH by hand on the command line,
except when I forget and waste a reboot. I can't install a symlink,
because the install provess renames the symlink. Is there an easy way
to semi-permanently change INSTALL_PATH without triggering the -dirty
detection? Create a GNUmakefile that includes the Makefile?)

Mark Lord

unread,

Jun 19, 2006, 10:24:22 AM6/19/06

to Linus Torvalds, Linux Kernel Mailing List

Linus Torvalds wrote:
>
> Btw, one thing that I was planning to ask people - does anybody find the
> full-format ChangeLog's that I produce at all useful?

Very useful, thanks. Without it, we would be shutting out the 99.99%
of the Linux universe who never use Git.

Git is really only used by a handful of core developers -- that's who it
was built for and by. Sure, there's dozens or even a couple hundred names
in that handful now, but a heck of a lot more people never use git,
and never should have to use git.

Cheers

Adrian Bunk

unread,

Jun 19, 2006, 5:25:49 PM6/19/06

to Linus Torvalds, Linux Kernel Mailing List

On Sun, Jun 18, 2006 at 09:44:43AM -0700, Linus Torvalds wrote:
>
>
> On Sun, 18 Jun 2006, Adrian Bunk wrote:
> >
> > I like to read the shortlog for getting an overview of the changes
> > containing a bit more detail than your verbal summary at the top.
>
> Right. I always generate the shortlog for my own usage anyway. It's really
> the full long log that I'm asking whether people actually care about.

Sorry, it seems there were tomatoes on my eyes...

> Linus

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-

Julien Cristau

unread,

Jul 16, 2006, 3:35:05 PM7/16/06

to Linus Torvalds, Linux Kernel Mailing List, linu...@atrey.karlin.mff.cuni.cz

Hi,

I have a cardbus wireless adapter which worked until 2.6.16, but doesn't
on 2.6.17. I use standard Debian kernels, .config and dmesg outputs
available at:
http://liafa.jussieu.fr/~jcristau/tmp/dmesg-2.6.16
http://liafa.jussieu.fr/~jcristau/tmp/dmesg-2.6.17
http://liafa.jussieu.fr/~jcristau/tmp/config-2.6.16-2-686
http://liafa.jussieu.fr/~jcristau/tmp/config-2.6.17-1-686

Kernel 2.6.17 suggests to use pci=assign-busses, but that doesn't seem
to change anything.

Output of "lspci -vvvxxx" under 2.6.16 is attached.

Cheers,
Julien Cristau

lspci

signature.asc

Grant Grundler

unread,

Jul 17, 2006, 10:13:38 AM7/17/06

to Julien Cristau, Linux Kernel Mailing List, linu...@atrey.karlin.mff.cuni.cz

On Sun, Jul 16, 2006 at 09:34:53PM +0200, Julien Cristau wrote:
> Hi,
>
> I have a cardbus wireless adapter which worked until 2.6.16, but doesn't
> on 2.6.17. I use standard Debian kernels, .config and dmesg outputs
> available at:
> http://liafa.jussieu.fr/~jcristau/tmp/dmesg-2.6.16
> http://liafa.jussieu.fr/~jcristau/tmp/dmesg-2.6.17
> http://liafa.jussieu.fr/~jcristau/tmp/config-2.6.16-2-686
> http://liafa.jussieu.fr/~jcristau/tmp/config-2.6.17-1-686

Julien,
thanks for posting this.

I diff'ed the dmesg output and I think this is the chunk
might be more explicit symptom of your problem:
-Loaded prism54 driver, version 1.2

This output comes from drivers/net/wireless/prism54/islpci_hotplug.c:
printk(KERN_INFO "Loaded %s driver, version %s\n",

You can verify if the driver isn't getting loaded until later (udev?)
or not all by doing "modprobe prism54" and see of that starts
working. If not, then my next guess would be something changed in the
prism54 driver so it doesn't claim your device.

The other thing I noticed is IRQ11 is assigned to a different PCI device:
2.6.16 :
-PCI: Enabling device 0000:03:00.0 (0000 -> 0002)
-ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [PILC] -> GSI 11 (level, low) -> IR
Q 11

vs 2.6.17:
+ACPI: PCI Interrupt Link [PILA] enabled at IRQ 11
+ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [PILA] -> GSI 11 (level, low) -> IR
Q 11

This seems relevant since IRQ11 seems to be have been assigned by
the BIOS to _7_ devices according to the 2.6.16 lspci output.
This seems a bit unusual to me but maybe it's ok.

hth,
grant

Julien Cristau

unread,

Jul 17, 2006, 10:29:16 AM7/17/06

to Grant Grundler, Linux Kernel Mailing List, linu...@atrey.karlin.mff.cuni.cz

On Mon, Jul 17, 2006 at 08:13:15 -0600, Grant Grundler wrote:

> I diff'ed the dmesg output and I think this is the chunk
> might be more explicit symptom of your problem:
> -Loaded prism54 driver, version 1.2
>
> This output comes from drivers/net/wireless/prism54/islpci_hotplug.c:
> printk(KERN_INFO "Loaded %s driver, version %s\n",
>
> You can verify if the driver isn't getting loaded until later (udev?)
> or not all by doing "modprobe prism54" and see of that starts
> working. If not, then my next guess would be something changed in the
> prism54 driver so it doesn't claim your device.
>

Hi Grant,

Loading the driver with modprobe doesn't change anything (it just
outputs the 'Loaded prism54 driver' line), the device still doesn't
appear in lspci or ifconfig -a.

Cheers,
Julien

signature.asc

Grant Grundler

unread,

Jul 17, 2006, 11:31:57 AM7/17/06

to Julien Cristau, Linux Kernel Mailing List, linu...@atrey.karlin.mff.cuni.cz

On Mon, Jul 17, 2006 at 04:29:17PM +0200, Julien Cristau wrote:
> Loading the driver with modprobe doesn't change anything (it just
> outputs the 'Loaded prism54 driver' line), the device still doesn't
> appear in lspci or ifconfig -a.

Uhm, that's a different symptom than "doesn't work" :)
thanks for clarifying.

Sounds more like a problem with the Cardbus controller not providing
access to PCI config space, not telling PCI generic code there is a
PCI bus below it, or something like that.

Can you post "lspci -vvv -s 02:09" output for 2.6.17 as well?
I'd like to compare the CardBus bridge config info for both (2:09.0
and 02:09.1) controllers on both kernel releases.

thanks,

Julien Cristau

unread,

Jul 17, 2006, 12:13:33 PM7/17/06

to Grant Grundler, Linux Kernel Mailing List, linu...@atrey.karlin.mff.cuni.cz

On Mon, Jul 17, 2006 at 09:31:28 -0600, Grant Grundler wrote:

> On Mon, Jul 17, 2006 at 04:29:17PM +0200, Julien Cristau wrote:
> > Loading the driver with modprobe doesn't change anything (it just
> > outputs the 'Loaded prism54 driver' line), the device still doesn't
> > appear in lspci or ifconfig -a.
>
> Uhm, that's a different symptom than "doesn't work" :)
> thanks for clarifying.
>

Sorry for being unclear in my first mail :/

> Sounds more like a problem with the Cardbus controller not providing
> access to PCI config space, not telling PCI generic code there is a
> PCI bus below it, or something like that.
>
> Can you post "lspci -vvv -s 02:09" output for 2.6.17 as well?
> I'd like to compare the CardBus bridge config info for both (2:09.0
> and 02:09.1) controllers on both kernel releases.
>

Here it is:

02:09.0 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01)
Subsystem: Acer Incorporated [ALI] Unknown device 1027
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 80101000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
Memory window 0: 20000000-21fff000 (prefetchable)
Memory window 1: 26000000-27fff000
I/O window 0: 00007400-000074ff
I/O window 1: 00007800-000078ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+
16-bit legacy interface ports at 0001

02:09.1 CardBus bridge: Texas Instruments PCI1520 PC card Cardbus Controller (rev 01)
Subsystem: Acer Incorporated [ALI] Unknown device 1027
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168, Cache Line Size: 32 bytes
Interrupt: pin B routed to IRQ 11
Region 0: Memory at 80102000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
Memory window 0: 22000000-23fff000 (prefetchable)
Memory window 1: 28000000-29fff000
I/O window 0: 00007c00-00007cff
I/O window 1: 00001000-000010ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001

Thanks for your help!
Julien

signature.asc