How to guarantee that kmalloc returns an address below 4GB
Hey, is there an option for kmalloc, which I can use to allocate a buffer which is in physical memory placed below 4GB? Not in a remapped area. The only way I found is to use GFP_DMA, but this says the first 16MB isn't it? Ciao Thilo - 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/
How to guarantee that kmalloc returns an address below 4GB
Hey, is there an option for kmalloc, which I can use to allocate a buffer which is in physical memory placed below 4GB? Not in a remapped area. The only way I found is to use GFP_DMA, but this says the first 16MB isn't it? Ciao Thilo - 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: NonExecutable Bit in 32Bit
> > And this prevents the lowmemory to be secured by NX? > What do you mean, when you say "lowmemory"? I mean EF-Segments. Cause we got a kernel oops as we accidentally used ioremap_nocache on a EF-Segment address. Before that usage the EF-Segments weren't secured, afterwards they were. We use now ioremap which does the high low mem check, but I was a bit confused that NX was not active before. But I can't provide any further informations about the system, cause it was more or less support for a customer. Ciao Thilo - 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: NonExecutable Bit in 32Bit
> > > > CONFIG_HIGHMEM64G=y > > > > CONFIG_HIGHMEM=y > > > > CONFIG_X86_PAE=y > > > > > > Ok in highmem it's active, whats about lowmem? > > > x86-64 is NX active for lowmem too AFAIK. > > > > It's more of an issue of having PAE enabled. > > Without PAE you are not able to use the the NX bit. > That's the way the CPU works, not Linux. > > Forgot to add: > from arch/i386/Kconfig: > config X86_PAE > bool > depends on HIGHMEM64G > default y > select RESOURCES_64BIT > > > Hope this helps. > > Just that I get it right, NX just works with PAE enabled, and PAE just works with HIGHMEM64G enabled. And this prevents the lowmemory to be secured by NX? Ciao Thilo - 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: NonExecutable Bit in 32Bit
Hey, > CONFIG_HIGHMEM64G=y > CONFIG_HIGHMEM=y > CONFIG_X86_PAE=y Ok in highmem it's active, whats about lowmem? x86-64 is NX active for lowmem too AFAIK. Ciao Thilo - 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: NonExecutable Bit in 32Bit
Hey, CONFIG_HIGHMEM64G=y CONFIG_HIGHMEM=y CONFIG_X86_PAE=y Ok in highmem it's active, whats about lowmem? x86-64 is NX active for lowmem too AFAIK. Ciao Thilo - 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: NonExecutable Bit in 32Bit
CONFIG_HIGHMEM64G=y CONFIG_HIGHMEM=y CONFIG_X86_PAE=y Ok in highmem it's active, whats about lowmem? x86-64 is NX active for lowmem too AFAIK. It's more of an issue of having PAE enabled. Without PAE you are not able to use the the NX bit. That's the way the CPU works, not Linux. Forgot to add: from arch/i386/Kconfig: config X86_PAE bool depends on HIGHMEM64G default y select RESOURCES_64BIT Hope this helps. Just that I get it right, NX just works with PAE enabled, and PAE just works with HIGHMEM64G enabled. And this prevents the lowmemory to be secured by NX? Ciao Thilo - 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: NonExecutable Bit in 32Bit
And this prevents the lowmemory to be secured by NX? What do you mean, when you say lowmemory? I mean EF-Segments. Cause we got a kernel oops as we accidentally used ioremap_nocache on a EF-Segment address. Before that usage the EF-Segments weren't secured, afterwards they were. We use now ioremap which does the high low mem check, but I was a bit confused that NX was not active before. But I can't provide any further informations about the system, cause it was more or less support for a customer. Ciao Thilo - 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: NonExecutable Bit in 32Bit
> I don't think so - some i386 cpus definitely have support for the NX bit. Ok, the cpu's do support it, but the kernel doesn't use it if it is active in the bios. > Would having this be supported in i386 help debugging (and security) > significantly? @William: I don't understand this question :( Ciao Thilo - 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/
NonExecutable Bit in 32Bit
Hey, is it right, that the NX Bit is not used under i386-Arch but under x86_64-Arch? When yes, is there a special argument for it not to be used? Ciao Thilo - 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/
NonExecutable Bit in 32Bit
Hey, is it right, that the NX Bit is not used under i386-Arch but under x86_64-Arch? When yes, is there a special argument for it not to be used? Ciao Thilo - 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]: Fix bogus softlockup warning with sysrq-t
> I could easy add a "global disable" function, which would allow long > sysrq messages, and it would help Thilo with his long flash update freezes. A "global disable" and "reenable" functions pair which works during irq disabled, would be a perfect solution for me. Thx Jeremy for your effort :) Ciao Thilo - 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]: Fix bogus softlockup warning with sysrq-t
I could easy add a global disable function, which would allow long sysrq messages, and it would help Thilo with his long flash update freezes. A global disable and reenable functions pair which works during irq disabled, would be a perfect solution for me. Thx Jeremy for your effort :) Ciao Thilo - 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: how can I touch softlockup watchdog on all cpus?
> Sounds like you have a fundamentally incompatible set of requirements. Sounds so yep :) > Why do you need the softlockup watchdog if you intend to induce soft > lockups on purpose? It's a condition of a customer of us, so I can't change it. But it happens not often that my part is used. So I thought there is a mechanism to disable or reset the watchdog because it is a legal pause for it. And there is one "touch_softlockup_watchdog()", that does what I want, BUT just for the current cpu. And so the watchdog blats from the other cpu. Thilo - 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: how can I touch softlockup watchdog on all cpus?
> Just disable the softlockup watchdog. Thx for your answer, but this is no option for me, as I said in my first post :(. Thilo - 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: how can I touch softlockup watchdog on all cpus?
> You didn't explain _why_ you need to sleep for such a long time, > and as you didn't give a pointer to your code, there's not > much people can do to recommend changes other than "don't do that". The code which is executed between the local_irq_disable and enable, is just a function call into our companies bios (e.g. for updating itself) and the long time is just 15 sec. while the bios has full control and OS is halted. So I can't change anything at this point, but I need to fetch the watchdog, cause it is not so nice, if there is a big BUG output on console while the computer updates it's bios, very trustworthy isn't it :). Ciao Thilo @Dave: sorry that I send a direct mail :( - 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: how can I touch softlockup watchdog on all cpus?
You didn't explain _why_ you need to sleep for such a long time, and as you didn't give a pointer to your code, there's not much people can do to recommend changes other than don't do that. The code which is executed between the local_irq_disable and enable, is just a function call into our companies bios (e.g. for updating itself) and the long time is just 15 sec. while the bios has full control and OS is halted. So I can't change anything at this point, but I need to fetch the watchdog, cause it is not so nice, if there is a big BUG output on console while the computer updates it's bios, very trustworthy isn't it :). Ciao Thilo @Dave: sorry that I send a direct mail :( - 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: how can I touch softlockup watchdog on all cpus?
Just disable the softlockup watchdog. Thx for your answer, but this is no option for me, as I said in my first post :(. Thilo - 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: how can I touch softlockup watchdog on all cpus?
Sounds like you have a fundamentally incompatible set of requirements. Sounds so yep :) Why do you need the softlockup watchdog if you intend to induce soft lockups on purpose? It's a condition of a customer of us, so I can't change it. But it happens not often that my part is used. So I thought there is a mechanism to disable or reset the watchdog because it is a legal pause for it. And there is one touch_softlockup_watchdog(), that does what I want, BUT just for the current cpu. And so the watchdog blats from the other cpu. Thilo - 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/
how can I touch softlockup watchdog on all cpus?
Hey, my module generates this ugly softlockup dump, because all cpus are stopped longer then 10 secs. What I do is: [code] local_irq_disable(); // my stuff which takes long and stopps all cpus . touch_softlockup_watchdog(); local_irq_enable(); [/code] this prevents a dump of my current cpu but not for all. A call to smp_call_function with a function which calls touch_softlockup_watchdog in it, doesn't work because smp_call_function needs to be done with irqs enabled, so the watchdog comes first :(. Any hints or ideas how I can do it in a better way? Disabling softlockup watchdog is not possible for me. Ciao Thilo - 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/
how can I touch softlockup watchdog on all cpus?
Hey, my module generates this ugly softlockup dump, because all cpus are stopped longer then 10 secs. What I do is: [code] local_irq_disable(); // my stuff which takes long and stopps all cpus . touch_softlockup_watchdog(); local_irq_enable(); [/code] this prevents a dump of my current cpu but not for all. A call to smp_call_function with a function which calls touch_softlockup_watchdog in it, doesn't work because smp_call_function needs to be done with irqs enabled, so the watchdog comes first :(. Any hints or ideas how I can do it in a better way? Disabling softlockup watchdog is not possible for me. Ciao Thilo - 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/
Weird wasting of time between ioctl() and ioctl dispatcher
Hey, I'm a developer for Fujitsu Siemens Computers, working on a program which has it's own kernel modules and userland components. Now cause the program should be released we have done some testing and during this testphase a wierd wasting of time occured during the call of the ioctl() in the userland component and the actuall entering of the dispatcher function in the module. It takes 3 min. until the call at last enters my dispatcher. (Debugging output with printf on line before ioctl() and printk as first line in the dispatch function points that out). The dispatch function is the ioctl part of the fileoperations struct which defines the module stuff. The kernel I'm running is the 2.6.16.21-0.8-default of SLED10 (32Bit), but installed on a 64Bit machine. Can anyone point me to, where I can have a look where the waste of time comes from? The ioctl itself works fine afterwards, but the whole process is time-critical so the 3 min. do hurt :(. Ciao Thilo - 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/
Weird wasting of time between ioctl() and ioctl dispatcher
Hey, I'm a developer for Fujitsu Siemens Computers, working on a program which has it's own kernel modules and userland components. Now cause the program should be released we have done some testing and during this testphase a wierd wasting of time occured during the call of the ioctl() in the userland component and the actuall entering of the dispatcher function in the module. It takes 3 min. until the call at last enters my dispatcher. (Debugging output with printf on line before ioctl() and printk as first line in the dispatch function points that out). The dispatch function is the ioctl part of the fileoperations struct which defines the module stuff. The kernel I'm running is the 2.6.16.21-0.8-default of SLED10 (32Bit), but installed on a 64Bit machine. Can anyone point me to, where I can have a look where the waste of time comes from? The ioctl itself works fine afterwards, but the whole process is time-critical so the 3 min. do hurt :(. Ciao Thilo - 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/
