Re: Allow (O=...) from file
On Wed, Dec 05, 2007 at 10:37:03PM +0100, Erik Mouw wrote: > Here's a clue: when I build with ARCH=x86, I get some warnings, but the > targz-pkg builds succesfully: > > [EMAIL PROTECTED]:~/git/linux-2.6 > make ARCH=x86 allnoconfig > [...] > [EMAIL PROTECTED]:~/git/linux-2.6 > make ARCH=x86 targz-pkg > [...] > Kernel: arch/x86/boot/bzImage is ready (#1) > /bin/sh /home/erik/git/linux-2.6/scripts/package/buildtar targz-pkg > `/home/erik/git/linux-2.6/System.map' -> > /`/home/erik/git/linux-2.6/tar-install/boot/System.map-2.6.24-rc4' > `/home/erik/git/linux-2.6/.config' -> > /`/home/erik/git/linux-2.6/tar-install/boot/config-2.6.24-rc4' > `/home/erik/git/linux-2.6/vmlinux' -> > /`/home/erik/git/linux-2.6/tar-install/boot/vmlinux-2.6.24-rc4' > `arch/x86/boot/bzImage' -> > /`/home/erik/git/linux-2.6/tar-install/boot/vmlinux-kbuild-2.6.24-rc4' > > ** ** ** WARNING ** ** ** > > Your architecture did not define any architecture-dependant files > to be placed into the tarball. Please add those to > /home/erik/git/linux-2.6/scripts/package/buildtar ... > > Tarball successfully created in > /home/erik/git/linux-2.6/linux-2.6.24-rc4.tar.gz > > So it looks like the i386-x86_64 merge has something to do with it. Sorry, wrong clue. It builds because there are no modules to be made (allnoconfig). Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Allow (O=...) from file
On Wed, Dec 05, 2007 at 10:00:03PM +0100, Sam Ravnborg wrote:
> On Tue, Dec 04, 2007 at 09:04:33PM -0600, Jay Cliburn wrote:
> > Sam,
> >
> > This piece of the top-level Makefile in current git causes an
> > out-of-tree driver Makefile to fail.
> >
> > 101 ifdef O
> > 102 ifeq ("$(origin O)", "command line")
> > 103 KBUILD_OUTPUT := $(O)
> > 104 endif
> > 105 endif
> >
> > The out-of-tree driver Makefile contains an O=... directive that
> > (correctly) does _not_ specify the kernel source dir, and apparently
> > isn't overridden by the command line either. If in the above Makefile
> > snippet I change "command line" to "file", my out-of-tree make
> > succeeds. What do you think about allowing O= to come from a file in
> > addition to the command line?
>
> When you change "command line" to "file" you actually makes kbuild
> ignore the O=... value which is why it succeeds.
> The problem we solve with the error below is that in some case
> the Makefile for the kernel were overwritten.
> And I do not really understand why this does not happen in yours
> and Erik's case.
I just RTFM for GNU make, changing "command line" into "default" also
results in a succesful build.
> Anyway - the right fix seems to detect that the two directories
> are equal and then just ignore the O=... setting.
> But I am lacking time atm to fix it - only sparsely working on
> Linux the next few weeks.
Here's a clue: when I build with ARCH=x86, I get some warnings, but the
targz-pkg builds succesfully:
[EMAIL PROTECTED]:~/git/linux-2.6 > make ARCH=x86 allnoconfig
[...]
[EMAIL PROTECTED]:~/git/linux-2.6 > make ARCH=x86 targz-pkg
[...]
Kernel: arch/x86/boot/bzImage is ready (#1)
/bin/sh /home/erik/git/linux-2.6/scripts/package/buildtar targz-pkg
`/home/erik/git/linux-2.6/System.map' ->
/`/home/erik/git/linux-2.6/tar-install/boot/System.map-2.6.24-rc4'
`/home/erik/git/linux-2.6/.config' ->
/`/home/erik/git/linux-2.6/tar-install/boot/config-2.6.24-rc4'
`/home/erik/git/linux-2.6/vmlinux' ->
/`/home/erik/git/linux-2.6/tar-install/boot/vmlinux-2.6.24-rc4'
`arch/x86/boot/bzImage' ->
/`/home/erik/git/linux-2.6/tar-install/boot/vmlinux-kbuild-2.6.24-rc4'
** ** ** WARNING ** ** **
Your architecture did not define any architecture-dependant files
to be placed into the tarball. Please add those to
/home/erik/git/linux-2.6/scripts/package/buildtar ...
Tarball successfully created in
/home/erik/git/linux-2.6/linux-2.6.24-rc4.tar.gz
So it looks like the i386-x86_64 merge has something to do with it.
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
signature.asc
Description: Digital signature
Re: Allow (O=...) from file
On Tue, Dec 04, 2007 at 09:04:33PM -0600, Jay Cliburn wrote:
> Sam,
>
> This piece of the top-level Makefile in current git causes an
> out-of-tree driver Makefile to fail.
>
> 101 ifdef O
> 102 ifeq ("$(origin O)", "command line")
> 103 KBUILD_OUTPUT := $(O)
> 104 endif
> 105 endif
>
> The out-of-tree driver Makefile contains an O=... directive that
> (correctly) does _not_ specify the kernel source dir, and apparently
> isn't overridden by the command line either. If in the above Makefile
> snippet I change "command line" to "file", my out-of-tree make
> succeeds. What do you think about allowing O= to come from a file in
> addition to the command line?
Oh great, changing "command line" to "file" fixes my problem as well
(see http://lkml.org/lkml/2007/11/19/146 ). "make targz-pkg" works
flawless again.
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
signature.asc
Description: Digital signature
Re: Allow (O=...) from file
On Tue, Dec 04, 2007 at 09:04:33PM -0600, Jay Cliburn wrote: Sam, This piece of the top-level Makefile in current git causes an out-of-tree driver Makefile to fail. 101 ifdef O 102 ifeq ($(origin O), command line) 103 KBUILD_OUTPUT := $(O) 104 endif 105 endif The out-of-tree driver Makefile contains an O=... directive that (correctly) does _not_ specify the kernel source dir, and apparently isn't overridden by the command line either. If in the above Makefile snippet I change command line to file, my out-of-tree make succeeds. What do you think about allowing O= to come from a file in addition to the command line? Oh great, changing command line to file fixes my problem as well (see http://lkml.org/lkml/2007/11/19/146 ). make targz-pkg works flawless again. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Allow (O=...) from file
On Wed, Dec 05, 2007 at 10:00:03PM +0100, Sam Ravnborg wrote: On Tue, Dec 04, 2007 at 09:04:33PM -0600, Jay Cliburn wrote: Sam, This piece of the top-level Makefile in current git causes an out-of-tree driver Makefile to fail. 101 ifdef O 102 ifeq ($(origin O), command line) 103 KBUILD_OUTPUT := $(O) 104 endif 105 endif The out-of-tree driver Makefile contains an O=... directive that (correctly) does _not_ specify the kernel source dir, and apparently isn't overridden by the command line either. If in the above Makefile snippet I change command line to file, my out-of-tree make succeeds. What do you think about allowing O= to come from a file in addition to the command line? When you change command line to file you actually makes kbuild ignore the O=... value which is why it succeeds. The problem we solve with the error below is that in some case the Makefile for the kernel were overwritten. And I do not really understand why this does not happen in yours and Erik's case. I just RTFM for GNU make, changing command line into default also results in a succesful build. Anyway - the right fix seems to detect that the two directories are equal and then just ignore the O=... setting. But I am lacking time atm to fix it - only sparsely working on Linux the next few weeks. Here's a clue: when I build with ARCH=x86, I get some warnings, but the targz-pkg builds succesfully: [EMAIL PROTECTED]:~/git/linux-2.6 make ARCH=x86 allnoconfig [...] [EMAIL PROTECTED]:~/git/linux-2.6 make ARCH=x86 targz-pkg [...] Kernel: arch/x86/boot/bzImage is ready (#1) /bin/sh /home/erik/git/linux-2.6/scripts/package/buildtar targz-pkg `/home/erik/git/linux-2.6/System.map' - /`/home/erik/git/linux-2.6/tar-install/boot/System.map-2.6.24-rc4' `/home/erik/git/linux-2.6/.config' - /`/home/erik/git/linux-2.6/tar-install/boot/config-2.6.24-rc4' `/home/erik/git/linux-2.6/vmlinux' - /`/home/erik/git/linux-2.6/tar-install/boot/vmlinux-2.6.24-rc4' `arch/x86/boot/bzImage' - /`/home/erik/git/linux-2.6/tar-install/boot/vmlinux-kbuild-2.6.24-rc4' ** ** ** WARNING ** ** ** Your architecture did not define any architecture-dependant files to be placed into the tarball. Please add those to /home/erik/git/linux-2.6/scripts/package/buildtar ... Tarball successfully created in /home/erik/git/linux-2.6/linux-2.6.24-rc4.tar.gz So it looks like the i386-x86_64 merge has something to do with it. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Allow (O=...) from file
On Wed, Dec 05, 2007 at 10:37:03PM +0100, Erik Mouw wrote: Here's a clue: when I build with ARCH=x86, I get some warnings, but the targz-pkg builds succesfully: [EMAIL PROTECTED]:~/git/linux-2.6 make ARCH=x86 allnoconfig [...] [EMAIL PROTECTED]:~/git/linux-2.6 make ARCH=x86 targz-pkg [...] Kernel: arch/x86/boot/bzImage is ready (#1) /bin/sh /home/erik/git/linux-2.6/scripts/package/buildtar targz-pkg `/home/erik/git/linux-2.6/System.map' - /`/home/erik/git/linux-2.6/tar-install/boot/System.map-2.6.24-rc4' `/home/erik/git/linux-2.6/.config' - /`/home/erik/git/linux-2.6/tar-install/boot/config-2.6.24-rc4' `/home/erik/git/linux-2.6/vmlinux' - /`/home/erik/git/linux-2.6/tar-install/boot/vmlinux-2.6.24-rc4' `arch/x86/boot/bzImage' - /`/home/erik/git/linux-2.6/tar-install/boot/vmlinux-kbuild-2.6.24-rc4' ** ** ** WARNING ** ** ** Your architecture did not define any architecture-dependant files to be placed into the tarball. Please add those to /home/erik/git/linux-2.6/scripts/package/buildtar ... Tarball successfully created in /home/erik/git/linux-2.6/linux-2.6.24-rc4.tar.gz So it looks like the i386-x86_64 merge has something to do with it. Sorry, wrong clue. It builds because there are no modules to be made (allnoconfig). Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Linux 2.6.24-rc3
On Fri, Nov 16, 2007 at 09:33:22PM -0800, Linus Torvalds wrote: > Go get it, and test it. I gav 2.6.24 a first try and "make targz-pkg" fails on i386: /bin/sh /home/erik/git/linux-2.6/scripts/package/buildtar targz-pkg Makefile:119: *** Output directory (O=...) specifies kernel src dir. Stop. make[1]: *** [targz-pkg] Error 2 make: *** [targz-pkg] Error 2 Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Linux 2.6.24-rc3
On Fri, Nov 16, 2007 at 09:33:22PM -0800, Linus Torvalds wrote: Go get it, and test it. I gav 2.6.24 a first try and make targz-pkg fails on i386: /bin/sh /home/erik/git/linux-2.6/scripts/package/buildtar targz-pkg Makefile:119: *** Output directory (O=...) specifies kernel src dir. Stop. make[1]: *** [targz-pkg] Error 2 make: *** [targz-pkg] Error 2 Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: [PATCH] Documentation/arm/00-INDEX add missing entries.
On Thu, Aug 30, 2007 at 02:35:12PM -0500, Rob Landley wrote: > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> > > Index two unindexed documentation files. Looks OK to me, either submit to Russell's patch system, or maybe Andrew would like to take the patch. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: [PATCH] Documentation/arm/00-INDEX add missing entries.
On Thu, Aug 30, 2007 at 02:35:12PM -0500, Rob Landley wrote: Signed-off-by: Rob Landley [EMAIL PROTECTED] Index two unindexed documentation files. Looks OK to me, either submit to Russell's patch system, or maybe Andrew would like to take the patch. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Versioning file system
On Thu, Jul 05, 2007 at 09:57:40AM -0400, John Stoffel wrote: > >>>>> "Erik" == Erik Mouw <[EMAIL PROTECTED]> writes: > Erik> The only valid use of Streams in Windows I've seen was a virus > Erik> checker that stored a hash of the file in a separate > Erik> stream. Checking a file was a matter of rehashing it and > Erik> comparing against the hash stored in the special hash data > Erik> stream for that particular file. > > So what was stopping a virus from infecting a file, re-computing the > hash and pushing the new hash into the stream? Nothing, but the same holds for virus checkers that store the hash in a separate file. The only advantage of storing the hash in a stream is that the stream is automatically deleted when you remove the file. > You need to keep the computed hashes on Read-Only media for true > security, once you let the system change them, then you're toast Agreed. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Versioning file system
On Wed, Jul 04, 2007 at 04:47:59PM -0400, Theodore Tso wrote: > On Wed, Jul 04, 2007 at 07:32:34PM +0200, Erik Mouw wrote: > > (sorry for the late reply, just got back from holiday) > > > > On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: > > > As I mentioned in my Linux.conf.au presentation a year and a half ago, > > > the main use of Streams in Windows to date has been for system > > > crackers to hide trojan horse code and rootkits so that system > > > administrators couldn't find them. :-) > > > > The only valid use of Streams in Windows I've seen was a virus checker > > that stored a hash of the file in a separate stream. Checking a file > > was a matter of rehashing it and comparing against the hash stored in > > the special hash data stream for that particular file. > > And even that's not a valid use. All the virus would have to do is to > infect the file, and then update the "special hash data stream". Why > is it that when programmers are told about streams as a potential > technology choice, it makes their thinking become fuzzy? :-) I meant valid like "not used as malware". I agree a virus could recompute the hash and go unnoticed. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Versioning file system
On Wed, Jul 04, 2007 at 04:47:59PM -0400, Theodore Tso wrote: On Wed, Jul 04, 2007 at 07:32:34PM +0200, Erik Mouw wrote: (sorry for the late reply, just got back from holiday) On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: As I mentioned in my Linux.conf.au presentation a year and a half ago, the main use of Streams in Windows to date has been for system crackers to hide trojan horse code and rootkits so that system administrators couldn't find them. :-) The only valid use of Streams in Windows I've seen was a virus checker that stored a hash of the file in a separate stream. Checking a file was a matter of rehashing it and comparing against the hash stored in the special hash data stream for that particular file. And even that's not a valid use. All the virus would have to do is to infect the file, and then update the special hash data stream. Why is it that when programmers are told about streams as a potential technology choice, it makes their thinking become fuzzy? :-) I meant valid like not used as malware. I agree a virus could recompute the hash and go unnoticed. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Versioning file system
On Thu, Jul 05, 2007 at 09:57:40AM -0400, John Stoffel wrote: Erik == Erik Mouw [EMAIL PROTECTED] writes: Erik The only valid use of Streams in Windows I've seen was a virus Erik checker that stored a hash of the file in a separate Erik stream. Checking a file was a matter of rehashing it and Erik comparing against the hash stored in the special hash data Erik stream for that particular file. So what was stopping a virus from infecting a file, re-computing the hash and pushing the new hash into the stream? Nothing, but the same holds for virus checkers that store the hash in a separate file. The only advantage of storing the hash in a stream is that the stream is automatically deleted when you remove the file. You need to keep the computed hashes on Read-Only media for true security, once you let the system change them, then you're toast Agreed. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Versioning file system
(sorry for the late reply, just got back from holiday) On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: > As I mentioned in my Linux.conf.au presentation a year and a half ago, > the main use of Streams in Windows to date has been for system > crackers to hide trojan horse code and rootkits so that system > administrators couldn't find them. :-) The only valid use of Streams in Windows I've seen was a virus checker that stored a hash of the file in a separate stream. Checking a file was a matter of rehashing it and comparing against the hash stored in the special hash data stream for that particular file. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Versioning file system
(sorry for the late reply, just got back from holiday) On Mon, Jun 18, 2007 at 01:29:56PM -0400, Theodore Tso wrote: As I mentioned in my Linux.conf.au presentation a year and a half ago, the main use of Streams in Windows to date has been for system crackers to hide trojan horse code and rootkits so that system administrators couldn't find them. :-) The only valid use of Streams in Windows I've seen was a virus checker that stored a hash of the file in a separate stream. Checking a file was a matter of rehashing it and comparing against the hash stored in the special hash data stream for that particular file. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: no more git snapshots?
On Thu, Jun 07, 2007 at 01:22:06PM +0200, Christian Kujau wrote: > On Thu, 7 Jun 2007, Jan Engelhardt wrote: > >After that came -rc4. Next one will be -rc4-git1. > > Ah, ok. I'm using ketchup(1) to track 2.6-git, so it'd take a -rc4-git0 > (same as rc4) to notice that the next version came out... If you want to track 2.6-git, why don't you just use git? A daily "git pull" keeps you up-to-date. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: no more git snapshots?
On Thu, Jun 07, 2007 at 01:22:06PM +0200, Christian Kujau wrote: On Thu, 7 Jun 2007, Jan Engelhardt wrote: After that came -rc4. Next one will be -rc4-git1. Ah, ok. I'm using ketchup(1) to track 2.6-git, so it'd take a -rc4-git0 (same as rc4) to notice that the next version came out... If you want to track 2.6-git, why don't you just use git? A daily git pull keeps you up-to-date. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Question about spinlock in linux kernel
On Thu, Jun 07, 2007 at 12:40:58AM +0800, jidong xiao wrote:
> I found there is such a kernel symbol ".text.lock.spinlock",
> for example,
> # cat /proc/kallsyms | grep spinlock
> 8011e440 T bust_spinlocks
> 802d00fc t .text.lock.spinlock
> 8832ae20 d state_spinlock [nfs]
> but I can not find that who exported such a symbol?I am wondering
> where is this kernel originated from? I mean, if I faced any oops,
> which shows RIP is for example:
> RIP: 0010:[] {.text.lock.spinlock+0}
> then how can i locate the oops?it seems that .text.lock.spinlock is
> neither a function name, nor a variable name, so i am confused, who
> can help me out of here? Any advises is really really appreciated!
It's the name of the ELF section that holds the spinlocks. I wouldn't
know how you could get the name of a particular spinlock from there.
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
signature.asc
Description: Digital signature
Re: Question about spinlock in linux kernel
On Thu, Jun 07, 2007 at 12:40:58AM +0800, jidong xiao wrote:
I found there is such a kernel symbol .text.lock.spinlock,
for example,
# cat /proc/kallsyms | grep spinlock
8011e440 T bust_spinlocks
802d00fc t .text.lock.spinlock
8832ae20 d state_spinlock [nfs]
but I can not find that who exported such a symbol?I am wondering
where is this kernel originated from? I mean, if I faced any oops,
which shows RIP is for example:
RIP: 0010:[8031a4d9] 8031a4d9{.text.lock.spinlock+0}
then how can i locate the oops?it seems that .text.lock.spinlock is
neither a function name, nor a variable name, so i am confused, who
can help me out of here? Any advises is really really appreciated!
It's the name of the ELF section that holds the spinlocks. I wouldn't
know how you could get the name of a particular spinlock from there.
Erik
--
They're all fools. Don't worry. Darwin may be slow, but he'll
eventually get them. -- Matthew Lammers in alt.sysadmin.recovery
signature.asc
Description: Digital signature
Re: O_DIRECT for FAT
On Tue, May 15, 2007 at 01:02:51AM +0100, Hubertus Grobbel wrote: > I found out, that the option O_DIRECT for opening a file on a fat- > filesystem successfully completes. But reading and writing to that > file leads to EINVAL errors (using kernel 2.6.18). Make sure your buffer is page aligned and read/write in multiples of the hard block size (use blockdev --getss to figure out). Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: O_DIRECT for FAT
On Tue, May 15, 2007 at 01:02:51AM +0100, Hubertus Grobbel wrote: I found out, that the option O_DIRECT for opening a file on a fat- filesystem successfully completes. But reading and writing to that file leads to EINVAL errors (using kernel 2.6.18). Make sure your buffer is page aligned and read/write in multiples of the hard block size (use blockdev --getss to figure out). Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Execute in place
On Wed, May 02, 2007 at 03:04:44PM +0100, Hugh Dickins wrote: > On Tue, 1 May 2007, Phillip Susi wrote: > > I seem to remember seeing some patches go by at some point that allowed one > > of > > the rom type embeded system filesystems to directly execute binaries out of > > the original rom memory rather than copying them to ram first, then > > executing > > from there. I was wondering if rootfs or tmpfs support such execute in > > place > > today, or if binaries executed from there have their code segments > > duplicated > > in ram? > > Only ext2 supports it today: see Documentation/filesystems/xip.txt IIRC JFFS2 also supports XIP. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: Execute in place
On Wed, May 02, 2007 at 03:04:44PM +0100, Hugh Dickins wrote: On Tue, 1 May 2007, Phillip Susi wrote: I seem to remember seeing some patches go by at some point that allowed one of the rom type embeded system filesystems to directly execute binaries out of the original rom memory rather than copying them to ram first, then executing from there. I was wondering if rootfs or tmpfs support such execute in place today, or if binaries executed from there have their code segments duplicated in ram? Only ext2 supports it today: see Documentation/filesystems/xip.txt IIRC JFFS2 also supports XIP. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: ZFS with Linux: An Open Plea
On Tue, Apr 17, 2007 at 03:47:32PM +0200, Tomasz K?oczko wrote: > On Tue, 17 Apr 2007, Theodore Tso wrote: > [..] > >Well, that was totally useless answer from the ZFS developers. What > >he should have told you is to contact Sun management, since they are > >the only ones who can decide whether or not to release ZFS under a GPL > >license, and more importantly, to give a patent license for any > >patents they may have filed in the course of developing ZFS. This is > >not anything Linux developers can help you with. > > Realy can't or don't want (?) > So who is responsible for potential changing Linux code licensing for > allow if not incorporate CDDL code correct interraction without breaking > some law ? All Linux contributors (i.e: copyright owners) are. If you want to change the kernel license, you have all contributors to agree. Like somebody else in this thread already said: some of them can't be reached anymore, some of them are even dead. For Sun it would be much easier: there might be many contributors to ZFS, but all of them are employed by Sun and hence Sun owns the copyright and has the choice of license. > And/or what Linux can loose on follow this king changes ? A lot. Like an even playing field for all contributors. > And/or why Linux code licensing can't evolve ? Seems when Linux code was > licensed noone was thinking about case like interraction with code under > license like CDDL so why now it can be corrected and still many people try > to think like "anything arond Linux must evolve .. but not Linux" (?) The Linux kernel was licensed under GPLv2 way before Sun even thought about CDDL. You can't blame Linus for choosing a license that was incompatible with to be written future licenses. > Why this can't be fixes ? Because so far we haven't found a way to ask dead copyright owners to think about relicensing their code. And even if we had, that still doesn't mean they would actually agree with relicensing their code. > If in this ponit in Linux "evniroment" can't be chaged .. sorry but is it > not kind of hipocritics ? Nothing hypocritical about it, just undoable. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: ZFS with Linux: An Open Plea
On Tue, Apr 17, 2007 at 03:47:32PM +0200, Tomasz K?oczko wrote: On Tue, 17 Apr 2007, Theodore Tso wrote: [..] Well, that was totally useless answer from the ZFS developers. What he should have told you is to contact Sun management, since they are the only ones who can decide whether or not to release ZFS under a GPL license, and more importantly, to give a patent license for any patents they may have filed in the course of developing ZFS. This is not anything Linux developers can help you with. Realy can't or don't want (?) So who is responsible for potential changing Linux code licensing for allow if not incorporate CDDL code correct interraction without breaking some law ? All Linux contributors (i.e: copyright owners) are. If you want to change the kernel license, you have all contributors to agree. Like somebody else in this thread already said: some of them can't be reached anymore, some of them are even dead. For Sun it would be much easier: there might be many contributors to ZFS, but all of them are employed by Sun and hence Sun owns the copyright and has the choice of license. And/or what Linux can loose on follow this king changes ? A lot. Like an even playing field for all contributors. And/or why Linux code licensing can't evolve ? Seems when Linux code was licensed noone was thinking about case like interraction with code under license like CDDL so why now it can be corrected and still many people try to think like anything arond Linux must evolve .. but not Linux (?) The Linux kernel was licensed under GPLv2 way before Sun even thought about CDDL. You can't blame Linus for choosing a license that was incompatible with to be written future licenses. Why this can't be fixes ? Because so far we haven't found a way to ask dead copyright owners to think about relicensing their code. And even if we had, that still doesn't mean they would actually agree with relicensing their code. If in this ponit in Linux evniroment can't be chaged .. sorry but is it not kind of hipocritics ? Nothing hypocritical about it, just undoable. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery signature.asc Description: Digital signature
Re: System hanging randomly (SMP Kernel 2.6.20) - ATI chipset+Pentium 4HT
On Wed, Feb 28, 2007 at 07:18:01PM -0600, Xavier Callejas wrote: > I have a laptop Toshiba A70, I attach a DMESG so you know my system. > > The problem is that the system hang randomly and I don't know why, I can se > nothing on /var/log/message realted to the hang (I have to force a shutdown > first). > > With the NOAPIC option the hang just delay or dismish in frequency. Sometimes > the mouse still can move. > > I can't work in my comp. like this, I have posted many messages to suse > forum, > and other forums but nobody help me. I'm a primary Linux user, I'm a little > disapointed because I have not been able to find the solution since monts. Try to recreate the problem without the proprietary wlan driver. With that driver loaded it's impossible to debug. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: System hanging randomly (SMP Kernel 2.6.20) - ATI chipset+Pentium 4HT
On Wed, Feb 28, 2007 at 07:18:01PM -0600, Xavier Callejas wrote: I have a laptop Toshiba A70, I attach a DMESG so you know my system. The problem is that the system hang randomly and I don't know why, I can se nothing on /var/log/message realted to the hang (I have to force a shutdown first). With the NOAPIC option the hang just delay or dismish in frequency. Sometimes the mouse still can move. I can't work in my comp. like this, I have posted many messages to suse forum, and other forums but nobody help me. I'm a primary Linux user, I'm a little disapointed because I have not been able to find the solution since monts. Try to recreate the problem without the proprietary wlan driver. With that driver loaded it's impossible to debug. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Changelog question
On Sat, Feb 24, 2007 at 08:29:02PM +0100, Nicholas Mc Guire wrote: > looking at the Changelogs of the last 2.6.17 kernel and the > first 2.6.18 it is obvious that a lot happened in between - are > there some changelogs related to 2.6.18 development that are not found > at http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.18.# + > http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.18-rc# > For assessment purposes it would be helpfull to know what low level > changes happened i.e. when and where were __raw_spin_* introduced ? but > I was not able to extract such infos from the ChangeLogs in the above > directories. Use git to figure out: git-log v2.6.17..v2.6.18 Erik -- +-- Erik Mouw -- www.harddisk-recovery.nl -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Changelog question
On Sat, Feb 24, 2007 at 08:29:02PM +0100, Nicholas Mc Guire wrote: looking at the Changelogs of the last 2.6.17 kernel and the first 2.6.18 it is obvious that a lot happened in between - are there some changelogs related to 2.6.18 development that are not found at http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.18.# + http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.18-rc# For assessment purposes it would be helpfull to know what low level changes happened i.e. when and where were __raw_spin_* introduced ? but I was not able to extract such infos from the ChangeLogs in the above directories. Use git to figure out: git-log v2.6.17..v2.6.18 Erik -- +-- Erik Mouw -- www.harddisk-recovery.nl -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: smp and irq conflict
On Fri, Feb 02, 2007 at 01:04:53AM +0100, Lapo TIN wrote: > I need to capture at 25 frame per second from each channel... > So 25 x 8 total frames per second on the pci. Each PAL frame takes about 800k, so that makes 20MB/s per channel. With 8 channels that makes 160 MB/s. That will most certainly overwhelm a normal 33 MHz 32 bit PCI bus which has a theoretical bandwidth of 132 MB/s (90MB/s max in practice). Modern PCs have faster PCI busses (66MHz, 64 bit, PCI-X, or PCI-e) so there's less chance on bus contention. On the other hand, I suppose you will store the video streams on disk. That will use another 20MB/s per channel on the bus so the total becomes 320 MB/s. You need some careful system design in order to get that right. Especially look carefully at bus contention, if the system has multiple busses, distribute the bttv cards over those busses. Also be sure to have enough bandwidth for the disk subsystem. > So do you think I have to change the motherboard ? > What is important ? the chipset ? is there specification I need ? Last time I had to record frame-synchronous video from 3 streams (8 years ago) PCs could hardly manage 2 streams over their bus and there was no way to guarantee frame sync. The only way out was to use an SGI Onyx2 with 3 digital video option cards and a large disk subsystem. That made the whole system much more expensive but at that time it was the only way to meet all requirements. I don't know about current PCs, bus speeds have improved. It is however still important how those busses are connected together and to the chipset. You have to figure out from your motherboard documentation if there is enough bandwidth available. If there isn't, get a faster motherboard, or consider using compressing grabber cards like the Hauppauge PVR 150 or PVR 500. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: smp and irq conflict
On Fri, Feb 02, 2007 at 01:04:53AM +0100, Lapo TIN wrote: I need to capture at 25 frame per second from each channel... So 25 x 8 total frames per second on the pci. Each PAL frame takes about 800k, so that makes 20MB/s per channel. With 8 channels that makes 160 MB/s. That will most certainly overwhelm a normal 33 MHz 32 bit PCI bus which has a theoretical bandwidth of 132 MB/s (90MB/s max in practice). Modern PCs have faster PCI busses (66MHz, 64 bit, PCI-X, or PCI-e) so there's less chance on bus contention. On the other hand, I suppose you will store the video streams on disk. That will use another 20MB/s per channel on the bus so the total becomes 320 MB/s. You need some careful system design in order to get that right. Especially look carefully at bus contention, if the system has multiple busses, distribute the bttv cards over those busses. Also be sure to have enough bandwidth for the disk subsystem. So do you think I have to change the motherboard ? What is important ? the chipset ? is there specification I need ? Last time I had to record frame-synchronous video from 3 streams (8 years ago) PCs could hardly manage 2 streams over their bus and there was no way to guarantee frame sync. The only way out was to use an SGI Onyx2 with 3 digital video option cards and a large disk subsystem. That made the whole system much more expensive but at that time it was the only way to meet all requirements. I don't know about current PCs, bus speeds have improved. It is however still important how those busses are connected together and to the chipset. You have to figure out from your motherboard documentation if there is enough bandwidth available. If there isn't, get a faster motherboard, or consider using compressing grabber cards like the Hauppauge PVR 150 or PVR 500. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Free Linux Driver Development!
On Thu, Feb 01, 2007 at 09:45:06AM -0500, Lennart Sorensen wrote: > On Thu, Feb 01, 2007 at 02:59:03PM +0100, Erik Mouw wrote: > > I can't remember that kind of corruption ever being reported to the > > bcm43xx-dev mailing list. > > Well I assumed it messed up the eeprom settings, since we had to go into > the advanced driver settings and change it from 802.11b only back to > auto mode and I would think those settings are stored in the eeprom if > booting a 2.6.18 kernel and loading the bcm43xx driver can cause it to > stop working, then it has to be an eeprom setting. > > Actually I suppose the other posibility is that you simply have to power > cycle before booting windows after linux to avoid any left over settings > in the chip from being a problem. That may be what I did. Given I > couldn't get the card to connect using the bcm43xx driver anyhow, I > didn't spend too much time trying (I am fairly sure I set the AP to > 802.11g only though which may have been a problem). That's what my laptop needs. Not for the wireless card, but somehow windows locks up if I just reboot the machine. Of course no nice Oops message or so. > Excellent. Is the bcm43xx planning to get 802.11g mode working at some > point? Most certainly, the plans are there for quite some time, but... > Is broadcom ever going to help out with any specs for their > hardware or do they still mistakenly believe that end users are not > their customers? ... the documentation isn't. Right now the only available documentation comes from reverse engineering. It's actually rather amazing that the authors came this far, no vendor documentation yet still a lot of supported cards. > Given the behaviour of broadcom over the years I know > I don't intend to buy anything with a broadcom chip in it again, which > means broadcom's behaviour directly means they will get less sales to the > laptop makers, since some people will actively avoid anything with > broadcom's hardware in it. :) That's my take as well. They already lost us on the Gig ethernet cards. A couple of years ago we considered Broadcom based cards, but given the lack of vendor driver support, we got Intel E1000 based cards instead. We also considered NatSemi gigE cards, but the Intels were much faster. Right now we use about 15 E1000's with probably more to come (they go in every new machine). Not a high figure but still a lost sale for Broadcom. As for wireless, for personal use I needed a wireless PCMCIA/CardBus card and a Linksys bcm4318 based card was the only reasonably supported card I could get. It works but still has its peculiarities. Erik -- +-- Erik Mouw -- www.harddisk-recovery.nl -- 0800 220 20 20 -- | Eigen lab: Delftechpark 26, 2628 XH, Delft, Nederland | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! - 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: Need all the patche from kernel-2.6.7 to kernel-2.6.19 related to VM
On Wed, Jan 31, 2007 at 04:40:42AM +, Seetharam Dharmosoth wrote: > Can you please suggest me from where do I get the VM > patches from kernel2.6.7 to kernel-2.6.19? Untar linux-2.6.7 and 2.6.19 and run a diff against the mm directory in each tree. Or if you have git: "git diff ..v2.6.19 mm/" . Only disadvantage is that it will give you only the diff from 2.6.11. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Free Linux Driver Development!
On Tue, Jan 30, 2007 at 05:23:44PM -0500, Lennart Sorensen wrote: > On Tue, Jan 30, 2007 at 05:12:31PM -0500, Jeff Garzik wrote: > > You mean the bcm43xx wireless driver that's been upstream for months? > > And seems to do 802.11b only and screw up the eeprom settings so that > the windows driver gets confused next time you boot windows. Lovely > driver. I can't remember that kind of corruption ever being reported to the bcm43xx-dev mailing list. > If the bios on the laptop in question would let me change the > minipci card I would. To something with a ralink on it. You could use a CardBus or USB card. > Seems the ralink driver maintainers are doing a lot of the work on the > core wifi infastructure too. Lots of work beyond just the driver then. So are the bcm43xx maintainers. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Free Linux Driver Development!
On Tue, Jan 30, 2007 at 05:23:44PM -0500, Lennart Sorensen wrote: On Tue, Jan 30, 2007 at 05:12:31PM -0500, Jeff Garzik wrote: You mean the bcm43xx wireless driver that's been upstream for months? And seems to do 802.11b only and screw up the eeprom settings so that the windows driver gets confused next time you boot windows. Lovely driver. I can't remember that kind of corruption ever being reported to the bcm43xx-dev mailing list. If the bios on the laptop in question would let me change the minipci card I would. To something with a ralink on it. You could use a CardBus or USB card. Seems the ralink driver maintainers are doing a lot of the work on the core wifi infastructure too. Lots of work beyond just the driver then. So are the bcm43xx maintainers. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Need all the patche from kernel-2.6.7 to kernel-2.6.19 related to VM
On Wed, Jan 31, 2007 at 04:40:42AM +, Seetharam Dharmosoth wrote: Can you please suggest me from where do I get the VM patches from kernel2.6.7 to kernel-2.6.19? Untar linux-2.6.7 and 2.6.19 and run a diff against the mm directory in each tree. Or if you have git: git diff ..v2.6.19 mm/ . Only disadvantage is that it will give you only the diff from 2.6.11. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Free Linux Driver Development!
On Thu, Feb 01, 2007 at 09:45:06AM -0500, Lennart Sorensen wrote: On Thu, Feb 01, 2007 at 02:59:03PM +0100, Erik Mouw wrote: I can't remember that kind of corruption ever being reported to the bcm43xx-dev mailing list. Well I assumed it messed up the eeprom settings, since we had to go into the advanced driver settings and change it from 802.11b only back to auto mode and I would think those settings are stored in the eeprom if booting a 2.6.18 kernel and loading the bcm43xx driver can cause it to stop working, then it has to be an eeprom setting. Actually I suppose the other posibility is that you simply have to power cycle before booting windows after linux to avoid any left over settings in the chip from being a problem. That may be what I did. Given I couldn't get the card to connect using the bcm43xx driver anyhow, I didn't spend too much time trying (I am fairly sure I set the AP to 802.11g only though which may have been a problem). That's what my laptop needs. Not for the wireless card, but somehow windows locks up if I just reboot the machine. Of course no nice Oops message or so. Excellent. Is the bcm43xx planning to get 802.11g mode working at some point? Most certainly, the plans are there for quite some time, but... Is broadcom ever going to help out with any specs for their hardware or do they still mistakenly believe that end users are not their customers? ... the documentation isn't. Right now the only available documentation comes from reverse engineering. It's actually rather amazing that the authors came this far, no vendor documentation yet still a lot of supported cards. Given the behaviour of broadcom over the years I know I don't intend to buy anything with a broadcom chip in it again, which means broadcom's behaviour directly means they will get less sales to the laptop makers, since some people will actively avoid anything with broadcom's hardware in it. :) That's my take as well. They already lost us on the Gig ethernet cards. A couple of years ago we considered Broadcom based cards, but given the lack of vendor driver support, we got Intel E1000 based cards instead. We also considered NatSemi gigE cards, but the Intels were much faster. Right now we use about 15 E1000's with probably more to come (they go in every new machine). Not a high figure but still a lost sale for Broadcom. As for wireless, for personal use I needed a wireless PCMCIA/CardBus card and a Linksys bcm4318 based card was the only reasonably supported card I could get. It works but still has its peculiarities. Erik -- +-- Erik Mouw -- www.harddisk-recovery.nl -- 0800 220 20 20 -- | Eigen lab: Delftechpark 26, 2628 XH, Delft, Nederland | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! - 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] Print number of oopses in Sysrq-P output
On Thu, Jan 18, 2007 at 08:05:22PM +0300, Alexey Dobriyan wrote: > From: Pavel Emelianov <[EMAIL PROTECTED]> > > Useful in deciding whether said output should be ignored > in absence of other info. :) > > Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]> > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> > --- > > arch/i386/kernel/process.c |4 +++- > arch/i386/kernel/traps.c |2 +- > arch/x86_64/kernel/process.c |6 -- > arch/x86_64/kernel/traps.c |3 ++- > 4 files changed, 10 insertions(+), 5 deletions(-) What about the other architectures? > --- a/arch/i386/kernel/traps.c > +++ b/arch/i386/kernel/traps.c > @@ -366,6 +366,7 @@ int is_valid_bugaddr(unsigned long eip) > return ud2 == 0x0b0f; > } > > +int die_counter = 0; Global variables don't have to be initialised at 0. They live in the .bss segment so they will automatically initialised at 0 and not take space in the kernel image. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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] Print number of oopses in Sysrq-P output
On Thu, Jan 18, 2007 at 08:05:22PM +0300, Alexey Dobriyan wrote: From: Pavel Emelianov [EMAIL PROTECTED] Useful in deciding whether said output should be ignored in absence of other info. :) Signed-off-by: Pavel Emelianov [EMAIL PROTECTED] Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- arch/i386/kernel/process.c |4 +++- arch/i386/kernel/traps.c |2 +- arch/x86_64/kernel/process.c |6 -- arch/x86_64/kernel/traps.c |3 ++- 4 files changed, 10 insertions(+), 5 deletions(-) What about the other architectures? --- a/arch/i386/kernel/traps.c +++ b/arch/i386/kernel/traps.c @@ -366,6 +366,7 @@ int is_valid_bugaddr(unsigned long eip) return ud2 == 0x0b0f; } +int die_counter = 0; Global variables don't have to be initialised at 0. They live in the .bss segment so they will automatically initialised at 0 and not take space in the kernel image. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: query related to serial console
On Wed, Jan 17, 2007 at 11:26:54AM +, Seetharam Dharmosoth wrote: > Is Linux having 'non-break interface for serial > console' ? No idea. Could you explain what a 'non-break interface for serial console' is? Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Weird harddisk behaviour
On Wed, Jan 17, 2007 at 11:09:21AM +0100, Turbo Fredriksson wrote:
> Quoting Ken Moffat <[EMAIL PROTECTED]>:
> > Certainly, fdisk from util-linux doesn't know about mac disks, and
> > I thought the same was true for cfdisk and sfdisk. Many years ago
> > there was mac-fdisk, I think also known as pdisk, but nowadays the
> > common tool for partitioning mac disks is probably parted.
>
> Yes. See now that 'fdisk' is a softlink to 'mac-fdisk'...
>
> > Please try parted.
>
> Same thing ('mkpartfs primary ext2 0 40'):
>
> Jan 17 11:03:41 localhost kernel: [254985.117447] EXT2-fs: sdb1: couldn't
> mount RDWR because of unsupported optional features (1).
I don't know if any of those tools tell the kernel that the partition
table changedand that it has to reread them. To be sure the kernel
knows, run "blockdev --rereadpt /dev/sdb".
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
-
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: Weird harddisk behaviour
On Wed, Jan 17, 2007 at 11:09:21AM +0100, Turbo Fredriksson wrote:
Quoting Ken Moffat [EMAIL PROTECTED]:
Certainly, fdisk from util-linux doesn't know about mac disks, and
I thought the same was true for cfdisk and sfdisk. Many years ago
there was mac-fdisk, I think also known as pdisk, but nowadays the
common tool for partitioning mac disks is probably parted.
Yes. See now that 'fdisk' is a softlink to 'mac-fdisk'...
Please try parted.
Same thing ('mkpartfs primary ext2 0 40'):
Jan 17 11:03:41 localhost kernel: [254985.117447] EXT2-fs: sdb1: couldn't
mount RDWR because of unsupported optional features (1).
I don't know if any of those tools tell the kernel that the partition
table changedand that it has to reread them. To be sure the kernel
knows, run blockdev --rereadpt /dev/sdb.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
-
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: query related to serial console
On Wed, Jan 17, 2007 at 11:26:54AM +, Seetharam Dharmosoth wrote: Is Linux having 'non-break interface for serial console' ? No idea. Could you explain what a 'non-break interface for serial console' is? Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 create or read/write a file in linux device driver?
On Fri, Jan 12, 2007 at 09:27:01AM -0500, linux-os (Dick Johnson) wrote: > Sometimes a idiot boss will say; "You need to read or write files from > within the driver. If you don't do what I tell you, you are fired!" Sometimes PHBs want you to break the laws of physics. I suggest you read Dilbert about that. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 create or read/write a file in linux device driver?
On Fri, Jan 12, 2007 at 11:27:01AM +0100, Jesper Juhl wrote: > On 12/01/07, congwen <[EMAIL PROTECTED]> wrote: > >Hello everyone, I want to create and read/write a file in Linux kernel or > >device driver, > > Don't read/write user space files from kernel space. > > Please search the archives, this get asked a lot and it has been > explained a million times why it's a bad idea. > You can also read http://www.linuxjournal.com/article/8110 Rather point to http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 create or read/write a file in linux device driver?
On Fri, Jan 12, 2007 at 11:27:01AM +0100, Jesper Juhl wrote: On 12/01/07, congwen [EMAIL PROTECTED] wrote: Hello everyone, I want to create and read/write a file in Linux kernel or device driver, Don't read/write user space files from kernel space. Please search the archives, this get asked a lot and it has been explained a million times why it's a bad idea. You can also read http://www.linuxjournal.com/article/8110 Rather point to http://kernelnewbies.org/FAQ/WhyWritingFilesFromKernelIsBad Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 create or read/write a file in linux device driver?
On Fri, Jan 12, 2007 at 09:27:01AM -0500, linux-os (Dick Johnson) wrote: Sometimes a idiot boss will say; You need to read or write files from within the driver. If you don't do what I tell you, you are fired! Sometimes PHBs want you to break the laws of physics. I suggest you read Dilbert about that. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: can't cleanup /proc/swaps without rebooting ?
On Thu, Jan 11, 2007 at 03:59:30PM +0100, Jacky Malcles wrote: > is there a way, other than rebooting, to clean up /proc/swaps ? > > I'm in this situation (due to testing errors), > # cat /proc/swaps > FilenameTypeSizeUsed > Priority > /dev/sdc1 partition 2040064 0 -1 > /tmp/swaH4mvTI/swapfilenext\040(deleted) file 48960 0 -31 > /tmp/swa5TlBva/swapfilenext\040(deleted) file 49088 0 -118 > # > # swapon -s > FilenameTypeSizeUsed > Priority > /dev/sdc1 partition 2040064 0 -1 > /tmp/swaH4mvTI/swapfilenext\040(deleted) file 48960 0 -31 > /tmp/swa5TlBva/swapfilenext\040(deleted) file 49088 0 -118 > # "swapoff /dev/sdc1" or "swapoff /tmp/swa5TlBva/swapfilenext". Don't know if the latter works when the file is unlinked, just try. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: O_DIRECT question
On Wed, Jan 10, 2007 at 07:05:30PM -0800, Linus Torvalds wrote: > I should have fought back harder. There really is no valid reason for EVER > using O_DIRECT. You need a buffer whatever IO you do, and it might as well > be the page cache. There are better ways to control the page cache than > play games and think that a page cache isn't necessary. There is a valid reason: you really don't want to go through the page cache when a hard drive has bad blocks. The only way to get fast recovery and correct error reporting to userspace is by using O_DIRECT. > So don't use O_DIRECT. Use things like madvise() and posix_fadvise() > instead. Both don't do what I want it to do: only read the sector I request you to read and certainly do not try to outsmart me by doing some kind of readahead. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: O_DIRECT question
On Wed, Jan 10, 2007 at 07:05:30PM -0800, Linus Torvalds wrote: I should have fought back harder. There really is no valid reason for EVER using O_DIRECT. You need a buffer whatever IO you do, and it might as well be the page cache. There are better ways to control the page cache than play games and think that a page cache isn't necessary. There is a valid reason: you really don't want to go through the page cache when a hard drive has bad blocks. The only way to get fast recovery and correct error reporting to userspace is by using O_DIRECT. So don't use O_DIRECT. Use things like madvise() and posix_fadvise() instead. Both don't do what I want it to do: only read the sector I request you to read and certainly do not try to outsmart me by doing some kind of readahead. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: can't cleanup /proc/swaps without rebooting ?
On Thu, Jan 11, 2007 at 03:59:30PM +0100, Jacky Malcles wrote: is there a way, other than rebooting, to clean up /proc/swaps ? I'm in this situation (due to testing errors), # cat /proc/swaps FilenameTypeSizeUsed Priority /dev/sdc1 partition 2040064 0 -1 /tmp/swaH4mvTI/swapfilenext\040(deleted) file 48960 0 -31 /tmp/swa5TlBva/swapfilenext\040(deleted) file 49088 0 -118 # # swapon -s FilenameTypeSizeUsed Priority /dev/sdc1 partition 2040064 0 -1 /tmp/swaH4mvTI/swapfilenext\040(deleted) file 48960 0 -31 /tmp/swa5TlBva/swapfilenext\040(deleted) file 49088 0 -118 # swapoff /dev/sdc1 or swapoff /tmp/swa5TlBva/swapfilenext. Don't know if the latter works when the file is unlinked, just try. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Open letter to Linux kernel developers (was Re: Binary Drivers)
On Thu, Dec 21, 2006 at 01:16:15PM -0500, [EMAIL PROTECTED] wrote: > At least nVidia *does* actually Get It, they just don't have a choice in > implementing it, because all their current hardware includes patents that > they licensed from other companies (I believe some of the OpenGL stuff that > originated at SGI and got bought by Microsoft is involved, but I have no > hard references for actual patent numbers). And then they have the big > problem - do they keep using the patent in order to boost performance, > or no? Wasn't the whole idea about patents that you publish your invention? Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Open letter to Linux kernel developers (was Re: Binary Drivers)
On Thu, Dec 21, 2006 at 01:16:15PM -0500, [EMAIL PROTECTED] wrote: At least nVidia *does* actually Get It, they just don't have a choice in implementing it, because all their current hardware includes patents that they licensed from other companies (I believe some of the OpenGL stuff that originated at SGI and got bought by Microsoft is involved, but I have no hard references for actual patent numbers). And then they have the big problem - do they keep using the patent in order to boost performance, or no? Wasn't the whole idea about patents that you publish your invention? Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Binary Drivers
On Thu, Dec 21, 2006 at 10:33:10AM -0600, Scott Preece wrote: > (b) "Thank you for requesting a driver to support our hardware on > Linux. Unfortunately, we don't have time either to provide such a > driver or write the documentation that would allow you do so. The > Linux market is not big enough to justify the legal and technical > expense involved. However, we can provide you with this binary driver > that we believe will allow you to use the hardware in your system, > just as we provide binary drivers for other hardware platforms." You forgot to add: "However, we thought the legal and technical expense involved in writing this binary driver and possibly violating the Linux kernel copyright was well spend." My 0.02 EUR. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 disk performance.
On Thu, Dec 21, 2006 at 11:48:42AM +0545, Manish Regmi wrote: > Yes... my application does large amount of I/O. It actually writes > video data received from ethernet(IP camera) to the disk using 128 K > chunks. Bursty video traffic is really an application that could take advantage from the kernel buffering. Unless you want to reinvent the wheel and do the buffering yourself (it is possible though, I've done it on IRIX). BTW, why are you so keen on smooth-at-the-microlevel writeout? With real time video applications it's only important not to drop frames. How fast those frames will go to the disk isn't really an issue, as long as you don't overflow the intermediate buffer. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery - 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 disk performance.
On Thu, Dec 21, 2006 at 11:48:42AM +0545, Manish Regmi wrote: Yes... my application does large amount of I/O. It actually writes video data received from ethernet(IP camera) to the disk using 128 K chunks. Bursty video traffic is really an application that could take advantage from the kernel buffering. Unless you want to reinvent the wheel and do the buffering yourself (it is possible though, I've done it on IRIX). BTW, why are you so keen on smooth-at-the-microlevel writeout? With real time video applications it's only important not to drop frames. How fast those frames will go to the disk isn't really an issue, as long as you don't overflow the intermediate buffer. Erik -- They're all fools. Don't worry. Darwin may be slow, but he'll eventually get them. -- Matthew Lammers in alt.sysadmin.recovery - 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: Binary Drivers
On Thu, Dec 21, 2006 at 10:33:10AM -0600, Scott Preece wrote: (b) Thank you for requesting a driver to support our hardware on Linux. Unfortunately, we don't have time either to provide such a driver or write the documentation that would allow you do so. The Linux market is not big enough to justify the legal and technical expense involved. However, we can provide you with this binary driver that we believe will allow you to use the hardware in your system, just as we provide binary drivers for other hardware platforms. You forgot to add: However, we thought the legal and technical expense involved in writing this binary driver and possibly violating the Linux kernel copyright was well spend. My 0.02 EUR. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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] Add a new section to CodingStyle, promoting include/linux/kernel.h.
On Mon, Dec 18, 2006 at 12:43:35PM -0500, Robert P. J. Day wrote: > Add a new section to the CodingStyle file, encouraging people not to > re-invent available kernel macros such as ARRAY_SIZE(), > FIELD_SIZEOF(), min() and max(), among others. Good stuff. Could you also mention the printk() KERN_ALERT etc. levels? I've seen quite some people using "<1>" on the kernelnewbies list. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Detecting disk I/O errors
On Mon, Dec 18, 2006 at 02:05:41PM +0100, Olivier Galibert wrote: > Is there a way to know if there has been I/O error(s) on a specific > disk or partition since boot other than parsing dmesg and hoping it's > both still there and in the expected format? Use smartctl. It can be started in a monitor mode. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 disk performance.
On Mon, Dec 18, 2006 at 06:24:39PM +0545, Manish Regmi wrote: > On 12/18/06, Arjan van de Ven <[EMAIL PROTECTED]> wrote: > >if you want truely really smooth writes you'll have to work for it, > >since "bumpy" writes tend to be better for performance so naturally the > >kernel will favor those. > > > >to get smooth writes you'll need to do a threaded setup where you do an > >msync/fdatasync/sync_file_range on a frequent-but-regular interval from > >a thread. Be aware that this is quite likely to give you lower maximum > >performance than the batching behavior though. > > > > Thanks... > > But isn't O_DIRECT supposed to bypass buffering in Kernel? It is. > Doesn't it directly write to disk? Yes, but it still uses an IO scheduler. > I tried to put fdatasync() at regular intervals but there was no > visible effect. In your first message you mentioned you were using an ancient 2.6.10 kernel. That kernel uses the anticipatory IO scheduler. Update to the latest stable kernel (2.6.19.1 at time of writing) and it will default to the CFQ scheduler which has a smoother writeout, plus you can give your process a different IO scheduling class and level (see Documentation/block/ioprio.txt). Erik - 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 disk performance.
On Mon, Dec 18, 2006 at 06:24:39PM +0545, Manish Regmi wrote: On 12/18/06, Arjan van de Ven [EMAIL PROTECTED] wrote: if you want truely really smooth writes you'll have to work for it, since bumpy writes tend to be better for performance so naturally the kernel will favor those. to get smooth writes you'll need to do a threaded setup where you do an msync/fdatasync/sync_file_range on a frequent-but-regular interval from a thread. Be aware that this is quite likely to give you lower maximum performance than the batching behavior though. Thanks... But isn't O_DIRECT supposed to bypass buffering in Kernel? It is. Doesn't it directly write to disk? Yes, but it still uses an IO scheduler. I tried to put fdatasync() at regular intervals but there was no visible effect. In your first message you mentioned you were using an ancient 2.6.10 kernel. That kernel uses the anticipatory IO scheduler. Update to the latest stable kernel (2.6.19.1 at time of writing) and it will default to the CFQ scheduler which has a smoother writeout, plus you can give your process a different IO scheduling class and level (see Documentation/block/ioprio.txt). Erik - 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: Detecting disk I/O errors
On Mon, Dec 18, 2006 at 02:05:41PM +0100, Olivier Galibert wrote: Is there a way to know if there has been I/O error(s) on a specific disk or partition since boot other than parsing dmesg and hoping it's both still there and in the expected format? Use smartctl. It can be started in a monitor mode. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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] Add a new section to CodingStyle, promoting include/linux/kernel.h.
On Mon, Dec 18, 2006 at 12:43:35PM -0500, Robert P. J. Day wrote: Add a new section to the CodingStyle file, encouraging people not to re-invent available kernel macros such as ARRAY_SIZE(), FIELD_SIZEOF(), min() and max(), among others. Good stuff. Could you also mention the printk() KERN_ALERT etc. levels? I've seen quite some people using 1 on the kernelnewbies list. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 slack space question
On Fri, Dec 08, 2006 at 12:21:04PM -0500, Maria Short wrote: > I have a question regarding how the Linux kernel handles slack space. > I know that the ext3 filesystems typically use 1,2 or 4 KB blocks and > if a file is not an even multiple of the block size then the last > allocated block will not be completely filled, the remaining space is > wasted as slack space. > > What I need is the code in the kernel that does that. I have been > looking at http://lxr.linux.no/source/fs/ext3/inode.c but I could not > find the specific code for partially filling the last block and > placing an EOF at the end, leaving the rest to slack space. Think about it: what value would an EOF have if all byte values are allowed in a file? >From the very first Unix filesystem an inode contains both the number of blocks it contains and the actual file size. > Please forward the answer to [EMAIL PROTECTED] as soon as possible. Hmm no. You asked a public forum so the reply will go to that same public forum. See http://catb.org/esr/faqs/smart-questions.html#noprivate . Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 slack space question
On Fri, Dec 08, 2006 at 12:21:04PM -0500, Maria Short wrote: I have a question regarding how the Linux kernel handles slack space. I know that the ext3 filesystems typically use 1,2 or 4 KB blocks and if a file is not an even multiple of the block size then the last allocated block will not be completely filled, the remaining space is wasted as slack space. What I need is the code in the kernel that does that. I have been looking at http://lxr.linux.no/source/fs/ext3/inode.c but I could not find the specific code for partially filling the last block and placing an EOF at the end, leaving the rest to slack space. Think about it: what value would an EOF have if all byte values are allowed in a file? From the very first Unix filesystem an inode contains both the number of blocks it contains and the actual file size. Please forward the answer to [EMAIL PROTECTED] as soon as possible. Hmm no. You asked a public forum so the reply will go to that same public forum. See http://catb.org/esr/faqs/smart-questions.html#noprivate . Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 0/3] New firewire stack
On Tue, Dec 05, 2006 at 10:13:55AM -0500, Kristian Høgsberg wrote: > Marcel Holtmann wrote: > >can you please use drivers/firewire/ if you want to start clean or > >aiming at replacing drivers/ieee1394/. Using "fw" as an abbreviation in > >the directory path is not really helpful. > > Yes, that's probably a better idea. Do you see a problem with using fw_* > as a prefix in the code though? I don't see anybody using that prefix, but > Stefan pointed out to me that it's often used to abbreviate firmware too. So what about fiwi_*? If that's too close to wifi_*, try frwr_. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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 0/3] New firewire stack
On Tue, Dec 05, 2006 at 10:13:55AM -0500, Kristian Høgsberg wrote: Marcel Holtmann wrote: can you please use drivers/firewire/ if you want to start clean or aiming at replacing drivers/ieee1394/. Using fw as an abbreviation in the directory path is not really helpful. Yes, that's probably a better idea. Do you see a problem with using fw_* as a prefix in the code though? I don't see anybody using that prefix, but Stefan pointed out to me that it's often used to abbreviate firmware too. So what about fiwi_*? If that's too close to wifi_*, try frwr_. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: A problem about DIRECT IO on ext3
On Wed, Aug 31, 2005 at 10:07:45AM +0200, Jens Axboe wrote: > On Mon, Aug 29 2005, Erik Mouw wrote: > > There are four prerequisites for direct IO: > > - the file needs to be opened with O_DIRECT > > - the buffer needs to be page aligned (hint: use getpagesize() instead > > of assuming that a page is 4k > > - reads and writes need to happen *in* multiples of the soft block size > > - reads and writes need to happen *at* multiples of the soft block size > > Actually, the buffer only needs to be hard block size aligned, same goes > for the chunk size used for reads/writes. OK, so that's different from 2.4 where reads/writes needed to be soft block aligned and buffers page aligned. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands | Data lost? Stay calm and contact Harddisk-recovery.com - 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: A problem about DIRECT IO on ext3
On Wed, Aug 31, 2005 at 10:07:45AM +0200, Jens Axboe wrote: On Mon, Aug 29 2005, Erik Mouw wrote: There are four prerequisites for direct IO: - the file needs to be opened with O_DIRECT - the buffer needs to be page aligned (hint: use getpagesize() instead of assuming that a page is 4k - reads and writes need to happen *in* multiples of the soft block size - reads and writes need to happen *at* multiples of the soft block size Actually, the buffer only needs to be hard block size aligned, same goes for the chunk size used for reads/writes. OK, so that's different from 2.4 where reads/writes needed to be soft block aligned and buffers page aligned. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands | Data lost? Stay calm and contact Harddisk-recovery.com - 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.13-rc7
On Fri, Aug 26, 2005 at 09:33:29PM -0700, Deepak Saxena wrote: > On Aug 25 2005, at 16:04, Erik Mouw was caught saying: > > On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: > > > I really wanted to release a 2.6.13, but there's been enough changes > > > while we've been waiting for other issues to resolve that I think it's > > > best to do a -rc7 first. > > > > There's something strange going on with either ACPI or cpufreq. When > > Is there ever anything not strange going on with ACPI. :p Heh :) It gets even stranger: I had to boot to windows to be able to backup my phone. After that, I couldn't recreate the 2.6/3.6 GHz CPU problem anymore. Your explanation is as good as mine... Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: A problem about DIRECT IO on ext3
On Mon, Aug 29, 2005 at 08:15:43PM +0800, colin wrote:
> I wrote a simple program to test direct io, and found that there are some
> strange behaviors of it on "ext3".
> My simple program is below. Assume that the executable file name is
> "directio". If I do the following:
> 1. cp directio aaa
> 2. ./directio directio aaa
>
> The size of aaa is about the same with directio. This is wrong.
No, it's right, but it's not what you expected.
> It should be 3 times the size of directio because there are 2 write
> operations and one lseek to the file end.
I suggest to strace() your program to see what happens.
> If the second file is not opened with "O_DIRECT", the result is correct.
>
> What's the problem of direct io? I found that if I remove the instruction of
> lseek, the result is correct.
There are four prerequisites for direct IO:
- the file needs to be opened with O_DIRECT
- the buffer needs to be page aligned (hint: use getpagesize() instead
of assuming that a page is 4k
- reads and writes need to happen *in* multiples of the soft block size
- reads and writes need to happen *at* multiples of the soft block size
> Is there any problem of lseek when doing direct io on ext3?
> My platform is 2.6.11.
There is no problem.
> Regards,
> Colin
>
> #define _GNU_SOURCE
>
> #include
> #include
> #include
> #include
> #include
Compile your program with -Wall, you're missing quite some include
files over here.
> int main(int argc, char **argv) {
>
> int fd1, fd2, count;
> char *ptr1, *ptr2;
>
> if(argc == 3) {
> fd1 = open(argv[1], O_RDONLY | O_DIRECT, S_IRWXU);
> fd2 = open(argv[2], O_RDWR | O_CREAT | O_DIRECT);
> } else {
> printf("Error syntax\n");
> exit(1);
> }
> printf("%d\n", lseek(fd2, 0, SEEK_END));
Make that lseek(fd2, 4 * 4096, SEEK_SET);
> ptr1 = malloc(4096 + 4096-1);
> ptr2 = (void*)((int)ptr1 - (int)ptr1 % 4096 + 4096);
Use memalign() or posix_memalign().
> do {
> count = read(fd1, ptr2, 4096);
> if(!count)
> break;
And what happens when count < 0 ?
> write(fd2, ptr2, 4096);
> write(fd2, ptr2, 4096);
Check return values.
> } while(count > 0);
>
> free(ptr1);
> close(fd1);
> close(fd2);
return 0;
> }
With the changes, the result is:
[EMAIL PROTECTED]:/tmp > ls -l directio aaa
-rwxr-xr-x 1 erik erik 49152 2005-08-29 15:26 aaa*
-rwxr-xr-x 1 erik erik 12628 2005-08-29 15:26 directio*
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
-
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: A problem about DIRECT IO on ext3
On Mon, Aug 29, 2005 at 08:15:43PM +0800, colin wrote:
I wrote a simple program to test direct io, and found that there are some
strange behaviors of it on ext3.
My simple program is below. Assume that the executable file name is
directio. If I do the following:
1. cp directio aaa
2. ./directio directio aaa
The size of aaa is about the same with directio. This is wrong.
No, it's right, but it's not what you expected.
It should be 3 times the size of directio because there are 2 write
operations and one lseek to the file end.
I suggest to strace() your program to see what happens.
If the second file is not opened with O_DIRECT, the result is correct.
What's the problem of direct io? I found that if I remove the instruction of
lseek, the result is correct.
There are four prerequisites for direct IO:
- the file needs to be opened with O_DIRECT
- the buffer needs to be page aligned (hint: use getpagesize() instead
of assuming that a page is 4k
- reads and writes need to happen *in* multiples of the soft block size
- reads and writes need to happen *at* multiples of the soft block size
Is there any problem of lseek when doing direct io on ext3?
My platform is 2.6.11.
There is no problem.
Regards,
Colin
#define _GNU_SOURCE
#include stdio.h
#include fcntl.h
#include sys/stat.h
#include sys/types.h
#include stdlib.h
Compile your program with -Wall, you're missing quite some include
files over here.
int main(int argc, char **argv) {
int fd1, fd2, count;
char *ptr1, *ptr2;
if(argc == 3) {
fd1 = open(argv[1], O_RDONLY | O_DIRECT, S_IRWXU);
fd2 = open(argv[2], O_RDWR | O_CREAT | O_DIRECT);
} else {
printf(Error syntax\n);
exit(1);
}
printf(%d\n, lseek(fd2, 0, SEEK_END));
Make that lseek(fd2, 4 * 4096, SEEK_SET);
ptr1 = malloc(4096 + 4096-1);
ptr2 = (void*)((int)ptr1 - (int)ptr1 % 4096 + 4096);
Use memalign() or posix_memalign().
do {
count = read(fd1, ptr2, 4096);
if(!count)
break;
And what happens when count 0 ?
write(fd2, ptr2, 4096);
write(fd2, ptr2, 4096);
Check return values.
} while(count 0);
free(ptr1);
close(fd1);
close(fd2);
return 0;
}
With the changes, the result is:
[EMAIL PROTECTED]:/tmp ls -l directio aaa
-rwxr-xr-x 1 erik erik 49152 2005-08-29 15:26 aaa*
-rwxr-xr-x 1 erik erik 12628 2005-08-29 15:26 directio*
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
-
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.13-rc7
On Fri, Aug 26, 2005 at 09:33:29PM -0700, Deepak Saxena wrote: On Aug 25 2005, at 16:04, Erik Mouw was caught saying: On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: I really wanted to release a 2.6.13, but there's been enough changes while we've been waiting for other issues to resolve that I think it's best to do a -rc7 first. There's something strange going on with either ACPI or cpufreq. When Is there ever anything not strange going on with ACPI. :p Heh :) It gets even stranger: I had to boot to windows to be able to backup my phone. After that, I couldn't recreate the 2.6/3.6 GHz CPU problem anymore. Your explanation is as good as mine... Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: syscall: sys_promote
On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote: > I just wrote a tool with kernel patch, which is to set the uid's of a running > process without FORK. > > The tool is at http://users.freeforge.net/~coywolf/pub/promote/ > Usage: promote [uid] > > I once need such a tool to work together with my admin in order to tune my web > configuration. I think it's quite convenient sometimes. > > The situations I can image are: > > 1) root processes can be set to normal priorities, to serve web > service for eg. Most (if not all) web servers can be told to drop all privileges and run as a normal user. If not, you can use selinux to create a policy for such processes (IIRC that's what Fedora does). > 2) admins promote trusted users, so they can do some system work without > knowing >the password Use sudo for that, it allows even much finer grained control. > 3) admins can `promote' a suspect process instead of killing it. Why would that change anything? You only change a process's UID, nothing else. You don't change things like resource limits, so a process started as root with unlimited limits is still allowed to use those limits. AFAIK setrlimit() can't be used to change resource limits of other processes. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote: > > On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote: > > > Right, but it would be nice to have that option if initramfs > > > using tmpfs becomes part of the kernel. > > > > But it's not needed so why add bloat? > > I'm not subscribed, so sorry if this doesn't fall into the original > thread. I'm curious as to why the kernel has to include the decoder - > why you can't just run a self-extracting executable in an empty > initramfs (with a preset capacity if needs be). How would that help? It's still a decoder in the kernel, so why not use one that's well tested instead of using whatever the archive thinks is good? Also remember the code has to be cross platform: an in-kernel decoder will just work on any platform, a self-extracting binary will probably only work on one platform. Besides, initramfs was made to set up userland. A self-extracting binary creates a chicken-and-egg problem: when run it will create a userland, but in order to be run it needs a userland. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 02:15:13PM -0400, [EMAIL PROTECTED] wrote: > >>Could you please please pretty please get an RFC compliant mailer that >>generates "In-Reply-To" and preferable even "References" headers? >>Right >>now every mail you write starts a new thread instead of referencing to >>the previous one. See http://lkml.org/lkml/2005/8/25/180/ to see what >>I mean. > > I'm not subscribed to the list and I use lynx and a small mda > called msmtp, so I know it's awkward (perhaps mostly for me). No, it's mostly awkward for the people reading linux-kernel. Linux-kernel is a very high volume mailing list, and proper use of email threading is *vital* to read it: you immediately get all references to previous messages, and it makes it easy to skip threads you're not interested in (nobody except Alan Cox and his gnomes reads every message to linux-kernel). If you're not subscribed, the normal way is to: - Ask to be Cc'ed (that usually happens anyway). - Reply to the sender, the list, and everybody else in the Cc list. - Keep In-Reply-To and References headers so the other subscribers know what to read and what not. > But, that's my setup. It would never occur to me to use something as inappropriate as a web browser as a mail client... > Perhaps if the list had a followup/reply option, I could use that in lynx. It hasn't for good reasons. Read the LKML FAQ at http://www.tux.org/lkml/ . > But, the list just seems to be useful for reading purposes. > > Perhaps I could access the list through a newsreader and the > replys would be threaded/referenced. Please do so. It will certainly help you to get more/different replies. >>Cpio is perhaps as available as tar, but it's not as used as tar. >>>So? Firefox is as available as IE, but it's not as used as IE. Does >>>that make IE better? > > I have no opinion on which one is better. > > I prefer tar because I have more experience with it, and it works. The kernel people prefer cpio because they have experience with it, it doesn't need too much code, and it works. > It seems to be the most used archiver in the UNIX world. You've been told that there are *technical* reasons not to use tar in the kernel. The kernel developers never cared about what was most used or what "the market wants", but only about what was *technically* useful. >>I know generally an initrd is used to load modules and prepare >>the installation of a Linux system, so it doesn't require much >>in a filesystem. >>>An initramfs can be used to do the same, but doesn't have the overhead >>>of a block device. IOW: it requires even *less* than an initrd. > > Right, an initramfs can/should replace the old initrd method, but > it should be comparable and have a filesystem like tmpfs as an option. Initramfs using ramfs *is* comparable and it *has* a filesystem. > The old initrd method could use any filesystem for the initrd > that the kernel could support, but now with initramfs all you > have is ramfs. Did you ever take some time to actually *understand* what ramfs is, *why* it is used for initramfs, and why you can't use any filesystem you like for an initramfs? > If you add tmpfs to initramfs you make initramfs comparable enough > (on the filesystem level) to replace the old initrd method. Read the code, ramfs *is* comparable to the old initrd method, and tmpfs is the same as ramfs with the difference that its pages can be swapped out. > Initramfs is already ahead of the old initrd method on other levels. It is, but mostly because it makes the kernel boot procedure so much easier and removes a lot of special cases in the code. >>But, it can also be used to hold and run a complete Linux system, >>so a more robust filesystem (tmpfs) is useful. >>>What makes you think tmpfs is more robust than ramfs? What do you mean >>>with a "robust filesystem"? > > I've used tmpfs and ramfs, so it's based on experience. You have used both, so why is tmpfs a "robust filesystem" and ramfs not? Again, what is your definition of a "robust filesystem"? > I'm sure someone could give you a more technical answer, but if > you're a coder you would probably already know. > > For one, if you do "dd if=/dev/zero of=foo" on a ramfs the system > will lock up. "Doctor, it hurts when I do this!" "Well, then don't do that." You found a nice case of "Unix, rope, foot". Erik PS: I'm not going to hunt through my linux-kernel mailbox for replies without proper In-Reply-To and References headers in the hope that I stumble over a possible reply from you. Any reply without such headers will most proba
Re: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 02:15:13PM -0400, [EMAIL PROTECTED] wrote: Could you please please pretty please get an RFC compliant mailer that generates In-Reply-To and preferable even References headers? Right now every mail you write starts a new thread instead of referencing to the previous one. See http://lkml.org/lkml/2005/8/25/180/ to see what I mean. I'm not subscribed to the list and I use lynx and a small mda called msmtp, so I know it's awkward (perhaps mostly for me). No, it's mostly awkward for the people reading linux-kernel. Linux-kernel is a very high volume mailing list, and proper use of email threading is *vital* to read it: you immediately get all references to previous messages, and it makes it easy to skip threads you're not interested in (nobody except Alan Cox and his gnomes reads every message to linux-kernel). If you're not subscribed, the normal way is to: - Ask to be Cc'ed (that usually happens anyway). - Reply to the sender, the list, and everybody else in the Cc list. - Keep In-Reply-To and References headers so the other subscribers know what to read and what not. But, that's my setup. It would never occur to me to use something as inappropriate as a web browser as a mail client... Perhaps if the list had a followup/reply option, I could use that in lynx. It hasn't for good reasons. Read the LKML FAQ at http://www.tux.org/lkml/ . But, the list just seems to be useful for reading purposes. Perhaps I could access the list through a newsreader and the replys would be threaded/referenced. Please do so. It will certainly help you to get more/different replies. Cpio is perhaps as available as tar, but it's not as used as tar. So? Firefox is as available as IE, but it's not as used as IE. Does that make IE better? I have no opinion on which one is better. I prefer tar because I have more experience with it, and it works. The kernel people prefer cpio because they have experience with it, it doesn't need too much code, and it works. It seems to be the most used archiver in the UNIX world. You've been told that there are *technical* reasons not to use tar in the kernel. The kernel developers never cared about what was most used or what the market wants, but only about what was *technically* useful. I know generally an initrd is used to load modules and prepare the installation of a Linux system, so it doesn't require much in a filesystem. An initramfs can be used to do the same, but doesn't have the overhead of a block device. IOW: it requires even *less* than an initrd. Right, an initramfs can/should replace the old initrd method, but it should be comparable and have a filesystem like tmpfs as an option. Initramfs using ramfs *is* comparable and it *has* a filesystem. The old initrd method could use any filesystem for the initrd that the kernel could support, but now with initramfs all you have is ramfs. Did you ever take some time to actually *understand* what ramfs is, *why* it is used for initramfs, and why you can't use any filesystem you like for an initramfs? If you add tmpfs to initramfs you make initramfs comparable enough (on the filesystem level) to replace the old initrd method. Read the code, ramfs *is* comparable to the old initrd method, and tmpfs is the same as ramfs with the difference that its pages can be swapped out. Initramfs is already ahead of the old initrd method on other levels. It is, but mostly because it makes the kernel boot procedure so much easier and removes a lot of special cases in the code. But, it can also be used to hold and run a complete Linux system, so a more robust filesystem (tmpfs) is useful. What makes you think tmpfs is more robust than ramfs? What do you mean with a robust filesystem? I've used tmpfs and ramfs, so it's based on experience. You have used both, so why is tmpfs a robust filesystem and ramfs not? Again, what is your definition of a robust filesystem? I'm sure someone could give you a more technical answer, but if you're a coder you would probably already know. For one, if you do dd if=/dev/zero of=foo on a ramfs the system will lock up. Doctor, it hurts when I do this! Well, then don't do that. You found a nice case of Unix, rope, foot. Erik PS: I'm not going to hunt through my linux-kernel mailbox for replies without proper In-Reply-To and References headers in the hope that I stumble over a possible reply from you. Any reply without such headers will most probably not been seen and just ignored. -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote: On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote: Right, but it would be nice to have that option if initramfs using tmpfs becomes part of the kernel. But it's not needed so why add bloat? I'm not subscribed, so sorry if this doesn't fall into the original thread. I'm curious as to why the kernel has to include the decoder - why you can't just run a self-extracting executable in an empty initramfs (with a preset capacity if needs be). How would that help? It's still a decoder in the kernel, so why not use one that's well tested instead of using whatever the archive thinks is good? Also remember the code has to be cross platform: an in-kernel decoder will just work on any platform, a self-extracting binary will probably only work on one platform. Besides, initramfs was made to set up userland. A self-extracting binary creates a chicken-and-egg problem: when run it will create a userland, but in order to be run it needs a userland. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: syscall: sys_promote
On Fri, Aug 26, 2005 at 05:25:37PM +0800, Coywolf Qi Hunt wrote: I just wrote a tool with kernel patch, which is to set the uid's of a running process without FORK. The tool is at http://users.freeforge.net/~coywolf/pub/promote/ Usage: promote pid [uid] I once need such a tool to work together with my admin in order to tune my web configuration. I think it's quite convenient sometimes. The situations I can image are: 1) root processes can be set to normal priorities, to serve web service for eg. Most (if not all) web servers can be told to drop all privileges and run as a normal user. If not, you can use selinux to create a policy for such processes (IIRC that's what Fedora does). 2) admins promote trusted users, so they can do some system work without knowing the password Use sudo for that, it allows even much finer grained control. 3) admins can `promote' a suspect process instead of killing it. Why would that change anything? You only change a process's UID, nothing else. You don't change things like resource limits, so a process started as root with unlimited limits is still allowed to use those limits. AFAIK setrlimit() can't be used to change resource limits of other processes. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote: > What if you have a root.cpio.gz that requires 200MB to hold, but you > only have 300MB of memory? > > 50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_size=90%). tmpfs will not help you here. Yes, it can be swapped, but just like with ramfs you first need to *unpack* the cpio archive before you can even start the "swapon /dev/hda2" command on it. Same with initrd, btw. If the compressed initrd image, plus the uncompressed image, plus the kernel size are larger than the memory size, the system will not boot. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Initramfs and TMPFS!
Could you please please pretty please get an RFC compliant mailer that generates "In-Reply-To" and preferable even "References" headers? Right now every mail you write starts a new thread instead of referencing to the previous one. See http://lkml.org/lkml/2005/8/25/180/ to see what I mean. On Thu, Aug 25, 2005 at 11:34:01AM -0400, [EMAIL PROTECTED] wrote: > >>On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote: >>I don't know, because tar is probably more widely used and >>consequently people are more familiar with how to use it. >>>As I said before, the cpio format is cleaner/easier to parse in the >>>kernel. Everyone has cpio probably so using tar isn't necessary. > > Cpio is perhaps as available as tar, but it's not as used as tar. So? Firefox is as available as IE, but it's not as used as IE. Does that make IE better? > Unless tar would be inordinately larger than a cpio implementation > (I can't imagine, but I'm not a coder!) I would prefer it. You have been told a couple of times that a tar implementation in kernel is indeed larger than a cpio implementation. If you're not a coder, just believe the coders. > If initramfs replaces the old initrd method it should have something > as a filesystem that's robust and inspires confidence like ext2. The simplicity of ramfs inspires more than enough confidence. > I know generally an initrd is used to load modules and prepare > the installation of a Linux system, so it doesn't require much > in a filesystem. An initramfs can be used to do the same, but doesn't have the overhead of a block device. IOW: it requires even *less* than an initrd. > But, it can also be used to hold and run a complete Linux system, > so a more robust filesystem (tmpfs) is useful. What makes you think tmpfs is more robust than ramfs? What do you mean with a "robust filesystem"? Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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.13-rc7
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: > I really wanted to release a 2.6.13, but there's been enough changes > while we've been waiting for other issues to resolve that I think it's > best to do a -rc7 first. There's something strange going on with either ACPI or cpufreq. When the system boots, I see that the CPU is correctly detected as a 1200 MHz mobile Athlon, but once I log in /proc/cpuinfo says it's 2.6 or 3.6 GHz CPU. I don't have the laptop with me right now, but I'll send the boot messages tonight. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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.13-rc7
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote: I really wanted to release a 2.6.13, but there's been enough changes while we've been waiting for other issues to resolve that I think it's best to do a -rc7 first. There's something strange going on with either ACPI or cpufreq. When the system boots, I see that the CPU is correctly detected as a 1200 MHz mobile Athlon, but once I log in /proc/cpuinfo says it's 2.6 or 3.6 GHz CPU. I don't have the laptop with me right now, but I'll send the boot messages tonight. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Initramfs and TMPFS!
Could you please please pretty please get an RFC compliant mailer that generates In-Reply-To and preferable even References headers? Right now every mail you write starts a new thread instead of referencing to the previous one. See http://lkml.org/lkml/2005/8/25/180/ to see what I mean. On Thu, Aug 25, 2005 at 11:34:01AM -0400, [EMAIL PROTECTED] wrote: On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote: I don't know, because tar is probably more widely used and consequently people are more familiar with how to use it. As I said before, the cpio format is cleaner/easier to parse in the kernel. Everyone has cpio probably so using tar isn't necessary. Cpio is perhaps as available as tar, but it's not as used as tar. So? Firefox is as available as IE, but it's not as used as IE. Does that make IE better? Unless tar would be inordinately larger than a cpio implementation (I can't imagine, but I'm not a coder!) I would prefer it. You have been told a couple of times that a tar implementation in kernel is indeed larger than a cpio implementation. If you're not a coder, just believe the coders. If initramfs replaces the old initrd method it should have something as a filesystem that's robust and inspires confidence like ext2. The simplicity of ramfs inspires more than enough confidence. I know generally an initrd is used to load modules and prepare the installation of a Linux system, so it doesn't require much in a filesystem. An initramfs can be used to do the same, but doesn't have the overhead of a block device. IOW: it requires even *less* than an initrd. But, it can also be used to hold and run a complete Linux system, so a more robust filesystem (tmpfs) is useful. What makes you think tmpfs is more robust than ramfs? What do you mean with a robust filesystem? Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: Initramfs and TMPFS!
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote: What if you have a root.cpio.gz that requires 200MB to hold, but you only have 300MB of memory? 50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_size=90%). tmpfs will not help you here. Yes, it can be swapped, but just like with ramfs you first need to *unpack* the cpio archive before you can even start the swapon /dev/hda2 command on it. Same with initrd, btw. If the compressed initrd image, plus the uncompressed image, plus the kernel size are larger than the memory size, the system will not boot. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: IRQ problem with PCMCIA
On Tue, Aug 23, 2005 at 11:31:58AM +0100, Alan Cox wrote: > On Maw, 2005-08-23 at 09:49 +0200, Erik Mouw wrote: > > Is there any place where we can get your current patches? > > Which ones - the PATA IDE ones are in 2.6.11-ac, a subset in Fedora > (other changes in the core IDE code make forward porting stuff for > hotplug really tricky past 2.6.11). I know about those and have been using them on my laptop. > The SATA ones I can certainly put up if there is interest. I don't want > to put them somewhere too available yet because this right now is stuff > you only want to use under controlled circumstances for development > until both they and the core SATA layer have some improvements. That's the one I'm interested in. Yes, I do understand it can erase all my partitions, etc. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: debug a high load average
On Tue, Aug 23, 2005 at 04:38:36PM +0530, Rajesh wrote: > I have a case occasionally when I copy data from a usb storage (ipod) to > my hard drive the load average goes up from 0.4 to about 15.0, and the > system becomes very unusable till I kill the cp command. I have checked > the CPU usage, bytes read from usb device, byte written to hard drive > etc, and all these values are low like CPU usage is at a maximum of 30%, > disk read bytes is at an average of 1.5 MiB/s, disk write bytes is at > 1.5 MiB/s, number of processes is at 110, etc, during this high load. 1.5 MB/s suggests you're using an IDE drive in PIO mode. Switch to DMA mode (hdparm -d 1 /dev/hda) and see if it gets any better. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: what does scsi sense means?
On Tue, Aug 23, 2005 at 05:07:12PM +0800, jeff shia wrote: > in the file of aic7.c ,what is the function of the structure of > scsi_sense?here what is the meaning of sense?just like probe? Return "value" of a failed command. Normally commands just succeed, but if it fails, you can get "sense information" which tells you more about why a particular command failed. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: IRQ problem with PCMCIA
On Mon, Aug 22, 2005 at 12:30:15PM +0100, Alan Cox wrote: > Actually I'm rather busy porting the old ATA drivers over to the new > SATA layer right now. HPT and VIA will be nasty to do but the simpler > drivers are moving over quite nicely. Is there any place where we can get your current patches? Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: IRQ problem with PCMCIA
On Mon, Aug 22, 2005 at 12:30:15PM +0100, Alan Cox wrote: Actually I'm rather busy porting the old ATA drivers over to the new SATA layer right now. HPT and VIA will be nasty to do but the simpler drivers are moving over quite nicely. Is there any place where we can get your current patches? Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: debug a high load average
On Tue, Aug 23, 2005 at 04:38:36PM +0530, Rajesh wrote: I have a case occasionally when I copy data from a usb storage (ipod) to my hard drive the load average goes up from 0.4 to about 15.0, and the system becomes very unusable till I kill the cp command. I have checked the CPU usage, bytes read from usb device, byte written to hard drive etc, and all these values are low like CPU usage is at a maximum of 30%, disk read bytes is at an average of 1.5 MiB/s, disk write bytes is at 1.5 MiB/s, number of processes is at 110, etc, during this high load. 1.5 MB/s suggests you're using an IDE drive in PIO mode. Switch to DMA mode (hdparm -d 1 /dev/hda) and see if it gets any better. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: IRQ problem with PCMCIA
On Tue, Aug 23, 2005 at 11:31:58AM +0100, Alan Cox wrote: On Maw, 2005-08-23 at 09:49 +0200, Erik Mouw wrote: Is there any place where we can get your current patches? Which ones - the PATA IDE ones are in 2.6.11-ac, a subset in Fedora (other changes in the core IDE code make forward porting stuff for hotplug really tricky past 2.6.11). I know about those and have been using them on my laptop. The SATA ones I can certainly put up if there is interest. I don't want to put them somewhere too available yet because this right now is stuff you only want to use under controlled circumstances for development until both they and the core SATA layer have some improvements. That's the one I'm interested in. Yes, I do understand it can erase all my partitions, etc. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: what does scsi sense means?
On Tue, Aug 23, 2005 at 05:07:12PM +0800, jeff shia wrote: in the file of aic7.c ,what is the function of the structure of scsi_sense?here what is the meaning of sense?just like probe? Return value of a failed command. Normally commands just succeed, but if it fails, you can get sense information which tells you more about why a particular command failed. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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
On Fri, Aug 12, 2005 at 05:28:12PM +0530, Srinivas K wrote: > post concepts regarding linux kernel which will be useful It would also be useful if you didn't send messages with silly disclaimers to publicly archived mailing lists. According to your own disclaimer, you are not allowed to post to this list at all. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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
On Fri, Aug 12, 2005 at 05:28:12PM +0530, Srinivas K wrote: post concepts regarding linux kernel which will be useful It would also be useful if you didn't send messages with silly disclaimers to publicly archived mailing lists. According to your own disclaimer, you are not allowed to post to this list at all. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: VGER news
On Tue, Aug 09, 2005 at 04:33:47PM +0200, Jan Engelhardt wrote: > > >Folks at Dell have donated a new machine to be VGER, and > >folks at RedHat have installed it into co-location facility > >with 1000Mbps network connection into the machine. > > May 24 2004 on kernel.org: > ISC has upgraded our outbound connection to 1000 Mbit/s. Thanks! That's www and ftp.kernel.org, the archive server. > So you have 2000 Mbps now? No, this time vger.kernel.org (the mailing list server) got an 1000 Mbit/s connection. > >This update got considerable performance increase into the > >machine for our list loads. In terms of Bogomips around 7-8, > >but for actual loads nearly twice as much. > > Wow, that's a lot of bogomips. That's just a little faster than my 386 > (running 2.6.13-rc1): http://jengelh.hopto.org/GFX0/proc386.jpg Matti is talking about an increase, which implies a difference. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: VGER news
On Tue, Aug 09, 2005 at 04:33:47PM +0200, Jan Engelhardt wrote: Folks at Dell have donated a new machine to be VGER, and folks at RedHat have installed it into co-location facility with 1000Mbps network connection into the machine. May 24 2004 on kernel.org: ISC has upgraded our outbound connection to 1000 Mbit/s. Thanks! That's www and ftp.kernel.org, the archive server. So you have 2000 Mbps now? No, this time vger.kernel.org (the mailing list server) got an 1000 Mbit/s connection. This update got considerable performance increase into the machine for our list loads. In terms of Bogomips around 7-8, but for actual loads nearly twice as much. Wow, that's a lot of bogomips. That's just a little faster than my 386 (running 2.6.13-rc1): http://jengelh.hopto.org/GFX0/proc386.jpg Matti is talking about an increase, which implies a difference. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: core file not generated when kernel is crashed with Sysrq key
On Thu, Jul 28, 2005 at 04:52:42AM -0700, dipankar das wrote: > core file is not generated when kernel is crashed with > Sysrq key ? That's right. > What could be the reason for this ? Because it wasn't designed to do so. Core files are for crashing userland programs. There are projects for kernel crash dumps, search the archives. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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: core file not generated when kernel is crashed with Sysrq key
On Thu, Jul 28, 2005 at 04:52:42AM -0700, dipankar das wrote: core file is not generated when kernel is crashed with Sysrq key ? That's right. What could be the reason for this ? Because it wasn't designed to do so. Core files are for crashing userland programs. There are projects for kernel crash dumps, search the archives. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - 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/
