* xorg problems with v2.6.27-rc1-2457-gdcb80fd
@ 2008-07-31 12:56 Nico -telmich- Schottelius
2008-07-31 13:23 ` How to debug linux-next? (was: Re: xorg problems with v2.6.27-rc1-2457-gdcb80fd) Nico -telmich- Schottelius
0 siblings, 1 reply; 9+ messages in thread
From: Nico -telmich- Schottelius @ 2008-07-31 12:56 UTC (permalink / raw)
To: linux-next
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
Hello!
When booting this kernel, xorg crashes. Details can be found on
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493101.
Possibly more an xorg issue, just wanted to report that xorg still works
with 2.6.26-next-20080725.
Sincerly,
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* How to debug linux-next? (was: Re: xorg problems with v2.6.27-rc1-2457-gdcb80fd)
2008-07-31 12:56 xorg problems with v2.6.27-rc1-2457-gdcb80fd Nico -telmich- Schottelius
@ 2008-07-31 13:23 ` Nico -telmich- Schottelius
2008-07-31 13:35 ` Stephen Rothwell
0 siblings, 1 reply; 9+ messages in thread
From: Nico -telmich- Schottelius @ 2008-07-31 13:23 UTC (permalink / raw)
To: linux-next
[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]
Hello again!
Some questions about using and debugging linux-next:
- Where to report errors? to this ml? cc-ing the related subsystem
maintainer(s)?
- What's the normal way of finding out the source for a problem, if you know
a good commit (9bead9ae16728973cd31d9fd60c496e0e2fabbd1) and a
bad commit (dcb80fdb8cffd3fa06cd322b3e8227632ec23597)?
- As far as I can see, you are doing rebase on linux-next. Why don't you
continue to do git-merge?
- And would a non-rebased tree not make life much easier for debugging
purposes?
My motivation is to find out the reason why xorg crashes now together
with the xorg guys. But currently it seems to be impossible for me to
detect which commits have been between to snapshots of the master
branch of linux-next.
Sincerly,
Nico
Nico -telmich- Schottelius [Thu, Jul 31, 2008 at 02:56:30PM +0200]:
> Hello!
>
> When booting this kernel, xorg crashes. Details can be found on
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493101.
>
> Possibly more an xorg issue, just wanted to report that xorg still works
> with 2.6.26-next-20080725.
>
> Sincerly,
>
> Nico
>
> --
> Think about Free and Open Source Software (FOSS).
> http://nico.schottelius.org/documentations/foss/the-term-foss/
>
> PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to debug linux-next? (was: Re: xorg problems with v2.6.27-rc1-2457-gdcb80fd)
2008-07-31 13:23 ` How to debug linux-next? (was: Re: xorg problems with v2.6.27-rc1-2457-gdcb80fd) Nico -telmich- Schottelius
@ 2008-07-31 13:35 ` Stephen Rothwell
2008-07-31 14:41 ` How to debug linux-next? Nico -telmich- Schottelius
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Rothwell @ 2008-07-31 13:35 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]
On Thu, 31 Jul 2008 15:23:44 +0200 Nico -telmich- Schottelius <nico-linux-next@schottelius•org> wrote:
>
> Some questions about using and debugging linux-next:
>
> - Where to report errors? to this ml? cc-ing the related subsystem
> maintainer(s)?
Yes.
> - What's the normal way of finding out the source for a problem, if you know
> a good commit (9bead9ae16728973cd31d9fd60c496e0e2fabbd1) and a
> bad commit (dcb80fdb8cffd3fa06cd322b3e8227632ec23597)?
It is much easier to use "git bisect" within a single linux-next release
than between releases. The latter should work some of the time but is
complicated by the fact that linux-next is effectively rebased every
day. So it is sensible to see if the "stable" branch of linux-next works
(as that is just Linus' tree) and use that as a "good" starting point if
so. If that doesn't work, then the problem is in Linus' tree already.
> - As far as I can see, you are doing rebase on linux-next. Why don't you
> continue to do git-merge?
Because some of the trees that are merged into linux-next are rebased
fairly often as well.
> - And would a non-rebased tree not make life much easier for debugging
> purposes?
I don't know. What it would do is produce a lot more merge conflicts as
patches are moved around, changed, removed etc on a daily basis.
> My motivation is to find out the reason why xorg crashes now together
> with the xorg guys. But currently it seems to be impossible for me to
> detect which commits have been between to snapshots of the master
> branch of linux-next.
Yeah, that is a pain. Does Linus' tree work?
--
Cheers,
Stephen Rothwell sfr@canb•auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to debug linux-next?
2008-07-31 13:35 ` Stephen Rothwell
@ 2008-07-31 14:41 ` Nico -telmich- Schottelius
2008-07-31 15:58 ` Takashi Iwai
0 siblings, 1 reply; 9+ messages in thread
From: Nico -telmich- Schottelius @ 2008-07-31 14:41 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next
[-- Attachment #1: Type: text/plain, Size: 2297 bytes --]
Stephen Rothwell [Thu, Jul 31, 2008 at 11:35:58PM +1000]:
> > - What's the normal way of finding out the source for a problem, if you know
> > a good commit (9bead9ae16728973cd31d9fd60c496e0e2fabbd1) and a
> > bad commit (dcb80fdb8cffd3fa06cd322b3e8227632ec23597)?
>
> It is much easier to use "git bisect" within a single linux-next release
> than between releases.
Yep, that's the problem I am facing now.
> > - As far as I can see, you are doing rebase on linux-next. Why don't you
> > continue to do git-merge?
>
> Because some of the trees that are merged into linux-next are rebased
> fairly often as well.
Argh, such a pain. Imho it would be much nicer for tracking down
problems, if people just continue their graph, without doing rebase.
Stephen, as you've more experience with the other maintainers:
Would it not be possible to retrieve a branch from most subsystems
that is never rebased?
Imho doing rebase breaks alot of possibilities with git, as you remove
commits and break the history (which is what makes git powerful for me).
> > - And would a non-rebased tree not make life much easier for debugging
> > purposes?
>
> I don't know. What it would do is produce a lot more merge conflicts as
> patches are moved around, changed, removed etc on a daily basis.
The only issue I see is with rewritten patches. Otherwise git-merge
should detect already applied patches and without git I see
git-format-patch and git-am as quite strong tools.
I must confess, that I _really_ like the idea of doing
git-fetch && git-merge linux-next, so git-bisect works
for all versions.
> > My motivation is to find out the reason why xorg crashes now together
> > with the xorg guys. But currently it seems to be impossible for me to
> > detect which commits have been between to snapshots of the master
> > branch of linux-next.
>
> Yeah, that is a pain. Does Linus' tree work?
Just compiling..the dual core 1.83ghz cpu is just too slow...reboot...
works. I'm writing this E-Mail running 2.6.27-rc1-denkbrett-00156-g94ad374
under xorg.
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to debug linux-next?
2008-07-31 14:41 ` How to debug linux-next? Nico -telmich- Schottelius
@ 2008-07-31 15:58 ` Takashi Iwai
2008-07-31 16:09 ` Nico -telmich- Schottelius
0 siblings, 1 reply; 9+ messages in thread
From: Takashi Iwai @ 2008-07-31 15:58 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Stephen Rothwell, linux-next
At Thu, 31 Jul 2008 16:41:11 +0200,
Nico -telmich- Schottelius wrote:
>
> > > - And would a non-rebased tree not make life much easier for debugging
> > > purposes?
> >
> > I don't know. What it would do is produce a lot more merge conflicts as
> > patches are moved around, changed, removed etc on a daily basis.
>
> The only issue I see is with rewritten patches. Otherwise git-merge
> should detect already applied patches and without git I see
> git-format-patch and git-am as quite strong tools.
>
> I must confess, that I _really_ like the idea of doing
> git-fetch && git-merge linux-next, so git-bisect works
> for all versions.
I also would love to have a continuous git tree, but I guess it's
pretty hard for linux-next after some time. git-merge doesn't always
track rebased trees perfectly, and we have also quilt trees in
addition. Moreover, sometimes some subtrees have to be dropped
temporarily for fatal conflicts.
One thing I think sometimes useful is a record of HEAD of each merged
tree in a file, say, Next/heads. Then you can see what changes have
been done in each subtree more easily.
BTW, you can try to merge the tree by yourself. For example, starting
from next-20080729, merge next-20080730, resolve conflicts manually,
and go next to 20080731. It seems working with a relatively small
number of conflicts for a few days difference.
Takashi
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to debug linux-next?
2008-07-31 15:58 ` Takashi Iwai
@ 2008-07-31 16:09 ` Nico -telmich- Schottelius
2008-07-31 16:36 ` Takashi Iwai
0 siblings, 1 reply; 9+ messages in thread
From: Nico -telmich- Schottelius @ 2008-07-31 16:09 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Stephen Rothwell, linux-next
[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]
Takashi Iwai [Thu, Jul 31, 2008 at 05:58:46PM +0200]:
> I also would love to have a continuous git tree, but I guess it's
> pretty hard for linux-next after some time. git-merge doesn't always
> track rebased trees perfectly, and we have also quilt trees in
> addition. Moreover, sometimes some subtrees have to be dropped
> temporarily for fatal conflicts.
Yes, imho rebase is something that must create pain, as it changes the
history (independent of git and linux).
For quilt, I did never use it -- not sure how those trees could be
integrated.
And dropping trees: Would not ignore those branches for
merging help? Or if stuff has to be removed, to revert changes?
> One thing I think sometimes useful is a record of HEAD of each merged
> tree in a file, say, Next/heads. Then you can see what changes have
> been done in each subtree more easily.
Sounds a little bit like manual merge recording.
> BTW, you can try to merge the tree by yourself.
Well, yes, but that breaks my idea of having all trees based on the same
history: If I want to see, what the agp team did after v2.6.29 was
released and compare it to what I've -- I cannot do it, because their
v2.6.29 base is a different one than mine.
Maybe merging stuff from different people is really (not yet?)
practical, but imho something that really uses the commit ids and
messages that are already existent would be pretty useful, so we
can use the usual tools like git-log and git-bisect.
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to debug linux-next?
2008-07-31 16:09 ` Nico -telmich- Schottelius
@ 2008-07-31 16:36 ` Takashi Iwai
2008-07-31 16:54 ` Nico -telmich- Schottelius
0 siblings, 1 reply; 9+ messages in thread
From: Takashi Iwai @ 2008-07-31 16:36 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Stephen Rothwell, linux-next
At Thu, 31 Jul 2008 18:09:52 +0200,
Nico -telmich- Schottelius wrote:
>
> Takashi Iwai [Thu, Jul 31, 2008 at 05:58:46PM +0200]:
> > I also would love to have a continuous git tree, but I guess it's
> > pretty hard for linux-next after some time. git-merge doesn't always
> > track rebased trees perfectly, and we have also quilt trees in
> > addition. Moreover, sometimes some subtrees have to be dropped
> > temporarily for fatal conflicts.
>
> Yes, imho rebase is something that must create pain, as it changes the
> history (independent of git and linux).
> For quilt, I did never use it -- not sure how those trees could be
> integrated.
>
> And dropping trees: Would not ignore those branches for
> merging help? Or if stuff has to be removed, to revert changes?
Hm, what are the difference between them? Since linux-next is
re-generated at each time, both should mean the same...
> > One thing I think sometimes useful is a record of HEAD of each merged
> > tree in a file, say, Next/heads. Then you can see what changes have
> > been done in each subtree more easily.
>
> Sounds a little bit like manual merge recording.
The full merge log is found in Next subdirectory, but it's difficult
to find out the necessary information from the log text.
Suppose a list of tree and id pairs like
tree-a 012345
tree-b 432100
...
then you can find easily which tree is changed by git-diff of this
file.
> > BTW, you can try to merge the tree by yourself.
>
> Well, yes, but that breaks my idea of having all trees based on the same
> history: If I want to see, what the agp team did after v2.6.29 was
> released and compare it to what I've -- I cannot do it, because their
> v2.6.29 base is a different one than mine.
Well, I meant you can try to get some continuous history by yourself
to solve your problem. You know 20080729 is good, and 20080731 is
bad, and you do want a continuous history between them. Then you can
start from the good point and merge the next-tree itself manually
until the bad point.
I didn't suggest to keep maintaining self-made linux-next tree, of
course :)
Takashi
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to debug linux-next?
2008-07-31 16:36 ` Takashi Iwai
@ 2008-07-31 16:54 ` Nico -telmich- Schottelius
2008-07-31 16:59 ` Takashi Iwai
0 siblings, 1 reply; 9+ messages in thread
From: Nico -telmich- Schottelius @ 2008-07-31 16:54 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Stephen Rothwell, linux-next
[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]
Takashi Iwai [Thu, Jul 31, 2008 at 06:36:38PM +0200]:
> Nico -telmich- Schottelius wrote:
> > Takashi Iwai [Thu, Jul 31, 2008 at 05:58:46PM +0200]:
> > > I also would love to have a continuous git tree, but I guess it's
> > > pretty hard for linux-next after some time. git-merge doesn't always
> > > track rebased trees perfectly, and we have also quilt trees in
> > > addition. Moreover, sometimes some subtrees have to be dropped
> > > temporarily for fatal conflicts.
> >
> > Yes, imho rebase is something that must create pain, as it changes the
> > history (independent of git and linux).
> > For quilt, I did never use it -- not sure how those trees could be
> > integrated.
> >
> > And dropping trees: Would not ignore those branches for
> > merging help? Or if stuff has to be removed, to revert changes?
>
> Hm, what are the difference between them? Since linux-next is
> re-generated at each time, both should mean the same...
A revert is recorded in the history.
A rebase isn't (and isn't thought to).
> > > One thing I think sometimes useful is a record of HEAD of each merged
> > > tree in a file, say, Next/heads. Then you can see what changes have
> > > been done in each subtree more easily.
> >
> > Sounds a little bit like manual merge recording.
>
> The full merge log is found in Next subdirectory, but it's difficult
> to find out the necessary information from the log text.
>
> Suppose a list of tree and id pairs like
>
> tree-a 012345
> tree-b 432100
> ...
>
> then you can find easily which tree is changed by git-diff of this
> file.
That's exactly what I meant with manual merge recording :-)
> > > BTW, you can try to merge the tree by yourself.
> >
> > Well, yes, but that breaks my idea of having all trees based on the same
> > history: If I want to see, what the agp team did after v2.6.29 was
> > released and compare it to what I've -- I cannot do it, because their
> > v2.6.29 base is a different one than mine.
>
> Well, I meant you can try to get some continuous history by yourself
> to solve your problem. You know 20080729 is good, and 20080731 is
> bad, and you do want a continuous history between them. Then you can
> start from the good point and merge the next-tree itself manually
> until the bad point.
That maybe a good idea to fix debug the issue now ... although
I still hope, we'll get a more generic way to fix such things
(-> when there are more linux-next testers, more such problems
will arise).
I am still not sure, what would allow me the easiest way of debugging,
will perhaps have a deeper look at it later.
> I didn't suggest to keep maintaining self-made linux-next tree, of
> course :)
In fact, I am very happy for the work Stephen does. It really allows
testing new stuff quite easily.
Nico
--
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/
PGP: BFE4 C736 ABE5 406F 8F42 F7CF B8BE F92A 9885 188C
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: How to debug linux-next?
2008-07-31 16:54 ` Nico -telmich- Schottelius
@ 2008-07-31 16:59 ` Takashi Iwai
0 siblings, 0 replies; 9+ messages in thread
From: Takashi Iwai @ 2008-07-31 16:59 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Stephen Rothwell, linux-next
At Thu, 31 Jul 2008 18:54:05 +0200,
Nico -telmich- Schottelius wrote:
>
> Takashi Iwai [Thu, Jul 31, 2008 at 06:36:38PM +0200]:
> > Nico -telmich- Schottelius wrote:
> > > Takashi Iwai [Thu, Jul 31, 2008 at 05:58:46PM +0200]:
> > > > I also would love to have a continuous git tree, but I guess it's
> > > > pretty hard for linux-next after some time. git-merge doesn't always
> > > > track rebased trees perfectly, and we have also quilt trees in
> > > > addition. Moreover, sometimes some subtrees have to be dropped
> > > > temporarily for fatal conflicts.
> > >
> > > Yes, imho rebase is something that must create pain, as it changes the
> > > history (independent of git and linux).
> > > For quilt, I did never use it -- not sure how those trees could be
> > > integrated.
> > >
> > > And dropping trees: Would not ignore those branches for
> > > merging help? Or if stuff has to be removed, to revert changes?
> >
> > Hm, what are the difference between them? Since linux-next is
> > re-generated at each time, both should mean the same...
>
> A revert is recorded in the history.
> A rebase isn't (and isn't thought to).
Ah, so you mean to revert the whole tree commit?
Not sure whether it looks nice...
> > > > BTW, you can try to merge the tree by yourself.
> > >
> > > Well, yes, but that breaks my idea of having all trees based on the same
> > > history: If I want to see, what the agp team did after v2.6.29 was
> > > released and compare it to what I've -- I cannot do it, because their
> > > v2.6.29 base is a different one than mine.
> >
> > Well, I meant you can try to get some continuous history by yourself
> > to solve your problem. You know 20080729 is good, and 20080731 is
> > bad, and you do want a continuous history between them. Then you can
> > start from the good point and merge the next-tree itself manually
> > until the bad point.
>
> That maybe a good idea to fix debug the issue now ... although
> I still hope, we'll get a more generic way to fix such things
> (-> when there are more linux-next testers, more such problems
> will arise).
Yes.
> I am still not sure, what would allow me the easiest way of debugging,
> will perhaps have a deeper look at it later.
If it's about input-layer change like Andrew's case, Dmitry's patch
should solve. Or, revert the commit 0571c5d20aca7...
> > I didn't suggest to keep maintaining self-made linux-next tree, of
> > course :)
>
> In fact, I am very happy for the work Stephen does. It really allows
> testing new stuff quite easily.
Definitely.
Takashi
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-07-31 16:59 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-31 12:56 xorg problems with v2.6.27-rc1-2457-gdcb80fd Nico -telmich- Schottelius
2008-07-31 13:23 ` How to debug linux-next? (was: Re: xorg problems with v2.6.27-rc1-2457-gdcb80fd) Nico -telmich- Schottelius
2008-07-31 13:35 ` Stephen Rothwell
2008-07-31 14:41 ` How to debug linux-next? Nico -telmich- Schottelius
2008-07-31 15:58 ` Takashi Iwai
2008-07-31 16:09 ` Nico -telmich- Schottelius
2008-07-31 16:36 ` Takashi Iwai
2008-07-31 16:54 ` Nico -telmich- Schottelius
2008-07-31 16:59 ` Takashi Iwai
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox