Re: [ACPI] [2.6.12-rc2][suspend] Suspending Thinkpad: drive bay light in S3 mode stays on
Sure, I suppose you can, but most suspend tools just echo stuff to /sys (or still /proc/acpi/sleep) which makes it harder to script it. Besides, when a laptop goes into suspend to RAM there should be no extra power on except a Moon or some other icon. That said, the ACPI thinkpad extras was designed to do all of this so why shouldn't the driver do S3 suspend if it hooks into it already? Shawn. --- Matthew Garrett [EMAIL PROTECTED] wrote: On Mon, 2005-04-11 at 16:03 -0400, Shawn Starr wrote: I notice in Linux and in XP the drive bay light remains on while the laptop is in suspend-to-RAM. I know the ACPI thinkpad extras added to the kernel recently can turn this off. I wonder if we can/or need to write hooks to turn the light off so to conserve power when we're in S3 Just disable it in your suspend script. There's no reason to push that sort of policy into the kernel. -- Matthew Garrett | [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: Policy question (was Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop)
Well, of course. When I get around to figuring out the best way to do this. Since I don't want to bloat up sysfs ACPI stuff just to check if the echoed value is a number or string. We can just gradually phase it out by just marking it DEPRECATED and keep it ON in the Kbuild file so nobody looses the functionality until then. I'm thinking 2 years but some say thats too long :) Now that I look at it, I don't need to put it into a CONFIG option as its already a module :-) even better. Shawn. On April 11, 2005 20:09, Rob Landley wrote: On Wednesday 06 April 2005 05:22 pm, Shawn Starr wrote: --- Pavel Machek [EMAIL PROTECTED] wrote: Hi! So nobody minds if I make this into a CONFIG option marked as Deprecated? :) Actually it should probably go through Documentation/feature-removal-schedule.txt ...and give it *long* timeout, since it is API change. Pavel Shouldn't all deprecated features be in feature-removal-schedule.txt? There are four entries in feature-removal-schedule in 2.6.12-rc2, but `find . -name Kconfig | xargs grep -i deprecated` finds eight entries. (And there's more if the grep -i is for obsolete instead...) Just wondering... Rob - 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: [PATCH 2.6.11.6] Add power cycle to ipmi_poweroff module
Shouldn't IPMI be using /sys instead /proc? I thought we're trying to cleanup /proc? --- List: linux-kernel Subject:RE: [PATCH 2.6.11.6] Add power cycle to ipmi_poweroff module From: Date: 2005-04-08 15:53:54 Message-ID: [Download message RAW] The message handler and si are already using /proc/ipmi/. The patch code simply reuse it. By the way, shouldn't we be using sysfs? As for separating from power_off, it just seem so simple to integrate the power cycle command into the power_off code. It could definitely be a separate module. Thanks, -Chris Poblete -Original Message- From: Corey Minyard [mailto:[EMAIL PROTECTED] Sent: Friday, April 08, 2005 10:35 AM To: Poblete, Chris Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH 2.6.11.6] Add power cycle to ipmi_poweroff module [EMAIL PROTECTED] wrote: >Below is a patch to add "power cycle" functionality to the IPMI power >off module ipmi_poweroff. > >A new module param is added to support this: >parmtype: do_power_cycle:int >parm: do_power_cycle: Set to 1 to enable power cycle instead >of power down. Power cycle is contingent on hardware support, otherwise >it defaults back to power down. > >This parameter can also be dynamically modified through the proc >filesystem: >/proc/ipmi//poweroff > > This should probably be /proc/sys/dev/ipmi/power_cycle_on_halt. Most things to control a system go there. The /proc/sys/dev/ipmi directory should probably be created by the base IPMI file, too. Thinking about it a little more, this should really be an option for reset, not for power off (thus making the name power_cycle_on_reset). I'm not sure how easy that will be to tie into. It doesn't look easy; there's not something like pm_power_off for reset. All the proc fs stuff should be ifdef-ed appropriately so it will compile with procfs turned off. -Corey >The power cycle action is considered an optional chassis control in the >IPMI specification. However, it is definitely useful when the hardware >supports it. A power cycle is usually required in order to reset a >firmware in a bad state. This action is critical to allow remote >management of servers. > >The implementation adds power cycle as optional to the ipmi_poweroff >module. It can be modified dynamically through the proc entry mentioned >above. During a power down and enabled, the power cycle command is sent >to the BMC firmware. If it fails either due to non-support or some >error, it will retry to send the command as power off. > >Signed-off-by: Christopher A. Poblete <[EMAIL PROTECTED]> > >-- >Chris Poblete >Software Engineer >Dell OpenManage Instrumentation - 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: [PATCH 2.6.11.6] Add power cycle to ipmi_poweroff module
Shouldn't IPMI be using /sys instead /proc? I thought we're trying to cleanup /proc? --- List: linux-kernel Subject:RE: [PATCH 2.6.11.6] Add power cycle to ipmi_poweroff module From: Chris_Poblete () Dell ! com Date: 2005-04-08 15:53:54 Message-ID: D69989B48C25DB489BBB0207D0BF51F70262F423 () ausx2kmpc104 ! aus ! amer ! dell ! com [Download message RAW] The message handler and si are already using /proc/ipmi/intf_num. The patch code simply reuse it. By the way, shouldn't we be using sysfs? As for separating from power_off, it just seem so simple to integrate the power cycle command into the power_off code. It could definitely be a separate module. Thanks, -Chris Poblete -Original Message- From: Corey Minyard [mailto:[EMAIL PROTECTED] Sent: Friday, April 08, 2005 10:35 AM To: Poblete, Chris Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH 2.6.11.6] Add power cycle to ipmi_poweroff module [EMAIL PROTECTED] wrote: Below is a patch to add power cycle functionality to the IPMI power off module ipmi_poweroff. A new module param is added to support this: parmtype: do_power_cycle:int parm: do_power_cycle: Set to 1 to enable power cycle instead of power down. Power cycle is contingent on hardware support, otherwise it defaults back to power down. This parameter can also be dynamically modified through the proc filesystem: /proc/ipmi/interface_num/poweroff This should probably be /proc/sys/dev/ipmi/power_cycle_on_halt. Most things to control a system go there. The /proc/sys/dev/ipmi directory should probably be created by the base IPMI file, too. Thinking about it a little more, this should really be an option for reset, not for power off (thus making the name power_cycle_on_reset). I'm not sure how easy that will be to tie into. It doesn't look easy; there's not something like pm_power_off for reset. All the proc fs stuff should be ifdef-ed appropriately so it will compile with procfs turned off. -Corey The power cycle action is considered an optional chassis control in the IPMI specification. However, it is definitely useful when the hardware supports it. A power cycle is usually required in order to reset a firmware in a bad state. This action is critical to allow remote management of servers. The implementation adds power cycle as optional to the ipmi_poweroff module. It can be modified dynamically through the proc entry mentioned above. During a power down and enabled, the power cycle command is sent to the BMC firmware. If it fails either due to non-support or some error, it will retry to send the command as power off. Signed-off-by: Christopher A. Poblete [EMAIL PROTECTED] -- Chris Poblete Software Engineer Dell OpenManage Instrumentation - 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: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop
Yeah, I can do that, I don't need angry programmers chasing after me :-) Shawn. --- Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > So nobody minds if I make this into a CONFIG > option marked as Deprecated? :) > > Actually it should probably go through > > Documentation/feature-removal-schedule.txt > > ...and give it *long* timeout, since it is API > change. > 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: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop
Yeah, I can do that, I don't need angry programmers chasing after me :-) Shawn. --- Pavel Machek [EMAIL PROTECTED] wrote: Hi! So nobody minds if I make this into a CONFIG option marked as Deprecated? :) Actually it should probably go through Documentation/feature-removal-schedule.txt ...and give it *long* timeout, since it is API change. 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: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop
So nobody minds if I make this into a CONFIG option marked as Deprecated? :) Shawn. > > > Do you know if /proc/acpi/sleep will be deprecated in > > favour of /sys/power/state? If so, this thread will be > > moot ;) > > No idea, deprecating it would be ok with me. > >Pavel pgpGfWAs0n7J0.pgp Description: PGP signature
Re: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop
I'm working o --- Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > I've noticed something strange with issuing > 'standby' to the system: > > > > when echoing "standby" to /sys/power/state, > nothing happens, not even a log or > > system activity to attempt standby mode. > > > > However, trying echo "1" to /proc/acpi/sleep the > system attempts to (standby) > > and aborts: > > > > [4295945.236000] PM: Preparing system for suspend > > [4295946.27] Stopping tasks: > > > =| > > [4295946.37] Restarting tasks... done > > > > We get no reason as to why it quickly aborts. > > > [4294672.065000] ACPI: CPU0 (power states: C1[C1] > C2[C2] C3[C3]) > > [4294676.827000] ACPI: (supports S0 S3 S4 S5) > > > ...aha, but your system does not support S1 aka > standby. > Right, so nothing should happen if I try to do it, but something does only in /proc/acpi/sleep does the system attempt S1 which is not supported. Do you know if /proc/acpi/sleep will be deprecated in favour of /sys/power/state? If so, this thread will be moot ;) > > What is '1' in /proc/acpi/sleep? standby mode is > not the same as suspend to > > ram? when I put a normal desktop in standby mode > its still 'on' but the hard > > disk is put to sleep and the system runs in a > lower power mode. > > stanby != suspend to ram. Correct, I wanted to be sure. > > Pavel > -- > 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 > time=448769.1 ms > > - 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: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop
I'm working o --- Pavel Machek [EMAIL PROTECTED] wrote: Hi! I've noticed something strange with issuing 'standby' to the system: when echoing standby to /sys/power/state, nothing happens, not even a log or system activity to attempt standby mode. However, trying echo 1 to /proc/acpi/sleep the system attempts to (standby) and aborts: [4295945.236000] PM: Preparing system for suspend [4295946.27] Stopping tasks: =| [4295946.37] Restarting tasks... done We get no reason as to why it quickly aborts. [4294672.065000] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) [4294676.827000] ACPI: (supports S0 S3 S4 S5) ...aha, but your system does not support S1 aka standby. Right, so nothing should happen if I try to do it, but something does only in /proc/acpi/sleep does the system attempt S1 which is not supported. Do you know if /proc/acpi/sleep will be deprecated in favour of /sys/power/state? If so, this thread will be moot ;) What is '1' in /proc/acpi/sleep? standby mode is not the same as suspend to ram? when I put a normal desktop in standby mode its still 'on' but the hard disk is put to sleep and the system runs in a lower power mode. stanby != suspend to ram. Correct, I wanted to be sure. Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - 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: [2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop
So nobody minds if I make this into a CONFIG option marked as Deprecated? :) Shawn. Do you know if /proc/acpi/sleep will be deprecated in favour of /sys/power/state? If so, this thread will be moot ;) No idea, deprecating it would be ok with me. Pavel pgpGfWAs0n7J0.pgp Description: PGP signature
[2.6.12-rc1] suspend to Disk success - T42 laptop
Hello Pavel, I can now suspend to disk on the laptop with 2.6.12-rc1. There is no failures anymore. It resumes perfectly. Thank you. Shawn. - 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/
[2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop
Hello, I've noticed something strange with issuing 'standby' to the system: when echoing "standby" to /sys/power/state, nothing happens, not even a log or system activity to attempt standby mode. However, trying echo "1" to /proc/acpi/sleep the system attempts to (standby) and aborts: [4295945.236000] PM: Preparing system for suspend [4295946.27] Stopping tasks: =| [4295946.37] Restarting tasks... done We get no reason as to why it quickly aborts. [4294672.065000] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) [4294676.827000] ACPI: (supports S0 S3 S4 S5) What is '1' in /proc/acpi/sleep? standby mode is not the same as suspend to ram? when I put a normal desktop in standby mode its still 'on' but the hard disk is put to sleep and the system runs in a lower power mode. Shawn. - 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/
[2.6.12-rc1][ACPI][suspend] /proc/acpi/sleep vs /sys/power/state issue - 'standby' on a laptop
Hello, I've noticed something strange with issuing 'standby' to the system: when echoing standby to /sys/power/state, nothing happens, not even a log or system activity to attempt standby mode. However, trying echo 1 to /proc/acpi/sleep the system attempts to (standby) and aborts: [4295945.236000] PM: Preparing system for suspend [4295946.27] Stopping tasks: =| [4295946.37] Restarting tasks... done We get no reason as to why it quickly aborts. [4294672.065000] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) [4294676.827000] ACPI: (supports S0 S3 S4 S5) What is '1' in /proc/acpi/sleep? standby mode is not the same as suspend to ram? when I put a normal desktop in standby mode its still 'on' but the hard disk is put to sleep and the system runs in a lower power mode. Shawn. - 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/
[2.6.12-rc1] suspend to Disk success - T42 laptop
Hello Pavel, I can now suspend to disk on the laptop with 2.6.12-rc1. There is no failures anymore. It resumes perfectly. Thank you. Shawn. - 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/
[2.6.11.5][BUILD] i2c.h breakage in 2.6.12-rc1 + -mm only
include/linux/i2c.h:58: error: array type has incomplete element type include/linux/i2c.h:197: error: array type has incomplete element type /usr/local/src/sources/r300_driver/drm/linux-core/radeon_drv.h:274: confused by earlier errors, bailing out I see further back you fed the gcc 4.0 compile fixes to akpm for this, can this be merged in to 2.6.11.6? Thanks, Shawn. - 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/
[2.6.11.5][BUILD] i2c.h breakage in 2.6.12-rc1 + -mm only
include/linux/i2c.h:58: error: array type has incomplete element type include/linux/i2c.h:197: error: array type has incomplete element type /usr/local/src/sources/r300_driver/drm/linux-core/radeon_drv.h:274: confused by earlier errors, bailing out I see further back you fed the gcc 4.0 compile fixes to akpm for this, can this be merged in to 2.6.11.6? Thanks, Shawn. - 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: Linux 2.6.11.1
Sure, I can do this. Wrt to trivial patches, will these patches that go into rusty's patch bot go into Linus's tree or into the -mm tree? The reason I ask that is because a trivial patch may fix an oops if there's an off-by-one problem and typically I'd submit that to the trivial patch bot. That's why I was wondering about why this tree doesn't except trivial changes. Thanks, Shawn. On March 6, 2005 00:06, you wrote: > On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote: > > Sounds great, I can be a QA resource for what machines I have. > > > > How do people get involved in QAing these releases? > > Get the last release and test it out. If you have problems, and have > simple/obvious patches, send them on. > > 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: Linux 2.6.11.1
Sure, I can do this. Wrt to trivial patches, will these patches that go into rusty's patch bot go into Linus's tree or into the -mm tree? The reason I ask that is because a trivial patch may fix an oops if there's an off-by-one problem and typically I'd submit that to the trivial patch bot. That's why I was wondering about why this tree doesn't except trivial changes. Thanks, Shawn. On March 6, 2005 00:06, you wrote: On Sat, Mar 05, 2005 at 01:16:10AM -0500, Shawn Starr wrote: Sounds great, I can be a QA resource for what machines I have. How do people get involved in QAing these releases? Get the last release and test it out. If you have problems, and have simple/obvious patches, send them on. 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: Linux 2.6.11.1
Sounds great, I can be a QA resource for what machines I have. How do people get involved in QAing these releases? What other help? Shawn. > List: linux-kernel > Subject:Linux 2.6.11.1 > From: Greg KH > Date: 2005-03-04 17:53:02 > Message-ID: <20050304175302.GA29289 () kroah ! com> > [Download message RAW] > > For those of you who haven't waded through the huge "RFD: Kernel release > numbering" thread on lkml to realize that we are now going to start > putting out 2.6.x.y releases, here's the summary: > > A few of us $suckers will be trying to maintain a 2.6.x.y set of > releases that happen after 2.6.x is released. It will contain > only a set of bugfixes and security fixes that meet a strict set > of guidelines, as defined by Linus at: > http://article.gmane.org/gmane.linux.kernel/283396 > > Chris Wright and I are going to start working on doing this work, we > will have a @kernel.org to post these types of bug fixes to, > and a set of people we bounce the patches off of to test for "smells > good" validation. We will also have a bk-commits type mailing list for > those who want to watch the patches flow in, and a bk tree from which > changsets can be pulled from. > > Chris and I will be hashing all of the details out next Tuesday, and > hopefully all the infrastructure will be in place soon. When that > happens, we will post the full details on how all of this is going to > work. In the meantime, feel free to CC: me and Chris on patches that > everyone thinks should go into the 2.6.11.y releases. > > But right now, Chris is on a plane, and we don't have the email alias > set up, or the proper permissions set up on kernel.org to push changes > into the v2.6 directory, but we have a few bugs that are needing to be > fixed in the 2.6.11 release. And since our mantra is, "release early > and often", here's the first release. - 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: [RFQ] Rules for accepting patches into the linux-releases tree
How does this fit into Rusty's trivial patch bot? This process will fold that into a formal method now? Shawn. > List: linux-kernel > Subject:[RFQ] Rules for accepting patches into the linux-releases tree > From: Greg KH > Date: 2005-03-04 22:21:46 > Message-ID: <20050304222146.GA1686 () kroah ! com> > [Download message RAW] > > Anything else anyone can think of? Any objections to any of these? > I based them off of Linus's original list. > > thanks, > > greg k-h > > -- > > Rules on what kind of patches are accepted, and what ones are not, into > the "linux-release" tree. > > - It can not bigger than 100 lines, with context. > - It must fix only one thing. > - It must fix a real bug that bothers people (not a, "This could be a >problem..." type thing.) > - It must fix a problem that causes a build error (but not for things >marked CONFIG_BROKEN), an oops, a hang, or a real security issue. > - No "theoretical race condition" issues, unless an explanation of how >the race can be exploited. > - It can not contain any "trivial" fixes in it (spelling changes, >whitespace cleanups, etc.) - 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: [RFQ] Rules for accepting patches into the linux-releases tree
How does this fit into Rusty's trivial patch bot? This process will fold that into a formal method now? Shawn. List: linux-kernel Subject:[RFQ] Rules for accepting patches into the linux-releases tree From: Greg KH greg () kroah ! com Date: 2005-03-04 22:21:46 Message-ID: 20050304222146.GA1686 () kroah ! com [Download message RAW] Anything else anyone can think of? Any objections to any of these? I based them off of Linus's original list. thanks, greg k-h -- Rules on what kind of patches are accepted, and what ones are not, into the linux-release tree. - It can not bigger than 100 lines, with context. - It must fix only one thing. - It must fix a real bug that bothers people (not a, This could be a problem... type thing.) - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, or a real security issue. - No theoretical race condition issues, unless an explanation of how the race can be exploited. - It can not contain any trivial fixes in it (spelling changes, whitespace cleanups, etc.) - 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: Linux 2.6.11.1
Sounds great, I can be a QA resource for what machines I have. How do people get involved in QAing these releases? What other help? Shawn. List: linux-kernel Subject:Linux 2.6.11.1 From: Greg KH greg () kroah ! com Date: 2005-03-04 17:53:02 Message-ID: 20050304175302.GA29289 () kroah ! com [Download message RAW] For those of you who haven't waded through the huge RFD: Kernel release numbering thread on lkml to realize that we are now going to start putting out 2.6.x.y releases, here's the summary: A few of us $suckers will be trying to maintain a 2.6.x.y set of releases that happen after 2.6.x is released. It will contain only a set of bugfixes and security fixes that meet a strict set of guidelines, as defined by Linus at: http://article.gmane.org/gmane.linux.kernel/283396 Chris Wright and I are going to start working on doing this work, we will have a SOME_ALIAS@kernel.org to post these types of bug fixes to, and a set of people we bounce the patches off of to test for smells good validation. We will also have a bk-commits type mailing list for those who want to watch the patches flow in, and a bk tree from which changsets can be pulled from. Chris and I will be hashing all of the details out next Tuesday, and hopefully all the infrastructure will be in place soon. When that happens, we will post the full details on how all of this is going to work. In the meantime, feel free to CC: me and Chris on patches that everyone thinks should go into the 2.6.11.y releases. But right now, Chris is on a plane, and we don't have the email alias set up, or the proper permissions set up on kernel.org to push changes into the v2.6 directory, but we have a few bugs that are needing to be fixed in the 2.6.11 release. And since our mantra is, release early and often, here's the first release. - 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/
SELinux and sysfs
Perhaps in future, maybe SELinux could take advantage of sysfs to modify some policies? Is this doable? Sure, we still need some flat files for static configurations, but what about dynamic ones? Shawn. - 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/
SELinux and sysfs
Perhaps in future, maybe SELinux could take advantage of sysfs to modify some policies? Is this doable? Sure, we still need some flat files for static configurations, but what about dynamic ones? Shawn. - 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/
[2.6.11-rc3] - Slow boot up
>From -rc2 to -rc3 I noticed a serious slowdown during initial bootup, it takes the system a lot longer to probe devices. Anyone else noticed this? I have a T42 laptop, I will be testing this on another system to see if this is noticed as well. Shawn. - 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/
[2.6.11-rc3] - Slow boot up
From -rc2 to -rc3 I noticed a serious slowdown during initial bootup, it takes the system a lot longer to probe devices. Anyone else noticed this? I have a T42 laptop, I will be testing this on another system to see if this is noticed as well. Shawn. - 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/
[PATCH 2.6.11-rc2] I2C: lm80 driver improvement - again...
Description: Cleanup some cluttered macros, add error checking for fan divisor
value set.
Signed-off-by: Sytse Wielinga <[EMAIL PROTECTED]>
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Shawn Starr <[EMAIL PROTECTED]>
Description: Cleanup some cluttered macros, add error checking for fan divisor
value set.
Approved-by: Greg KH <[EMAIL PROTECTED]>
Signed-off-by: Sytse Wielinga <[EMAIL PROTECTED]>
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Shawn Starr <[EMAIL PROTECTED]>
--- linux-2.6.11-rc2/drivers/i2c/chips/lm80.c 2005-01-26 02:04:38.0
-0500
+++ linux-2.6.11-rc2-fixes/drivers/i2c/chips/lm80.c 2005-01-26
12:31:26.0 -0500
@@ -99,10 +99,7 @@ static inline long TEMP_FROM_REG(u16 tem
#define TEMP_LIMIT_TO_REG(val) SENSORS_LIMIT((val)<0?\
((val)-500)/1000:((val)+500)/1000,0,255)
-#define ALARMS_FROM_REG(val) (val)
-
#define DIV_FROM_REG(val) (1 << (val))
-#define DIV_TO_REG(val)
((val)==8?3:(val)==4?2:(val)==1?0:1)
/*
* Client data (each client gets its own)
@@ -269,7 +266,17 @@ static ssize_t set_fan_div(struct device
DIV_FROM_REG(data->fan_div[nr]));
val = simple_strtoul(buf, NULL, 10);
- data->fan_div[nr] = DIV_TO_REG(val);
+
+ switch (val) {
+ case 1: data->fan_div[nr] = 0; break;
+ case 2: data->fan_div[nr] = 1; break;
+ case 4: data->fan_div[nr] = 2; break;
+ case 8: data->fan_div[nr] = 3; break;
+ default:
+ dev_err(>dev, "fan_div value %ld not "
+ "supported. Choose one of 1, 2, 4 or 8!\n", val);
+ return -EINVAL;
+ }
reg = (lm80_read_value(client, LM80_REG_FANDIV) & ~(3 << (2 * (nr +
1
| (data->fan_div[nr] << (2 * (nr + 1)));
@@ -327,7 +334,7 @@ set_temp(os_hyst, temp_os_hyst, LM80_REG
static ssize_t show_alarms(struct device *dev, char *buf)
{
struct lm80_data *data = lm80_update_device(dev);
- return sprintf(buf, "%d\n", ALARMS_FROM_REG(data->alarms));
+ return sprintf(buf, "%u\n", data->alarms);
}
static DEVICE_ATTR(in0_min, S_IWUSR | S_IRUGO, show_in_min0, set_in_min0);
[PATCH 2.6.11-rc2] I2C: lm80 driver improvement - again...
Description: Cleanup some cluttered macros, add error checking for fan divisor
value set.
Signed-off-by: Sytse Wielinga [EMAIL PROTECTED]
Signed-off-by: Aurelien Jarno [EMAIL PROTECTED]
Signed-off-by: Shawn Starr [EMAIL PROTECTED]
Description: Cleanup some cluttered macros, add error checking for fan divisor
value set.
Approved-by: Greg KH [EMAIL PROTECTED]
Signed-off-by: Sytse Wielinga [EMAIL PROTECTED]
Signed-off-by: Aurelien Jarno [EMAIL PROTECTED]
Signed-off-by: Shawn Starr [EMAIL PROTECTED]
--- linux-2.6.11-rc2/drivers/i2c/chips/lm80.c 2005-01-26 02:04:38.0
-0500
+++ linux-2.6.11-rc2-fixes/drivers/i2c/chips/lm80.c 2005-01-26
12:31:26.0 -0500
@@ -99,10 +99,7 @@ static inline long TEMP_FROM_REG(u16 tem
#define TEMP_LIMIT_TO_REG(val) SENSORS_LIMIT((val)0?\
((val)-500)/1000:((val)+500)/1000,0,255)
-#define ALARMS_FROM_REG(val) (val)
-
#define DIV_FROM_REG(val) (1 (val))
-#define DIV_TO_REG(val)
((val)==8?3:(val)==4?2:(val)==1?0:1)
/*
* Client data (each client gets its own)
@@ -269,7 +266,17 @@ static ssize_t set_fan_div(struct device
DIV_FROM_REG(data-fan_div[nr]));
val = simple_strtoul(buf, NULL, 10);
- data-fan_div[nr] = DIV_TO_REG(val);
+
+ switch (val) {
+ case 1: data-fan_div[nr] = 0; break;
+ case 2: data-fan_div[nr] = 1; break;
+ case 4: data-fan_div[nr] = 2; break;
+ case 8: data-fan_div[nr] = 3; break;
+ default:
+ dev_err(client-dev, fan_div value %ld not
+ supported. Choose one of 1, 2, 4 or 8!\n, val);
+ return -EINVAL;
+ }
reg = (lm80_read_value(client, LM80_REG_FANDIV) ~(3 (2 * (nr +
1
| (data-fan_div[nr] (2 * (nr + 1)));
@@ -327,7 +334,7 @@ set_temp(os_hyst, temp_os_hyst, LM80_REG
static ssize_t show_alarms(struct device *dev, char *buf)
{
struct lm80_data *data = lm80_update_device(dev);
- return sprintf(buf, %d\n, ALARMS_FROM_REG(data-alarms));
+ return sprintf(buf, %u\n, data-alarms);
}
static DEVICE_ATTR(in0_min, S_IWUSR | S_IRUGO, show_in_min0, set_in_min0);
Re: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement -
Description: Cleanup some cluttered macros, add error checking for fan divisor value set. Approved-by: Greg KH <[EMAIL PROTECTED]> Signed-off-by: Sytse Wielinga <[EMAIL PROTECTED]> Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]> Signed-off-by: Shawn Starr <[EMAIL PROTECTED]> --- Greg KH <[EMAIL PROTECTED]> wrote: > On Wed, Jan 26, 2005 at 12:31:30PM -0500, Shawn > Starr wrote: > > Here is the corrected fix, yeah that didn't make > > sense. > > 3AM isn't a good time to send patches I guess :-) > > Care to resend it, with a full description and a > Signed-off-by: line so > I can apply it? > > thanks, > > greg k-h > lm80-fixup-3.diff Description: lm80-fixup-3.diff
Re: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement -
Description: Cleanup some cluttered macros, add error checking for fan divisor value set. Approved-by: Greg KH [EMAIL PROTECTED] Signed-off-by: Sytse Wielinga [EMAIL PROTECTED] Signed-off-by: Aurelien Jarno [EMAIL PROTECTED] Signed-off-by: Shawn Starr [EMAIL PROTECTED] --- Greg KH [EMAIL PROTECTED] wrote: On Wed, Jan 26, 2005 at 12:31:30PM -0500, Shawn Starr wrote: Here is the corrected fix, yeah that didn't make sense. 3AM isn't a good time to send patches I guess :-) Care to resend it, with a full description and a Signed-off-by: line so I can apply it? thanks, greg k-h lm80-fixup-3.diff Description: lm80-fixup-3.diff
Re: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien) - Resubmit #2
Here is the corrected fix, yeah that didn't make
sense.
3AM isn't a good time to send patches I guess :-)
--- Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 26, 2005 at 02:57:35AM -0500, Shawn
> Starr wrote:
> > static inline unsigned char FAN_TO_REG(unsigned
> rpm, unsigned div)
> > {
> > - if (rpm == 0)
> > + if (rpm <= 0)
>
> As was pointed out, this doesn't make any sense.
>
> Care to redo the patch?
>
> thanks,
>
> greg k-h
>
lm80-fixup-2.diff
Description: lm80-fixup-2.diff
Re: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien) - Resubmit #2
Here is the corrected fix, yeah that didn't make
sense.
3AM isn't a good time to send patches I guess :-)
--- Greg KH [EMAIL PROTECTED] wrote:
On Wed, Jan 26, 2005 at 02:57:35AM -0500, Shawn
Starr wrote:
static inline unsigned char FAN_TO_REG(unsigned
rpm, unsigned div)
{
- if (rpm == 0)
+ if (rpm = 0)
As was pointed out, this doesn't make any sense.
Care to redo the patch?
thanks,
greg k-h
lm80-fixup-2.diff
Description: lm80-fixup-2.diff
Re: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien) - Resubmit
You know, after seeing that patch, that it just makes sense to add some of
those cleanups to the lm80 driver.
Shawn.
lm80-i2c-0-28
Adapter: SMBus PIIX4 adapter at fe00
+5V: +4.90 V (min = +4.74 V, max = +5.25 V)
VTT: +1.72 V (min = +1.70 V, max = +2.10 V)
+3.3V: +3.35 V (min = +3.14 V, max = +3.47 V)
+Vcore:+1.98 V (min = +1.90 V, max = +2.10 V)
+12V: +11.30 V (min = +11.18 V, max = +12.63 V)
-12V: -11.88 V (min = -12.60 V, max = -11.39 V)
-5V: -4.92 V (min = -5.25 V, max = -4.76 V)
fan1: 1679 RPM (min = 1328 RPM, div = 4)
temp: +32.38°C (hot: limit = +60°C, hyst = +65°C)
: (os: limit = +54°C, hyst = +56°C)
Driver works with changes applied.
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Shawn Starr <[EMAIL PROTECTED]>
* Note to self, dont use Kmail for raw diff files
--- linux-2.6.11-rc2/drivers/i2c/chips/lm80.c 2005-01-26 02:04:38.0 -0500
+++ linux-2.6.11-rc2-fixes/drivers/i2c/chips/lm80.c 2005-01-26 02:41:00.0 -0500
@@ -72,7 +72,7 @@ SENSORS_INSMOD_1(lm80);
static inline unsigned char FAN_TO_REG(unsigned rpm, unsigned div)
{
- if (rpm == 0)
+ if (rpm <= 0)
return 255;
rpm = SENSORS_LIMIT(rpm, 1, 100);
return SENSORS_LIMIT((135 + rpm*div / 2) / (rpm*div), 1, 254);
@@ -99,10 +99,7 @@ static inline long TEMP_FROM_REG(u16 tem
#define TEMP_LIMIT_TO_REG(val) SENSORS_LIMIT((val)<0?\
((val)-500)/1000:((val)+500)/1000,0,255)
-#define ALARMS_FROM_REG(val) (val)
-
#define DIV_FROM_REG(val) (1 << (val))
-#define DIV_TO_REG(val) ((val)==8?3:(val)==4?2:(val)==1?0:1)
/*
* Client data (each client gets its own)
@@ -269,7 +266,17 @@ static ssize_t set_fan_div(struct device
DIV_FROM_REG(data->fan_div[nr]));
val = simple_strtoul(buf, NULL, 10);
- data->fan_div[nr] = DIV_TO_REG(val);
+
+ switch (val) {
+ case 1: data->fan_div[nr] = 0; break;
+ case 2: data->fan_div[nr] = 1; break;
+ case 4: data->fan_div[nr] = 2; break;
+ case 8: data->fan_div[nr] = 3; break;
+ default:
+ dev_err(>dev, "fan_div value %ld not "
+ "supported. Choose one of 1, 2, 4 or 8!\n", val);
+ return -EINVAL;
+ }
reg = (lm80_read_value(client, LM80_REG_FANDIV) & ~(3 << (2 * (nr + 1
| (data->fan_div[nr] << (2 * (nr + 1)));
@@ -327,7 +334,7 @@ set_temp(os_hyst, temp_os_hyst, LM80_REG
static ssize_t show_alarms(struct device *dev, char *buf)
{
struct lm80_data *data = lm80_update_device(dev);
- return sprintf(buf, "%d\n", ALARMS_FROM_REG(data->alarms));
+ return sprintf(buf, "%u\n", data->alarms);
}
static DEVICE_ATTR(in0_min, S_IWUSR | S_IRUGO, show_in_min0, set_in_min0);
[PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien)
You know, after seeing that patch, that it just makes sense to add some of
those cleanups to the lm80 driver.
Shawn.
lm80-i2c-0-28
Adapter: SMBus PIIX4 adapter at fe00
+5V: +4.90 V (min = +4.74 V, max = +5.25 V)
VTT: +1.72 V (min = +1.70 V, max = +2.10 V)
+3.3V: +3.35 V (min = +3.14 V, max = +3.47 V)
+Vcore:+1.98 V (min = +1.90 V, max = +2.10 V)
+12V: +11.30 V (min = +11.18 V, max = +12.63 V)
-12V: -11.88 V (min = -12.60 V, max = -11.39 V)
-5V: -4.92 V (min = -5.25 V, max = -4.76 V)
fan1: 1679 RPM (min = 1328 RPM, div = 4)
temp: +32.38°C (hot: limit = +60°C, hyst = +65°C)
: (os: limit = +54°C, hyst = +56°C)
Driver works with changes applied.
Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]>
Signed-off-by: Shawn Starr <[EMAIL PROTECTED]>
--- linux-2.6.11-rc2/drivers/i2c/chips/lm80.c 2005-01-26 02:04:38.0
-0500
+++ linux-2.6.11-rc2-fixes/drivers/i2c/chips/lm80.c 2005-01-26
02:41:00.0 -0500
@@ -72,7 +72,7 @@ SENSORS_INSMOD_1(lm80);
static inline unsigned char FAN_TO_REG(unsigned rpm, unsigned div)
{
- if (rpm == 0)
+ if (rpm <= 0)
return 255;
rpm = SENSORS_LIMIT(rpm, 1, 100);
return SENSORS_LIMIT((135 + rpm*div / 2) / (rpm*div), 1, 254);
@@ -99,10 +99,7 @@ static inline long TEMP_FROM_REG(u16 tem
#define TEMP_LIMIT_TO_REG(val) SENSORS_LIMIT((val)<0?\
((val)-500)/1000:((val)+500)/1000,0,255)
-#define ALARMS_FROM_REG(val) (val)
-
#define DIV_FROM_REG(val) (1 << (val))
-#define DIV_TO_REG(val) ((val)==8?3:(val)==4?2:(val)==1?0:1)
/*
* Client data (each client gets its own)
@@ -269,7 +266,17 @@ static ssize_t set_fan_div(struct device
DIV_FROM_REG(data->fan_div[nr]));
val = simple_strtoul(buf, NULL, 10);
- data->fan_div[nr] = DIV_TO_REG(val);
+
+ switch (val) {
+ case 1: data->fan_div[nr] = 0; break;
+ case 2: data->fan_div[nr] = 1; break;
+ case 4: data->fan_div[nr] = 2; break;
+ case 8: data->fan_div[nr] = 3; break;
+ default:
+ dev_err(>dev, "fan_div value %ld not "
+ "supported. Choose one of 1, 2, 4 or 8!\n", val);
+ return -EINVAL;
+ }
reg = (lm80_read_value(client, LM80_REG_FANDIV) & ~(3 << (2 * (nr + 1
| (data->fan_div[nr] << (2 * (nr + 1)));
@@ -327,7 +334,7 @@ set_temp(os_hyst, temp_os_hyst, LM80_REG
static ssize_t show_alarms(struct device *dev, char *buf)
{
struct lm80_data *data = lm80_update_device(dev);
- return sprintf(buf, "%d\n", ALARMS_FROM_REG(data->alarms));
+ return sprintf(buf, "%u\n", data->alarms);
}
static DEVICE_ATTR(in0_min, S_IWUSR | S_IRUGO, show_in_min0, set_in_min0);
-
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/
[PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien)
You know, after seeing that patch, that it just makes sense to add some of
those cleanups to the lm80 driver.
Shawn.
lm80-i2c-0-28
Adapter: SMBus PIIX4 adapter at fe00
+5V: +4.90 V (min = +4.74 V, max = +5.25 V)
VTT: +1.72 V (min = +1.70 V, max = +2.10 V)
+3.3V: +3.35 V (min = +3.14 V, max = +3.47 V)
+Vcore:+1.98 V (min = +1.90 V, max = +2.10 V)
+12V: +11.30 V (min = +11.18 V, max = +12.63 V)
-12V: -11.88 V (min = -12.60 V, max = -11.39 V)
-5V: -4.92 V (min = -5.25 V, max = -4.76 V)
fan1: 1679 RPM (min = 1328 RPM, div = 4)
temp: +32.38°C (hot: limit = +60°C, hyst = +65°C)
: (os: limit = +54°C, hyst = +56°C)
Driver works with changes applied.
Signed-off-by: Aurelien Jarno [EMAIL PROTECTED]
Signed-off-by: Shawn Starr [EMAIL PROTECTED]
--- linux-2.6.11-rc2/drivers/i2c/chips/lm80.c 2005-01-26 02:04:38.0
-0500
+++ linux-2.6.11-rc2-fixes/drivers/i2c/chips/lm80.c 2005-01-26
02:41:00.0 -0500
@@ -72,7 +72,7 @@ SENSORS_INSMOD_1(lm80);
static inline unsigned char FAN_TO_REG(unsigned rpm, unsigned div)
{
- if (rpm == 0)
+ if (rpm = 0)
return 255;
rpm = SENSORS_LIMIT(rpm, 1, 100);
return SENSORS_LIMIT((135 + rpm*div / 2) / (rpm*div), 1, 254);
@@ -99,10 +99,7 @@ static inline long TEMP_FROM_REG(u16 tem
#define TEMP_LIMIT_TO_REG(val) SENSORS_LIMIT((val)0?\
((val)-500)/1000:((val)+500)/1000,0,255)
-#define ALARMS_FROM_REG(val) (val)
-
#define DIV_FROM_REG(val) (1 (val))
-#define DIV_TO_REG(val) ((val)==8?3:(val)==4?2:(val)==1?0:1)
/*
* Client data (each client gets its own)
@@ -269,7 +266,17 @@ static ssize_t set_fan_div(struct device
DIV_FROM_REG(data-fan_div[nr]));
val = simple_strtoul(buf, NULL, 10);
- data-fan_div[nr] = DIV_TO_REG(val);
+
+ switch (val) {
+ case 1: data-fan_div[nr] = 0; break;
+ case 2: data-fan_div[nr] = 1; break;
+ case 4: data-fan_div[nr] = 2; break;
+ case 8: data-fan_div[nr] = 3; break;
+ default:
+ dev_err(client-dev, fan_div value %ld not
+ supported. Choose one of 1, 2, 4 or 8!\n, val);
+ return -EINVAL;
+ }
reg = (lm80_read_value(client, LM80_REG_FANDIV) ~(3 (2 * (nr + 1
| (data-fan_div[nr] (2 * (nr + 1)));
@@ -327,7 +334,7 @@ set_temp(os_hyst, temp_os_hyst, LM80_REG
static ssize_t show_alarms(struct device *dev, char *buf)
{
struct lm80_data *data = lm80_update_device(dev);
- return sprintf(buf, %d\n, ALARMS_FROM_REG(data-alarms));
+ return sprintf(buf, %u\n, data-alarms);
}
static DEVICE_ATTR(in0_min, S_IWUSR | S_IRUGO, show_in_min0, set_in_min0);
-
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: [PATCH 2.6.11-rc2] I2C: lm80 driver improvement (From Aurelien) - Resubmit
You know, after seeing that patch, that it just makes sense to add some of
those cleanups to the lm80 driver.
Shawn.
lm80-i2c-0-28
Adapter: SMBus PIIX4 adapter at fe00
+5V: +4.90 V (min = +4.74 V, max = +5.25 V)
VTT: +1.72 V (min = +1.70 V, max = +2.10 V)
+3.3V: +3.35 V (min = +3.14 V, max = +3.47 V)
+Vcore:+1.98 V (min = +1.90 V, max = +2.10 V)
+12V: +11.30 V (min = +11.18 V, max = +12.63 V)
-12V: -11.88 V (min = -12.60 V, max = -11.39 V)
-5V: -4.92 V (min = -5.25 V, max = -4.76 V)
fan1: 1679 RPM (min = 1328 RPM, div = 4)
temp: +32.38°C (hot: limit = +60°C, hyst = +65°C)
: (os: limit = +54°C, hyst = +56°C)
Driver works with changes applied.
Signed-off-by: Aurelien Jarno [EMAIL PROTECTED]
Signed-off-by: Shawn Starr [EMAIL PROTECTED]
* Note to self, dont use Kmail for raw diff files
--- linux-2.6.11-rc2/drivers/i2c/chips/lm80.c 2005-01-26 02:04:38.0 -0500
+++ linux-2.6.11-rc2-fixes/drivers/i2c/chips/lm80.c 2005-01-26 02:41:00.0 -0500
@@ -72,7 +72,7 @@ SENSORS_INSMOD_1(lm80);
static inline unsigned char FAN_TO_REG(unsigned rpm, unsigned div)
{
- if (rpm == 0)
+ if (rpm = 0)
return 255;
rpm = SENSORS_LIMIT(rpm, 1, 100);
return SENSORS_LIMIT((135 + rpm*div / 2) / (rpm*div), 1, 254);
@@ -99,10 +99,7 @@ static inline long TEMP_FROM_REG(u16 tem
#define TEMP_LIMIT_TO_REG(val) SENSORS_LIMIT((val)0?\
((val)-500)/1000:((val)+500)/1000,0,255)
-#define ALARMS_FROM_REG(val) (val)
-
#define DIV_FROM_REG(val) (1 (val))
-#define DIV_TO_REG(val) ((val)==8?3:(val)==4?2:(val)==1?0:1)
/*
* Client data (each client gets its own)
@@ -269,7 +266,17 @@ static ssize_t set_fan_div(struct device
DIV_FROM_REG(data-fan_div[nr]));
val = simple_strtoul(buf, NULL, 10);
- data-fan_div[nr] = DIV_TO_REG(val);
+
+ switch (val) {
+ case 1: data-fan_div[nr] = 0; break;
+ case 2: data-fan_div[nr] = 1; break;
+ case 4: data-fan_div[nr] = 2; break;
+ case 8: data-fan_div[nr] = 3; break;
+ default:
+ dev_err(client-dev, fan_div value %ld not
+ supported. Choose one of 1, 2, 4 or 8!\n, val);
+ return -EINVAL;
+ }
reg = (lm80_read_value(client, LM80_REG_FANDIV) ~(3 (2 * (nr + 1
| (data-fan_div[nr] (2 * (nr + 1)));
@@ -327,7 +334,7 @@ set_temp(os_hyst, temp_os_hyst, LM80_REG
static ssize_t show_alarms(struct device *dev, char *buf)
{
struct lm80_data *data = lm80_update_device(dev);
- return sprintf(buf, %d\n, ALARMS_FROM_REG(data-alarms));
+ return sprintf(buf, %u\n, data-alarms);
}
static DEVICE_ATTR(in0_min, S_IWUSR | S_IRUGO, show_in_min0, set_in_min0);
Kernel HOWTO update?
Section: 7.6 You forgot to run LILO, or system doesn't boot at all You might want to update the following line: "Using LILO with big drives (more than 1024 cylinders) can cause problems. See the LILO mini-HOWTO or documentation for help on that." This isn't true anymore unless your using an older version of LILO. Shawn. - 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/
Kernel HOWTO update?
Section: 7.6 You forgot to run LILO, or system doesn't boot at all You might want to update the following line: Using LILO with big drives (more than 1024 cylinders) can cause problems. See the LILO mini-HOWTO or documentation for help on that. This isn't true anymore unless your using an older version of LILO. Shawn. - 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: The Joy of Forking
Fork nothing, stop taking stupidity. The kernel SOURCES may be 26MB but that does NOT mean you have to use every driver! Shawn. On Mon, 25 Jun 2001, Rick Hohensee wrote: > > > > Rick Hohensee <[EMAIL PROTECTED]> said: > > > 2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has > > > already stuck his tippy-toe is that pool, and his toe is fine. > > > > Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave > > Miller, or any of the arch maintainers. Alan has said several times that he > > will sync up with Linus, and he still stages patches upwards. Alan doesn't > > like the "all shall be devfs" ukase (and neither do I, BTW), and will > > maintain non-devfs systems for the time being. > > > > I do see the merit of some kind of devfs, but there still is a lot of stuff > > that needs a more reasonable solution, so no thanks for now. > > I've had quite a good two rants lately and will be happy to get on to > other things for now. My point is to think of devfs and dozens of other > things in the context of more than one Linux. Just a thought. > > Rick Hohensee > www.clienux.com > > > -- > > Horst von Brand [EMAIL PROTECTED] > > Casilla 9G, Vin~a del Mar, Chile +56 32 672616 > > > > - > 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/ > > - 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: EXT2 Filesystem permissions (bug)?
oh ;) I never noticed that info before, then again 2 hours of sleep might be the cause :) On 25 Jun 2001, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author: Shawn Starr <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Is this a bug or something thats undocumented somewhere? > > > > dT > > and > > drwSrwSrwT > > > > are these special bits? I'm not aware of +S and +T > > > > It's neither a bug nor undocumented. > > "info ls" would have told you the following: > > The permissions listed are similar to symbolic mode > specifications > (*note Symbolic Modes::.). But `ls' combines multiple bits into > the third character of each set of permissions as follows: > `s' > If the setuid or setgid bit and the corresponding executable > bit are both set. > > `S' > If the setuid or setgid bit is set but the corresponding > executable bit is not set. > > `t' > If the sticky bit and the other-executable bit are both set. > > `T' > If the sticky bit is set but the other-executable bit is not > set. > > `x' > If the executable bit is set and none of the above apply. > > `-' > Otherwise. > > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt > - > 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/ > > - 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/
EXT2 Filesystem permissions (bug)?
Is this a bug or something thats undocumented somewhere? dT and drwSrwSrwT are these special bits? I'm not aware of +S and +T Shawn. - 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: Linux 2.4.6-pre3 breaks ReiserFS mount on boot
Not /dev/hda42, thats odd. From 2.4.5 -> 2.4.6 ReiserFS would refuse to mount the drive on startup. I noticed in pre5 there was a reiserfs fix to something but im not sure if its related or not. My domain is also back so I'm going to resubscribe. Shawn. On Tue, 19 Jun 2001, Neil Brown wrote: > On Tuesday June 19, [EMAIL PROTECTED] wrote: > > On Mon, Jun 18, 2001 at 11:57:16PM -0400, Shawn Starr wrote: > > > > > > read_super_block: can't find a reiserfs filesystem on dev 03:42 > > > read_old_super_block: try to find super block in old location > > > read_old_super_block: can't find a reiserfs filesystem on dev 03:42 > > > Kernel Panic: VFS: Unable to mount root fs on 03:42 > > > > > > my super block broke somewhere? > > > > Out of curiousity, what device are you trying to boot from? 03:42, at least > > according to linux/Documentation/devices.txt, corresponds to /dev/hda42. > > or, noting that kdevname used hexadecimal, > /dev/hdb2 > > NeilBrown > > > > > Is that really the disk you're trying to mount? I'm not familiar with how > > some IDE RAID controllers present disks, but it was the first thing I > > noticed. > > > > -Jeff > > > > -- > > Jeff Mahoney > > [EMAIL PROTECTED] > > [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/ > > - 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: Linux 2.4.6-pre3 breaks ReiserFS mount on boot
Not /dev/hda42, thats odd. From 2.4.5 - 2.4.6 ReiserFS would refuse to mount the drive on startup. I noticed in pre5 there was a reiserfs fix to something but im not sure if its related or not. My domain is also back so I'm going to resubscribe. Shawn. On Tue, 19 Jun 2001, Neil Brown wrote: On Tuesday June 19, [EMAIL PROTECTED] wrote: On Mon, Jun 18, 2001 at 11:57:16PM -0400, Shawn Starr wrote: read_super_block: can't find a reiserfs filesystem on dev 03:42 read_old_super_block: try to find super block in old location read_old_super_block: can't find a reiserfs filesystem on dev 03:42 Kernel Panic: VFS: Unable to mount root fs on 03:42 my super block broke somewhere? Out of curiousity, what device are you trying to boot from? 03:42, at least according to linux/Documentation/devices.txt, corresponds to /dev/hda42. or, noting that kdevname used hexadecimal, /dev/hdb2 NeilBrown Is that really the disk you're trying to mount? I'm not familiar with how some IDE RAID controllers present disks, but it was the first thing I noticed. -Jeff -- Jeff Mahoney [EMAIL PROTECTED] [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/ - 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/
EXT2 Filesystem permissions (bug)?
Is this a bug or something thats undocumented somewhere? dT and drwSrwSrwT are these special bits? I'm not aware of +S and +T Shawn. - 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: EXT2 Filesystem permissions (bug)?
oh ;) I never noticed that info before, then again 2 hours of sleep might be the cause :) On 25 Jun 2001, H. Peter Anvin wrote: Followup to: [EMAIL PROTECTED] By author:Shawn Starr [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Is this a bug or something thats undocumented somewhere? dT and drwSrwSrwT are these special bits? I'm not aware of +S and +T It's neither a bug nor undocumented. info ls would have told you the following: The permissions listed are similar to symbolic mode specifications (*note Symbolic Modes::.). But `ls' combines multiple bits into the third character of each set of permissions as follows: `s' If the setuid or setgid bit and the corresponding executable bit are both set. `S' If the setuid or setgid bit is set but the corresponding executable bit is not set. `t' If the sticky bit and the other-executable bit are both set. `T' If the sticky bit is set but the other-executable bit is not set. `x' If the executable bit is set and none of the above apply. `-' Otherwise. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! Unix gives you enough rope to shoot yourself in the foot. http://www.zytor.com/~hpa/puzzle.txt - 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/ - 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: The Joy of Forking
Fork nothing, stop taking stupidity. The kernel SOURCES may be 26MB but that does NOT mean you have to use every driver! Shawn. On Mon, 25 Jun 2001, Rick Hohensee wrote: Rick Hohensee [EMAIL PROTECTED] said: 2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has already stuck his tippy-toe is that pool, and his toe is fine. Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave Miller, or any of the arch maintainers. Alan has said several times that he will sync up with Linus, and he still stages patches upwards. Alan doesn't like the all shall be devfs ukase (and neither do I, BTW), and will maintain non-devfs systems for the time being. I do see the merit of some kind of devfs, but there still is a lot of stuff that needs a more reasonable solution, so no thanks for now. I've had quite a good two rants lately and will be happy to get on to other things for now. My point is to think of devfs and dozens of other things in the context of more than one Linux. Just a thought. Rick Hohensee www.clienux.com -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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/ - 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: Linux 2.4.6-pre3 breaks ReiserFS mount on boot
read_super_block: can't find a reiserfs filesystem on dev 03:42 read_old_super_block: try to find super block in old location read_old_super_block: can't find a reiserfs filesystem on dev 03:42 Kernel Panic: VFS: Unable to mount root fs on 03:42 my super block broke somewhere? Shawn. On Mon, 18 Jun 2001, Shawn Starr wrote: > > Two things: > > 1) It broke apparently with gcc 2.95.3 when patching from 2.4.6-pre2 -> > 2.4.6pre3 > > 2) I tried building it with gcc 3.00 and had same result. > > 3) I now have gcc 3.00 and going to rebuild 2.4.6-pre2 and see if reiserfs > panics if it doesn't there's an issue with the new pre3 modifications. > > I hope ReiserFS *MAINTAINS* compatability from slightly older revisions, > or even migrates systems over to handle new issues. > > Shawn. > > On Mon, 18 Jun 2001, Olivier Galibert wrote: > > > On Mon, Jun 18, 2001 at 10:58:57PM -0400, Shawn Starr wrote: > > > When diffing 2.4.6-pre2 & pre3 I noticed some reiserfs code was changed. > > > This seems to cause VFS to panic via reiserfs. > > > > > > Anyone else notice this? > > > > I don't, and I boot on reiserfs. > > > > OG. > > - > > 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/ > > > > > > - 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: Linux 2.4.6-pre3 breaks ReiserFS mount on boot
Two things: 1) It broke apparently with gcc 2.95.3 when patching from 2.4.6-pre2 -> 2.4.6pre3 2) I tried building it with gcc 3.00 and had same result. 3) I now have gcc 3.00 and going to rebuild 2.4.6-pre2 and see if reiserfs panics if it doesn't there's an issue with the new pre3 modifications. I hope ReiserFS *MAINTAINS* compatability from slightly older revisions, or even migrates systems over to handle new issues. Shawn. On Mon, 18 Jun 2001, Olivier Galibert wrote: > On Mon, Jun 18, 2001 at 10:58:57PM -0400, Shawn Starr wrote: > > When diffing 2.4.6-pre2 & pre3 I noticed some reiserfs code was changed. > > This seems to cause VFS to panic via reiserfs. > > > > Anyone else notice this? > > I don't, and I boot on reiserfs. > > OG. > - > 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/ > > - 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/
Linux 2.4.6-pre3 breaks ReiserFS mount on boot
When diffing 2.4.6-pre2 & pre3 I noticed some reiserfs code was changed. This seems to cause VFS to panic via reiserfs. Anyone else notice this? Shawn. - 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/
Linux 2.4.6-pre3 breaks ReiserFS mount on boot
When diffing 2.4.6-pre2 pre3 I noticed some reiserfs code was changed. This seems to cause VFS to panic via reiserfs. Anyone else notice this? Shawn. - 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: Linux 2.4.6-pre3 breaks ReiserFS mount on boot
Two things: 1) It broke apparently with gcc 2.95.3 when patching from 2.4.6-pre2 - 2.4.6pre3 2) I tried building it with gcc 3.00 and had same result. 3) I now have gcc 3.00 and going to rebuild 2.4.6-pre2 and see if reiserfs panics if it doesn't there's an issue with the new pre3 modifications. I hope ReiserFS *MAINTAINS* compatability from slightly older revisions, or even migrates systems over to handle new issues. Shawn. On Mon, 18 Jun 2001, Olivier Galibert wrote: On Mon, Jun 18, 2001 at 10:58:57PM -0400, Shawn Starr wrote: When diffing 2.4.6-pre2 pre3 I noticed some reiserfs code was changed. This seems to cause VFS to panic via reiserfs. Anyone else notice this? I don't, and I boot on reiserfs. OG. - 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/ - 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: Linux 2.4.6-pre3 breaks ReiserFS mount on boot
read_super_block: can't find a reiserfs filesystem on dev 03:42 read_old_super_block: try to find super block in old location read_old_super_block: can't find a reiserfs filesystem on dev 03:42 Kernel Panic: VFS: Unable to mount root fs on 03:42 my super block broke somewhere? Shawn. On Mon, 18 Jun 2001, Shawn Starr wrote: Two things: 1) It broke apparently with gcc 2.95.3 when patching from 2.4.6-pre2 - 2.4.6pre3 2) I tried building it with gcc 3.00 and had same result. 3) I now have gcc 3.00 and going to rebuild 2.4.6-pre2 and see if reiserfs panics if it doesn't there's an issue with the new pre3 modifications. I hope ReiserFS *MAINTAINS* compatability from slightly older revisions, or even migrates systems over to handle new issues. Shawn. On Mon, 18 Jun 2001, Olivier Galibert wrote: On Mon, Jun 18, 2001 at 10:58:57PM -0400, Shawn Starr wrote: When diffing 2.4.6-pre2 pre3 I noticed some reiserfs code was changed. This seems to cause VFS to panic via reiserfs. Anyone else notice this? I don't, and I boot on reiserfs. OG. - 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/ - 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: Gigabit Intel NIC? - Intel Gigabit Ethernet Pro/1000T
We're testing the cards to see how much traffic they can handle (on Linux & OpenBSD) So, if we do get the specs (and if without any NDAs) I would be happy to pass them on to the Linux community. I'm not a kernel developer, just a bug finder when I see things. Shawn. On 11 Jun 2001 15:59:38 -0700, Ken Brownfield wrote: > We did some brief testing with this card a couple of months ago. The > original drivers were pretty flaky but the recent drivers seem fine. I > haven't done extremely heavy traffic or testing (no longer have the > switch and multiple machines) but I've been compiling and loading the > module for a while now with 2.4.x. > > FWIW, > -- > Ken. > > On Monday, June 11, 2001, at 03:42 PM, Shawn Starr wrote: > > > > > How good is the linux kernel driver for the Intel gigabit Ethernet > > NIC (copper) with the TL82543GC chipset? The card says it's > > a "PRO/1000T" server adapter, and it looks like the part > > number A19845-003. > > > > The sales guy who is promoting it says this is apparently a new > > card and he claims he can get specs from engineering. > > Not sure about NDA status. > > > > So my question is... is it worth calling this guy's bluff? > > > > Shawn. > > > > - > > 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/ > - 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/
Gigabit Intel NIC? - Intel Gigabit Ethernet Pro/1000T
How good is the linux kernel driver for the Intel gigabit Ethernet NIC (copper) with the TL82543GC chipset? The card says it's a "PRO/1000T" server adapter, and it looks like the part number A19845-003. The sales guy who is promoting it says this is apparently a new card and he claims he can get specs from engineering. Not sure about NDA status. So my question is... is it worth calling this guy's bluff? Shawn. - 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/
Gigabit Intel NIC? - Intel Gigabit Ethernet Pro/1000T
How good is the linux kernel driver for the Intel gigabit Ethernet NIC (copper) with the TL82543GC chipset? The card says it's a PRO/1000T server adapter, and it looks like the part number A19845-003. The sales guy who is promoting it says this is apparently a new card and he claims he can get specs from engineering. Not sure about NDA status. So my question is... is it worth calling this guy's bluff? Shawn. - 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: Gigabit Intel NIC? - Intel Gigabit Ethernet Pro/1000T
We're testing the cards to see how much traffic they can handle (on Linux OpenBSD) So, if we do get the specs (and if without any NDAs) I would be happy to pass them on to the Linux community. I'm not a kernel developer, just a bug finder when I see things. Shawn. On 11 Jun 2001 15:59:38 -0700, Ken Brownfield wrote: We did some brief testing with this card a couple of months ago. The original drivers were pretty flaky but the recent drivers seem fine. I haven't done extremely heavy traffic or testing (no longer have the switch and multiple machines) but I've been compiling and loading the module for a while now with 2.4.x. FWIW, -- Ken. On Monday, June 11, 2001, at 03:42 PM, Shawn Starr wrote: How good is the linux kernel driver for the Intel gigabit Ethernet NIC (copper) with the TL82543GC chipset? The card says it's a PRO/1000T server adapter, and it looks like the part number A19845-003. The sales guy who is promoting it says this is apparently a new card and he claims he can get specs from engineering. Not sure about NDA status. So my question is... is it worth calling this guy's bluff? Shawn. - 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/ - 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/
Kernel 2.4.6-pre2 patch buglet
Is it me or does this patch forget to change the kernel version? ;-) make menuconfig reports pre1 still.. oh well no biggie.. Shawn. - 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/
Kernel 2.4.6-pre2 patch buglet
Is it me or does this patch forget to change the kernel version? ;-) make menuconfig reports pre1 still.. oh well no biggie.. Shawn. - 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: 2.4.6-pre1 unresolved symbols
Thanks, Patch applied. On Tue, 5 Jun 2001, Jeff Garzik wrote: > Shawn Starr wrote: > > > > I have noticed unresolves symbols for the netfilter modules. this occurs > > durning depmod -a. > > Note they are the same unresolved symbol. > > Ingo Molnar has posted a patch for this, entitled > [patch] softirq-2.4.6-B4 > > or you can edit kernel/ksyms.c yourself, and add the lines > > EXPORT_SYMBOL(do_softirq); > EXPORT_SYMBOL(tasklet_schedule); > EXPORT_SYMBOL(tasklet_hi_schedule); > > -- > Jeff Garzik | An expert is one who knows more and more about > Building 1024| less and less until he knows absolutely everything > MandrakeSoft | about nothing. > > - 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: 2.4.6-pre1 unresolved symbols
I have noticed unresolves symbols for the netfilter modules. this occurs durning depmod -a. Shawn. On Tue, 5 Jun 2001, George Bonser wrote: > > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/net/3c59x.o > depmod: do_softirq > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/net/bonding.o > depmod: do_softirq > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/net/plip.o > depmod: tasklet_hi_schedule > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/net/ppp_generic.o > depmod: do_softirq > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/net/slip.o > depmod: do_softirq > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/scsi/imm.o > depmod: tasklet_hi_schedule > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/scsi/ppa.o > depmod: tasklet_hi_schedule > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/net/ipv6/ipv6.o > depmod: do_softirq > > - > 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/ > > - 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: 2.4.6-pre1 unresolved symbols
I have noticed unresolves symbols for the netfilter modules. this occurs durning depmod -a. Shawn. On Tue, 5 Jun 2001, George Bonser wrote: depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/3c59x.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/bonding.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/plip.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/ppp_generic.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/slip.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/scsi/imm.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/scsi/ppa.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/net/ipv6/ipv6.o depmod: do_softirq - 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/ - 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: 2.4.6-pre1 unresolved symbols
Thanks, Patch applied. On Tue, 5 Jun 2001, Jeff Garzik wrote: Shawn Starr wrote: I have noticed unresolves symbols for the netfilter modules. this occurs durning depmod -a. Note they are the same unresolved symbol. Ingo Molnar has posted a patch for this, entitled [patch] softirq-2.4.6-B4 or you can edit kernel/ksyms.c yourself, and add the lines EXPORT_SYMBOL(do_softirq); EXPORT_SYMBOL(tasklet_schedule); EXPORT_SYMBOL(tasklet_hi_schedule); -- Jeff Garzik | An expert is one who knows more and more about Building 1024| less and less until he knows absolutely everything MandrakeSoft | about nothing. - 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: compile failure in 2.4.5-pre4
Ok, so the code was easy to fix ;p
On Mon, 21 May 2001, Keith Owens wrote:
> On Mon, 21 May 101 16:38:45 +1000 (EST),
> Allan Duncan <[EMAIL PROTECTED]> wrote:
> >drivers/ide/ide-pci.c:711
> > if (!IDE_PCI_DEVID_EQ(d->devid, DEVID_CS5530)
>
> for (i = 0; i < 1000; ++i)
> printf("I must scan kernel archives before report bugs\n");
>
> http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg45470.html
>
> >Allan Duncan [EMAIL PROTECTED] (+613) 9253 6708, Fax 9253 6775
> > (We are just a number)
>
> Who is number 1?
> You are number 6.
> I am not a number, I am a free man!
>
> -
> 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/
>
>
-
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: compile failure in 2.4.5-pre4
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o ide-pci.o ide-pci.c ide-pci.c: In function `ide_setup_pci_device': ide-pci.c:712: parse error before `hwif' make[3]: *** [ide-pci.o] Error 1 Yeah, same compile bug. On Mon, 21 May 101, Allan Duncan wrote: > This addition for 2.4.5-pre4 has caused a compile failure with a parsing error: > > drivers/ide/ide-pci.c:711 > if (!IDE_PCI_DEVID_EQ(d->devid, DEVID_CS5530) > > In my case CONFIG_BLK_DEV_CS5530 is not defined. > > -- > Allan Duncan [EMAIL PROTECTED] (+613) 9253 6708, Fax 9253 6775 > (We are just a number) > Next Generation Infrastructure Program - Transport Architecture Project > Telstra Research Labs, Box 249 Rosebank MDC, Clayton, Victoria, 3169, Australia > - > 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/ > > - 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: compile failure in 2.4.5-pre4
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586-c -o ide-pci.o ide-pci.c ide-pci.c: In function `ide_setup_pci_device': ide-pci.c:712: parse error before `hwif' make[3]: *** [ide-pci.o] Error 1 Yeah, same compile bug. On Mon, 21 May 101, Allan Duncan wrote: This addition for 2.4.5-pre4 has caused a compile failure with a parsing error: drivers/ide/ide-pci.c:711 if (!IDE_PCI_DEVID_EQ(d-devid, DEVID_CS5530) In my case CONFIG_BLK_DEV_CS5530 is not defined. -- Allan Duncan [EMAIL PROTECTED] (+613) 9253 6708, Fax 9253 6775 (We are just a number) Next Generation Infrastructure Program - Transport Architecture Project Telstra Research Labs, Box 249 Rosebank MDC, Clayton, Victoria, 3169, Australia - 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/ - 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: compile failure in 2.4.5-pre4
Ok, so the code was easy to fix ;p On Mon, 21 May 2001, Keith Owens wrote: On Mon, 21 May 101 16:38:45 +1000 (EST), Allan Duncan [EMAIL PROTECTED] wrote: drivers/ide/ide-pci.c:711 if (!IDE_PCI_DEVID_EQ(d-devid, DEVID_CS5530) for (i = 0; i 1000; ++i) printf(I must scan kernel archives before report bugs\n); http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg45470.html Allan Duncan [EMAIL PROTECTED] (+613) 9253 6708, Fax 9253 6775 (We are just a number) Who is number 1? You are number 6. I am not a number, I am a free man! - 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/ - 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/
Mail admin notice
My emails may bounce between 3AM -> 8AM Est time, @Home is doing some fiber upgrades and i dont have a second MX server (as I am the domain/dns/mail etc). Please bear with bounces until then. Shawn. - 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/
Mail admin notice
My emails may bounce between 3AM - 8AM Est time, @Home is doing some fiber upgrades and i dont have a second MX server (as I am the domain/dns/mail etc). Please bear with bounces until then. Shawn. - 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: kernel.org: 2.4.5-pre4 missing ChangeLog info - scratch that
It's in ChangeLog but not patch-2.4.5.log. Shawn. On Sat, 19 May 2001, Shawn Starr wrote: > Someone add the changelog info to kernel.org? > > merci. > > Shawn. > > - 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/
kernel.org: 2.4.5-pre4 missing ChangeLog info
Someone add the changelog info to kernel.org? merci. Shawn. - 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/
kernel.org: 2.4.5-pre4 missing ChangeLog info
Someone add the changelog info to kernel.org? merci. Shawn. - 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: kernel.org: 2.4.5-pre4 missing ChangeLog info - scratch that
It's in ChangeLog but not patch-2.4.5.log. Shawn. On Sat, 19 May 2001, Shawn Starr wrote: Someone add the changelog info to kernel.org? merci. Shawn. - 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/
Mail boucing...
Sorry if my mail has been bouncing. I've been experimenting with some configurations and I am moving tomorrow so my domain/IP will be changing. Whoever, deleted me from list, thanks. Please don't block sh0n.net though from posting. I'll read myself when my new IP is added to my domain. Thank you. Shawn. - 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/
Mail boucing...
Sorry if my mail has been bouncing. I've been experimenting with some configurations and I am moving tomorrow so my domain/IP will be changing. Whoever, deleted me from list, thanks. Please don't block sh0n.net though from posting. I'll read myself when my new IP is added to my domain. Thank you. Shawn. - 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/
Serious Latency problems : 2.4.4-pre5
Note: I'm not on this mailing list (for now, domain IP is changing). Please email directly 1) I've noticed very high CPU load 3.00 running ./configure alone 2) some gnome applications (Gnome Mailcheck broke with 2.4.4-pre5) 3) Resolving local domains takes an awful long time (though netscape) but not with 2.4.3. Odd bugs... reverted for now. Shawn. - 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/
Serious Latency problems : 2.4.4-pre5
Note: I'm not on this mailing list (for now, domain IP is changing). Please email directly 1) I've noticed very high CPU load 3.00 running ./configure alone 2) some gnome applications (Gnome Mailcheck broke with 2.4.4-pre5) 3) Resolving local domains takes an awful long time (though netscape) but not with 2.4.3. Odd bugs... reverted for now. Shawn. - 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: gcc-2.95.3
You should be ok :) On Fri, 6 Apr 2001, Jeff Chua wrote: > > Does anybody have bad experience with gcc-2.95.3? > > I'm using gcc-2.95.2 with linux 2.4.3 and have no problem with it. > > > Thanks, > Jeff > [ [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/ > > - 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: gcc-2.95.3
You should be ok :) On Fri, 6 Apr 2001, Jeff Chua wrote: Does anybody have bad experience with gcc-2.95.3? I'm using gcc-2.95.2 with linux 2.4.3 and have no problem with it. Thanks, Jeff [ [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/ - 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: ReiserFS? How reliable is it? Is this the future?
I've had 0, Ziltch problems with ReiserFS at the moment. It's solid for me. On Tue, 3 Apr 2001, Harald Dunkel wrote: > Hi folks, > > If I get the DVD stuff working, then I won't need NT anymore, i.e. > I will have an empty disk. > > What is your impression about ReiserFS? Does it work? Is it stable > enough for my daily work, or is it something to try out and watch > carefully? Do you use ReiserFS for your boot partition? > > Or should I try ext3 instead? > > > Regards > > Harri > - > 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/ > > - 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: ReiserFS? How reliable is it? Is this the future?
I've had 0, Ziltch problems with ReiserFS at the moment. It's solid for me. On Tue, 3 Apr 2001, Harald Dunkel wrote: Hi folks, If I get the DVD stuff working, then I won't need NT anymore, i.e. I will have an empty disk. What is your impression about ReiserFS? Does it work? Is it stable enough for my daily work, or is it something to try out and watch carefully? Do you use ReiserFS for your boot partition? Or should I try ext3 instead? Regards Harri - 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/ - 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: Strange lines in dmesg
Na, thats ok, that's just a dumping of debug info :) Not to worry. On Fri, 30 Mar 2001, Denis Perchine wrote: > Hello, > > I got the following lines in dmesg: > > freesibling > task PCstack pid father child younger older > init S C144DF28 4912 1 0 840 (NOTLB) > Call Trace: [] [] [] [] [] > [] > keventd S 6020 2 1(L-TLB) 3 > Call Trace: [] [] > kswapdS C1455FAC 5812 3 1(L-TLB) 4 2 > Call Trace: [] [] [] [] [] > kreclaimd S 0286 6316 4 1(L-TLB) 5 3 > Call Trace: [] [] [] > bdflush S C145 5972 5 1(L-TLB) 6 4 > Call Trace: [] [] > kupdated S C147FFC8 6296 6 1(L-TLB) 197 5 > > And more for other processes. > > As far as I can understand lines containing 'Call Trace' are printed in > trap.c in show_trace function. Does anyone know what this thing can mean, and > how to found a real reason? > > Problem is that on this machine I have install 2.3.2-ac26 + Morton's patch to > allow very large processes not be killed when there are not reused pages in > swap, etc. > > My sci advisor have real problem as his process beying killed when reached > 960Mb. There is 256Mb of RAM in machine, and 1.5Gb of swap... It looks like > it is again a problem with kernel does not use all possibilities before kill > a process. > > And what worries me is that I found mentioned above lines in kernel log. > > -- > Sincerely Yours, > Denis Perchine > > -- > E-Mail: [EMAIL PROTECTED] > HomePage: http://www.perchine.com/dyp/ > FidoNet: 2:5000/120.5 > -- > - > 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/ > > - 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: Strange lines in dmesg
Na, thats ok, that's just a dumping of debug info :) Not to worry. On Fri, 30 Mar 2001, Denis Perchine wrote: Hello, I got the following lines in dmesg: freesibling task PCstack pid father child younger older init S C144DF28 4912 1 0 840 (NOTLB) Call Trace: [c0ab] [c01110f0] [c01398e5] [c0139c8e] [c01330c4] [c0106dd7] keventd S 6020 2 1(L-TLB) 3 Call Trace: [c011d9db] [c01054f4] kswapdS C1455FAC 5812 3 1(L-TLB) 4 2 Call Trace: [c0ab] [c01110f0] [c01116ea] [c0127499] [c01054f4] kreclaimd S 0286 6316 4 1(L-TLB) 5 3 Call Trace: [c0111695] [c012754b] [c01054f4] bdflush S C145 5972 5 1(L-TLB) 6 4 Call Trace: [c012f97e] [c01054f4] kupdated S C147FFC8 6296 6 1(L-TLB) 197 5 And more for other processes. As far as I can understand lines containing 'Call Trace' are printed in trap.c in show_trace function. Does anyone know what this thing can mean, and how to found a real reason? Problem is that on this machine I have install 2.3.2-ac26 + Morton's patch to allow very large processes not be killed when there are not reused pages in swap, etc. My sci advisor have real problem as his process beying killed when reached 960Mb. There is 256Mb of RAM in machine, and 1.5Gb of swap... It looks like it is again a problem with kernel does not use all possibilities before kill a process. And what worries me is that I found mentioned above lines in kernel log. -- Sincerely Yours, Denis Perchine -- E-Mail: [EMAIL PROTECTED] HomePage: http://www.perchine.com/dyp/ FidoNet: 2:5000/120.5 -- - 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/ - 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: [WISHLIST] Addition of suspend patch into 2.5?
Not only for laptops :) It's nice for PCs too also. On Thu, 29 Mar 2001, Robert-Velisav MICIOVICI wrote: > > Just a small adition to the 2.5 whislist: > Is "hibernation" on linux possible? Ideally it should write out on the / > running on ext2fs and the new journaling fs's like reiserfs, xfs, etx3 etc > and not some special filesystem or unpartiotioned space etc. I mean that > this should be working without the need to repartiotion/reinstall. > This is something **very** useful for laptop owners, not having to shut > down (all) applications when need to grab the laptop and travel. > Id' like to see this working nice in 2.6. > > Best regards, > r > > On Thu, 22 Feb 2001, Pavel Machek wrote: > > > Date: Thu, 22 Feb 2001 21:43:08 +0100 > > From: Pavel Machek <[EMAIL PROTECTED]> > > To: Shawn Starr <[EMAIL PROTECTED]>, lkm <[EMAIL PROTECTED]> > > Subject: Re: [WISHLIST] Addition of suspend patch into 2.5? > > > > Hi! > > > > > Any idea if suspend/hybernation will be in future kernels? > > > > I'd like it included, too. Some toshiba laptops support sleep but not > > suspend, and battery runs out within few hours if it was low before > > suspend. That's bad. > > > > And the patch was pretty clean last time I checked. > > Pavel > > -- > > I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." > > Panos Katsaloulis describing me w.r.t. patents at [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/ > > > > - > 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/ > > - 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: [WISHLIST] Addition of suspend patch into 2.5?
Not only for laptops :) It's nice for PCs too also. On Thu, 29 Mar 2001, Robert-Velisav MICIOVICI wrote: Just a small adition to the 2.5 whislist: Is "hibernation" on linux possible? Ideally it should write out on the / running on ext2fs and the new journaling fs's like reiserfs, xfs, etx3 etc and not some special filesystem or unpartiotioned space etc. I mean that this should be working without the need to repartiotion/reinstall. This is something **very** useful for laptop owners, not having to shut down (all) applications when need to grab the laptop and travel. Id' like to see this working nice in 2.6. Best regards, r On Thu, 22 Feb 2001, Pavel Machek wrote: Date: Thu, 22 Feb 2001 21:43:08 +0100 From: Pavel Machek [EMAIL PROTECTED] To: Shawn Starr [EMAIL PROTECTED], lkm [EMAIL PROTECTED] Subject: Re: [WISHLIST] Addition of suspend patch into 2.5? Hi! Any idea if suspend/hybernation will be in future kernels? I'd like it included, too. Some toshiba laptops support sleep but not suspend, and battery runs out within few hours if it was low before suspend. That's bad. And the patch was pretty clean last time I checked. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [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/ - 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/ - 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: Disturbing news..
Well, why can't the ELF loader module/kernel detect or have some sort of restriction on modifying other/ELF binaries including itself from changing the Entry point? There has to be a way stop this. WHY would anyone want to modify the entry point anyway? (there may be some reasons but I really dont know what). Even if it's user level, this cant affect files with root permissions (unless root is running them or suid). Any idea? On Wed, 28 Mar 2001, Matti Aarnio wrote: > On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote: > > Date: Wed, 28 Mar 2001 01:16:02 -0500 (EST) > > From: Shawn Starr <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Subject: Disturbing news.. > > > > http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh > > Isn't it time to change the ELF format to stop this crap? > > Shawn. > > Why ? "Double-click on attachment to run it" is typical > M$ client stupidity -- and the reason why there > are so many things that can mail themselves around. > > Changeing ELF-format would be comparable to what M$ did when > they met the first Word macro viruses -- they changed the > script language inside the Word... What good did that do ? > Did it harm people ? You bet... > > > You are downloading binaries off the net, and not compiling > from the sources ? (Yes, we all do that. This is why folks > these days carry PGP signatures at the RPM packages.) > > > So, the program modifies ELF format executables by rewriting > some instructions in the beginning (propably to map-in the virus > code proper with X-bit on), and tags itself (PIC presumably) at > the end of the file. > > > > Another issue is "safe conduct" practice of installing binaries > with minimum privileges (ok, granted that for e.g. RPMs that > usually means root), and *never* running them with undue levels > of privileges -- not even as the owner of said executables. > > > > Ok, granted that we have dangers of getting arbitrary BAD programs > into our systems, how can we combat that ? Virus-scanners > (as much good as they could do..) don't really work in UNIX > environments where "small things" like intercept of every > exec(), and open() via privileged program (scanner) is not > available feature. (I think doing it by passing a AF_UNIX > message with fd + flags to registered server, expecting answer > for the open() -- this would happen *after* the file open is > done with user privileges, but before the call returns.) > (Trapping open() so that shared-libraries could be scanned.) > > There could be, I think, a method for doing such intercepts, > which could be used by security scanners to implement some > sense of security in Linux-like systems. > > Is it good enough, e.g. when some file is multiply-mapped to > shared programs, and application rewrites parts of the file ? > Can it detect that kind of multi-mapped writing-sharing ? > > Can such system be made fast ? (Scanner becomes performance > bottle-neck.) > > > How about PROPER Orange Book B-level security ? > E.g. NSA trusted-linux ? > > > /Matti Aarnio > > - 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: Disturbing news.. Idea
Why not make a new file permission? to deny a ELF binary the ability to modify the ELF entry point? like +p if the file had +p (by default) the kernel would deny the ELF binary the ability to modify files. Shawn. On Wed, 28 Mar 2001, Shawn Starr wrote: > > http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh > > Isn't it time to change the ELF format to stop this crap? > > Shawn. > > > - > 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/ > > - 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/
Disturbing news..
http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh Isn't it time to change the ELF format to stop this crap? Shawn. - 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: Kernel QA
I disagree, 2.4.x is "stable" and as such we need as many people to use the kernels to see whats wrong with them. 2.4 *DOES* Work, I've had very small problems (ok, the thread hanging issue was a big one) but other then that It's been solid. It depends on the hardware. Shawn. On Tue, 27 Mar 2001, James Lewis Nance wrote: > On Tue, Mar 27, 2001 at 12:13:32AM -0800, David Konerding wrote: > > > No, the point is that the linux developers should regression test their > > code BEFORE > > releasing it to the public as a version like "2.4.2". When I see a > > version like "2.4.2", I have an expectation that all the stupid little > > problems (like mounting loopback filesystem) have already been found. > > You bring up a good point. We call the even branches the stable branches > and we do other things that promote the idea that people should be able to > download a 2.even.X kernel, install it on their machine, and expect it to > work. I think we need to back away from this idea. It seems to me that > the real (perhaps not the intended) function of kernel releases is keeping > kernel developers in sync. Promoting the idea that they are thought to be > suitable for production use just gets us in trouble. > > Instead I think we need to encourage people who want to use Linux, > rather than develop it, to use kernels from a distribution. After all, > the distributors put a lot of effort into doing QA and putting together a > compatable system, we should leverage that. We need to ensure that people > know that when they install the latest kernel from Linus, they are the QA. > > Please note that I am not trying to say that we should not try and > make the kernels we release as good as possible. It certainly makes > things a lot better for everyone if bugs dont get introduced by new > kernel versions. I do think we need to be more explicit about exactly > what people should and should not be able to expect from a "Linus kernel". > > Thanks, > > Jim > - > 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/ > > - 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: Kernel QA
I disagree, 2.4.x is "stable" and as such we need as many people to use the kernels to see whats wrong with them. 2.4 *DOES* Work, I've had very small problems (ok, the thread hanging issue was a big one) but other then that It's been solid. It depends on the hardware. Shawn. On Tue, 27 Mar 2001, James Lewis Nance wrote: On Tue, Mar 27, 2001 at 12:13:32AM -0800, David Konerding wrote: No, the point is that the linux developers should regression test their code BEFORE releasing it to the public as a version like "2.4.2". When I see a version like "2.4.2", I have an expectation that all the stupid little problems (like mounting loopback filesystem) have already been found. You bring up a good point. We call the even branches the stable branches and we do other things that promote the idea that people should be able to download a 2.even.X kernel, install it on their machine, and expect it to work. I think we need to back away from this idea. It seems to me that the real (perhaps not the intended) function of kernel releases is keeping kernel developers in sync. Promoting the idea that they are thought to be suitable for production use just gets us in trouble. Instead I think we need to encourage people who want to use Linux, rather than develop it, to use kernels from a distribution. After all, the distributors put a lot of effort into doing QA and putting together a compatable system, we should leverage that. We need to ensure that people know that when they install the latest kernel from Linus, they are the QA. Please note that I am not trying to say that we should not try and make the kernels we release as good as possible. It certainly makes things a lot better for everyone if bugs dont get introduced by new kernel versions. I do think we need to be more explicit about exactly what people should and should not be able to expect from a "Linus kernel". Thanks, Jim - 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/ - 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/
Disturbing news..
http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh Isn't it time to change the ELF format to stop this crap? Shawn. - 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: Disturbing news.. Idea
Why not make a new file permission? to deny a ELF binary the ability to modify the ELF entry point? like +p if the file had +p (by default) the kernel would deny the ELF binary the ability to modify files. Shawn. On Wed, 28 Mar 2001, Shawn Starr wrote: http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh Isn't it time to change the ELF format to stop this crap? Shawn. - 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/ - 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: Disturbing news..
Well, why can't the ELF loader module/kernel detect or have some sort of restriction on modifying other/ELF binaries including itself from changing the Entry point? There has to be a way stop this. WHY would anyone want to modify the entry point anyway? (there may be some reasons but I really dont know what). Even if it's user level, this cant affect files with root permissions (unless root is running them or suid). Any idea? On Wed, 28 Mar 2001, Matti Aarnio wrote: On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote: Date: Wed, 28 Mar 2001 01:16:02 -0500 (EST) From: Shawn Starr [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Disturbing news.. http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh Isn't it time to change the ELF format to stop this crap? Shawn. Why ? "Double-click on attachment to run it" is typical M$ client stupidity -- and the reason why there are so many things that can mail themselves around. Changeing ELF-format would be comparable to what M$ did when they met the first Word macro viruses -- they changed the script language inside the Word... What good did that do ? Did it harm people ? You bet... You are downloading binaries off the net, and not compiling from the sources ? (Yes, we all do that. This is why folks these days carry PGP signatures at the RPM packages.) So, the program modifies ELF format executables by rewriting some instructions in the beginning (propably to map-in the virus code proper with X-bit on), and tags itself (PIC presumably) at the end of the file. Another issue is "safe conduct" practice of installing binaries with minimum privileges (ok, granted that for e.g. RPMs that usually means root), and *never* running them with undue levels of privileges -- not even as the owner of said executables. Ok, granted that we have dangers of getting arbitrary BAD programs into our systems, how can we combat that ? Virus-scanners (as much good as they could do..) don't really work in UNIX environments where "small things" like intercept of every exec(), and open() via privileged program (scanner) is not available feature. (I think doing it by passing a AF_UNIX message with fd + flags to registered server, expecting answer for the open() -- this would happen *after* the file open is done with user privileges, but before the call returns.) (Trapping open() so that shared-libraries could be scanned.) There could be, I think, a method for doing such intercepts, which could be used by security scanners to implement some sense of security in Linux-like systems. Is it good enough, e.g. when some file is multiply-mapped to shared programs, and application rewrites parts of the file ? Can it detect that kind of multi-mapped writing-sharing ? Can such system be made fast ? (Scanner becomes performance bottle-neck.) How about PROPER Orange Book B-level security ? E.g. NSA trusted-linux ? /Matti Aarnio - 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: CDROM and harddisk fighting over DMA
Some CDROMS can do this, My old Acer 12x cdrom was fighting with DMA with
my new Fujitsu drive, I disabled the cd-rom and no more DMA errors ;-)
You might also be able to fix this by rearranging the CD-ROM and drives:
move the CD-ROM off the HD's IDE chain and put it separate (if its not
already).
Shawn.
On Tue, 20 Mar 2001, Wouter Verhelst wrote:
> (I'm not subscribed to linux-kernel, so please CC any answers. TIA)
>
> Hello
>
> Since I bought my new harddisk (a Maxtor 40GB of about a half year old
> now), I've had errors over my console like this:
>
> hda: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
>
> hda is my harddisk. The CDROM was first connected to hdb, but I changed
> that to hdc, trying to get rid of these errors. This did not resolve the
> issue.
> After playing around a bit, I found out that these errors occur when both
> the CDROM and the harddisk are being accessed at the same time (well,
> almost; it's not an SMP system ;-). I managed to fix it by disabling DMA
> on the harddisk, using hdparm. Disabling DMA on the CDROM, by contrast,
> did not resolve the issue.
>
> However, as this slows down my data throughput speed quite drastically,
> I'd like to do this differently.
>
> I first posted this to comp.os.linux.setup, but did not get any useful
> information. I believe it's not some misconfiguration from my side, so I
> sent this here since this mailinglist is listed as relevant mailinglist
> for the IDE subsystem; however, if this is the wrong place to ask, please
> redirect.
>
> --
> wouter dot verhelst at advalvas in belgium
>
> Real men don't take backups.
> They put their source on a public FTP-server and let the world mirror it.
> -- Linus Torvalds
>
> -
> 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/
>
>
-
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: CDROM and harddisk fighting over DMA
Some CDROMS can do this, My old Acer 12x cdrom was fighting with DMA with
my new Fujitsu drive, I disabled the cd-rom and no more DMA errors ;-)
You might also be able to fix this by rearranging the CD-ROM and drives:
move the CD-ROM off the HD's IDE chain and put it separate (if its not
already).
Shawn.
On Tue, 20 Mar 2001, Wouter Verhelst wrote:
(I'm not subscribed to linux-kernel, so please CC any answers. TIA)
Hello
Since I bought my new harddisk (a Maxtor 40GB of about a half year old
now), I've had errors over my console like this:
hda: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda is my harddisk. The CDROM was first connected to hdb, but I changed
that to hdc, trying to get rid of these errors. This did not resolve the
issue.
After playing around a bit, I found out that these errors occur when both
the CDROM and the harddisk are being accessed at the same time (well,
almost; it's not an SMP system ;-). I managed to fix it by disabling DMA
on the harddisk, using hdparm. Disabling DMA on the CDROM, by contrast,
did not resolve the issue.
However, as this slows down my data throughput speed quite drastically,
I'd like to do this differently.
I first posted this to comp.os.linux.setup, but did not get any useful
information. I believe it's not some misconfiguration from my side, so I
sent this here since this mailinglist is listed as relevant mailinglist
for the IDE subsystem; however, if this is the wrong place to ask, please
redirect.
--
wouter dot verhelst at advalvas in belgium
Real men don't take backups.
They put their source on a public FTP-server and let the world mirror it.
-- Linus Torvalds
-
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/
-
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/
2.4.3-pre4: Unable to handle kernel NULL pointer dereference at virtual address 000000fb
I have included the ksymoops debug and dmesg (both small).. Any ideas? Shawn. ksymoops 2.3.7 on i586 2.4.3-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-pre4/ (default) -m /boot/System.map (specified) Intel Pentium with F0 0F bug - workaround enabled. Unable to handle kernel NULL pointer dereference at virtual address 00fb c2016531 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: ebx: c0709dc8 ecx: c10e3a60 edx: c1258800 esi: edi: 0082 ebp: c1258878 esp: c0709f54 ds: 0018 es: 0018 ss: 0018 Process scsi_eh_0 (pid: 297, stackpage=c0709000) Stack: 0282 c1258800 c1274a00 c20165cf c1258800 c1258878 0282 c1274a00 c019dddf c1274a00 2003 c019e427 c1274a00 c0708000 c0709fdc c0709fdc c1258800 c0709fe8 c0709fe8 c10e3a60 c019e8fb Call Trace: [] [] [] [] [] Code: f6 80 fb 00 00 00 10 75 70 8b 4d 00 31 d2 eb 0a 89 ca 8b 82 >>EIP; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <= Trace; c20165cf <[aha152x]aha152x_bus_reset+13/a0> Trace; c019dddf Trace; c019e427 Trace; c019e8fb Trace; c010742c Code; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <_EIP>: Code; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <= 0: f6 80 fb 00 00 00 10 testb $0x10,0xfb(%eax) <= Code; c2016538 <[aha152x]free_hard_reset_SCs+28/ac> 7: 75 70 jne79 <_EIP+0x79> c20165aa <[aha152x]free_hard_reset_SCs+9a/ac> Code; c201653a <[aha152x]free_hard_reset_SCs+2a/ac> 9: 8b 4d 00 mov0x0(%ebp),%ecx Code; c201653d <[aha152x]free_hard_reset_SCs+2d/ac> c: 31 d2 xor%edx,%edx Code; c201653f <[aha152x]free_hard_reset_SCs+2f/ac> e: eb 0a jmp1a <_EIP+0x1a> c201654b <[aha152x]free_hard_reset_SCs+3b/ac> Code; c2016541 <[aha152x]free_hard_reset_SCs+31/ac> 10: 89 ca mov%ecx,%edx Code; c2016543 <[aha152x]free_hard_reset_SCs+33/ac> 12: 8b 82 00 00 00 00 mov0x0(%edx),%eax Linux version 2.4.3-pre4 (root@stucko) (gcc version 2.95.3 20010219 (prerelease)) #1 Sun Mar 18 01:29:02 EST 2001 BIOS-provided physical RAM map: BIOS-88: 0009f000 @ (usable) BIOS-88: 0170 @ 0010 (usable) On node 0 totalpages: 6144 zone(0): 4096 pages. zone(1): 2048 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=Linux ro root=302 Initializing CPU#0 Detected 83.524 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 166.29 BogoMIPS Memory: 22124k/24576k available (996k kernel code, 2064k reserved, 382k data, 60k init, 0k highmem) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) CPU: Before vendor init, caps: 013f , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. CPU: After vendor init, caps: 013f CPU: After generic, caps: 013f CPU: Common caps: 013f CPU: Intel OverDrive PODP5V83 stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX isapnp: Scanning for Pnp cards... isapnp: Card 'Adaptec AVA-1505AI' isapnp: Card '3Com 3C509B EtherLink III' isapnp: 2 Plug & Play cards detected total Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 parport0: PC-style at 0x378 [PCSPP(,...)] pty: 256 Unix98 ptys configured block: queued sectors max/low 14605kB/4868kB, 64 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST3491A D, ATA DISK drive hdb: QUANTUM PD210A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 836070 sectors (428 MB) w/120KiB Cache, CHS=899/15/62 hdb: 408564 sectors (209 MB) w/32KiB Cache, CHS=873/13/36 Partition check: hda: hda1 hda2 hdb: hdb1 hdb2 paride: epat registered as protocol 0 pd: pd version 1.05, major 45, cluster 64, nice 0 pda: Sharing parport0 at 0x378 pda: epat 1.01, Shuttle EPAT chip c6 at 0x378, mode 1 (5/3), delay 1 pda: AVATAR AR2250, master, 489472 blocks [239M], (956/16/32), removable media pda: pda1 Floppy drive(s): fd0 is 1.44M FDC 0 is an 8272A eth0: 3c509 at 0x220, 10baseT port, address 00 a0 24 46 41 c0, IRQ 5. 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] loop: loaded (max 8 devices) Serial driver version 5.05 (2000-12-13) with ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16450 ttyS01 at 0x02f8 (irq = 3) is a 16450 SCSI subsystem driver
2.4.3-pre4: Unable to handle kernel NULL pointer dereference at virtual address 000000fb
I have included the ksymoops debug and dmesg (both small).. Any ideas? Shawn. ksymoops 2.3.7 on i586 2.4.3-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-pre4/ (default) -m /boot/System.map (specified) Intel Pentium with F0 0F bug - workaround enabled. Unable to handle kernel NULL pointer dereference at virtual address 00fb c2016531 *pde = Oops: CPU:0 EIP:0010:[c2016531] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: ebx: c0709dc8 ecx: c10e3a60 edx: c1258800 esi: edi: 0082 ebp: c1258878 esp: c0709f54 ds: 0018 es: 0018 ss: 0018 Process scsi_eh_0 (pid: 297, stackpage=c0709000) Stack: 0282 c1258800 c1274a00 c20165cf c1258800 c1258878 0282 c1274a00 c019dddf c1274a00 2003 c019e427 c1274a00 c0708000 c0709fdc c0709fdc c1258800 c0709fe8 c0709fe8 c10e3a60 c019e8fb Call Trace: [c20165cf] [c019dddf] [c019e427] [c019e8fb] [c010742c] Code: f6 80 fb 00 00 00 10 75 70 8b 4d 00 31 d2 eb 0a 89 ca 8b 82 EIP; c2016531 [aha152x]free_hard_reset_SCs+21/ac = Trace; c20165cf [aha152x]aha152x_bus_reset+13/a0 Trace; c019dddf scsi_try_bus_reset+3f/90 Trace; c019e427 scsi_unjam_host+35b/75c Trace; c019e8fb scsi_error_handler+d3/138 Trace; c010742c kernel_thread+28/38 Code; c2016531 [aha152x]free_hard_reset_SCs+21/ac _EIP: Code; c2016531 [aha152x]free_hard_reset_SCs+21/ac = 0: f6 80 fb 00 00 00 10 testb $0x10,0xfb(%eax) = Code; c2016538 [aha152x]free_hard_reset_SCs+28/ac 7: 75 70 jne79 _EIP+0x79 c20165aa [aha152x]free_hard_reset_SCs+9a/ac Code; c201653a [aha152x]free_hard_reset_SCs+2a/ac 9: 8b 4d 00 mov0x0(%ebp),%ecx Code; c201653d [aha152x]free_hard_reset_SCs+2d/ac c: 31 d2 xor%edx,%edx Code; c201653f [aha152x]free_hard_reset_SCs+2f/ac e: eb 0a jmp1a _EIP+0x1a c201654b [aha152x]free_hard_reset_SCs+3b/ac Code; c2016541 [aha152x]free_hard_reset_SCs+31/ac 10: 89 ca mov%ecx,%edx Code; c2016543 [aha152x]free_hard_reset_SCs+33/ac 12: 8b 82 00 00 00 00 mov0x0(%edx),%eax Linux version 2.4.3-pre4 (root@stucko) (gcc version 2.95.3 20010219 (prerelease)) #1 Sun Mar 18 01:29:02 EST 2001 BIOS-provided physical RAM map: BIOS-88: 0009f000 @ (usable) BIOS-88: 0170 @ 0010 (usable) On node 0 totalpages: 6144 zone(0): 4096 pages. zone(1): 2048 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=Linux ro root=302 Initializing CPU#0 Detected 83.524 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 166.29 BogoMIPS Memory: 22124k/24576k available (996k kernel code, 2064k reserved, 382k data, 60k init, 0k highmem) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) CPU: Before vendor init, caps: 013f , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. CPU: After vendor init, caps: 013f CPU: After generic, caps: 013f CPU: Common caps: 013f CPU: Intel OverDrive PODP5V83 stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX isapnp: Scanning for Pnp cards... isapnp: Card 'Adaptec AVA-1505AI' isapnp: Card '3Com 3C509B EtherLink III' isapnp: 2 Plug Play cards detected total Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 parport0: PC-style at 0x378 [PCSPP(,...)] pty: 256 Unix98 ptys configured block: queued sectors max/low 14605kB/4868kB, 64 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST3491A D, ATA DISK drive hdb: QUANTUM PD210A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 836070 sectors (428 MB) w/120KiB Cache, CHS=899/15/62 hdb: 408564 sectors (209 MB) w/32KiB Cache, CHS=873/13/36 Partition check: hda: hda1 hda2 hdb: hdb1 hdb2 paride: epat registered as protocol 0 pd: pd version 1.05, major 45, cluster 64, nice 0 pda: Sharing parport0 at 0x378 pda: epat 1.01, Shuttle EPAT chip c6 at 0x378, mode 1 (5/3), delay 1 pda: AVATAR AR2250, master, 489472 blocks [239M], (956/16/32), removable media pda: pda1 Floppy drive(s): fd0 is 1.44M FDC 0 is an 8272A eth0: 3c509 at 0x220, 10baseT port, address 00 a0 24 46 41 c0, IRQ 5. 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] loop: loaded (max 8 devices) Serial driver version 5.05 (2000-12-13) with ISAPNP
2.4.3-pre4: Unable to handle kernel NULL pointer dereference at virtual address 000000fb
I have included the ksymoops debug and dmesg (both small).. Any ideas? Shawn. ksymoops 2.3.7 on i586 2.4.3-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-pre4/ (default) -m /boot/System.map (specified) Intel Pentium with F0 0F bug - workaround enabled. Unable to handle kernel NULL pointer dereference at virtual address 00fb c2016531 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: ebx: c0709dc8 ecx: c10e3a60 edx: c1258800 esi: edi: 0082 ebp: c1258878 esp: c0709f54 ds: 0018 es: 0018 ss: 0018 Process scsi_eh_0 (pid: 297, stackpage=c0709000) Stack: 0282 c1258800 c1274a00 c20165cf c1258800 c1258878 0282 c1274a00 c019dddf c1274a00 2003 c019e427 c1274a00 c0708000 c0709fdc c0709fdc c1258800 c0709fe8 c0709fe8 c10e3a60 c019e8fb Call Trace: [] [] [] [] [] Code: f6 80 fb 00 00 00 10 75 70 8b 4d 00 31 d2 eb 0a 89 ca 8b 82 >>EIP; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <= Trace; c20165cf <[aha152x]aha152x_bus_reset+13/a0> Trace; c019dddf Trace; c019e427 Trace; c019e8fb Trace; c010742c Code; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <_EIP>: Code; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <= 0: f6 80 fb 00 00 00 10 testb $0x10,0xfb(%eax) <= Code; c2016538 <[aha152x]free_hard_reset_SCs+28/ac> 7: 75 70 jne79 <_EIP+0x79> c20165aa <[aha152x]free_hard_reset_SCs+9a/ac> Code; c201653a <[aha152x]free_hard_reset_SCs+2a/ac> 9: 8b 4d 00 mov0x0(%ebp),%ecx Code; c201653d <[aha152x]free_hard_reset_SCs+2d/ac> c: 31 d2 xor%edx,%edx Code; c201653f <[aha152x]free_hard_reset_SCs+2f/ac> e: eb 0a jmp1a <_EIP+0x1a> c201654b <[aha152x]free_hard_reset_SCs+3b/ac> Code; c2016541 <[aha152x]free_hard_reset_SCs+31/ac> 10: 89 ca mov%ecx,%edx Code; c2016543 <[aha152x]free_hard_reset_SCs+33/ac> 12: 8b 82 00 00 00 00 mov0x0(%edx),%eax Linux version 2.4.3-pre4 (root@stucko) (gcc version 2.95.3 20010219 (prerelease)) #1 Sun Mar 18 01:29:02 EST 2001 BIOS-provided physical RAM map: BIOS-88: 0009f000 @ (usable) BIOS-88: 0170 @ 0010 (usable) On node 0 totalpages: 6144 zone(0): 4096 pages. zone(1): 2048 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=Linux ro root=302 Initializing CPU#0 Detected 83.524 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 166.29 BogoMIPS Memory: 22124k/24576k available (996k kernel code, 2064k reserved, 382k data, 60k init, 0k highmem) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) CPU: Before vendor init, caps: 013f , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. CPU: After vendor init, caps: 013f CPU: After generic, caps: 013f CPU: Common caps: 013f CPU: Intel OverDrive PODP5V83 stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX isapnp: Scanning for Pnp cards... isapnp: Card 'Adaptec AVA-1505AI' isapnp: Card '3Com 3C509B EtherLink III' isapnp: 2 Plug & Play cards detected total Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 parport0: PC-style at 0x378 [PCSPP(,...)] pty: 256 Unix98 ptys configured block: queued sectors max/low 14605kB/4868kB, 64 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST3491A D, ATA DISK drive hdb: QUANTUM PD210A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 836070 sectors (428 MB) w/120KiB Cache, CHS=899/15/62 hdb: 408564 sectors (209 MB) w/32KiB Cache, CHS=873/13/36 Partition check: hda: hda1 hda2 hdb: hdb1 hdb2 paride: epat registered as protocol 0 pd: pd version 1.05, major 45, cluster 64, nice 0 pda: Sharing parport0 at 0x378 pda: epat 1.01, Shuttle EPAT chip c6 at 0x378, mode 1 (5/3), delay 1 pda: AVATAR AR2250, master, 489472 blocks [239M], (956/16/32), removable media pda: pda1 Floppy drive(s): fd0 is 1.44M FDC 0 is an 8272A eth0: 3c509 at 0x220, 10baseT port, address 00 a0 24 46 41 c0, IRQ 5. 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] loop: loaded (max 8 devices) Serial driver version 5.05 (2000-12-13) with ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16450 ttyS01 at 0x02f8 (irq = 3) is a 16450 SCSI subsystem
2.4.3-pre4: Unable to handle kernel NULL pointer dereference at virtual address 000000fb
I have included the ksymoops debug and dmesg (both small).. Any ideas? Shawn. ksymoops 2.3.7 on i586 2.4.3-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-pre4/ (default) -m /boot/System.map (specified) Intel Pentium with F0 0F bug - workaround enabled. Unable to handle kernel NULL pointer dereference at virtual address 00fb c2016531 *pde = Oops: CPU:0 EIP:0010:[c2016531] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: ebx: c0709dc8 ecx: c10e3a60 edx: c1258800 esi: edi: 0082 ebp: c1258878 esp: c0709f54 ds: 0018 es: 0018 ss: 0018 Process scsi_eh_0 (pid: 297, stackpage=c0709000) Stack: 0282 c1258800 c1274a00 c20165cf c1258800 c1258878 0282 c1274a00 c019dddf c1274a00 2003 c019e427 c1274a00 c0708000 c0709fdc c0709fdc c1258800 c0709fe8 c0709fe8 c10e3a60 c019e8fb Call Trace: [c20165cf] [c019dddf] [c019e427] [c019e8fb] [c010742c] Code: f6 80 fb 00 00 00 10 75 70 8b 4d 00 31 d2 eb 0a 89 ca 8b 82 EIP; c2016531 [aha152x]free_hard_reset_SCs+21/ac = Trace; c20165cf [aha152x]aha152x_bus_reset+13/a0 Trace; c019dddf scsi_try_bus_reset+3f/90 Trace; c019e427 scsi_unjam_host+35b/75c Trace; c019e8fb scsi_error_handler+d3/138 Trace; c010742c kernel_thread+28/38 Code; c2016531 [aha152x]free_hard_reset_SCs+21/ac _EIP: Code; c2016531 [aha152x]free_hard_reset_SCs+21/ac = 0: f6 80 fb 00 00 00 10 testb $0x10,0xfb(%eax) = Code; c2016538 [aha152x]free_hard_reset_SCs+28/ac 7: 75 70 jne79 _EIP+0x79 c20165aa [aha152x]free_hard_reset_SCs+9a/ac Code; c201653a [aha152x]free_hard_reset_SCs+2a/ac 9: 8b 4d 00 mov0x0(%ebp),%ecx Code; c201653d [aha152x]free_hard_reset_SCs+2d/ac c: 31 d2 xor%edx,%edx Code; c201653f [aha152x]free_hard_reset_SCs+2f/ac e: eb 0a jmp1a _EIP+0x1a c201654b [aha152x]free_hard_reset_SCs+3b/ac Code; c2016541 [aha152x]free_hard_reset_SCs+31/ac 10: 89 ca mov%ecx,%edx Code; c2016543 [aha152x]free_hard_reset_SCs+33/ac 12: 8b 82 00 00 00 00 mov0x0(%edx),%eax Linux version 2.4.3-pre4 (root@stucko) (gcc version 2.95.3 20010219 (prerelease)) #1 Sun Mar 18 01:29:02 EST 2001 BIOS-provided physical RAM map: BIOS-88: 0009f000 @ (usable) BIOS-88: 0170 @ 0010 (usable) On node 0 totalpages: 6144 zone(0): 4096 pages. zone(1): 2048 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=Linux ro root=302 Initializing CPU#0 Detected 83.524 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 166.29 BogoMIPS Memory: 22124k/24576k available (996k kernel code, 2064k reserved, 382k data, 60k init, 0k highmem) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) CPU: Before vendor init, caps: 013f , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. CPU: After vendor init, caps: 013f CPU: After generic, caps: 013f CPU: Common caps: 013f CPU: Intel OverDrive PODP5V83 stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX isapnp: Scanning for Pnp cards... isapnp: Card 'Adaptec AVA-1505AI' isapnp: Card '3Com 3C509B EtherLink III' isapnp: 2 Plug Play cards detected total Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 parport0: PC-style at 0x378 [PCSPP(,...)] pty: 256 Unix98 ptys configured block: queued sectors max/low 14605kB/4868kB, 64 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST3491A D, ATA DISK drive hdb: QUANTUM PD210A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 836070 sectors (428 MB) w/120KiB Cache, CHS=899/15/62 hdb: 408564 sectors (209 MB) w/32KiB Cache, CHS=873/13/36 Partition check: hda: hda1 hda2 hdb: hdb1 hdb2 paride: epat registered as protocol 0 pd: pd version 1.05, major 45, cluster 64, nice 0 pda: Sharing parport0 at 0x378 pda: epat 1.01, Shuttle EPAT chip c6 at 0x378, mode 1 (5/3), delay 1 pda: AVATAR AR2250, master, 489472 blocks [239M], (956/16/32), removable media pda: pda1 Floppy drive(s): fd0 is 1.44M FDC 0 is an 8272A eth0: 3c509 at 0x220, 10baseT port, address 00 a0 24 46 41 c0, IRQ 5. 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] loop: loaded (max 8 devices) Serial driver version 5.05 (2000-12-13) with ISAPNP
Re: Odd error message..
hehe, your not the only one getting that :) I get it from the sg.o module. (it appears). Aaron Sethman wrote: > __alloc_pages: 2-order allocation failed. > > I get many of these across the console when testing a network application > that. Basically the client opens up a bunch of connections to the server > and starts firing off data as quickly as it can. If you need further > information please let me know. > > Regards, > > Aaron > > - > 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/ -- Hugged a Tux today? (tm) - 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: Odd error message..
hehe, your not the only one getting that :) I get it from the sg.o module. (it appears). Aaron Sethman wrote: __alloc_pages: 2-order allocation failed. I get many of these across the console when testing a network application that. Basically the client opens up a bunch of connections to the server and starts firing off data as quickly as it can. If you need further information please let me know. Regards, Aaron - 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/ -- Hugged a Tux today? (tm) - 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/
