LinuxLists.cc - 2.6.16-rc2-mm1

On Fri, Feb 10, 2006 at 02:25:02PM -0800, Andrew Morton wrote:

> > --- linux-2.6.16-rc2-mm1/drivers/net/tulip/media.c 2006-02-09 22:13:36.403653502 -0500
> > +++ linux-2.6.16-rc2-mm1-new/drivers/net/tulip/media.c 2006-02-10 15:51:41.821983228 -0500
> > @@ -399,8 +399,6 @@ void tulip_select_media(struct net_devic
> >
> > tp->csr6 = new_csr6 | (tp->csr6 & 0xfdff) | (tp->full_duplex ? 0x0200 : 0);
> >
> > - mdelay(1);
> > -
> > return;
> > }
>
> It might not be. And the knowledge of which cards this will bust and why
> may be lost in the mists of time.

Tulip fixes for Cobalt Qube/RaQ

change 12755c16a9e4fa2fd5b0ca1963e83d671a6251da
on 2005-06-26 16 by Ralf Baechle <[email protected]>

Dave

2006-02-11 20:32:04

On Sat, Feb 11, 2006 at 01:41:42PM -0800, Andrew Morton wrote:
> Martin Hermanowski <[email protected]> wrote:
> >
> > Hi,
> >
> > 2.6.16-rc2-mm1 is running fine on my IBM notebook, but the hdaps module
> > (acceleration sensor) does not work like I expected:
> >
> > ,----[ modprobe hdaps ]
> > | Feb 11 21:24:26 nimrais kernel: hdaps: inverting axis readings.
> > | Feb 11 21:24:26 nimrais kernel: hdaps: IBM ThinkPad T41p detected.
> > | Feb 11 21:24:26 nimrais kernel: hdaps: driver successfully loaded.
> > `----
> >
> > AFAIK the module should create sysfs files in
> > /sys/devices/platform/hdaps/, but I see only `bus', `power' and
> > `uevent'.
> >
> > When unloading the hdaps module, I get a BUG:
> >
> > ,----[ rmmod hdaps ]
> > | Feb 11 21:24:49 nimrais kernel: <c011d8b6> release_resource+0x76/0x80 <c0265bf4> platform_device_del+0x44/0x60
> > | Feb 11 21:24:49 nimrais kernel: <c0265c18> platform_device_unregister+0x8/0x10 <f9b9c8ed> hdaps_exit+0xd/0x25 [hdaps]
> > | Feb 11 21:24:49 nimrais kernel: <f9b9c8e0> hdaps_exit+0x0/0x25 [hdaps] <c0132e05> sys_delete_module+0x145/0x1c0
> > | Feb 11 21:24:49 nimrais kernel: <c0149901> remove_vma+0x41/0x50 <c014ab57> do_munmap+0x1a7/0x200
> > | Feb 11 21:24:49 nimrais kernel: <c0102d91> syscall_call+0x7/0xb
> > | Feb 11 21:24:49 nimrais kernel: hdaps: driver unloaded.
> > `----
> >
> > Do you need more information?
> >
>
> Thanks, I'll drop hdaps-convert-to-the-new-platform-device-interface.patch,
> which very likely to have caused this.
>
> You could try reverting that patch (wget
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc2/2.6.16-rc2-mm1/broken-out/hdaps-convert-to-the-new-platform-device-interface.patch
> ; patch -p1 -R < hdaps-convert-to-the-new-platform-device-interface.patch) or please test next -mm, let us know?

This fails:
,----[ patch -p1 -R < ../hdaps-convert-to-the-new-platform-device-interface.patch ]
| patching file drivers/hwmon/hdaps.c
| Hunk #1 succeeded at 37 (offset 1 line).
| Hunk #2 succeeded at 63 (offset 1 line).
| Hunk #3 succeeded at 285 with fuzz 2 (offset 1 line).
| Hunk #4 FAILED at 321.
| Hunk #5 FAILED at 340.
| Hunk #6 succeeded at 474 (offset 1 line).
| Hunk #7 succeeded at 512 (offset 1 line).
| Hunk #8 succeeded at 533 (offset 1 line).
| 2 out of 8 hunks FAILED -- saving rejects to file
| drivers/hwmon/hdaps.c.rej
`----

At hunk 4/5, the patch expects `down_trylock' and `up', while
`mutex_trylock' and `mutex_unlock' are used in the actual file, I think.

I will try next -mm anyway, because although the fsck-errors caused by
ext3_getblocks are not harmful, they make me nervous ;-)

--
Martin Hermanowski
http://mh57.de/martin

Attachments:

(No filename) (2.63 kB)
signature.asc (189.00 B)
Digital signature Download all attachments

2006-02-11 23:35:16

by Andrew Morton

Alexandre Buisse <[email protected]> wrote:
>
> On Tue, Feb 14, 2006 at 00:47:15 +0100, Andrew Morton wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc2/2.6.16-rc2-mm1/
> >
>
> Hi,
>
> I have been using 2.6.16-rc2-mm1 for a couple of days on my laptop and
> tonight it was particularly slow. After shutting down firefox, X and
> pretty much every user application, free was still saying:
>
> ubik:~> free -l
> total used free shared buffers
> cached
> Mem: 508592 502948 5644 0
> 7056 25084
> Low: 508592 502948 5644
> High: 0 0 0
> -/+ buffers/cache: 470808 37784
> Swap: 506512 86260 420252
>
>
> ps is almost empty, but /proc/slabinfo (see attached file for the
> complete output) has some weird lines:
>
> sock_inode_cache 644184 644202 448 9 1 : tunables 54 27 0 : slabdata 71578 71578 0
>
> inode_cache 1216 1232 360 11 1 : tunables 54 27 0 : slabdata 112 112 0 : shrinker stat 2103424 2101400
> dentry_cache 647419 649830 128 30 1 : tunables 120 60 0 : slabdata 21661 21661 0 : shrinker stat 5027712 2374200
>
>

Well it _could_ be caused by an errant application. But if it just started
happening, it's more likely the kernel. There are related changes in
Dave's tree.

You could try `echo 3 > /proc/sys/vm/drop_caches' to see if they're
reclaimable.