All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Kujau <evil@g-house.de>
To: Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Linus Torvalds <torvalds@osdl.org>,
	alsa-devel@lists.sourceforge.net, linux-sound@vger.kernel.org,
	Greg KH <greg@kroah.com>
Subject: Re: Oops in 2.6.10-rc1
Date: Mon, 08 Nov 2004 21:59:11 +0100	[thread overview]
Message-ID: <418FDE1F.7060804@g-house.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0411080951390.2301@ppc970.osdl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus Torvalds schrieb:
>
> No, just gut feel. If the pre-merge ALSA works, and the post-merge one 
> doesn't, and the oops in both cases happen somewhere close to where it 
> does "pci_enable_device()", there's not a lot left. There are interrupts, 
> and there is the PCI layer...

yes, makes sense.

>>
>>i did "bk undo -a1.2463" from a current -BK tree and it oopses:
> 
> Note that "bk undo -axxx" will _leave_ xxx in place, and undo everything 
> after. 
> 
> So what you did still has the merge in the tree, and that it still oopses 
> is thus to be expected. BUT, we're getting closer.

yes, i think i understood that. that's why i wanted to revert 1.2463 too.

[...]

> 
> Now, that's fine - the USB merge is likely to be ok, so try doing
> 
> 	bk undo -a1.2462

for now i appreciate your work here but i have to postpone the the "bk
revtool" stuff because i have no X _and_ bk here. (but i'm a good student
and will do my homework)

> and you will now have a tree that is exactly the same as before, except it 
> does _not_ have the PCI merge from Greg.
> 
> And if this one does not oops, you can now officially blame Greg.

i can't wait... ;)

>> Now, if you want to get _really_ fancy, you can now look at each changeset 
> that differed, with something like
> 
> 	bk set -n -d -r1.2462 -r1.2463 | bk -R prs -h -d'<:P:@:HOST:>\n$each(:C:){\t(:C:)\n}\n' -
> 
> which is black magic that does a set operation and shows all the changes 
> in between the sets of "bk at 1.2462" and "bk at 1.2463".
> 
> (This is _not_ the same as "bk changes -r1.2462..1.2463", because that one 
> just shows the single merge change that is on the direct _path_ from one 
> changeset to another. The black magic thing shows the set difference of 
> changesets that comes from the full graph at two points).
> 
> Then you can look at each change individually and see if they matter.

will do, after the build

> 
> And once you can do the set operations, you're officially a BK poweruser.  
> Me, I just have a script, I'm a BK dabbler.
> 
> Looking at the list (appended), I don't see anything obvious, but hey, if 
> it was obvious it wouldn't have been merged in the first place. 
> 
> Thanks for your willingness to pursue this thing,

hey, thanks to you and to the folks in the Cc: field to chase a bug which
only _i_ encounter until now.

/me is building now....
thanks,
Christian.
- --
BOFH excuse #111:

The salesman drove over the CPU board.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBj94f+A7rjkF8z0wRAm/uAJ0eTBa20JnX+250GpFiSED4b+arQwCggSgo
CO/MQ+1jeOOvb7WaJRKg7uY=
=Qlt1
-----END PGP SIGNATURE-----

WARNING: multiple messages have this Message-ID (diff)
From: Christian Kujau <evil@g-house.de>
To: Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Linus Torvalds <torvalds@osdl.org>,
	alsa-devel@lists.sourceforge.net, linux-sound@vger.kernel.org,
	Greg KH <greg@kroah.com>
Subject: Re: Oops in 2.6.10-rc1
Date: Mon, 08 Nov 2004 20:59:11 +0000	[thread overview]
Message-ID: <418FDE1F.7060804@g-house.de> (raw)
In-Reply-To: <Pine.LNX.4.58.0411080951390.2301@ppc970.osdl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus Torvalds schrieb:
>
> No, just gut feel. If the pre-merge ALSA works, and the post-merge one 
> doesn't, and the oops in both cases happen somewhere close to where it 
> does "pci_enable_device()", there's not a lot left. There are interrupts, 
> and there is the PCI layer...

yes, makes sense.

>>
>>i did "bk undo -a1.2463" from a current -BK tree and it oopses:
> 
> Note that "bk undo -axxx" will _leave_ xxx in place, and undo everything 
> after. 
> 
> So what you did still has the merge in the tree, and that it still oopses 
> is thus to be expected. BUT, we're getting closer.

yes, i think i understood that. that's why i wanted to revert 1.2463 too.

[...]

> 
> Now, that's fine - the USB merge is likely to be ok, so try doing
> 
> 	bk undo -a1.2462

for now i appreciate your work here but i have to postpone the the "bk
revtool" stuff because i have no X _and_ bk here. (but i'm a good student
and will do my homework)

> and you will now have a tree that is exactly the same as before, except it 
> does _not_ have the PCI merge from Greg.
> 
> And if this one does not oops, you can now officially blame Greg.

i can't wait... ;)

>> Now, if you want to get _really_ fancy, you can now look at each changeset 
> that differed, with something like
> 
> 	bk set -n -d -r1.2462 -r1.2463 | bk -R prs -h -d'<:P:@:HOST:>\n$each(:C:){\t(:C:)\n}\n' -
> 
> which is black magic that does a set operation and shows all the changes 
> in between the sets of "bk at 1.2462" and "bk at 1.2463".
> 
> (This is _not_ the same as "bk changes -r1.2462..1.2463", because that one 
> just shows the single merge change that is on the direct _path_ from one 
> changeset to another. The black magic thing shows the set difference of 
> changesets that comes from the full graph at two points).
> 
> Then you can look at each change individually and see if they matter.

will do, after the build

> 
> And once you can do the set operations, you're officially a BK poweruser.  
> Me, I just have a script, I'm a BK dabbler.
> 
> Looking at the list (appended), I don't see anything obvious, but hey, if 
> it was obvious it wouldn't have been merged in the first place. 
> 
> Thanks for your willingness to pursue this thing,

hey, thanks to you and to the folks in the Cc: field to chase a bug which
only _i_ encounter until now.

/me is building now....
thanks,
Christian.
- --
BOFH excuse #111:

The salesman drove over the CPU board.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBj94f+A7rjkF8z0wRAm/uAJ0eTBa20JnX+250GpFiSED4b+arQwCggSgo
CO/MQ+1jeOOvb7WaJRKg7uY=Qlt1
-----END PGP SIGNATURE-----

  reply	other threads:[~2004-11-08 21:01 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-28 13:12 Oops in 2.6.10-rc1 Christian
2004-10-28 13:29 ` [Alsa-devel] " Jaroslav Kysela
2004-10-28 14:09   ` Christian
2004-11-04 15:16     ` Christian Kujau
2004-11-05  2:35       ` Christian Kujau
2004-11-05 11:40         ` holborn
2004-11-07  1:24       ` Christian Kujau
2004-11-07  7:02         ` Linus Torvalds
2004-11-07 13:10           ` Christian Kujau
2004-11-07 16:02             ` Christian Kujau
2004-11-07 16:57               ` Linus Torvalds
2004-11-07 18:31                 ` Christian Kujau
2004-11-07 18:44                   ` Linus Torvalds
2004-11-07 23:45                   ` Christian Kujau
2004-11-07 23:45                     ` Christian Kujau
2004-11-08  1:16                     ` Linus Torvalds
2004-11-08  1:16                       ` Linus Torvalds
2004-11-08 13:01                       ` Christian Kujau
2004-11-08 13:01                         ` Christian Kujau
2004-11-08 18:13                         ` Linus Torvalds
2004-11-08 18:13                           ` Linus Torvalds
2004-11-08 20:59                           ` Christian Kujau [this message]
2004-11-08 20:59                             ` Christian Kujau
2004-11-08 23:49                             ` Christian Kujau
2004-11-09  1:05                               ` Linus Torvalds
2004-11-09  1:41                                 ` Christian Kujau
2004-11-09  1:31                               ` Christian Kujau
2004-11-09  7:40                                 ` Pekka Enberg
2004-11-09 12:33                                   ` Christian Kujau
2004-11-09 17:26                                     ` Oops in 2.6.10-rc1 (almost solved) Christian Kujau
2004-11-09 18:53                                       ` Linus Torvalds
2004-11-09 19:04                                         ` [PATCH] kobject: fix double kobject_put() in error path of kobject_add() Greg KH
2004-11-09 19:08                                           ` Greg KH
2004-11-09 20:19                                             ` Pekka Enberg
2004-11-09 21:21                                             ` Christian Kujau
2004-11-09 21:31                                             ` Christian Kujau
2004-11-09 19:09                                           ` Linus Torvalds
2004-11-09 22:06                                             ` Christian Kujau
2004-11-09 23:30                                         ` Oops in 2.6.10-rc1 (almost solved) Christian Kujau
2004-11-09 23:40                                           ` Matt Domsch
2004-11-10  0:21                                             ` Christian Kujau
2004-11-10  1:01                                               ` Linus Torvalds
2004-11-11 22:43                                             ` Matt Domsch
2004-11-11 22:53                                               ` Linus Torvalds
2004-11-11 22:55                                                 ` Matt Domsch
2004-11-12  0:27                                               ` Christian Kujau
2004-11-12  0:49                                                 ` Linus Torvalds
2004-11-12  1:27                                                   ` Christian Kujau
2004-11-10  0:12                           ` Oops in 2.6.10-rc1 Christian Kujau
2004-11-10  0:23                             ` Linus Torvalds
2004-11-08 18:44                         ` Pekka Enberg
2004-11-08 18:44                           ` Pekka Enberg
2004-11-08 19:00                           ` Greg KH
2004-11-08 19:00                             ` Greg KH
2004-11-08 19:18                             ` Pekka Enberg
2004-11-08 19:18                               ` Pekka Enberg
2004-11-08 19:30                               ` Pekka Enberg
2004-11-08 19:30                                 ` Pekka Enberg
2004-11-08 20:31                               ` Christian Kujau
2004-11-08 20:31                                 ` Christian Kujau
2004-11-07 13:05         ` Pekka Enberg
2004-11-07 13:43           ` Christian Kujau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=418FDE1F.7060804@g-house.de \
    --to=evil@g-house.de \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.