headers
Zwane Mwaikambo | 1 Dec 2003 01:10
Picon

Re: Oops + crash in 2.6.0-test11

On Mon, 1 Dec 2003, [iso-8859-1] szonyi calin wrote:

> Hi
> I was watching tv with tvtime and reading lkml on yahoo mail
> (with opera
> if matters). I decided to start xawtv instead of tvtime because
> tvtime
> looked like it was skiping frames.
> So i pressed the q key in tvtime and with the tvtime window
> dissapeared
> also the xterm window from which it was started. I tryed to
> start xterm
> but the xterm window mapped quickly and then dissapeared. I
> switched to
> my syslog VT and noticed an oops. I couldn't start a new shell
> nor from
> console nor from X (starting a new shell gave me a segfault or
> an oops)
> I couldn't shutdown cleanly (i had to use sysrq)
>
> Attached are the program versions, config, dmesg (from syslog)
> and oopses.

How reproduceable is this? Can you try  with the following kernel config
options enabled? I'm suspecting the bttv driver.

CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SPINLOCK=y
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 1 Dec 2003 01:09

Re: FYI: My current suspend bigdiff


> As you suspect, you want only one of the fixes.
> 
> I would probably prefer Pavel's patch over mine, as he knows the suspend 
> subsystem better than me :)

Actually, you want more than that...

You want something similar to what I did for IDE, that is pipe the
suspend/resume requests down the request queue & block the queue,
though with additional crap to deal with the libata probe thread
and the scsi error mgmnt.

I didn't yet have time for it, but basically, what is needed is
to make a scsi version of the suspend/resume code that is in the
IDE code, and then hook that on sd, sg, etc...

Then, libata would have to get in the loop as HW driver, and also
by properly translating the flush cache / standby requests

Ben.
Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 1 Dec 2003 01:11

Re: PowerMac floppy (SWIM-3) doesn't compile

On Sun, 2003-11-30 at 22:25, Mikael Pettersson wrote:
> On Sun, 30 Nov 2003 10:19:07 +0100 (MET), Sebastiaan <S.Breedveld <at> ewi.tudelft.nl> wrote:
> >I am trying to build the 2.6.0-test11 kernel for my PowerMac 7300/166, but
> >the floppy controller doesn't want to compile. I have:
> 
> Known problem. Has been reported several times, but the PPC
> maintainers haven't bothered merging the fix yet.

The maintainer did bother, but along with a bunch of other PPC
driver updates, the fix is on hold until after 2.6.0. Code
freeze...

Also, the swim3 drivers, even with that fix, isn't in a very
good shape. It needs to be cleaned up and ported to the new
driver model.

> I'm using the patch below since the 2.5.7x kernels.
> (Paul Mackerras' 2.4 swim3 rework forward-ported to 2.5 by me.)
> There's also an "official" powermac tree somewhere which
> includes some swim3 patch, but I don't know if it's the same
> as this one.

Please test and let me know. It's at
bk://ppc.bkbits.net/linuxppc-2.5-benh or rsync from
source.mvista.com::linuxppc-2.5-benh.

> As for the boot problem you reported, please try a newer gcc
> like 3.2.3 or 3.3.2. I had lots of wierd problems with 2.95.3
> and the 2.4 kernels on ppc before I switched to gcc-3.x.x.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rudo Thomas | 1 Dec 2003 01:16
Picon

Re: Bug with extraversion in kernel-2.4.23

> The extraversion variable of the Makefile is very badly interpreted.
> When the kernel is installed, I have 2 directory of modules :
> /lib/modules/2.4.23
> /lib/modules/2.4.23-fnux (my extraversion is -fnux)

No way. The directory without -fnux is probably just a leftover from previous
make modules_install. When you run 2.4.23-fnux, you won't need it.

Rudo.
Permalink | Reply | 1 comment |
headers
Mike Gorse | 1 Dec 2003 01:18

Oops w/sysfs when closing a disconnected usb serial device

With 2.6.0-test11, I get a panic if I disconnect a USB serial device with
a fd open on it and then close the fd.  When the device is disconnected,
usb_disconnect calls usb_disable_device, which calls device_del, which
calls kobject_del, which removes the device's sysfs directory.  If a user
space program has the tts device open, then kobject_cleanup and
destroy_serial do not get called until the device is closed, but by then
the kobject_del call to the interface has caused the tty device's sysfs
directory to be nuked from under it.  Eventually sysfs_remove_dir is
called and eventually calls simple_rmdir with a dentry with a NULL
d_inode, causing an oops.  I can make the Oops go away with the following
patch:

--- fs/sysfs/dir.c.orig	2003-11-30 18:59:34.395284712 -0500
+++ fs/sysfs/dir.c	2003-11-30 18:59:50.944768808 -0500
 <at>  <at>  -83,7 +83,7  <at>  <at> 
 	struct dentry * parent = dget(d->d_parent);
 	down(&parent->d_inode->i_sem);
 	d_delete(d);
-	simple_rmdir(parent->d_inode,d);
+	if (d->d_inode) simple_rmdir(parent->d_inode,d);

 	pr_debug(" o %s removing done (%d)\n",d->d_name.name,
 		 atomic_read(&d->d_count));

-- Michael Gorse / AIM:linvortex / http://mgorse.home.dhs.org --
Permalink | Reply | 10 comments |
headers
john smith | 1 Dec 2003 01:27
Picon

Re: Kernel modul licensing issues

Hi Manfred

Thanks for your reply.

You wrote:
> Wrong mailing list.
> You must find a lawyer, and he'll answer your questions.

Of course, the company I'm working for will contact their
lawyers before releasing anything for linux. The reason
because I'm asking here is to get an idea of your attitude
regarding binary kernel modules in this specific scenario
and your interpretation of the GPL in my case.
I'd be glad if we can support linux but if it's not possible
due to unclear legal interpretations of the GPL we certainly
won't.

> RCU is a patented algorithm - mention that to your lawyer.
> Your creation must not be derived from the kernel
> (because creating derived works is  an exclusive right of
> the copyright owner, and you don't have and won't 
> get a permission), and it must not infringe the RCU patents.

Thanks for this information. I guess we can live without rcu.

> You have written an algorithm module that is tightly coupled to the 
> Linux kernel, and you think it's not derived from the kernel, correct? 
> As a non-lawyer, it'd say that's wrong.

Well, the algorithm has been developped totally independent from
(Continue reading)

Permalink | Reply | 1 comment |
headers
Larry McVoy | 1 Dec 2003 01:44
Favicon

bkbits.net down for cleaning

It's that time of the month, time to get the dust out of the machine and do
a disk check.  We're off the air for maybe an hour or two.
--

-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm
Permalink | Reply | 1 comment |
headers
Valdis.Kletnieks | 1 Dec 2003 01:50
Picon
Favicon

Re: Bug with extraversion in kernel-2.4.23

On Mon, 01 Dec 2003 01:16:02 +0100, Rudo Thomas <thomr9am <at> ss1000.ms.mff.cuni.cz>  said:
> > The extraversion variable of the Makefile is very badly interpreted.
> > When the kernel is installed, I have 2 directory of modules :
> > /lib/modules/2.4.23
> > /lib/modules/2.4.23-fnux (my extraversion is -fnux)
> 
> No way. The directory without -fnux is probably just a leftover from previous
> make modules_install. When you run 2.4.23-fnux, you won't need it.

On the other hand, you probably want to keep the 2.4.23(no-ext) directory
around as well, so you can boot a 2.4.23 kernel to clean up after a broken
build of a 2.4.23-fnux won't boot.

There's a reason why my /lib/modules has 6 subdirectories - I have 6
bootable kernels sitting around, Just In Case (well... OK. 2 spares would
probably be enough, but it's easier to do a "which -mm did the problem start?"
regression if you have the most recent few handy to try.. ;)
Permalink | Reply | 0 comments |
headers
Valdis.Kletnieks | 1 Dec 2003 01:57
Picon
Favicon

Re: Kernel modul licensing issues

On Mon, 01 Dec 2003 01:27:58 +0100, john smith said:

> Well, the algorithm has been developped totally independent from
> linux. It also works under other OS's without any adjustments apart
> from alloc and locking stuff.
> 
> The fact that it receives kernel data as input IMO does not make it
> tightly coupled to the linux kernel since the algorithm does not even
> know or care what it receives as input (at least as far as kernel data
> is concerned). It basically considers kernel data: char[]

You're probably "in the clear" if that's what's really going on, and
can probably go a route similar to NVidia (GPL interface to a binary
module).  The part I'm not having warm fuzzies about is that the only
application that comes to mind that could take a char[] and be totally
kernel-independent and that would make sense in the kernel rather than
out in userspace is a crypto transform - and that's because closed
source crypto is usually not taken seriously.

Consider what Matt Blaze did to Clipper, which was even more closed
source than what you're doing....  Of course, if you're not doing
crypto, then you can apply the usual cost/benefit analysis of doing
it closed source versus the payoff for an attacker to crack it....
Permalink | Reply | 0 comments |
headers
Keith Owens | 1 Dec 2003 02:06
Picon
Favicon

Announce: XFS split patches for 2.4.23


Content-Type: text/plain; charset=us-ascii

ftp://oss.sgi.com/projects/xfs/download/patches/2.4.23.  

For some time the XFS group have been producing split patches for XFS,
separating the core XFS changes from additional patches such as kdb,
acl, dmapi.  The split patches are released to the world with the hope
that developers and distributors will find them useful.

Read the README in each directory very carefully, the split patch
format has changed over a few kernel releases.  Any questions that are
covered by the README will be ignored.  There is even a 2.4.24/README
for the terminally impatient :).
Permalink | Reply | 0 comments |

Gmane