Re: dmesg verbosity [was Re: AGP bogosities]
On 30/03/2005 10:45:55 linux-kernel-owner wrote: >> The solution is fairly well known. Rather than treating the zillions of >> disk seeks during the boot process as random unconnected events, you > >Heh, we actually tried that at SuSE and yes, eliminating seeks helps a >bit, but no, it is not magicall cure you'd want it to be. > >Only solution seems to be "do less during boot". What about the init scripts? They are all spawned from the master one, they all spawn zillions of simple utilities. And udev startup time under SuSE 9.2 is just awful. It might be the Unix way but it is killing the boot process. What I tried to do once, and I even contacted somebody from SuSE with a working proof of concept code is the following: Master init script written in Perl. All the service init scripts rewritten in Perl which can be invoked independently, but they all follow the convention and implement functions such as start() stop() reload() etc.. Then the master init script includes one at a time and "evals" them (well just the function which it is interested in). Since everything is written in Perl there is no need to invoke external greps, seds, cuts etc.. And rc.status was also only processed once (by the master init script). It was fast but I don't have any exact numbers because I only implemented rc, rc.boot, rc.status and sshd (AFAIR) before giving up. I think I should be able to dig that code from somewhere if someone is interested... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Hi! > > > I'm really not trolling, but I suspect if we made the boot process less > > > verbose, people would start to wonder more about why Linux takes so much > > > longer than XP to boot. > > > > By the way, Microsoft seems to be claiming that boot time will be reduced > > to the half > > with Longhorn. While we already know how ms marketing team works, 50% looks > > like a lot. Is there a good place to discuss what could be done in the > > linuxland to > > improve things? It doesn't looks like a couple of optimizations will be > > enought... > > > > Yup, many people on this list seem unaware but read the XP white papers, > then try booting it side by side with Linux. They put some serious, > serious engineering into that problem and came out with a big win. > Screw Longhorn, we need improve by 50% to catch up to what they can do > NOW. > > The solution is fairly well known. Rather than treating the zillions of > disk seeks during the boot process as random unconnected events, you Heh, we actually tried that at SuSE and yes, eliminating seeks helps a bit, but no, it is not magicall cure you'd want it to be. Only solution seems to be "do less during boot". Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Hi! I'm really not trolling, but I suspect if we made the boot process less verbose, people would start to wonder more about why Linux takes so much longer than XP to boot. By the way, Microsoft seems to be claiming that boot time will be reduced to the half with Longhorn. While we already know how ms marketing team works, 50% looks like a lot. Is there a good place to discuss what could be done in the linuxland to improve things? It doesn't looks like a couple of optimizations will be enought... Yup, many people on this list seem unaware but read the XP white papers, then try booting it side by side with Linux. They put some serious, serious engineering into that problem and came out with a big win. Screw Longhorn, we need improve by 50% to catch up to what they can do NOW. The solution is fairly well known. Rather than treating the zillions of disk seeks during the boot process as random unconnected events, you Heh, we actually tried that at SuSE and yes, eliminating seeks helps a bit, but no, it is not magicall cure you'd want it to be. Only solution seems to be do less during boot. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On 30/03/2005 10:45:55 linux-kernel-owner wrote: The solution is fairly well known. Rather than treating the zillions of disk seeks during the boot process as random unconnected events, you Heh, we actually tried that at SuSE and yes, eliminating seeks helps a bit, but no, it is not magicall cure you'd want it to be. Only solution seems to be do less during boot. What about the init scripts? They are all spawned from the master one, they all spawn zillions of simple utilities. And udev startup time under SuSE 9.2 is just awful. It might be the Unix way but it is killing the boot process. What I tried to do once, and I even contacted somebody from SuSE with a working proof of concept code is the following: Master init script written in Perl. All the service init scripts rewritten in Perl which can be invoked independently, but they all follow the convention and implement functions such as start() stop() reload() etc.. Then the master init script includes one at a time and evals them (well just the function which it is interested in). Since everything is written in Perl there is no need to invoke external greps, seds, cuts etc.. And rc.status was also only processed once (by the master init script). It was fast but I don't have any exact numbers because I only implemented rc, rc.boot, rc.status and sshd (AFAIR) before giving up. I think I should be able to dig that code from somewhere if someone is interested... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Wed, Mar 23, 2005 at 05:49:47PM +0100, Giuseppe Bilotta wrote: > > > What are the cons of using "all of" the RAM at boot time to > > > cache the boot disk? > > Dave Jones wrote: > > It's memory that's otherwise unused. Once you start using the system > > anything cached will get reclaimed as its needed. > > So there is no substantial loss? IOW, it would suffice to have > all the "loaded at boot" stuff in the first > bytes of the hard disk? It very likely also needs to be contiguous on-disk (Ie, no in-file fragmentation). You want to limit the amount of seeking that gets done so the drive readahead just performs continuous reads. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
> > What are the cons of using "all of" the RAM at boot time to > > cache the boot disk? Dave Jones wrote: > It's memory that's otherwise unused. Once you start using the system > anything cached will get reclaimed as its needed. So there is no substantial loss? IOW, it would suffice to have all the "loaded at boot" stuff in the first bytes of the hard disk? -- Giuseppe "Oblomov" Bilotta Can't you see It all makes perfect sense Expressed in dollar and cents Pounds shillings and pence (Roger Waters) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Wed, Mar 23, 2005 at 09:21:22AM +0100, Giuseppe Bilotta wrote: > Dave Jones wrote: > > Some of the folks on our desktop team have been doing a bunch of > > experiments > > at getting boot times down, including laying out the blocks in a more > > optimal manner, allowing /sbin/readahead to slurp the data off the disk > > in one big chunk, and run almost entirely from cache. > > What are the cons of using "all of" the RAM at boot time to > cache the boot disk? It's memory that's otherwise unused. Once you start using the system anything cached will get reclaimed as its needed. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
El Tue, 22 Mar 2005 20:13:15 -0500, Dave Jones <[EMAIL PROTECTED]> escribió: > With something like this, and some additional bookkeeping to keep track of > which files we open in the first few minutes of uptime, we could periodically > reorganise the layout back to an optimal state. That wouldn't be too hard (a libc wrapper could do it, right?) But how could you get track of "code page faults"? Perhaps it's not worth of it "preloading" the parts of the executable (and linked libraries) used and it's much simpler to read everything? (Andrew Morton suggested in the past using mincore(2) IIRC) Altought even if you optimize the disk's layout and pre-read everything you need, a big problem is the initscript scripts. I don't think it's init fault, handling absolutely _everything_ trough scripts is not going to help, specially when all^Wmost of linux systems use a shell which claims to be "too big and too slow" in its own man page ;) There're some shells (like zsh) which can "compile" scripts and generate "bytecode" I wonder if that would help (zsh seems to handle bash scripts so it may be interesting to try) Although like many people suggested, microsoft's "magic wand" to speed up everything could have been "lets save a suspend image of the system just before detecting new non-critical hardware and use it to boot the system". I guess its not possible to save/load suspend images to/from a filesystem? So, a list of steps needed (which doesn't means I'm voluntering to do all of them 8) could be: 1- Be able to keep track of what a process does in its whole life, or in the first N seconds (optimizing system's startup it's nice, but being able to speed up how fast openoffice loads when the system is already up would be even better). Using LD_PRELOAD=/something command could do this? 2- Get the on-disk info, port Andrew Morton's "move block" patch to 2.6, and use it to reorganize the disk's layout periodically (specially when package managers install something, ie: if people runs mozilla very often, mozilla files should be kept in the same place of the disk than all its libraries), using stadistics from step 1 3 - Create a tool which looks at all the data got from step 1 and "preloads" optimally from disk all the neccesary data (ie: using the path of one program, or several if you want to run two programs at the same time), with the reorganization done in step 2 it'd be even faster. Boot scripts would be just another user, and gnome and kde could use it too for single programs. If the tool detects that a program has been changed (looking at the "changed date" field for example) it could launch the process with the tools from step 1, so the stadistics get regenerated again. Is there something crazy in this idea? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Lee Revell wrote: > Yup, many people on this list seem unaware but read the XP white papers, > then try booting it side by side with Linux. They put some serious, > serious engineering into that problem and came out with a big win. > Screw Longhorn, we need improve by 50% to catch up to what they can do > NOW. > > The solution is fairly well known. Rather than treating the zillions of > disk seeks during the boot process as random unconnected events, you > analyze the I/O done during the boot process, then lay out those disk > blocks optimally based on this information so on the next boot you just > do one big streaming read. The patent side has been discussed and there > seems to be plenty of prior art. > > Someone needs to just do it. All the required information is right > there. Hm. My previous WinXP box (this same machine, different hard disk) was VERY fast in booting WinXP, out of the box. After two years of usage, installations, uninstallations and whatnot it had become slow as molasses. The Linux installation on the SAME machine was not affected. -- Giuseppe "Oblomov" Bilotta Can't you see It all makes perfect sense Expressed in dollar and cents Pounds shillings and pence (Roger Waters) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Dave Jones wrote: > Some of the folks on our desktop team have been doing a bunch of experiments > at getting boot times down, including laying out the blocks in a more > optimal manner, allowing /sbin/readahead to slurp the data off the disk > in one big chunk, and run almost entirely from cache. What are the cons of using "all of" the RAM at boot time to cache the boot disk? -- Giuseppe "Oblomov" Bilotta Can't you see It all makes perfect sense Expressed in dollar and cents Pounds shillings and pence (Roger Waters) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Dave Jones wrote: Some of the folks on our desktop team have been doing a bunch of experiments at getting boot times down, including laying out the blocks in a more optimal manner, allowing /sbin/readahead to slurp the data off the disk in one big chunk, and run almost entirely from cache. What are the cons of using all of the RAM at boot time to cache the boot disk? -- Giuseppe Oblomov Bilotta Can't you see It all makes perfect sense Expressed in dollar and cents Pounds shillings and pence (Roger Waters) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Lee Revell wrote: Yup, many people on this list seem unaware but read the XP white papers, then try booting it side by side with Linux. They put some serious, serious engineering into that problem and came out with a big win. Screw Longhorn, we need improve by 50% to catch up to what they can do NOW. The solution is fairly well known. Rather than treating the zillions of disk seeks during the boot process as random unconnected events, you analyze the I/O done during the boot process, then lay out those disk blocks optimally based on this information so on the next boot you just do one big streaming read. The patent side has been discussed and there seems to be plenty of prior art. Someone needs to just do it. All the required information is right there. Hm. My previous WinXP box (this same machine, different hard disk) was VERY fast in booting WinXP, out of the box. After two years of usage, installations, uninstallations and whatnot it had become slow as molasses. The Linux installation on the SAME machine was not affected. -- Giuseppe Oblomov Bilotta Can't you see It all makes perfect sense Expressed in dollar and cents Pounds shillings and pence (Roger Waters) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
El Tue, 22 Mar 2005 20:13:15 -0500, Dave Jones [EMAIL PROTECTED] escribió: With something like this, and some additional bookkeeping to keep track of which files we open in the first few minutes of uptime, we could periodically reorganise the layout back to an optimal state. That wouldn't be too hard (a libc wrapper could do it, right?) But how could you get track of code page faults? Perhaps it's not worth of it preloading the parts of the executable (and linked libraries) used and it's much simpler to read everything? (Andrew Morton suggested in the past using mincore(2) IIRC) Altought even if you optimize the disk's layout and pre-read everything you need, a big problem is the initscript scripts. I don't think it's init fault, handling absolutely _everything_ trough scripts is not going to help, specially when all^Wmost of linux systems use a shell which claims to be too big and too slow in its own man page ;) There're some shells (like zsh) which can compile scripts and generate bytecode I wonder if that would help (zsh seems to handle bash scripts so it may be interesting to try) Although like many people suggested, microsoft's magic wand to speed up everything could have been lets save a suspend image of the system just before detecting new non-critical hardware and use it to boot the system. I guess its not possible to save/load suspend images to/from a filesystem? So, a list of steps needed (which doesn't means I'm voluntering to do all of them 8) could be: 1- Be able to keep track of what a process does in its whole life, or in the first N seconds (optimizing system's startup it's nice, but being able to speed up how fast openoffice loads when the system is already up would be even better). Using LD_PRELOAD=/something command could do this? 2- Get the on-disk info, port Andrew Morton's move block patch to 2.6, and use it to reorganize the disk's layout periodically (specially when package managers install something, ie: if people runs mozilla very often, mozilla files should be kept in the same place of the disk than all its libraries), using stadistics from step 1 3 - Create a tool which looks at all the data got from step 1 and preloads optimally from disk all the neccesary data (ie: using the path of one program, or several if you want to run two programs at the same time), with the reorganization done in step 2 it'd be even faster. Boot scripts would be just another user, and gnome and kde could use it too for single programs. If the tool detects that a program has been changed (looking at the changed date field for example) it could launch the process with the tools from step 1, so the stadistics get regenerated again. Is there something crazy in this idea? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Wed, Mar 23, 2005 at 09:21:22AM +0100, Giuseppe Bilotta wrote: Dave Jones wrote: Some of the folks on our desktop team have been doing a bunch of experiments at getting boot times down, including laying out the blocks in a more optimal manner, allowing /sbin/readahead to slurp the data off the disk in one big chunk, and run almost entirely from cache. What are the cons of using all of the RAM at boot time to cache the boot disk? It's memory that's otherwise unused. Once you start using the system anything cached will get reclaimed as its needed. Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
What are the cons of using all of the RAM at boot time to cache the boot disk? Dave Jones wrote: It's memory that's otherwise unused. Once you start using the system anything cached will get reclaimed as its needed. So there is no substantial loss? IOW, it would suffice to have all the loaded at boot stuff in the first amount of RAM bytes of the hard disk? -- Giuseppe Oblomov Bilotta Can't you see It all makes perfect sense Expressed in dollar and cents Pounds shillings and pence (Roger Waters) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Wed, Mar 23, 2005 at 05:49:47PM +0100, Giuseppe Bilotta wrote: What are the cons of using all of the RAM at boot time to cache the boot disk? Dave Jones wrote: It's memory that's otherwise unused. Once you start using the system anything cached will get reclaimed as its needed. So there is no substantial loss? IOW, it would suffice to have all the loaded at boot stuff in the first amount of RAM bytes of the hard disk? It very likely also needs to be contiguous on-disk (Ie, no in-file fragmentation). You want to limit the amount of seeking that gets done so the drive readahead just performs continuous reads. Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Dave Jones <[EMAIL PROTECTED]> wrote: > > This old mail: http://marc.free.net.ph/message/20040304.030616.59761bf3.html > references a 'move block' ioctl, which is probably the hardest part of the > problem, > though I didn't find the code referenced in that mail. Andrew ? That would be http://www.zip.com.au/~akpm/ext3-reloc-page.patch Against 2.4.18, untested ;) > With something like this, and some additional bookkeeping to keep track of > which files we open in the first few minutes of uptime, we could periodically > reorganise the layout back to an optimal state. Fun project. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Tue, Mar 22, 2005 at 07:53:37PM -0500, Lee Revell wrote: > The solution is fairly well known. Rather than treating the zillions of > disk seeks during the boot process as random unconnected events, you > analyze the I/O done during the boot process, then lay out those disk > blocks optimally based on this information so on the next boot you just > do one big streaming read. The patent side has been discussed and there > seems to be plenty of prior art. > > Someone needs to just do it. All the required information is right > there. Some of the folks on our desktop team have been doing a bunch of experiments at getting boot times down, including laying out the blocks in a more optimal manner, allowing /sbin/readahead to slurp the data off the disk in one big chunk, and run almost entirely from cache. The results are quite impressive, though the absense of any kind of tool to reorganise the layout means that once a few packages are installed/removed, the layout is no longer optimal. This old mail: http://marc.free.net.ph/message/20040304.030616.59761bf3.html references a 'move block' ioctl, which is probably the hardest part of the problem, though I didn't find the code referenced in that mail. Andrew ? With something like this, and some additional bookkeeping to keep track of which files we open in the first few minutes of uptime, we could periodically reorganise the layout back to an optimal state. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote: > El Mon, 14 Mar 2005 14:07:53 -0500, > Lee Revell <[EMAIL PROTECTED]> escribió: > > > I'm really not trolling, but I suspect if we made the boot process less > > verbose, people would start to wonder more about why Linux takes so much > > longer than XP to boot. > > By the way, Microsoft seems to be claiming that boot time will be reduced to > the half > with Longhorn. While we already know how ms marketing team works, 50% looks > like a lot. Is there a good place to discuss what could be done in the > linuxland to > improve things? It doesn't looks like a couple of optimizations will be > enought... Make software suspend work 100% of the time and rename "resume" to "fastboot". -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: dmesg verbosity [was Re: AGP bogosities]
On Wed, 23 Mar 2005 01:37:29 +0100, Diego Calleja <[EMAIL PROTECTED]> wrote: >El Mon, 14 Mar 2005 14:07:53 -0500, >Lee Revell <[EMAIL PROTECTED]> escribió: > >> I'm really not trolling, but I suspect if we made the boot process less >> verbose, people would start to wonder more about why Linux takes so much >> longer than XP to boot. > >By the way, Microsoft seems to be claiming that boot time will be reduced to >the half >with Longhorn. While we already know how ms marketing team works, 50% looks >like a lot. Is there a good place to discuss what could be done in the >linuxland to >improve things? It doesn't looks like a couple of optimizations will be >enought... Considering msft don't do full options hardware detection until after GUI shell is up, next speed up could simply be start from hibernate? They already do a hardware signature, and if hardware changed you may need a new license anyway :-) Pay per cold boot? Noisy startup? 2.6 has good solution in default kernel build, display milestones during startup or super quiet loader option passed from boot? "dmesg -qq" thru "dmesg -vv" stir anyone? Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote: > El Mon, 14 Mar 2005 14:07:53 -0500, > Lee Revell <[EMAIL PROTECTED]> escribió: > > > I'm really not trolling, but I suspect if we made the boot process less > > verbose, people would start to wonder more about why Linux takes so much > > longer than XP to boot. > > By the way, Microsoft seems to be claiming that boot time will be reduced to > the half > with Longhorn. While we already know how ms marketing team works, 50% looks > like a lot. Is there a good place to discuss what could be done in the > linuxland to > improve things? It doesn't looks like a couple of optimizations will be > enought... > Yup, many people on this list seem unaware but read the XP white papers, then try booting it side by side with Linux. They put some serious, serious engineering into that problem and came out with a big win. Screw Longhorn, we need improve by 50% to catch up to what they can do NOW. The solution is fairly well known. Rather than treating the zillions of disk seeks during the boot process as random unconnected events, you analyze the I/O done during the boot process, then lay out those disk blocks optimally based on this information so on the next boot you just do one big streaming read. The patent side has been discussed and there seems to be plenty of prior art. Someone needs to just do it. All the required information is right there. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
El Mon, 14 Mar 2005 14:07:53 -0500, Lee Revell <[EMAIL PROTECTED]> escribió: > I'm really not trolling, but I suspect if we made the boot process less > verbose, people would start to wonder more about why Linux takes so much > longer than XP to boot. By the way, Microsoft seems to be claiming that boot time will be reduced to the half with Longhorn. While we already know how ms marketing team works, 50% looks like a lot. Is there a good place to discuss what could be done in the linuxland to improve things? It doesn't looks like a couple of optimizations will be enought... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
El Mon, 14 Mar 2005 14:07:53 -0500, Lee Revell [EMAIL PROTECTED] escribió: I'm really not trolling, but I suspect if we made the boot process less verbose, people would start to wonder more about why Linux takes so much longer than XP to boot. By the way, Microsoft seems to be claiming that boot time will be reduced to the half with Longhorn. While we already know how ms marketing team works, 50% looks like a lot. Is there a good place to discuss what could be done in the linuxland to improve things? It doesn't looks like a couple of optimizations will be enought... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote: El Mon, 14 Mar 2005 14:07:53 -0500, Lee Revell [EMAIL PROTECTED] escribió: I'm really not trolling, but I suspect if we made the boot process less verbose, people would start to wonder more about why Linux takes so much longer than XP to boot. By the way, Microsoft seems to be claiming that boot time will be reduced to the half with Longhorn. While we already know how ms marketing team works, 50% looks like a lot. Is there a good place to discuss what could be done in the linuxland to improve things? It doesn't looks like a couple of optimizations will be enought... Yup, many people on this list seem unaware but read the XP white papers, then try booting it side by side with Linux. They put some serious, serious engineering into that problem and came out with a big win. Screw Longhorn, we need improve by 50% to catch up to what they can do NOW. The solution is fairly well known. Rather than treating the zillions of disk seeks during the boot process as random unconnected events, you analyze the I/O done during the boot process, then lay out those disk blocks optimally based on this information so on the next boot you just do one big streaming read. The patent side has been discussed and there seems to be plenty of prior art. Someone needs to just do it. All the required information is right there. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Wed, 23 Mar 2005 01:37:29 +0100, Diego Calleja [EMAIL PROTECTED] wrote: El Mon, 14 Mar 2005 14:07:53 -0500, Lee Revell [EMAIL PROTECTED] escribió: I'm really not trolling, but I suspect if we made the boot process less verbose, people would start to wonder more about why Linux takes so much longer than XP to boot. By the way, Microsoft seems to be claiming that boot time will be reduced to the half with Longhorn. While we already know how ms marketing team works, 50% looks like a lot. Is there a good place to discuss what could be done in the linuxland to improve things? It doesn't looks like a couple of optimizations will be enought... Considering msft don't do full options hardware detection until after GUI shell is up, next speed up could simply be start from hibernate? They already do a hardware signature, and if hardware changed you may need a new license anyway :-) Pay per cold boot? Noisy startup? 2.6 has good solution in default kernel build, display milestones during startup or super quiet loader option passed from boot? dmesg -qq thru dmesg -vv stir anyone? Grant. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Wed, 2005-03-23 at 01:37 +0100, Diego Calleja wrote: El Mon, 14 Mar 2005 14:07:53 -0500, Lee Revell [EMAIL PROTECTED] escribió: I'm really not trolling, but I suspect if we made the boot process less verbose, people would start to wonder more about why Linux takes so much longer than XP to boot. By the way, Microsoft seems to be claiming that boot time will be reduced to the half with Longhorn. While we already know how ms marketing team works, 50% looks like a lot. Is there a good place to discuss what could be done in the linuxland to improve things? It doesn't looks like a couple of optimizations will be enought... Make software suspend work 100% of the time and rename resume to fastboot. -- Zan Lynx [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: dmesg verbosity [was Re: AGP bogosities]
On Tue, Mar 22, 2005 at 07:53:37PM -0500, Lee Revell wrote: The solution is fairly well known. Rather than treating the zillions of disk seeks during the boot process as random unconnected events, you analyze the I/O done during the boot process, then lay out those disk blocks optimally based on this information so on the next boot you just do one big streaming read. The patent side has been discussed and there seems to be plenty of prior art. Someone needs to just do it. All the required information is right there. Some of the folks on our desktop team have been doing a bunch of experiments at getting boot times down, including laying out the blocks in a more optimal manner, allowing /sbin/readahead to slurp the data off the disk in one big chunk, and run almost entirely from cache. The results are quite impressive, though the absense of any kind of tool to reorganise the layout means that once a few packages are installed/removed, the layout is no longer optimal. This old mail: http://marc.free.net.ph/message/20040304.030616.59761bf3.html references a 'move block' ioctl, which is probably the hardest part of the problem, though I didn't find the code referenced in that mail. Andrew ? With something like this, and some additional bookkeeping to keep track of which files we open in the first few minutes of uptime, we could periodically reorganise the layout back to an optimal state. Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Dave Jones [EMAIL PROTECTED] wrote: This old mail: http://marc.free.net.ph/message/20040304.030616.59761bf3.html references a 'move block' ioctl, which is probably the hardest part of the problem, though I didn't find the code referenced in that mail. Andrew ? That would be http://www.zip.com.au/~akpm/ext3-reloc-page.patch Against 2.4.18, untested ;) With something like this, and some additional bookkeeping to keep track of which files we open in the first few minutes of uptime, we could periodically reorganise the layout back to an optimal state. Fun project. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Mon, 14 Mar 2005, Lee Revell wrote: On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote: Why should people look at all that "horrid" debug info everytime they boot, except when they have a problem? I'm really not trolling, but I suspect if we made the boot process less verbose, people would start to wonder more about why Linux takes so much longer than XP to boot. two things 1. linux shouldn't take longer to boot then windows (and if properly configured it doesn't) 2. there's a _long_ way between the current situation where a driver can spew 500+ lines of logging and there being so little logging that people don't know what's going on. if you are on a slow console (say a serial console) just letting the boot messages scroll by can take quite a while today. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Mon, 14 Mar 2005, Lee Revell wrote: On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote: Why should people look at all that horrid debug info everytime they boot, except when they have a problem? I'm really not trolling, but I suspect if we made the boot process less verbose, people would start to wonder more about why Linux takes so much longer than XP to boot. two things 1. linux shouldn't take longer to boot then windows (and if properly configured it doesn't) 2. there's a _long_ way between the current situation where a driver can spew 500+ lines of logging and there being so little logging that people don't know what's going on. if you are on a slow console (say a serial console) just letting the boot messages scroll by can take quite a while today. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Linus Torvalds <[EMAIL PROTECTED]> writes: > And those occasional people are often not going to eb very good at > reporting bugs. If they don't see anything happening, they'll just give up > rather than bother to report it. So I do think we want the fairly verbose > thing enabled by default. You can then hide it with the graphical bootup > for "most people". Loading the usb drivers on my machine dumps 155 lines into dmesg. Surely that's a bit excessive? But really for me it's the network drivers that actually annoy me. They dump stuff into dmesg during the regular course of operation. As a result it doesn't take long until the boot messages leave the buffer. Of course they're in the log files, but running dmesg and getting screenfulls of the same messages about boring network events over and over just annoys me. -- greg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Linus Torvalds [EMAIL PROTECTED] writes: And those occasional people are often not going to eb very good at reporting bugs. If they don't see anything happening, they'll just give up rather than bother to report it. So I do think we want the fairly verbose thing enabled by default. You can then hide it with the graphical bootup for most people. Loading the usb drivers on my machine dumps 155 lines into dmesg. Surely that's a bit excessive? But really for me it's the network drivers that actually annoy me. They dump stuff into dmesg during the regular course of operation. As a result it doesn't take long until the boot messages leave the buffer. Of course they're in the log files, but running dmesg and getting screenfulls of the same messages about boring network events over and over just annoys me. -- greg - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Hi! > > We already have the 'quiet' option, but even so, I think the kernel is > > *way* > > too verbose. Someone needs to make a personal crusade out of removing > > unneeded and unjustified printks from the kernel before it really gets > > better > > though... > > Oh well, I admit going backward here with my new radeonfb which will be > very verbose in a first release, but that will be necessary to track > down all the various issues with monitor detection, BIOSes telling crap > about connectors etc... I'd say that's okay, as long as you remove the messages afterwards. Perhaps "cleanup printks just before you remove dependency on CONFIG_EXPERIMENTAL is right thing to require"? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Tue, 15 Mar 2005, Benjamin Herrenschmidt wrote: We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... Oh well, I admit going backward here with my new radeonfb which will be very verbose in a first release, but that will be necessary to track down all the various issues with monitor detection, BIOSes telling crap about connectors etc... This isn't the problem, the fact that if I have all the encryption modes turned on I get several hundred lines of output telling me that it tested the encryption and got the result it expected is. you are turning up the verbosity becouse it's needed, if you don't turn it down in a few releases (assuming you fix the problems by then ;-) then you would become part of the problem. back in the 1.3/2.0 days when I started useing linux I was a PC repair technition and when working on the windows PC's I would use a linux boot disk to identify the hardware that was in the machine based on the dmesg output (and the ports things were on) so that I could configure the windows drivers. So it's not that I can't understand the value of the dmesg output, it's that there is now so much additional data that it's no longer reasonable to see what's going on. when the boot dmesg output overflows the 500 line buffer of a VGA console so that you can not scroll back and see the messages by the time the system starts things have gotten too verbose. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
> We already have the 'quiet' option, but even so, I think the kernel is *way* > too verbose. Someone needs to make a personal crusade out of removing > unneeded and unjustified printks from the kernel before it really gets better > though... Oh well, I admit going backward here with my new radeonfb which will be very verbose in a first release, but that will be necessary to track down all the various issues with monitor detection, BIOSes telling crap about connectors etc... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
[trimming cc list in case this starts a flame war) On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote: > Why should people look at all that "horrid" debug info everytime > they boot, except when they have a problem? I'm really not trolling, but I suspect if we made the boot process less verbose, people would start to wonder more about why Linux takes so much longer than XP to boot. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
El Mon, 14 Mar 2005 08:55:18 -0800, Jesse Barnes <[EMAIL PROTECTED]> escribió: > We already have the 'quiet' option, but even so, I think the kernel is *way* > too verbose. Someone needs to make a personal crusade out of removing > unneeded and unjustified printks from the kernel before it really gets better > though... But people who wants to know what has been and what hasn't been detected should start looking at sysfs, shouldn't them?. dmesg is not reliable *at all*, sometimes when you rmmod something, it doesn't put anything in dmesg, but it did when it was loaded, so you'll see some messaje in the printk saying "foo was loaded", but it isn't really loaded Personally I don't use dmesg anymore to look "what devices are being handled by the kernel", just sysfs and /proc files. I only look at dmesg when "something goes wrong" and it doesn't works properly. IMHO dmesg in linux is just a "debug tool" (unlike the BSDs, who seem to have very strict rules for dmesg messages) and it's nice that it's verbose, and it could even be "quiet" by default - people who have problems and can't look at sysfs could add a "noquiet" boot option or run dmesg if it boots. IIRC is what solaris and other people do by default. Why should people look at all that "horrid" debug info everytime they boot, except when they have a problem? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Hi! > > We already have the 'quiet' option, but even so, I think the kernel is > > *way* > > too verbose. Someone needs to make a personal crusade out of removing > > unneeded and unjustified printks from the kernel before it really gets > > better > > though... > > The thing is, this comes up every once in a while (pretty often, > actually), but the bulk of those messages _do_ end up being useful. For > certain classes of bugs, I almost invariably ask for the bootup messages: > the PCI interrupt routing printou stuff is absolutely invaluable. > > In fact, even the ones that have no "information" end up often being a big > clue about where the hang happened. Problem is that by now we have so much information that valuable scrolls up. Users start to missing trace dumps in bootup phase because it just scrolls away too quickly. I know that "no information" messages can be valuable, but they make messages with usefull information less likely to be noticed. And people start doing ugly stuff like *** This is really *** important message when they want their messages to be actually seen. Perhaps we should reduce ammount of that "no information" messages? I particulary hate "XXX driver registered" even when that driver has no hardware. Kernel is quite unlikely to hang at that point. > And those occasional people are often not going to eb very good at > reporting bugs. If they don't see anything happening, they'll just give up > rather than bother to report it. So I do think we want the fairly verbose > thing enabled by default. You can then hide it with the graphical bootup > for "most people". Does it mean that fbsplash done right would be ok for mainline? ;-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Monday, March 14, 2005 9:18 am, Linus Torvalds wrote: > In fact, even the ones that have no "information" end up often being a big > clue about where the hang happened. Yeah, I use the startup output all the time for stuff like that, no question it's useful. > And those occasional people are often not going to eb very good at > reporting bugs. If they don't see anything happening, they'll just give up > rather than bother to report it. So I do think we want the fairly verbose > thing enabled by default. You can then hide it with the graphical bootup > for "most people". Ok, and for the development kernel that makes a lot of sense. But as we've seen from this thread, leaving in old printks that were once useful but no longer are tends to clutter things up and hide real errors. I'd like to see us get better about that--reporting real errors better and keeping the junk to a minimum. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Mon, Mar 14, 2005 at 08:55:18AM -0800, Jesse Barnes wrote: > On Monday, March 14, 2005 12:37 am, Pavel Machek wrote: > > Perhaps we could have a rule like > > > > "non-experimental driver may only print out one line per actual > > device?" > > > > (and perhaps: dmesg output for boot going okay should fit on one screen). > > > > Or perhaps we should have warnings-like regression testing. > > > > "New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg > > junk". > > Pavel > > We already have the 'quiet' option, but even so, I think the kernel is *way* > too verbose. Someone needs to make a personal crusade out of removing > unneeded and unjustified printks from the kernel before it really gets > better > though... As long as the patches to remove/quiten various texts go through the various subsystem maintainers, this shouldn't be a problem, though I imagine there will be some resistance to some parts. One of the biggest offenders is ACPI. On my desktop, that alone accounts for 10% of the messages since boot. (12:05:09:[EMAIL PROTECTED]:~)$ dmesg -s 128000 | grep ^ACPI | wc -l 50 (12:05:18:[EMAIL PROTECTED]:~)$ dmesg -s 128000 | wc -l 500 On SMP there's way too much noise. We could do some checks in the CPU init code to not print any of the init junk if its the same as the boot CPU. That should be fairly trivial, and would reduce quite a few messages. Of the 500 messages in my dmesg scrollback right now, 412 of them are unique. Removing some of this duplication sounds like an excellent place to begin. Another way to save some text could be to cluster multiple lines so that instead of.. ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. we have ACPI: IRQs 0,2,9 used by override. (Whatever the hell that message means anyway -- this one just used as an example). Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Mon, 14 Mar 2005, Jesse Barnes wrote: > > We already have the 'quiet' option, but even so, I think the kernel is *way* > too verbose. Someone needs to make a personal crusade out of removing > unneeded and unjustified printks from the kernel before it really gets better > though... The thing is, this comes up every once in a while (pretty often, actually), but the bulk of those messages _do_ end up being useful. For certain classes of bugs, I almost invariably ask for the bootup messages: the PCI interrupt routing printou stuff is absolutely invaluable. In fact, even the ones that have no "information" end up often being a big clue about where the hang happened. So yes, when things work (and hey, that's happily 99.9% of the time) they are almost all worthless. But just _one_ case where they help is a big deal. So don't say "most people don't care", because that is a totally irrelevant argument. It's not "most people" who matter. It's not even kernel developers who matter - they can know how to enable the stuff if they ever see a problem. The _only_ people who matter are the very occasional regular users that see problems. And those occasional people are often not going to eb very good at reporting bugs. If they don't see anything happening, they'll just give up rather than bother to report it. So I do think we want the fairly verbose thing enabled by default. You can then hide it with the graphical bootup for "most people". Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Hi! > > "non-experimental driver may only print out one line per actual > > device?" > > > > (and perhaps: dmesg output for boot going okay should fit on one screen). > > > > Or perhaps we should have warnings-like regression testing. > > > > "New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg > > junk". > > Pavel > > We already have the 'quiet' option, but even so, I think the kernel is *way* > too verbose. Someone needs to make a personal crusade out of removing > unneeded and unjustified printks from the kernel before it really gets better > though... I know about "quiet". You can 2> /dev/null on warnings, too ;-), and quiet is quite equivalent... And I'm about fed enough to start that personal crusade. OTOH "POSIX conformance testing by UniFix" is gone now ;-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Monday, March 14, 2005 12:37 am, Pavel Machek wrote: > Perhaps we could have a rule like > > "non-experimental driver may only print out one line per actual > device?" > > (and perhaps: dmesg output for boot going okay should fit on one screen). > > Or perhaps we should have warnings-like regression testing. > > "New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg > junk". > Pavel We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dmesg verbosity [was Re: AGP bogosities]
Hi! > >>I'm fascinated that not a single person picked up on this problem > >>whilst the agp code sat in -mm. Even if DRI isn't enabled, > >>every box out there with AGP that uses the generic routines > >>(which is a majority), should have barfed loudly when it hit > >>this check during boot. Does no-one read dmesg output any more ? > > > >Its way too long these days. Like "so long it overflows even enlarged > >buffer". We should prune these messages down to "one line per hw > >device or serious problems only". > > especially if you turn on encryption options. I can understand that output > being useful for debugging, but there should be a way to not deal with it > in the normal case. Perhaps we could have a rule like "non-experimental driver may only print out one line per actual device?" (and perhaps: dmesg output for boot going okay should fit on one screen). Or perhaps we should have warnings-like regression testing. "New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg junk". Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Mon, 14 Mar 2005, Pavel Machek wrote: I'm fascinated that not a single person picked up on this problem whilst the agp code sat in -mm. Even if DRI isn't enabled, every box out there with AGP that uses the generic routines (which is a majority), should have barfed loudly when it hit this check during boot. Does no-one read dmesg output any more ? Its way too long these days. Like "so long it overflows even enlarged buffer". We should prune these messages down to "one line per hw device or serious problems only". especially if you turn on encryption options. I can understand that output being useful for debugging, but there should be a way to not deal with it in the normal case. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Pá 11-03-05 17:26:14, Dave Jones wrote: > On Sat, Mar 12, 2005 at 07:18:19AM +0900, OGAWA Hirofumi wrote: > > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > > > Hmm.. We seem to not have any tests for the counts becoming negative, and > > > this would seem to be an easy mistake to make considering that both I > and > > > Dave did it. > > > > I stole this from -mm. > > I'm fascinated that not a single person picked up on this problem > whilst the agp code sat in -mm. Even if DRI isn't enabled, > every box out there with AGP that uses the generic routines > (which is a majority), should have barfed loudly when it hit > this check during boot. Does no-one read dmesg output any more ? Its way too long these days. Like "so long it overflows even enlarged buffer". We should prune these messages down to "one line per hw device or serious problems only". Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Pá 11-03-05 17:26:14, Dave Jones wrote: On Sat, Mar 12, 2005 at 07:18:19AM +0900, OGAWA Hirofumi wrote: Linus Torvalds [EMAIL PROTECTED] writes: Hmm.. We seem to not have any tests for the counts becoming negative, and this would seem to be an easy mistake to make considering that both I and Dave did it. I stole this from -mm. I'm fascinated that not a single person picked up on this problem whilst the agp code sat in -mm. Even if DRI isn't enabled, every box out there with AGP that uses the generic routines (which is a majority), should have barfed loudly when it hit this check during boot. Does no-one read dmesg output any more ? Its way too long these days. Like so long it overflows even enlarged buffer. We should prune these messages down to one line per hw device or serious problems only. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Mon, 14 Mar 2005, Pavel Machek wrote: I'm fascinated that not a single person picked up on this problem whilst the agp code sat in -mm. Even if DRI isn't enabled, every box out there with AGP that uses the generic routines (which is a majority), should have barfed loudly when it hit this check during boot. Does no-one read dmesg output any more ? Its way too long these days. Like so long it overflows even enlarged buffer. We should prune these messages down to one line per hw device or serious problems only. especially if you turn on encryption options. I can understand that output being useful for debugging, but there should be a way to not deal with it in the normal case. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dmesg verbosity [was Re: AGP bogosities]
Hi! I'm fascinated that not a single person picked up on this problem whilst the agp code sat in -mm. Even if DRI isn't enabled, every box out there with AGP that uses the generic routines (which is a majority), should have barfed loudly when it hit this check during boot. Does no-one read dmesg output any more ? Its way too long these days. Like so long it overflows even enlarged buffer. We should prune these messages down to one line per hw device or serious problems only. especially if you turn on encryption options. I can understand that output being useful for debugging, but there should be a way to not deal with it in the normal case. Perhaps we could have a rule like non-experimental driver may only print out one line per actual device? (and perhaps: dmesg output for boot going okay should fit on one screen). Or perhaps we should have warnings-like regression testing. New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg junk. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Monday, March 14, 2005 12:37 am, Pavel Machek wrote: Perhaps we could have a rule like non-experimental driver may only print out one line per actual device? (and perhaps: dmesg output for boot going okay should fit on one screen). Or perhaps we should have warnings-like regression testing. New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg junk. Pavel We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Hi! non-experimental driver may only print out one line per actual device? (and perhaps: dmesg output for boot going okay should fit on one screen). Or perhaps we should have warnings-like regression testing. New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg junk. Pavel We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... I know about quiet. You can 2 /dev/null on warnings, too ;-), and quiet is quite equivalent... And I'm about fed enough to start that personal crusade. OTOH POSIX conformance testing by UniFix is gone now ;-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Mon, 14 Mar 2005, Jesse Barnes wrote: We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... The thing is, this comes up every once in a while (pretty often, actually), but the bulk of those messages _do_ end up being useful. For certain classes of bugs, I almost invariably ask for the bootup messages: the PCI interrupt routing printou stuff is absolutely invaluable. In fact, even the ones that have no information end up often being a big clue about where the hang happened. So yes, when things work (and hey, that's happily 99.9% of the time) they are almost all worthless. But just _one_ case where they help is a big deal. So don't say most people don't care, because that is a totally irrelevant argument. It's not most people who matter. It's not even kernel developers who matter - they can know how to enable the stuff if they ever see a problem. The _only_ people who matter are the very occasional regular users that see problems. And those occasional people are often not going to eb very good at reporting bugs. If they don't see anything happening, they'll just give up rather than bother to report it. So I do think we want the fairly verbose thing enabled by default. You can then hide it with the graphical bootup for most people. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Mon, Mar 14, 2005 at 08:55:18AM -0800, Jesse Barnes wrote: On Monday, March 14, 2005 12:37 am, Pavel Machek wrote: Perhaps we could have a rule like non-experimental driver may only print out one line per actual device? (and perhaps: dmesg output for boot going okay should fit on one screen). Or perhaps we should have warnings-like regression testing. New kernel 2.8.17 came: 3 errors, 135 warnings, 1890 lines of dmesg junk. Pavel We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... As long as the patches to remove/quiten various texts go through the various subsystem maintainers, this shouldn't be a problem, though I imagine there will be some resistance to some parts. One of the biggest offenders is ACPI. On my desktop, that alone accounts for 10% of the messages since boot. (12:05:09:[EMAIL PROTECTED]:~)$ dmesg -s 128000 | grep ^ACPI | wc -l 50 (12:05:18:[EMAIL PROTECTED]:~)$ dmesg -s 128000 | wc -l 500 On SMP there's way too much noise. We could do some checks in the CPU init code to not print any of the init junk if its the same as the boot CPU. That should be fairly trivial, and would reduce quite a few messages. Of the 500 messages in my dmesg scrollback right now, 412 of them are unique. Removing some of this duplication sounds like an excellent place to begin. Another way to save some text could be to cluster multiple lines so that instead of.. ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. we have ACPI: IRQs 0,2,9 used by override. (Whatever the hell that message means anyway -- this one just used as an example). Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Monday, March 14, 2005 9:18 am, Linus Torvalds wrote: In fact, even the ones that have no information end up often being a big clue about where the hang happened. Yeah, I use the startup output all the time for stuff like that, no question it's useful. And those occasional people are often not going to eb very good at reporting bugs. If they don't see anything happening, they'll just give up rather than bother to report it. So I do think we want the fairly verbose thing enabled by default. You can then hide it with the graphical bootup for most people. Ok, and for the development kernel that makes a lot of sense. But as we've seen from this thread, leaving in old printks that were once useful but no longer are tends to clutter things up and hide real errors. I'd like to see us get better about that--reporting real errors better and keeping the junk to a minimum. Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Hi! We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... The thing is, this comes up every once in a while (pretty often, actually), but the bulk of those messages _do_ end up being useful. For certain classes of bugs, I almost invariably ask for the bootup messages: the PCI interrupt routing printou stuff is absolutely invaluable. In fact, even the ones that have no information end up often being a big clue about where the hang happened. Problem is that by now we have so much information that valuable scrolls up. Users start to missing trace dumps in bootup phase because it just scrolls away too quickly. I know that no information messages can be valuable, but they make messages with usefull information less likely to be noticed. And people start doing ugly stuff like *** This is really *** important message when they want their messages to be actually seen. Perhaps we should reduce ammount of that no information messages? I particulary hate XXX driver registered even when that driver has no hardware. Kernel is quite unlikely to hang at that point. And those occasional people are often not going to eb very good at reporting bugs. If they don't see anything happening, they'll just give up rather than bother to report it. So I do think we want the fairly verbose thing enabled by default. You can then hide it with the graphical bootup for most people. Does it mean that fbsplash done right would be ok for mainline? ;-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
El Mon, 14 Mar 2005 08:55:18 -0800, Jesse Barnes [EMAIL PROTECTED] escribió: We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... But people who wants to know what has been and what hasn't been detected should start looking at sysfs, shouldn't them?. dmesg is not reliable *at all*, sometimes when you rmmod something, it doesn't put anything in dmesg, but it did when it was loaded, so you'll see some messaje in the printk saying foo was loaded, but it isn't really loaded Personally I don't use dmesg anymore to look what devices are being handled by the kernel, just sysfs and /proc files. I only look at dmesg when something goes wrong and it doesn't works properly. IMHO dmesg in linux is just a debug tool (unlike the BSDs, who seem to have very strict rules for dmesg messages) and it's nice that it's verbose, and it could even be quiet by default - people who have problems and can't look at sysfs could add a noquiet boot option or run dmesg if it boots. IIRC is what solaris and other people do by default. Why should people look at all that horrid debug info everytime they boot, except when they have a problem? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
[trimming cc list in case this starts a flame war) On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote: Why should people look at all that horrid debug info everytime they boot, except when they have a problem? I'm really not trolling, but I suspect if we made the boot process less verbose, people would start to wonder more about why Linux takes so much longer than XP to boot. Lee - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... Oh well, I admit going backward here with my new radeonfb which will be very verbose in a first release, but that will be necessary to track down all the various issues with monitor detection, BIOSes telling crap about connectors etc... Ben. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
On Tue, 15 Mar 2005, Benjamin Herrenschmidt wrote: We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... Oh well, I admit going backward here with my new radeonfb which will be very verbose in a first release, but that will be necessary to track down all the various issues with monitor detection, BIOSes telling crap about connectors etc... This isn't the problem, the fact that if I have all the encryption modes turned on I get several hundred lines of output telling me that it tested the encryption and got the result it expected is. you are turning up the verbosity becouse it's needed, if you don't turn it down in a few releases (assuming you fix the problems by then ;-) then you would become part of the problem. back in the 1.3/2.0 days when I started useing linux I was a PC repair technition and when working on the windows PC's I would use a linux boot disk to identify the hardware that was in the machine based on the dmesg output (and the ports things were on) so that I could configure the windows drivers. So it's not that I can't understand the value of the dmesg output, it's that there is now so much additional data that it's no longer reasonable to see what's going on. when the boot dmesg output overflows the 500 line buffer of a VGA console so that you can not scroll back and see the messages by the time the system starts things have gotten too verbose. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dmesg verbosity [was Re: AGP bogosities]
Hi! We already have the 'quiet' option, but even so, I think the kernel is *way* too verbose. Someone needs to make a personal crusade out of removing unneeded and unjustified printks from the kernel before it really gets better though... Oh well, I admit going backward here with my new radeonfb which will be very verbose in a first release, but that will be necessary to track down all the various issues with monitor detection, BIOSes telling crap about connectors etc... I'd say that's okay, as long as you remove the messages afterwards. Perhaps cleanup printks just before you remove dependency on CONFIG_EXPERIMENTAL is right thing to require? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Sat, Mar 12, 2005 at 11:08:20PM -0500, Dave Jones wrote: > On Sat, Mar 12, 2005 at 07:13:05PM -0800, Jesse Barnes wrote: > > On Friday, March 11, 2005 7:58 pm, Dave Jones wrote: > > > > sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was > waiting > > > > for the TIO header files to make it from the ia64 tree into Linus's > > > > tree. > > > > > > Actually I just got swamped with other stuff, and dropped the ball. > > > I still have the patch in my queue though, so I can push that along. > > > > > > Are those headers in mainline yet ? > > > > Yeah, I think it's all there now. Looks like Linus did a pull from ia64 > > recently, so it *should* all build. > > Ok, pushed out to bk://linux-djb.bkbits.net/agpgart Erk, Personality crisis, or an unfortunate typo. s/djb/dj/ obviously. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Sat, Mar 12, 2005 at 07:13:05PM -0800, Jesse Barnes wrote: > On Friday, March 11, 2005 7:58 pm, Dave Jones wrote: > > > sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was waiting > > > for the TIO header files to make it from the ia64 tree into Linus's > > > tree. > > > > Actually I just got swamped with other stuff, and dropped the ball. > > I still have the patch in my queue though, so I can push that along. > > > > Are those headers in mainline yet ? > > Yeah, I think it's all there now. Looks like Linus did a pull from ia64 > recently, so it *should* all build. Ok, pushed out to bk://linux-djb.bkbits.net/agpgart Linus, please pull. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Friday, March 11, 2005 7:58 pm, Dave Jones wrote: > > sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was waiting > > for the TIO header files to make it from the ia64 tree into Linus's > > tree. > > Actually I just got swamped with other stuff, and dropped the ball. > I still have the patch in my queue though, so I can push that along. > > Are those headers in mainline yet ? Yeah, I think it's all there now. Looks like Linus did a pull from ia64 recently, so it *should* all build. Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Thu, Mar 10, 2005 at 09:49:53PM -0500, Dave Jones wrote: > On Fri, Mar 11, 2005 at 01:40:24PM +1100, Benjamin Herrenschmidt wrote: > > > > > After it does that pci_dev_put on the from, it does another pci_dev_get > > > on 'dev', which is what my put was releasing. > > > > > > Or am I terribly confused ? > > > > Well, pci_get_class() put's the passed-in device and get's() the > > returned one. So if you run it in a loop, you should never have to > > either get or put. When you exit the loop with a valid pci_dev, though, > > you should definitely put() it after you're done with it, but this is > > something that should be done only for that specific instance and after > > you are finished with it... > > Yeah. Makes perfect sense now I've had it spelled out for me :-) > I think Linus is right though that some extra bullet-proofing in kref_put > to BUG() if it goes negative would've caught this. I wonder if anyone > else has fallen into this trap. It can't go negative. If it hits zero, the object is freed and cleaned up. If you have slab debugging enabled, the next time you try to access this pointer, boom. So no atomic negative checks will help with kref/kobject code, sorry. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Sun, 13 Mar 2005, OGAWA Hirofumi wrote: > > However, inode->i_writecount and some stuffs seems to be already using > the negative values (or sparc was used the signed 24 bits value). > > Anyway, unfortunately inode->i_writecount triggered in atomic_dec(). Ahh, you're right. Thanks for testing it out, Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
Linus Torvalds <[EMAIL PROTECTED]> writes: > Btw, this should probably check for negative 32-bit values too, ie the > test should probably be > > if ((int)atomic_read(v) <= 0) > > and it should probably be done for the regular atomic_dec() etc cases too, > not just the dec-and-test. "atomic" values simply aren't historically > well-defined for negative values (sparc used to limit them to 24 bits), so > a negative thing would always be a bug, I think. However, inode->i_writecount and some stuffs seems to be already using the negative values (or sparc was used the signed 24 bits value). Anyway, unfortunately inode->i_writecount triggered in atomic_dec(). Thanks. -- OGAWA Hirofumi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Sat, 12 Mar 2005, OGAWA Hirofumi wrote:
>
> diff -puN include/asm-i386/atomic.h~detect-atomic-counter-underflows
> include/asm-i386/atomic.h
> --- 25/include/asm-i386/atomic.h~detect-atomic-counter-underflows Wed Nov
> 3 15:27:37 2004
> +++ 25-akpm/include/asm-i386/atomic.h Wed Nov 3 15:27:37 2004
> @@ -132,6 +132,10 @@ static __inline__ int atomic_dec_and_tes
> {
> unsigned char c;
>
> + if (!atomic_read(v)) {
> + printk("BUG: atomic counter underflow at:\n");
> + dump_stack();
> + }
Btw, this should probably check for negative 32-bit values too, ie the
test should probably be
if ((int)atomic_read(v) <= 0)
and it should probably be done for the regular atomic_dec() etc cases too,
not just the dec-and-test. "atomic" values simply aren't historically
well-defined for negative values (sparc used to limit them to 24 bits), so
a negative thing would always be a bug, I think.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Sat, Mar 12, 2005 at 07:13:05PM -0800, Jesse Barnes wrote: On Friday, March 11, 2005 7:58 pm, Dave Jones wrote: sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was waiting for the TIO header files to make it from the ia64 tree into Linus's tree. Actually I just got swamped with other stuff, and dropped the ball. I still have the patch in my queue though, so I can push that along. Are those headers in mainline yet ? Yeah, I think it's all there now. Looks like Linus did a pull from ia64 recently, so it *should* all build. Ok, pushed out to bk://linux-djb.bkbits.net/agpgart Linus, please pull. Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Sat, Mar 12, 2005 at 11:08:20PM -0500, Dave Jones wrote: On Sat, Mar 12, 2005 at 07:13:05PM -0800, Jesse Barnes wrote: On Friday, March 11, 2005 7:58 pm, Dave Jones wrote: sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was waiting for the TIO header files to make it from the ia64 tree into Linus's tree. Actually I just got swamped with other stuff, and dropped the ball. I still have the patch in my queue though, so I can push that along. Are those headers in mainline yet ? Yeah, I think it's all there now. Looks like Linus did a pull from ia64 recently, so it *should* all build. Ok, pushed out to bk://linux-djb.bkbits.net/agpgart Erk, Personality crisis, or an unfortunate typo. s/djb/dj/ obviously. Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Sat, 12 Mar 2005, OGAWA Hirofumi wrote:
diff -puN include/asm-i386/atomic.h~detect-atomic-counter-underflows
include/asm-i386/atomic.h
--- 25/include/asm-i386/atomic.h~detect-atomic-counter-underflows Wed Nov
3 15:27:37 2004
+++ 25-akpm/include/asm-i386/atomic.h Wed Nov 3 15:27:37 2004
@@ -132,6 +132,10 @@ static __inline__ int atomic_dec_and_tes
{
unsigned char c;
+ if (!atomic_read(v)) {
+ printk(BUG: atomic counter underflow at:\n);
+ dump_stack();
+ }
Btw, this should probably check for negative 32-bit values too, ie the
test should probably be
if ((int)atomic_read(v) = 0)
and it should probably be done for the regular atomic_dec() etc cases too,
not just the dec-and-test. atomic values simply aren't historically
well-defined for negative values (sparc used to limit them to 24 bits), so
a negative thing would always be a bug, I think.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
Linus Torvalds [EMAIL PROTECTED] writes: Btw, this should probably check for negative 32-bit values too, ie the test should probably be if ((int)atomic_read(v) = 0) and it should probably be done for the regular atomic_dec() etc cases too, not just the dec-and-test. atomic values simply aren't historically well-defined for negative values (sparc used to limit them to 24 bits), so a negative thing would always be a bug, I think. However, inode-i_writecount and some stuffs seems to be already using the negative values (or sparc was used the signed 24 bits value). Anyway, unfortunately inode-i_writecount triggered in atomic_dec(). Thanks. -- OGAWA Hirofumi [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Sun, 13 Mar 2005, OGAWA Hirofumi wrote: However, inode-i_writecount and some stuffs seems to be already using the negative values (or sparc was used the signed 24 bits value). Anyway, unfortunately inode-i_writecount triggered in atomic_dec(). Ahh, you're right. Thanks for testing it out, Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Thu, Mar 10, 2005 at 09:49:53PM -0500, Dave Jones wrote: On Fri, Mar 11, 2005 at 01:40:24PM +1100, Benjamin Herrenschmidt wrote: After it does that pci_dev_put on the from, it does another pci_dev_get on 'dev', which is what my put was releasing. Or am I terribly confused ? Well, pci_get_class() put's the passed-in device and get's() the returned one. So if you run it in a loop, you should never have to either get or put. When you exit the loop with a valid pci_dev, though, you should definitely put() it after you're done with it, but this is something that should be done only for that specific instance and after you are finished with it... Yeah. Makes perfect sense now I've had it spelled out for me :-) I think Linus is right though that some extra bullet-proofing in kref_put to BUG() if it goes negative would've caught this. I wonder if anyone else has fallen into this trap. It can't go negative. If it hits zero, the object is freed and cleaned up. If you have slab debugging enabled, the next time you try to access this pointer, boom. So no atomic negative checks will help with kref/kobject code, sorry. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Friday, March 11, 2005 7:58 pm, Dave Jones wrote: sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was waiting for the TIO header files to make it from the ia64 tree into Linus's tree. Actually I just got swamped with other stuff, and dropped the ball. I still have the patch in my queue though, so I can push that along. Are those headers in mainline yet ? Yeah, I think it's all there now. Looks like Linus did a pull from ia64 recently, so it *should* all build. Thanks, Jesse - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri Mar 11 2005 - 18:30:03 EST Bjorn Helgaas wrote: > On Sat, 2005-03-12 at 09:43 +1100, Paul Mackerras wrote: > > On PPC/PPC64 machines, the host bridges generally do not appear as PCI > > devices either. *However*, the AGP spec requires a set of registers > > in PCI config space for controlling the target (host) side of the AGP > > bus. In other words you are required to have a PCI device to > > represent the host side of the AGP bus, with a capability structure > > in > > its config space which contains the standard AGP registers. > > I still don't quite understand this. If the host bridge is not a > PCI device, what PCI device contains the AGP capability that controls > the host bridge? I assume you're saying that you are required to > have TWO PCI devices that have the AGP capability, one for the AGP > device and one for the bridge. Note that the PPC processor bus can connect to multiple "north bridges" (or other PPCs) at the same time. It's not a point-to-point bus. It sounds like the AGP bridge in question sits directly on the processor bus, in which case there would not necessarily be any equivalent to the PCI configuration registers for the bridge itself. Does anyone know offhand what part number this AGP bridge is or who makes it? ken - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri, Mar 11, 2005 at 07:27:04PM -0800, Mike Werner wrote: > On Friday 11 March 2005 10:04, Jesse Barnes wrote: > > On Friday, March 11, 2005 9:59 am, Bjorn Helgaas wrote: > > > > Right, it's a special agp driver, sgi-agp.c. > > > > > > Where's sgi-agp.c? The HP (ia64-only at the moment) code is hp-agp.c. > > > It does make a fake PCI dev for the bridge because DRM still seemed to > > > want that. > > > > I think Mike posted it but hasn't submitted it to Dave yet since it needed > > another change that only just made it into the ia64 tree. > > > > Jesse > > > Hi, > sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was waiting for > the TIO header > files to make it from the ia64 tree into Linus's tree. Actually I just got swamped with other stuff, and dropped the ball. I still have the patch in my queue though, so I can push that along. Are those headers in mainline yet ? Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Friday 11 March 2005 10:04, Jesse Barnes wrote: > On Friday, March 11, 2005 9:59 am, Bjorn Helgaas wrote: > > > Right, it's a special agp driver, sgi-agp.c. > > > > Where's sgi-agp.c? The HP (ia64-only at the moment) code is hp-agp.c. > > It does make a fake PCI dev for the bridge because DRM still seemed to > > want that. > > I think Mike posted it but hasn't submitted it to Dave yet since it needed > another change that only just made it into the ia64 tree. > > Jesse > Hi, sgi-agp.c was sent to Dave about 2 weeks ago. I assumed he was waiting for the TIO header files to make it from the ia64 tree into Linus's tree. Yours, Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
Bjorn Helgaas writes: > I still don't quite understand this. If the host bridge is not a > PCI device, what PCI device contains the AGP capability that controls > the host bridge? I assume you're saying that you are required to The AGP spec shows an example northbridge implementation that has the AGP interface circuitry as a PCI-to-PCI bridge. You don't have to do it that way, but in any case you need some sort of PCI device to represent the target (host) end of the AGP link. > have TWO PCI devices that have the AGP capability, one for the AGP > device and one for the bridge. Yes, exactly. > HP boxes certainly don't have that (zx6000 sample below). I guess > it wouldn't be the first time we deviated from a spec ;-) > > Can you point me to the relevant section? In the AGP 2.0 spec, the clearest statement I can find is in section 6.1.5, on page 248, where it says "Configuration registers are used by the operating system to initialize A.G.P. features. These features must be supported by both A.G.P. master and target devices in the following registers.", followed by a description of various PCI config space registers. In the context, "configuration registers" means registers in the config space of a PCI device. The AGP 3.0 spec is a delta from the AGP 2.0 spec and doesn't revoke that requirement anywhere that I could see. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
> I still don't quite understand this. If the host bridge is not a > PCI device, what PCI device contains the AGP capability that controls > the host bridge? I assume you're saying that you are required to > have TWO PCI devices that have the AGP capability, one for the AGP > device and one for the bridge. > > HP boxes certainly don't have that (zx6000 sample below). I guess > it wouldn't be the first time we deviated from a spec ;-) We are basically hitting a "hole" in the PCI spec itself :) It doesn't really defines how a host bridge can expose itself as a device. That means that in most cases, the host bridge either isn't visible at all, or is as a random device at the first level (which makes it a sibling of other devices, quite broken ). Also, there is no standard "devfn" for it, so it can be anywhere and there is no "simple" way of knowing which devie is actually the host in a generic way. Most of the time, looking for a devie with the class "host bridge" will work, but it's not guaranteed. Some hosts also expose the AGP stuff differently. In some cases, like Apple U3 HT host, it also has a set of registers that mimmic a PCI config space, but aren't implemented in the PCI config space proper, and thus, unless you add special case to your pci_ops, you won't see it on the bus. (Apple's AGP host appears as a device on it's own bus though). So while AGP requires a set of PCI config space registers with the AGP capabilities for the host, it's very possible that you have those in a space that don't appear on the PCI (just as MMIO registers on your bridge somewhere), or whatever other fancy setup. In fact, that part of the spec hits the above hole, so I wouldn't be surprised if vendors decided to ignore it and do fancy things. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Friday 11 March 2005 18:09, Paul Mackerras wrote: >Dave Jones writes: >> I'm fascinated that not a single person picked up on this problem >> whilst the agp code sat in -mm. Even if DRI isn't enabled, >> every box out there with AGP that uses the generic routines >> (which is a majority), should have barfed loudly when it hit >> this check during boot. Does no-one read dmesg output any more ? > >That loop would only get executed when you enable AGP, which I think >would generally only happen when starting X with DRI enabled. > >Paul. Which I am doing here I believe, and my current dmesg ring does go back to the tail end of whats in /var/log/dmesg, but: Its got a lot of crap about tainted kernels, AND its not by any means all from the stuff that pcHDTV-1.6 builds and inserts into the /var/modules/`name -r`/kernel/drivers etc etc directories. Its also bitching about nearly every i2c module loaded! With lines along the general theme of this: -- i2c_core: No versions for exported symbols. Tainting kernel. i2c_algo_bit: No versions for exported symbols. Tainting kernel. kobject_register failed for i2c_algo_bit (-17) [] kobject_register+0x57/0x60 [] mod_sysfs_setup+0x50/0xb0 [] load_module+0x889/0xb70 [] sys_init_module+0x56/0x220 [] sysenter_past_esp+0x52/0x75 --- and yet, gkrellm, and sensors are both working quite nicely. WTH? I am rather certain that versioning info in the modules IS turned on in the .config: However, a grep of .config makes a liar out of me, it is NOT set: [EMAIL PROTECTED] linux-2.6.11.2]# grep VERSION .config CONFIG_LOCALVERSION="" # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set Rebuild coming up. :( >- >To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Friday 11 March 2005 17:33, Chris Wedgwood wrote: >On Fri, Mar 11, 2005 at 05:26:14PM -0500, Dave Jones wrote: >> Does no-one read dmesg output any more? > >For many people it's overly verbose and long --- so I assume they > just tune it out. > >Sometimes I wonder if it would be a worth-while effort to trim the >dmesg boot text down to what users really *need* to know. We could >retain most of the other stuff at a different log-level which would > be exposed by a kernel command line parameter or something during > boot for when people have problems. With all due respect to the people that it will take to make that happen, thats a heck of a good idea. However, what I'd like to see is a difference between whats output to the screen during bootup (set that to relatively quiet unless a problem is hit) but to continue to log the full output to /var/log/dmesg-$date when the ring is dumped and syslog can then take the rest of it. Overwriting /var/log/dmesg at every boot removes a lot of forensic info that could come in handier than sliced bread and bottled beer at times. Let rotatelog take care of deleting anything more than a week out of date so they don't take up space once their usefullness has expired. How many 'aye's do I hear? -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
Dave Jones writes: > I'm fascinated that not a single person picked up on this problem > whilst the agp code sat in -mm. Even if DRI isn't enabled, > every box out there with AGP that uses the generic routines > (which is a majority), should have barfed loudly when it hit > this check during boot. Does no-one read dmesg output any more ? That loop would only get executed when you enable AGP, which I think would generally only happen when starting X with DRI enabled. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote: > On 03.11, Dave Jones wrote: > > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote: > > > > > > On 03.11, Paul Mackerras wrote: > > > > Linus, > > > > > > > ... > > > > > > > > Oh, and by the way, I have 3D working relatively well on my G5 with a > > > > 64-bit kernel (and 32-bit X server and clients), which is why I care > > > > about AGP 3.0 support. :) > > > > > > > > > > I think it is not a G5 only problem. I have a x8 card, a x8 slot, but > > > agpgart keeps saying this: > > > > > > Mar 11 23:00:28 werewolf dm: Display manager startup succeeded > > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant > > device at :00:00.0. > > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. > > Fixed. > > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) > > in AGP3 mode. Fixed. > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > :00:00.0 into 4x mode > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > :01:00.0 into 4x mode > > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant > > device at :00:00.0. > > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. > > Fixed. > > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) > > in AGP3 mode. Fixed. > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > :00:00.0 into 4x mode > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > :01:00.0 into 4x mode > > > > > > The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells me > > > it is in x8 mode, but i suspect it lies > > > > > > Will try your patch right now. > > > > Looks fine, now I got: > > agpgart: Found an AGP 3.0 compliant device at :00:00.0. > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode > agpgart: Found an AGP 3.0 compliant device at :00:00.0. > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode > > werewolf:~> lspci > 00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub > (rev 02) > 00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev > 02) > ... > 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] > (rev a1) > > BTW, I had to patch the nVidia driver. It just tries up to x4 AGP... > New and old one works fine with Paul's patch: --old-- agpgart: Found an AGP 3.0 compliant device at :00:00.0. agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode. agpgart: Putting AGP V3 device at :00:00.0 into 8x mode agpgart: Putting AGP V3 device at :01:00.0 into 8x mode --- (ok, so old driver is a bit dodgy) --new-- agpgart: Found an AGP 3.0 compliant device at :00:00.0. agpgart: Putting AGP V3 device at :00:00.0 into 8x mode agpgart: Putting AGP V3 device at :01:00.0 into 8x mode --- -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: AGP bogosities
On Fri, 2005-03-11 at 23:17 +, J.A. Magallon wrote: > On 03.12, Martin Schlemmer wrote: > > On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote: > > > On 03.11, Dave Jones wrote: > > > > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote: > > > > > > > > > > On 03.11, Paul Mackerras wrote: > > > > > > Linus, > > > > > > > > > > > ... > > > > > > > > > > > > Oh, and by the way, I have 3D working relatively well on my G5 > > > > with a > > > > > > 64-bit kernel (and 32-bit X server and clients), which is why I > > > > care > > > > > > about AGP 3.0 support. :) > > > > > > > > > > > > > > > > I think it is not a G5 only problem. I have a x8 card, a x8 slot, but > > > > > agpgart keeps saying this: > > > > > > > > > > Mar 11 23:00:28 werewolf dm: Display manager startup succeeded > > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant > > > > device at :00:00.0. > > > > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode > > > > 0xa. Fixed. > > > > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags > > > > (2) in AGP3 mode. Fixed. > > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > > > :00:00.0 into 4x mode > > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > > > :01:00.0 into 4x mode > > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant > > > > device at :00:00.0. > > > > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode > > > > 0xa. Fixed. > > > > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags > > > > (2) in AGP3 mode. Fixed. > > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > > > :00:00.0 into 4x mode > > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > > > :01:00.0 into 4x mode > > > > > > > > > > The nvidia driver (brand new 1.0-7167, now works with stock -mm) > > > > tells me > > > > > it is in x8 mode, but i suspect it lies > > > > > > > > > > Will try your patch right now. > > > > > > > > > > Looks fine, now I got: > > > > > > agpgart: Found an AGP 3.0 compliant device at :00:00.0. > > > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode > > > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode > > > agpgart: Found an AGP 3.0 compliant device at :00:00.0. > > > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode > > > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode > > > > > > werewolf:~> lspci > > > 00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub > > > (rev 02) > > > 00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller > > > (rev 02) > > > ... > > > 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX > > > 5200] (rev a1) > > > > > > BTW, I had to patch the nVidia driver. It just tries up to x4 AGP... > > > > > > > New and old one works fine with Paul's patch: > > > > --old-- > > agpgart: Found an AGP 3.0 compliant device at :00:00.0. > > agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode. > > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode > > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode > > --- > > > > (ok, so old driver is a bit dodgy) > > > > --new-- > > agpgart: Found an AGP 3.0 compliant device at :00:00.0. > > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode > > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode > > --- > > > > Just curiosity, what says your /proc/driver/nvidia/agp/status ? > - # cat /proc/driver/nvidia/agp/status Status: Enabled Driver: AGPGART AGP Rate:8x Fast Writes: Enabled SBA: Enabled - -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: AGP bogosities
On 03.12, Martin Schlemmer wrote: > On Fri, 2005-03-11 at 23:17 +, J.A. Magallon wrote: > > On 03.12, Martin Schlemmer wrote: > > > On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote: > > > > On 03.11, Dave Jones wrote: > > > > > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote: > > > > > > ... > > > > > > > Just curiosity, what says your /proc/driver/nvidia/agp/status ? > > > > - > # cat /proc/driver/nvidia/agp/status > Status: Enabled > Driver: AGPGART > AGP Rate:8x > Fast Writes: Enabled > SBA: Enabled > - > Ah, I got it. The AGPRate is a _limit_ and is not active by default. It is not the rates to probe... If you activate it and dont change to 15 you limit the driver to x4. If you do nothing, no limit. Thanks. -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.11-jam3 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-6mdk)) #3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Sat, 2005-03-12 at 09:43 +1100, Paul Mackerras wrote: > On PPC/PPC64 machines, the host bridges generally do not appear as PCI > devices either. *However*, the AGP spec requires a set of registers > in PCI config space for controlling the target (host) side of the AGP > bus. In other words you are required to have a PCI device to > represent the host side of the AGP bus, with a capability structure in > its config space which contains the standard AGP registers. I still don't quite understand this. If the host bridge is not a PCI device, what PCI device contains the AGP capability that controls the host bridge? I assume you're saying that you are required to have TWO PCI devices that have the AGP capability, one for the AGP device and one for the bridge. HP boxes certainly don't have that (zx6000 sample below). I guess it wouldn't be the first time we deviated from a spec ;-) Can you point me to the relevant section? :00:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 010a Flags: bus master, stepping, 66MHz, medium devsel, latency 192, IRQ 255 Memory at 8000 (32-bit, prefetchable) [size=128M] I/O ports at 0d00 [size=256] Memory at 8802 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 8800 [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Capabilities: [50] Power Management version 2 :80:03.0 PCI bridge: Intel Corp. 21154 PCI-to-PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 128 Bus: primary=80, secondary=81, subordinate=81, sec-latency=128 I/O behind bridge: 4000-4fff Memory behind bridge: a000-a40f Capabilities: [dc] Power Management version 1 :81:04.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Hewlett-Packard Company: Unknown device 1293 Flags: bus master, medium devsel, latency 128 Memory at a4032000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 :81:04.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: Hewlett-Packard Company: Unknown device aa55 Flags: bus master, medium devsel, latency 128 Memory at a4031000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 :81:04.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI]) Subsystem: Hewlett-Packard Company: Unknown device aa55 Flags: bus master, medium devsel, latency 128 Memory at a403 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 :81:05.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA]) Subsystem: Hewlett-Packard Company: Unknown device 1292 Flags: bus master, stepping, medium devsel, latency 128, IRQ 255 Memory at a000 (32-bit, prefetchable) [size=64M] I/O ports at 4000 [disabled] [size=256] Memory at a402 (32-bit, non-prefetchable) [size=64K] Expansion ROM at a400 [disabled] [size=128K] Capabilities: [50] Power Management version 2 :a0:01.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: NEC Corporation USB Flags: bus master, medium devsel, latency 128 Memory at d0022000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 :a0:01.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI]) Subsystem: NEC Corporation USB Flags: bus master, medium devsel, latency 128 Memory at d0021000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 2 :a0:01.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI]) Subsystem: NEC Corporation USB 2.0 Flags: bus master, medium devsel, latency 128 Memory at d002 (32-bit, non-prefetchable) [size=256] Capabilities: [40] Power Management version 2 :a0:02.0 IDE interface: Silicon Image, Inc. (formerly CMD Technology Inc) PCI0649 (rev 02) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc) PCI0649 Flags: bus master, medium devsel, latency 64, IRQ 52 I/O ports at a0e8 [size=8] I/O ports at a0f4 [size=4] I/O ports at a0e0 [size=8] I/O ports at a0f0 [size=4] I/O ports at a0d0 [size=16] Capabilities: [60] Power Management version 2 :a0:03.0 Ethernet controller: Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02) Subsystem: Hewlett-Packard Company:
Re: AGP bogosities
On 03.12, Martin Schlemmer wrote: > On Fri, 2005-03-11 at 22:46 +, J.A. Magallon wrote: > > On 03.11, Dave Jones wrote: > > > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote: > > > > > > > > On 03.11, Paul Mackerras wrote: > > > > > Linus, > > > > > > > > > ... > > > > > > > > > > Oh, and by the way, I have 3D working relatively well on my G5 with a > > > > > 64-bit kernel (and 32-bit X server and clients), which is why I care > > > > > about AGP 3.0 support. :) > > > > > > > > > > > > > I think it is not a G5 only problem. I have a x8 card, a x8 slot, but > > > > agpgart keeps saying this: > > > > > > > > Mar 11 23:00:28 werewolf dm: Display manager startup succeeded > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant > > > device at :00:00.0. > > > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode > > > 0xa. Fixed. > > > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags > > > (2) in AGP3 mode. Fixed. > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > > :00:00.0 into 4x mode > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > > :01:00.0 into 4x mode > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant > > > device at :00:00.0. > > > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode > > > 0xa. Fixed. > > > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags > > > (2) in AGP3 mode. Fixed. > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > > :00:00.0 into 4x mode > > > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > > > :01:00.0 into 4x mode > > > > > > > > The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells > > > me > > > > it is in x8 mode, but i suspect it lies > > > > > > > > Will try your patch right now. > > > > > > > Looks fine, now I got: > > > > agpgart: Found an AGP 3.0 compliant device at :00:00.0. > > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode > > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode > > agpgart: Found an AGP 3.0 compliant device at :00:00.0. > > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode > > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode > > > > werewolf:~> lspci > > 00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub > > (rev 02) > > 00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller > > (rev 02) > > ... > > 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX > > 5200] (rev a1) > > > > BTW, I had to patch the nVidia driver. It just tries up to x4 AGP... > > > > New and old one works fine with Paul's patch: > > --old-- > agpgart: Found an AGP 3.0 compliant device at :00:00.0. > agpgart: X tried to set rate=x12. Setting to AGP3 x8 mode. > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode > --- > > (ok, so old driver is a bit dodgy) > > --new-- > agpgart: Found an AGP 3.0 compliant device at :00:00.0. > agpgart: Putting AGP V3 device at :00:00.0 into 8x mode > agpgart: Putting AGP V3 device at :01:00.0 into 8x mode > --- > Just curiosity, what says your /proc/driver/nvidia/agp/status ? -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.11-jam3 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-6mdk)) #3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On 03.11, Dave Jones wrote: > On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote: > > > > On 03.11, Paul Mackerras wrote: > > > Linus, > > > > > ... > > > > > > Oh, and by the way, I have 3D working relatively well on my G5 with a > > > 64-bit kernel (and 32-bit X server and clients), which is why I care > > > about AGP 3.0 support. :) > > > > > > > I think it is not a G5 only problem. I have a x8 card, a x8 slot, but > > agpgart keeps saying this: > > > > Mar 11 23:00:28 werewolf dm: Display manager startup succeeded > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant > device at :00:00.0. > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. > Fixed. > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) > in AGP3 mode. Fixed. > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > :00:00.0 into 4x mode > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > :01:00.0 into 4x mode > > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant > device at :00:00.0. > > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. > Fixed. > > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) > in AGP3 mode. Fixed. > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > :00:00.0 into 4x mode > > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > :01:00.0 into 4x mode > > > > The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells me > > it is in x8 mode, but i suspect it lies > > > > Will try your patch right now. > Looks fine, now I got: agpgart: Found an AGP 3.0 compliant device at :00:00.0. agpgart: Putting AGP V3 device at :00:00.0 into 8x mode agpgart: Putting AGP V3 device at :01:00.0 into 8x mode agpgart: Found an AGP 3.0 compliant device at :00:00.0. agpgart: Putting AGP V3 device at :00:00.0 into 8x mode agpgart: Putting AGP V3 device at :01:00.0 into 8x mode werewolf:~> lspci 00:00.0 Host bridge: Intel Corporation 82875P/E7210 Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation 82875P Processor to AGP Controller (rev 02) ... 01:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) BTW, I had to patch the nVidia driver. It just tries up to x4 AGP... Thanks. -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.11-jam3 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-6mdk)) #2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri, 11 Mar 2005 17:42:46 -0500, Dmitry Torokhov
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sat, 12 Mar 2005 07:18:19 +0900, OGAWA Hirofumi
> <[EMAIL PROTECTED]> wrote:
> >
> > + if (!atomic_read(v)) {
> > + printk("BUG: atomic counter underflow at:\n");
> > + dump_stack();
> > + }
>
> I wonder if adding "unlikely" might be beneficial here.
Oh, it's just a debugging patch, nevermind...
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
Hi,
On Sat, 12 Mar 2005 07:18:19 +0900, OGAWA Hirofumi
<[EMAIL PROTECTED]> wrote:
>
> + if (!atomic_read(v)) {
> + printk("BUG: atomic counter underflow at:\n");
> + dump_stack();
> + }
I wonder if adding "unlikely" might be beneficial here.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
Bjorn Helgaas writes: > HP ia64 and parisc boxes are similar. The host bridges do not appear > as PCI devices. We discover them via ACPI on ia64 and PDC on parisc. On PPC/PPC64 machines, the host bridges generally do not appear as PCI devices either. *However*, the AGP spec requires a set of registers in PCI config space for controlling the target (host) side of the AGP bus. In other words you are required to have a PCI device to represent the host side of the AGP bus, with a capability structure in its config space which contains the standard AGP registers. The lspci that was posted showed no such device, which was why Ben was querying it. Maybe your systems aren't fully AGP-compliant, in which case much of the generic code won't be usable on your systems. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri, 11 Mar 2005, Dave Jones wrote: > > I'm fascinated that not a single person picked up on this problem > whilst the agp code sat in -mm. Even if DRI isn't enabled, > every box out there with AGP that uses the generic routines > (which is a majority), should have barfed loudly when it hit > this check during boot. Does no-one read dmesg output any more ? I don't think it actuially causes a barf, because the counts start at 1, and they go down to zero due to the double-free, but they don't become negative until you do that whole detection loop _twice_. I think- Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri, Mar 11, 2005 at 05:26:14PM -0500, Dave Jones wrote: > Does no-one read dmesg output any more? For many people it's overly verbose and long --- so I assume they just tune it out. Sometimes I wonder if it would be a worth-while effort to trim the dmesg boot text down to what users really *need* to know. We could retain most of the other stuff at a different log-level which would be exposed by a kernel command line parameter or something during boot for when people have problems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Sat, Mar 12, 2005 at 07:18:19AM +0900, OGAWA Hirofumi wrote: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > Hmm.. We seem to not have any tests for the counts becoming negative, and > > this would seem to be an easy mistake to make considering that both I and > > Dave did it. > > I stole this from -mm. I'm fascinated that not a single person picked up on this problem whilst the agp code sat in -mm. Even if DRI isn't enabled, every box out there with AGP that uses the generic routines (which is a majority), should have barfed loudly when it hit this check during boot. Does no-one read dmesg output any more ? Maybe OSDL can add an automated test to send diffs of dmesg between kernels like they do the automated warning announcements 8-) Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Hmm.. We seem to not have any tests for the counts becoming negative, and
> this would seem to be an easy mistake to make considering that both I and
> Dave did it.
I stole this from -mm.
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
From: Ingo Molnar <[EMAIL PROTECTED]>
The patch below will detect atomic counter underflows. This has been
test-driven in the -RT patchset for some time. qdisc_destroy() triggered
it sometimes (in a seemingly nonfatal way, during device shutdown) - with
DaveM suggesting that it is most likely a bug in the networking code. So
it would be nice to have this in -mm for some time to validate all atomic
counters on a broader base.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/include/asm-i386/atomic.h |4
1 files changed, 4 insertions(+)
diff -puN include/asm-i386/atomic.h~detect-atomic-counter-underflows
include/asm-i386/atomic.h
--- 25/include/asm-i386/atomic.h~detect-atomic-counter-underflows Wed Nov
3 15:27:37 2004
+++ 25-akpm/include/asm-i386/atomic.h Wed Nov 3 15:27:37 2004
@@ -132,6 +132,10 @@ static __inline__ int atomic_dec_and_tes
{
unsigned char c;
+ if (!atomic_read(v)) {
+ printk("BUG: atomic counter underflow at:\n");
+ dump_stack();
+ }
__asm__ __volatile__(
LOCK "decl %0; sete %1"
:"=m" (v->counter), "=qm" (c)
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Fri, Mar 11, 2005 at 10:11:08PM +, J.A. Magallon wrote: > > On 03.11, Paul Mackerras wrote: > > Linus, > > > ... > > > > Oh, and by the way, I have 3D working relatively well on my G5 with a > > 64-bit kernel (and 32-bit X server and clients), which is why I care > > about AGP 3.0 support. :) > > > > I think it is not a G5 only problem. I have a x8 card, a x8 slot, but > agpgart keeps saying this: > > Mar 11 23:00:28 werewolf dm: Display manager startup succeeded > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device > at :00:00.0. > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. > Fixed. > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in > AGP3 mode. Fixed. > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > :00:00.0 into 4x mode > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > :01:00.0 into 4x mode > Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device > at :00:00.0. > Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. > Fixed. > Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in > AGP3 mode. Fixed. > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > :00:00.0 into 4x mode > Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at > :01:00.0 into 4x mode > > The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells me > it is in x8 mode, but i suspect it lies > > Will try your patch right now. Testing latest -bk would be useful. It has Paul's patch, and a few others. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On 03.11, Paul Mackerras wrote: > Linus, > ... > > Oh, and by the way, I have 3D working relatively well on my G5 with a > 64-bit kernel (and 32-bit X server and clients), which is why I care > about AGP 3.0 support. :) > I think it is not a G5 only problem. I have a x8 card, a x8 slot, but agpgart keeps saying this: Mar 11 23:00:28 werewolf dm: Display manager startup succeeded Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at :00:00.0. Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed. Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed. Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at :00:00.0 into 4x mode Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at :01:00.0 into 4x mode Mar 11 23:00:29 werewolf kernel: agpgart: Found an AGP 3.0 compliant device at :00:00.0. Mar 11 23:00:29 werewolf kernel: agpgart: reserved bits set in mode 0xa. Fixed. Mar 11 23:00:29 werewolf kernel: agpgart: X passes broken AGP2 flags (2) in AGP3 mode. Fixed. Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at :00:00.0 into 4x mode Mar 11 23:00:29 werewolf kernel: agpgart: Putting AGP V3 device at :01:00.0 into 4x mode The nvidia driver (brand new 1.0-7167, now works with stock -mm) tells me it is in x8 mode, but i suspect it lies Will try your patch right now. -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Cooker) for i586 Linux 2.6.11-jam3 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-6mdk)) #2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Friday, March 11, 2005 10:04 am, James Simmons wrote: > > > Oh, and by the way, I have 3D working relatively well on my G5 with a > > > 64-bit kernel (and 32-bit X server and clients), which is why I care > > > about AGP 3.0 support. :) > > > > I have a system in my office with several gfx pipes on different AGP > > busses, and I'd like that to work well too! :) > > Where can you get one of these systems? http://www.sgi.com/prism is the site, you probably have to call a sales office to order one. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
On Friday, March 11, 2005 9:59 am, Bjorn Helgaas wrote: > > Right, it's a special agp driver, sgi-agp.c. > > Where's sgi-agp.c? The HP (ia64-only at the moment) code is hp-agp.c. > It does make a fake PCI dev for the bridge because DRM still seemed to > want that. I think Mike posted it but hasn't submitted it to Dave yet since it needed another change that only just made it into the ia64 tree. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AGP bogosities
> > Oh, and by the way, I have 3D working relatively well on my G5 with a > > 64-bit kernel (and 32-bit X server and clients), which is why I care > > about AGP 3.0 support. :) > > I have a system in my office with several gfx pipes on different AGP busses, > and I'd like that to work well too! :) Where can you get one of these systems? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
