* 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