headers
Michael Tokarev | 1 Jul 2006 01:04
Picon

Re: klibc and what's the next step?

Pavel Machek wrote:
[klibc/kinit in kernel]
> I'd like to eventually move swsusp out of kernel, and klibc means I
> may be able to do that without affecting users. Being in kinit is good
> enough, because I can actually share single source between kinit
> version and suspend.sf.net version.

Heh.  Take a look at anyone who's using real initramfs for their boot
process.  Not initrd, not kernel-without-any-preboot-fs, but real
initramfs.  For them, if kinit/klibc will be in kernel, nothing changes,
because their initramfs *replaces* in-kernel code and future supplied-
with-kernel-klibc-based-kinit.  So if you'll move swsusp into kinit,
it WILL break setups for those users!.. ;)

And with time, amount of such users increases.  Because everyone's
switching from initrd to initramfs; or because everyone's starting
using initramfs (not initrd as "obsolete") since their systems now
require some sort of custom stuff while mounting root (like firmware
loading, or device-mapper setup for sata pseudo-raids, or whatever).

Oh well.

/mjt
Permalink | Reply | 16 comments |
headers
Daniel Ritz | 1 Jul 2006 01:09
Picon

Re: [PATCH] cardbus: revert IO window limit

On Saturday 01 July 2006 00.18, Linus Torvalds wrote:
> 
> On Sat, 1 Jul 2006, Daniel Ritz wrote:
> > 
> > nope. but from the docs available i would _guess_ this thing is really
> > similar to the 82443BX/82371AB combination. at least the SMBus base address
> > register is hidden at the very same place (32bit at 0x90 in function 3 of the
> > "south" brigde)...so the attached little patch might be enough to fix things...
> 
> Alessio has PCI ID 8086:7194, which is not the 82443MX_3, so you'd need 
> something like this instead (but yes, it might indeed be the standard 
> PIIX4 quirks).
> 

errm...no. the SMBus device is in device 00:07.3 (power management controller)...
and that has ID 8086:719b (from his lspci -vvx output)...

rgds
-daniel
Permalink | Reply | 5 comments |
headers
Benjamin Herrenschmidt | 1 Jul 2006 01:13

Re: [PATCH] powerpc:Fix rheap alignment problem

On Fri, 2006-06-30 at 21:02 +0800, Li Yang-r58472 wrote:
> Honour alignment parameter in the rheap allocator.
> Remove compile warning.

What is this used for ? This rheap allocator ? I see no user in
arch/powerpc at least and only two users apparently in arch/ppc... are
we sure we need something that complex for these ? Can't we just use a
running bitmap allocator or an idr ?

Cheers,
Ben.

> Signed-off-by: Pantelis Antoniou <pantelis <at> embeddedalley.com>
> Signed-off-by: Li Yang <leoli <at> freescale.com>
> 
> ---
>  arch/powerpc/lib/Makefile |    1 +
>  arch/powerpc/lib/rheap.c  |   24 ++++++++++++++++++++----
>  include/asm-ppc/rheap.h   |    4 ++++
>  3 files changed, 25 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
> index 34f5c2e..136a892 100644
> --- a/arch/powerpc/lib/Makefile
> +++ b/arch/powerpc/lib/Makefile
>  <at>  <at>  -11,6 +11,7  <at>  <at>  obj-y			+= bitops.o
>  obj-$(CONFIG_PPC64)	+= checksum_64.o copypage_64.o copyuser_64.o \
>  			   memcpy_64.o usercopy_64.o mem_64.o string.o \
>  			   strcase.o
> +obj-$(CONFIG_QUICC_ENGINE) += rheap.o
(Continue reading)

Permalink | Reply | 18 comments |
headers
H. Peter Anvin | 1 Jul 2006 01:15
Favicon

Re: klibc and what's the next step?

Michael Tokarev wrote:
> Pavel Machek wrote:
> [klibc/kinit in kernel]
>> I'd like to eventually move swsusp out of kernel, and klibc means I
>> may be able to do that without affecting users. Being in kinit is good
>> enough, because I can actually share single source between kinit
>> version and suspend.sf.net version.
> 
> Heh.  Take a look at anyone who's using real initramfs for their boot
> process.  Not initrd, not kernel-without-any-preboot-fs, but real
> initramfs.  For them, if kinit/klibc will be in kernel, nothing changes,
> because their initramfs *replaces* in-kernel code and future supplied-
> with-kernel-klibc-based-kinit.  So if you'll move swsusp into kinit,
> it WILL break setups for those users!.. ;)
> 

There are two ways to deal with this.

Either the kernel can unconditionally invoke /kinit, which then would 
invoke the users /init if present, or the swsusp can be a separate 
initramfs binary which the user's initramfs gets to invoke (the second 
is arguably neater, but requires minor changes to the users initramfs.)

Either way, it's a trivial problem to solve.

	-hpa
Permalink | Reply | 14 comments |
headers
Linus Torvalds | 1 Jul 2006 01:21

Re: [PATCH] cardbus: revert IO window limit


On Sat, 1 Jul 2006, Daniel Ritz wrote:
> 
> errm...no. the SMBus device is in device 00:07.3 (power management controller)...
> and that has ID 8086:719b (from his lspci -vvx output)...

Ahh, right. 

Alessio, try Daniel's patch. We'd love to hear if it works, and in 
particular what the dmesg output is (if it does work, it should print out 
something like

	PIIX4 ACPI PIO at 2000-203f
	PIIX4 SMB PIO at 2040-204f

and perhaps even a few "PIIX4 devres X" lines..)

Alessio, it might also make sense to try to enable ACPI if you haven't 
done so - not because you need to use it, but because sometimes the ACPI 
table parsing also ends up exposing these kinds of things..

		Linus
Permalink | Reply | 4 comments |
headers
Andrew Morton | 1 Jul 2006 01:26

Re: 2.6.17-mm4

Manuel Lauss <mano <at> roarinelk.homelinux.net> wrote:
>
> Hello,
> 
> With the attached .config, the kernel reliably panics when someone
> issues a 'sync' (or the kernel decides to write back its buffers):
> 
> reiser4 panicked cowardly: reiser4[sync(8465)]: commit_current_atom (fs/reiser4/txnmgr.c:1062)[zam-597]:
> Kernel panic - not syncing: reiser4[sync(8465)]: commit_current_atom (fs/reiser4/txnmgr.c:1062)[zam-597]:
> 
> (this is all that is printed)
> 
> This happens only with Reiser4 and libata ata_piix driver; it does not
> happen with Reiser4 and 'old' IDE piix driver. Other fs are also not
> affected. I have no idea how to track this, I hope someone else does :)
> 
> Hardware is a pentium-m laptop with ICH4 pata.
> 

Interesting, thanks.

My guess would be that there's a difference in the way in which the two
drivers handle write barriers, and the new driver has confused the reiser4
code.

Are you able to identify any earlier -mm kernel which ran OK with reiser4
and ata_piix?
Permalink | Reply | 1 comment |
headers
Pavel Machek | 1 Jul 2006 01:32
Picon

Re: klibc and what's the next step?

On Sat 2006-07-01 03:04:55, Michael Tokarev wrote:
> Pavel Machek wrote:
> [klibc/kinit in kernel]
> > I'd like to eventually move swsusp out of kernel, and klibc means I
> > may be able to do that without affecting users. Being in kinit is good
> > enough, because I can actually share single source between kinit
> > version and suspend.sf.net version.
> 
> Heh.  Take a look at anyone who's using real initramfs for their boot
> process.  Not initrd, not kernel-without-any-preboot-fs, but real
> initramfs.  For them, if kinit/klibc will be in kernel, nothing changes,
> because their initramfs *replaces* in-kernel code and future supplied-
> with-kernel-klibc-based-kinit.  So if you'll move swsusp into kinit,
> it WILL break setups for those users!.. ;)

Distros will probably want to use "real" code from swsusp.sf.net, not
stripped down version, provided for back compatibility with kernel.

								Pavel

--

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Permalink | Reply | 0 comments |
headers
Mingming Cao | 1 Jul 2006 01:44
Picon
Favicon

Re: Proposal and plan for ext2/3 future development work

On Fri, 2006-06-30 at 07:09 -0400, Patrick McFarland wrote:
> On Wednesday 28 June 2006 19:55, you wrote:
> > Given the recent discussion on LKML two weeks ago, it is clear that many
> > people feel they have a stake in the future development plans of the
> > ext2/ext3 filesystem, as it one of the most popular and commonly used
> > filesystems, particular amongst the kernel development community.  For
> > this reason, the stakes are higher than it would be for other
> > filesystems.  
> 
> http://en.wikipedia.org/wiki/Ext4
> 

Thanks, another wiki page for this project is hosted at:
http://fedoraproject.org/wiki/ext3-devel

Current patch set is at
http://ext2.sourceforge.net/48bitext3/patches/latest/

and current e2fsprogs patch set is at 
http://ext2.sourceforge.net/48bitext3/patches/e2fsprogs/48bit-
e2fsprogs-1.39/
Permalink | Reply | 0 comments |
headers
İsmail Dönmez | 1 Jul 2006 01:49
Picon
Favicon

Re: OSS driver removal, 2nd round

Cumartesi 1 Temmuz 2006 00:56 tarihinde, Lee Revell şunları yazmıştı: 
> On Sat, 2006-07-01 at 00:42 +0300, İsmail Dönmez wrote:
> > Cumartesi 1 Temmuz 2006 00:29 tarihinde şunları yazmıştınız:
> > > (I wish the authors of Skype, Flash, TeamSpeak, Enemy Territory, and
> > > other proprietary OSS-only apps would understand this ;-)
> >
> > New skype beta supports Alsa, doesn't work ATM but its a great step in
> > that direction and Flash9 for Linux will use Alsa.
>
> Really?  Got a link?  Last I heard about Flash was that their lawyers
> won't let them link to LGPL libraries which would rule out ALSA support.

Hear from the lead developer for Flash Linux : 
http://blogs.adobe.com/penguin.swf/2006/06/week_in_review_1.html

Regards,
ismail

--

-- 
日本のanimeは揺れる 

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Alsa-devel mailing list
Alsa-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Morton | 1 Jul 2006 01:55

Re: 2.6.17-mm one process gets stuck in infinite loop in the kernel.

Helge Hafting <helgehaf <at> aitel.hist.no> wrote:
>
> On Thu, Jun 29, 2006 at 10:41:17AM -0700, Andrew Morton wrote:
> > On Thu, 29 Jun 2006 13:25:20 +0200
> > Helge Hafting <helge.hafting <at> aitel.hist.no> wrote:
> > 
> > > I have seen this both with mm2, m33 and mm4.
> > > Suddenly, the load meter jumps.
> > > Using ps & top, I see one process using 100% cpu.
> > > This is always a process that was exiting, this tend to happen
> > > when I close applications, or doing debian upgrades which
> > > runs lots of short-lived processes.
> > > 
> > > I believe it is running in the kernel, ps lists it with stat "RN"
> > > and it cannot be killed, not even with kill -9 from root.
> > > 
> > > Something wrong with process termination?
> > > 
> > 
> > Please generate a kernel profile when it happens so we can see
> > where it got stuck.
> > 
> > <boot with profile=1>
> > <wait for it to happen>
> > readprofile -r
> > sleep 10
> > readprofile -n -v -m /boot/System.map | sort -n -k 3 | tail -40
> 
> It was easier to reproduce on my home machine, running mm2.
> I followed the recipe above, except typing manually means
(Continue reading)

Permalink | Reply | 2 comments |

Gmane