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: 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: 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
(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: 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: 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: 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: 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: 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: [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: 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: 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: 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: [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 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: 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: 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 t
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: 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: 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: 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: Problem with Asus P4C800-DX and P4 -Northwood-
On Mon, Jul 25, 2005 at 10:38:25PM +0200, Jesper Juhl wrote: > It's even more complex than that as far as I know, you also have the > issue of seek times - tracks near the middle of the platter will be > nearer the head more often (on average) then tracks at the edge. > > For people who like visuals, IBM has a nice little picture in their > AIX performance tuning guide : > http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/aixbman/prftungd/diskperf2.htm Quote from that document: "Data is more dense as it moves toward the center, resulting in less physical movement of the head. This results in faster overall throughput" This is not true. The whole idea of different recording zones with different sectors/track is to keep the overall data density (in bits/square mm) more or less constant. I'd say it's even the other way around from what IBM pictures: there are more sectors/track in outer zones, so that means there is simply more data in the outer zones. If you want less physical movement of the head, you should make sure the data is in the zone(s) with the largest number of sectors/track. 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: Problem with Asus P4C800-DX and P4 -Northwood-
On Mon, Jul 25, 2005 at 10:12:58PM +0200, Andreas Baer wrote: > Erik Mouw wrote: > >Easy: Drives don't have the same speed on all tracks. The platters are > >built-up from zones with different recording densities: zones near the > >center of the platters have a lower recording density and hence a lower > >datarate (less bits/second pass under the head). Zones at the outer > >diameter have a higher recording density and a higher datarate. > > So it has definitely nothing to do with filesystem? I also thought about > physical reasons because I don't think the hdparm depends on filesystems... That's right, hdparm doesn't care about filesystems. The speed difference is caused by the physical geometry of the drive. 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: Problem with Asus P4C800-DX and P4 -Northwood-
On Mon, Jul 25, 2005 at 09:51:49PM +0200, Andreas Baer wrote: > > Willy Tarreau wrote: > >On Mon, Jul 25, 2005 at 03:10:08PM +0200, Andreas Baer wrote: > >>Here I have > >> > >>/dev/hda: 26.91 MB/sec > >>/dev/hda1: 26.90 MB/sec(Windows FAT32) > >>/dev/hda7: 17.89 MB/sec(Linux EXT3) > >> > >>Could you give me a reason how this is possible? > > > > > >a reason for what ? the fact that the notebook performs faster than the > >desktop while slower on I/O ? > > No, a reason why the partition with Linux (ReiserFS or Ext3) is always > slower > than the Windows partition? Easy: Drives don't have the same speed on all tracks. The platters are built-up from zones with different recording densities: zones near the center of the platters have a lower recording density and hence a lower datarate (less bits/second pass under the head). Zones at the outer diameter have a higher recording density and a higher datarate. Erik -- +-- Erik Mouw -- www.harddisk-recovery.nl -- 0800 220 20 20 -- | 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: help! kernel errors?
On Mon, Jul 25, 2005 at 03:03:03PM +0400, Vladimir V. Saveliev wrote: > [EMAIL PROTECTED] wrote: > >Hello, > > > >I'm getting loads and loads of kernel errors in my syslog, but am unable to > >decipher them into anything meaningful. > You may want to take a look at linux/Documentation/oops-tracing.txt And we're only interested in the *first* Oops, not in any later one. The first Oops is most probably the cause of all other Oopses. 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 cached memory
On Fri, Jul 22, 2005 at 05:46:58PM +0800, Ashley wrote: >I've a server with 2 Operton 64bit CPU and 12G memory, and this server > is used to run applications which will comsume huge memory, > the problem is: when this aplications exits, the free memory of the server > is still very low(accroding to the output of "top"), and > from the output of command "free", I can see that many GB memory was cached > by kernel. Does anyone know how to free the kernel cached > memory? thanks in advance. Free memory is bad, it means the memory doesn't have a proper use. Cached memory will be freed automatically when the kernel needs memory for other (more important) things. 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: often ide errors on amd64 / A8N-SLI
On Thu, Jul 21, 2005 at 08:30:13PM +0100, Alan Cox wrote: > There was corruption on the cable between the controller and drive. That > usually indicates a cable or noise problem in the PC but could indicate > mistuning of the interface. Make sure the IDE cable is > > > [controller]< long section ->[slave]--short section-->[master] > > > as one common cause is having the cable the other way around. Another common cause is to have the master and slave swapped. The master should be at the end of the cable. 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 15 GB file on tmpfs
On Wed, Jul 20, 2005 at 01:35:07PM +, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > Erik Mouw <[EMAIL PROTECTED]> wrote: > >On Wed, Jul 20, 2005 at 02:16:36PM +0200, Bastiaan Naber wrote: > >AFAIK you can't use a 15 GB tmpfs on i386 because large memory support > >is basically a hack to support multiple 4GB memory spaces (some VM guru > >correct me if I'm wrong). > > I'm no VM guru but I have a 32 bit machine here with 8 GB of > memory and 8 GB of swap: > > # mount -t tmpfs -o size=$((12*1024*1024*1024)) tmpfs /mnt > # df > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda1 19228276 1200132 17051396 7% / > tmpfs 12582912 0 12582912 0% /mnt > > There you go, a 12 GB tmpfs. I haven't tried to create a 12 GB > file on it, though, since this is a production machine and it > needs the memory .. I stand corrected. > So yes that appears to work just fine. The question is if it's a good idea to use a 15GB tmpfs on a 32 bit i386 class machine. I guess a real 64 bit machine will be much faster in handling suchs amounts of data simply because you don't have to go through the hurdles needed to address such memory on i386. 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 15 GB file on tmpfs
On Wed, Jul 20, 2005 at 02:16:36PM +0200, Bastiaan Naber wrote: > I have a 15 GB file which I want to place in memory via tmpfs. I want to do > this because I need to have this data accessible with a very low seek time. That should be no problem on a 64 bit architecture. > I want to know if this is possible before spending 10,000 euros on a machine > that has 16 GB of memory. If you want to spend that amount of money on memory anyway, the extra cost for an AMD64 machine isn't that large. > The machine we plan to buy is a HP Proliant Xeon machine and I want to run a > 32 bit linux kernel on it (the xeon we want doesn't have the 64-bit stuff > yet) AFAIK you can't use a 15 GB tmpfs on i386 because large memory support is basically a hack to support multiple 4GB memory spaces (some VM guru correct me if I'm wrong). Just get an Athlon64 machine and run a 64 bit kernel on it. If compatibility is a problem, you can still run a 32 bit i386 userland on an x86_64 kernel. 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: Developing a filesystem
On Fri, Jul 08, 2005 at 12:14:56PM +0200, Guillermo López Alejos wrote: > Now I'm writing my own dummyfs (based on ramfs) to know how this > works, but I'm having problems compiling it; I need to include the > "linux/fs.h" header file to have access to some structures definitions > (such as struct file_system_type), but this is giving me some errors. > So I think that I have to integrate my code with the kernel sources to > make it compile. Have a look at http://lwn.net/Articles/21823/ "Compiling external modules". 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: [Hdaps-devel] RE: Head parking (was: IBM HDAPS things are looking up)
On Thu, Jul 07, 2005 at 11:45:38AM -0700, Martin Knoblauch wrote: > If IBM would provide a CD image (bootable ISO) containing FW for all > supported drives - that would be great. No need for the "other OS" any > more. I can imagine IBM doesn't do that because in that way you can't update the firmware of the CD/DVD drive. Bootable FreeDOS floppy images would be a nice idea, though. Erik (not a ThinkPad owner) -- +-- 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: enforcing DB immutability
On Wed, Apr 20, 2005 at 08:41:15AM -, [EMAIL PROTECTED] wrote: > [A discussion on the git list about how to provide a hardlinked file > that *cannot* me modified by an editor, but must be replaced by > a new copy.] Some time ago there was somebody working on copy-on-write links: once you modify a cow-linked file, the file contents are copied, the file is unlinked and you can safely work on the new file. It has some horrible semantics in that the inode number of the opened file changes, I don't know if applications are or should be aware of 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: SkyMinder (CLPS711x derivative) - decided to try 2.6.11.7
On Mon, Apr 18, 2005 at 12:30:52AM +0100, Luke Kenneth Casson Leighton wrote: > ... aaand it flopped. i'm not even getting data out of the > serial console - not a squeak. HELP! [...] > any help much appreciated. I'd suggest to try the linux-arm-kernel mailing list (requires subscription) and not mailing rmk personally with all your questions. See http://www.arm.linux.org.uk/ . 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: [Crosspost] GNU/Linux userland?
On Wed, Apr 13, 2005 at 09:40:31PM +0200, Oliver Korpilla wrote: > I wondered if there is a project or setup that does allow me to build a > GNU/Linux userland including kernel, build environment, basic tools with > a single script just as you can in NetBSD (build.sh) or FreeBSD (make > world). Try uclibc buildroot, see http://www.uclibc.org/toolchains.html . 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 crash problem and Madwifi
On Thu, Mar 24, 2005 at 08:35:49PM +0530, govind raj wrote: > kernel version:2.4.29 > board :net4521 > wireless card : Atheros-5212 > diriver madwifi-cvs-current.tar.bz2(v 1.30 2005/02/22) According to the FAQ at http://www.mattfoster.clara.co.uk/madwifi-1.htm#2 , Madwifi is based on a binary-only module. > I built the customized image from 2.4.29 and booted from this image [...] > Unable to handle kernel paging request at virtual address e49aac30 > printing eip: > c4878019 > *pde = > Oops: > CPU:0 > EIP:0010:[]Tainted: P Yes, tainted by a proprietary licensed module. Sorry, lkml is not able to help you with binary-only modules. Ask whoever supplied your driver for support. > EFLAGS: 00010246 > eax: 0804ab74 ebx: c3d76000 ecx: edx: > esi: c3d76000 edi: c3d76348 ebp: c3d76000 esp: c3c09ed0 > ds: 0018 es: 0018 ss: 0018 > Process ifconfig (pid: 116, stackpage=c3c09000) > Stack: 0804ab74 c3d7615c c3c54000 0804ab74 c3d76000 > 1043 > c01a5484 c3d76000 c3d76000 1002 c01a66c1 c3d76000 > c3c09f54 > c3c09f59 c3c2b144 ba10 c01dd219 c3d76000 1043 > > Call Trace:[] [] [] [] > [] > [] Next time run the oops through ksymoops. Undecoded oopses are almost useless. 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: forkbombing Linux distributions
On Wed, Mar 23, 2005 at 01:37:38PM +0100, Natanael Copa wrote: > On Wed, 2005-03-23 at 19:56 +0900, aq wrote: > > > /etc/limits does a better job at stopping forkbombs. > > but does not limit processes that are started from the boot scripts. So > if a buggy non-root service is exploited, an attacker would be able to > easily shut down the system. That's easy to fix: set limits from initrd or initramfs. 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: Random number generator in Linux kernel
On Mon, Mar 07, 2005 at 06:18:53PM -0500, Vineet Joglekar wrote: > I want a function where I will be supplying a seed to that function > as an input, and will get a random number back. If same seed is used, > same number should be generated again. Google for "Numerical recipes in C", it has a complete section about random numbers, including a couple of functions that do what you want. 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: CSMI questions
On Tue, Feb 22, 2005 at 03:14:50PM -0800, Greg KH wrote: > On Tue, Feb 22, 2005 at 11:16:56AM -0600, mikem wrote: > > I'd also like an (brief) explanation of why ioctls are so bad. I've seen > > the > > reasons of them never going away, etc. But from the beginning of time (UNIX) > > ioctls have been the preferred method of user space/kernel communication. > > That's because there was no other method. See the lkml archives for why > ioctls are considered bad, I don't want to dredge it up again. Here's a quote from the official syndicated kernelnewbies fortunes file (http://www.kernelnewbies.org/kernelnewbies-fortunes.tar.gz ): "Basically, ioctl's will _never_ be done right, because of the way people think about them. They are a back door. They are by design typeless and without rules. They are, in fact, the Microsoft of UNIX." - Linus Torvalds on linux-kernel For the full story, see http://lkml.org/lkml/2001/5/20/81 . 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: ReiserFS / 2.4.6 / Data Corruption
On Thu, Jul 19, 2001 at 12:02:59PM +1000, Steve Kieu wrote: > --- Erik Mouw <[EMAIL PROTECTED]> wrote: > On > > FUD. I've been using reiserfs on quite some systems > > Probably !. I said just from my computer, :-) > > Reiserfs uses system resources more than others. > Perfomance is ok (not as far more or less than JFS) > but after using for a while, some mysterious things > happen ; for example, the ini file of some program is > changed wihtout any reason. For example I run mc and > make it learn all keys, and pause when executing a > command ; After reboot, sometimes all these setting > are lost, some times not. It still happen with XFS > though but never see in ext2, ext3 (now I am using) That sounds more like hardware problems to me. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: kernel patch process
On Fri, Jul 06, 2001 at 11:28:35PM -0700, Satish Kumar wrote: > Can anyone let me know the steps for making/submitting > a linux kernel patch ? What is the difference between > an unofficial patch and an official patch ? See Documentation/SubmittingPatches in your kernel tree. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: [patch] Fix warnings in videobook
On Fri, Jul 06, 2001 at 06:26:14PM +0100, Alan Cox wrote: > > All of which can be fixed by changing <> into . Patch applies > > cleanly against 2.4.6, 2.4.7-pre3, and 2.4.6-ac1. Please apply, it even > > makes the tables visible :) > > That looks like tool problems. <> is valid SGML short format, are you > using XML docbook ? Not that I am aware of, I'm using the SGML packages in Debian Potato (2.2r3). > I'll apply them anyway - they do no harm and short form SGML is evil in some > books ;) Thanks. Erik [not an SGML language lawyer ;) ] -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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/
[patch] Fix warnings in videobook
Hi,
This patch fixes the Jade SGML warnings when compiling the videobook:
jade:videobook.sgml:182:34:E: character data is not allowed here
jade:videobook.sgml:182:47:E: end tag for "ROW" which is not finished
jade:videobook.sgml:182:50:E: document type does not allow element "TBODY" here;
assuming missing "TGROUP" start-tag
jade:videobook.sgml:182:50:E: required attribute "COLS" not specified
jade:videobook.sgml:184:8:E: character data is not allowed here
jade:videobook.sgml:186:42:E: end tag for element "ENTRY" which is not open
jade:videobook.sgml:187:6:E: end tag for element "ROW" which is not open
All of which can be fixed by changing <> into . Patch applies
cleanly against 2.4.6, 2.4.7-pre3, and 2.4.6-ac1. Please apply, it even
makes the tables visible :)
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~erik/
Index: Documentation/DocBook/videobook.tmpl
===
RCS file: /home/erik/cvsroot/elinux/Documentation/DocBook/videobook.tmpl,v
retrieving revision 1.1.1.8
retrieving revision 1.1.1.8.28.1
diff -u -r1.1.1.8 -r1.1.1.8.28.1
--- Documentation/DocBook/videobook.tmpl2001/02/20 16:52:53 1.1.1.8
+++ Documentation/DocBook/videobook.tmpl2001/07/06 17:20:09 1.1.1.8.28.1
@@ -179,23 +179,23 @@
-VFL_TYPE_RADIO<>/dev/radio{n}<>
+VFL_TYPE_RADIO/dev/radio{n}
Radio devices are assigned in this block. As with all of these
selections the actual number assignment is done by the video layer
accordijng to what is free.
-VFL_TYPE_GRABBER<>/dev/video{n}<>
+VFL_TYPE_GRABBER/dev/video{n}
Video capture devices and also -- counter-intuitively for the name --
hardware video playback devices such as MPEG2 cards.
-VFL_TYPE_VBI<>/dev/vbi{n}<>
+VFL_TYPE_VBI/dev/vbi{n}
The VBI devices capture the hidden lines on a television picture
that carry further information like closed caption data, teletext
(primarily in Europe) and now Intercast and the ATVEC internet
television encodings.
-VFL_TYPE_VTX<>/dev/vtx[n}<>
+VFL_TYPE_VTX/dev/vtx[n}
VTX is 'Videotext' also known as 'Teletext'. This is a system for
sending numbered, 40x25, mostly textual page images over the hidden
lines. Unlike the /dev/vbi interfaces, this is for 'smart' decoder
@@ -302,25 +302,25 @@
-name<>The device text name. This is intended for the user.
+nameThe device text name. This is intended for the user.
-channels<>The number of different channels you can tune on
+channelsThe number of different channels you can tune on
this card. It could even by zero for a card that has
no tuning capability. For our simple FM radio it is 1.
An AM/FM radio would report 2.
-audios<>The number of audio inputs on this device. For our
+audiosThe number of audio inputs on this device. For our
radio there is only one audio input.
-minwidth,minheight<>The smallest size the card is capable of
capturing
+minwidth,minheightThe smallest size the card is capable of
+capturing
images in. We set these to zero. Radios do not
capture pictures
-maxwidth,maxheight<>The largest image size the card is capable of
+maxwidth,maxheightThe largest image size the card is capable
+of
capturing. For our radio we report 0.
-type<>This reports the capabilities of the device, and
+typeThis reports the capabilities of the device, and
matches the field we filled in in the struct
video_device when registering.
@@ -415,7 +415,7 @@
VIDEO_TUNER_SECAMA SECAM (French) TV tuner
-VIDEO_TUNER_LOW<>
+VIDEO_TUNER_LOW
The tuner frequency is scaled in 1/16th of a KHz
steps. If not it is in 1/16th of a MHz steps
@@ -432,13 +432,13 @@
-VIDEO_MODE_PAL<>PAL Format
+VIDEO_MODE_PALPAL Format
-VIDEO_MODE_NTSC<>NTSC Format (USA)
+VIDEO_MO
Re: access to sysinfo structure
On Fri, Jul 06, 2001 at 05:18:43PM +0530, Naveen Kumar Pagidimarri wrote: >Is it possible to access sysinfo structure(which is in > > kernel.h) .This is related to system detailes(like Ram and other info) > > Actually this is updarted in init.c.Is it possible to access this > > information from userspace. cat /proc/loadavg cat /proc/meminfo cat /proc/uptime Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: Unresolved symbols since 2.4.5 ?
On Thu, Jul 05, 2001 at 02:48:52PM +0200, Cyril ADRIAN wrote: > >>>>> "Erik" == Erik Mouw <[EMAIL PROTECTED]> writes: > > Erik> Looks like your system has an old version of modutils. You need Adrian > Erik> Bunk's linux-2.4 packages for running linux-2.4.* with Debian potato. > Erik> Add the following two lines to /etc/apt/sources.list: > > Erik> deb http://people.debian.org/~bunk/debian potato main > Erik> deb-src http://people.debian.org/~bunk/debian potato main > > I have just the first line of those. dpkg --list | grep modutils shows: > > ii modutils 2.4.6-2.bunk Linux module utilities. > > Is it OK? Yes, that's the same as I have in my system. The only difference is that I don't use kbuild but build the kernels by hand (done that since linux-1.0.8, hard habit to break :). Or maybe you still have some cruft left in /etc/modutils/paths. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: Unresolved symbols since 2.4.5 ?
On Thu, Jul 05, 2001 at 02:32:21PM +0200, Cyril ADRIAN wrote:
> In short, since 2.4.5 I seem not to be able to install a kernel (depmod
> says "unresolved symbols"). 2.4.6 shows the same problem but as far as I
> remember 2.4.4 did not. The sources I use are downloaded straight from
> www.kernel.org and I always use the same .config file.
>
> Relevant data about my machine: PC Pentium III, 320 Mo, UDMA disks, and
> the OS is Debian GNU/Linux 2.2r3 ("Potato"). Currently I run a 2.4.1 kernel.
Looks like your system has an old version of modutils. You need Adrian
Bunk's linux-2.4 packages for running linux-2.4.* with Debian potato.
Add the following two lines to /etc/apt/sources.list:
deb http://people.debian.org/~bunk/debian potato main
deb-src http://people.debian.org/~bunk/debian potato main
Now run 'apt-get update ; apt-get dist-upgrade' and rebuild the kernel.
Erik
[happily running linux-2.4.6-pre8 on potato]
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~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/
[OT] Re: source for ps command
On Thu, Jul 05, 2001 at 05:20:38PM +0530, Naveen Kumar Pagidimarri wrote: > Please tell me where can i get the source of ps command or > > related source code for the implementation of ps command. If you don't get an answer it might be that: - your question is off topic for this list - the answer is too trivial to tell - nobody had time to answer it In any case don't post the same question within 30 minutes. Getting the source of a package is simple. On an RPM compatible system (Red Hat, SuSE, Mandrake): erik@merijn:~ >rpm -qf `which ps` procps-2.0.6-5 (get the procps-2.0.6 SRPM from CD or download it from the web) On a Debian system it's even easier: erik@arthur:~ >dpkg -S `which ps` procps: /bin/ps erik@arthur:~ >apt-get -qq source procps dpkg-source: extracting procps in procps-2.0.7 Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
On Thu, Jul 05, 2001 at 12:41:15AM +, Trevor Hemsley wrote: > OK, I've done quite a lot more work on this. It isn't 2.4.5, I'd > compiled USB support in when I went to 2.4.5 and it's that that causes > the problems. I backed out all changes made between 2.4.2 and 2.4.5 in > drivers/pcmcia and that made no difference to the lockup so then I > went back to the .config file from 2.4.2 and that worked. Hmm, Cardbus and USB problems... you probably have both Cardbus and i82365 support in your kernel configuration. Your .config file should have this: # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_I82365 is not set # CONFIG_TCIC is not set That fixed it for me for at least three laptops. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: Mail list archives down
On Wed, Jul 04, 2001 at 07:17:08PM +0200, David Balazic wrote: > I noticed 4 out of 5 LKML web archives listed in the FAQ > are down as of today. Here is another one that updates in real time but doesn't support thread mode: http://www.geocrawler.com/lists/3/Linux/35/0/ . Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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/
[OT] Re: shared memory problem
On Tue, Jul 03, 2001 at 02:49:24AM -0600, Blesson Paul wrote: > I have some confusion regarding key in shmget(). Let I > have two shared memory variables. For the first one, I put key "99" and the > size is 1024. Next, I put key "199" for the second variable and size 1024. > Will the two shared memory area overwrite each other. How can I gurranty. Is > the Linux kernelor the developer who should care about this problem No, the segments will not overwrite each other, see man shmget and get "Advanced programming in the UNIX environment" by Richard Stevens. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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/
[patch] fix TI 1410 lockups
Hi,
This patch fixes machine lockups with a TI 1410 cardbus bridge (as used
on Lucent PCI-PCMCIA adapter for Orinoco cards). The patch is against
linux-2.4.5-ac23.
Index: include/linux/pci_ids.h
===
RCS file: /home/erik/cvsroot/elinux/include/linux/pci_ids.h,v
retrieving revision 1.1.1.90
diff -u -r1.1.1.90 pci_ids.h
--- include/linux/pci_ids.h 2001/07/03 00:30:13 1.1.1.90
+++ include/linux/pci_ids.h 2001/07/03 06:48:16
@@ -524,6 +524,7 @@
#define PCI_DEVICE_ID_TI_1251B 0xac1f
#define PCI_DEVICE_ID_TI_4410 0xac41
#define PCI_DEVICE_ID_TI_4451 0xac42
+#define PCI_DEVICE_ID_TI_1410 0xac50
#define PCI_DEVICE_ID_TI_1420 0xac51
#define PCI_VENDOR_ID_SONY 0x104d
Index: drivers/pcmcia/yenta.c
===
RCS file: /home/erik/cvsroot/elinux/drivers/pcmcia/yenta.c,v
retrieving revision 1.1.1.61
diff -u -r1.1.1.61 yenta.c
--- drivers/pcmcia/yenta.c 2001/07/03 00:27:54 1.1.1.61
+++ drivers/pcmcia/yenta.c 2001/07/03 06:48:51
@@ -793,6 +793,7 @@
{ PD(TI,1251A), &ti_ops },
{ PD(TI,1211), &ti_ops },
{ PD(TI,1251B), &ti_ops },
+ { PD(TI,1410), &ti_ops },
{ PD(TI,1420), &ti_ops },
{ PD(TI,4410), &ti_ops },
{ PD(TI,4451), &ti_ops },
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~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: [Re: gcc: internal compiler error: program cc1 got fatal signal 11]
On Thu, Jun 28, 2001 at 11:23:37PM -0600, Blesson Paul wrote: > > "This is almost always the result of flakiness in your hardware - either > RAM (most likely), or motherboard (less likely). " > > I cannot understand this. There are many other > stuffs that I compiled with gcc without any problem. Again compilation is only > a application. It only parse and gernerates object files. How can RAM or > motherboard makes different Please read the complete Sig11 FAQ (http://www.bitwizard.nl/sig11/ ), your question is discussed in it as well. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: iwconfig seg-faults
On Thu, Jun 28, 2001 at 12:34:20PM +0100, Rodrigo Ventura wrote: > > SuSE 7.1, wireless-tools-20-5, kernel 2.4.5-pre3: > > /root# gdb iwconfig > [...] > (gdb) run wvlan0 > Starting program: /usr/bin/iwconfig wvlan0 > wvlan0IEEE 802.11-DS ESSID:"ISocRob" Nickname:"Gedeao" > Frequency:2.437GHz Sensitivity:1/3 Mode:Ad-Hoc > Access Point: 00:00:00:00:00:00 > Bit Rate:2Mb/s RTS thr:off Fragment thr:off > Encryption key:off > Power Management:off > Link quality:0 Signal level:0 Noise level:0 > Rx invalid nwid:0 invalid crypt:0 invalid misc:500 > > > Program received signal SIGSEGV, Segmentation fault. > 0xc22ab05c in ?? () > > Can't get any further useful info from gdb. > > Is this a known "issue"? Yes, recompile iwconfig against your current kernel solves the problem (you need to put a -I flag in the wireless-tools Makefile). Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: Microsoft and Xenix.
On Mon, Jun 25, 2001 at 10:17:09AM -0400, Rob Landley wrote: > On Monday 25 June 2001 11:13, you wrote: > > 1937 claude shannon A Symbolic Analysis of Relay and Switching Circuits," > > > > 1948 claude shannon A mathematical theory of information. > > > > without those you're kind in trouble on the computing front... [snip] > This was the dude who decided to apply a binary and boolean approach to > electronic computation, right? I KNOW I've read some stuff about him... late > last year? Yes, but the latter paper was the real milestone. This was the guy who actually defined what information *is*, and found out the upper limits of communication rates on a given channel. This was the guy who laid the fundaments of the information theory. Without information theory no compression, reliable transmission, reliable storage, crypthography, etc. Erik [who works in an information theory group] -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: MemShared == 0 ?
On Mon, Jun 25, 2001 at 11:21:55AM +0100, Rodrigo Ventura wrote: > /proc> cat version meminfo > Linux version 2.4.6-pre3 (yoda@damasio) (gcc version 2.95.2 19991024 (release)) #3 >Mon Jun 18 19:00:11 WEST 2001 > total:used:free: shared: buffers: cached: > Mem: 261779456 256925696 48537600 134025216 82280448 > Swap: 271425536 10993664 260431872 > MemTotal: 255644 kB \ > MemFree: 4740 kB \ > MemShared: 0 kB <<<<<<<<<< What's the meaning of this? * Check the lkml FAQ: http://www.tux.org/lkml/#s14-3 Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: GPIB support
On Mon, Jun 25, 2001 at 11:30:57AM +0800, hugang wrote: > What is GPIB. http://www.google.com/search?q=gpib Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: mktime in include/linux
On Thu, Jun 21, 2001 at 10:30:40PM -0400, Rick Hohensee wrote: > Why does Linux have a mktime routine fully coded in linux/time.h that > conflicts directly with the ANSI C standard library routine of the same > name? It breaks a couple things against libc5, including gcc 3.0. OK, you > don't care about libc5. It's still pretty weird. Wierd? Weird. This has been brought up many times on this list: you are not supposed to include kernel headers in userland. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: Controversy over dynamic linking -- how to end the panic
On Thu, Jun 21, 2001 at 02:03:32PM -0500, Timur Tabi wrote: > Besides, your opinion on this matter is irrelevant. Linus has already decided > to allow binary-only drivers. The question is not WHETHER it is allowed, but > HOW it will be allowed. Please stay on topic. In my opinion Linus was already too late when he decided to allow binary-only drivers. At that time there were already way too many principal authors that contributed to the kernel, and not all authors of all files might have agreed with his decision. But then again: IANAL and this is a legal issue, so Alan is right: consult a lawyer. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: gnu asm help...
On Mon, Jun 18, 2001 at 03:56:50PM -0700, Raj, Ashok wrote:
> i can understand what the LOCK "incl %0 means.. but not sure what the rest
> is for.
>
> thanks
> ashokr
>
> static __inline__ void atomic_inc(atomic_t *v)
> {
> __asm__ __volatile__(
> LOCK "incl %0"
> :"=m" (v->counter)
> :"m" (v->counter));
> }
I also don't know the exact meaning, but here are two nice tutorials
about inline assembly:
http://www-106.ibm.com/developerworks/linux/library/l-ia.html
http://www.uwsg.indiana.edu/hypermail/linux/kernel/9804.2/0953.html
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~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: [patch] nonblinking VGA block cursor
On Sat, Jun 16, 2001 at 01:44:40AM +0200, Daniel Phillips wrote: > IBM had lots of ideas about how computers should work. Remember the keyboard > keys that when CLACK CLACK CLACK. Thank god they turned out to be too > expensive to clone - nobody misses them now. I actually like that kind of keyboards, they're extremely reliable and are great to use. Anyway, my point is that keyboards are a matter of taste, just like blinking or non-blinking cursors are. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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/
procfs get_info() method obsolete?
Hi,
Can the procfs get_info() method be considered obsolete? When reading
this code fragment from fs/proc/generic.c I think yes:
if (dp->get_info) {
/*
* Handle backwards compatibility with the old net
* routines.
*/
n = dp->get_info(page, &start, *ppos, count);
However, I'd rather be sure before I start documenting lies in the
procfs-guide.
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED]
WWW: http://www-ict.its.tudelft.nl/~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: VM suggestion...
On Thu, Jun 07, 2001 at 04:36:05PM -0300, Marcelo Tosatti wrote: > On Thu, 7 Jun 2001, Jeff Garzik wrote: > > Statistics like this are cheap to use in runtime and should provide > > concrete information rather than guesses and estimations... > > I've been using LTT (Linux Trace Toolkit) to do similar stuff. But you can't expect everybody to use LTT. If you just make a couple of counters and give an easy way to get the values from userspace (proc, sysctl, syslog), you'll get bug reports with real information. IMHO data from real world workloads make more sense than "it doesn't work" reports. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: PID's
On Tue, Jun 05, 2001 at 12:50:55PM -0700, android wrote: > Is there a way to recycle unused PID's without rebooting the kernel? > So instead of the next available PID always getting larger and larger, > just reset it to use the first unused PID after 1. Is this possible? It already works like that. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: isolating process..
On Tue, Jun 05, 2001 at 12:37:55PM +0300, Bohdan Vlasyuk wrote: > Is it possible by any means to isolate any given process, so that > it'll be unable to crash system. Suppose all the process needs is > stdin, stdout, and CPU time. Can Linux guarantee that given process > won't hurt system stability ? Let us soppose that we have ideal CPU > without mistakes. How can I limit CPU time/Mem Usage for given > process? You just gave a nice description what an OS kernel should do :) > Please, supply ANY suggestions. > > My ideas: > > create some user, and decrease his ulimits up to miminum of 1 process, > 0 core size, appropriate memory/ etc. That's indeed the way to do it. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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/
[PATCH] procfs guide
Hi, I got some comments on my procfs guide when I posted it a couple of days ago, so here is a new version. What's new: - add revision history (Jonathan Lundel) - remove_proc_entry() is not recursive (Jonathan Lundel) - numerous spelling corrections (Marc Joosen) - /proc/sys files are sysctl, not procfs(John Levon) - add an implicit .c to .sgml rule to the Makefile (me) - fixed a too long comment in the example code (me) The patch is against 2.4.5-ac6, but should apply cleanly to 2.4.5-ac7 as well. Please apply. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ Index: Documentation/DocBook/Makefile === RCS file: /home/erik/cvsroot/elinux/Documentation/DocBook/Makefile,v retrieving revision 1.1.1.30 diff -u -r1.1.1.30 Makefile --- Documentation/DocBook/Makefile 2001/05/15 12:14:07 1.1.1.30 +++ Documentation/DocBook/Makefile 2001/06/03 21:09:27 @@ -1,7 +1,7 @@ BOOKS := wanbook.sgml z8530book.sgml mcabook.sgml videobook.sgml \ kernel-api.sgml parportbook.sgml kernel-hacking.sgml \ kernel-locking.sgml via-audio.sgml mousedrivers.sgml sis900.sgml \ - deviceiobook.sgml + deviceiobook.sgml procfs-guide.sgml PS := $(patsubst %.sgml, %.ps, $(BOOKS)) PDF:= $(patsubst %.sgml, %.pdf, $(BOOKS)) @@ -9,6 +9,7 @@ IMG-parportbook := parport-share.fig parport-multi.fig parport-structure.fig EPS-parportbook := $(patsubst %.fig, %.eps, $(IMG-parportbook)) JPG-parportbook := $(patsubst %.fig, %.jpeg, $(IMG-parportbook)) +C-procfs-example = procfs_example.sgml books: $(BOOKS) @@ -28,6 +29,15 @@ %.jpeg: %.fig -fig2dev -Ljpeg $< $@ +%.sgml: %.c + echo "" > $@ + expand --tabs=8 < $< | \ + sed -e "s/&/\\&/g" \ + -e "s//\\>/g" >> $@ + echo "" >> $@ + + $(TOPDIR)/scripts/docproc: $(MAKE) -C $(TOPDIR)/scripts docproc @@ -67,6 +77,9 @@ $(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/media/video/videodev.c \ videobook.sgml +procfs-guide.sgml: procfs-guide.tmpl procfs_example.sgml + $(TOPDIR)/scripts/docgen < procfs-guide.tmpl >$@ + APISOURCES := $(TOPDIR)/drivers/media/video/videodev.c \ $(TOPDIR)/arch/i386/kernel/irq.c \ $(TOPDIR)/arch/i386/kernel/mca.c \ @@ -128,6 +141,7 @@ -$(RM) $(BOOKS) -$(RM) $(DVI) $(AUX) $(TEX) $(LOG) $(OUT) -$(RM) $(JPG-parportbook) $(EPS-parportbook) + -$(RM) $(C-procfs-example) mrproper: clean -$(RM) $(PS) $(PDF) Index: Documentation/DocBook/procfs-guide.tmpl === RCS file: procfs-guide.tmpl diff -N procfs-guide.tmpl --- /dev/null Thu Mar 22 14:04:47 2001 +++ Documentation/DocBook/procfs-guide.tmpl Sun Jun 3 23:39:23 2001 @@ -0,0 +1,625 @@ + + +]> + + + +Linux Kernel Procfs Guide + + + + Erik + (J.A.K.) + Mouw + + Delft University of Technology + Faculty of Information Technology and Systems + +[EMAIL PROTECTED] +PO BOX 5031 +2600 GA +Delft +The Netherlands + + + + + + + + 1.0 + May 30, 2001 + Initial revision posted to linux-kernel + + + 1.1 + June 3, 2001 + Revised after comments from linux-kernel + + + + + 2001 + Erik Mouw + + + + + +This documentation is free software; you can redistribute it +and/or modify it under the terms of the GNU General Public +License as published by the Free Software Foundation; either +version 2 of the License, or (at your option) any later +version. + + + +This documentation is distributed in the hope that it will be +useful, but WITHOUT ANY WARRANTY; without even the implied +warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR +PURPOSE. See the GNU General Public License for more details. + + + +You should have received a copy of the GNU General Public +License along with this program; if not, write to the Free +Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, +MA 02111-1307 USA + + + +For more details see the file COPYING in the source +distribution of Linux. + + +
Re: Compile problem with ov511.c (Kernel 2.4.5)
On Sun, Jun 03, 2001 at 12:18:40AM -0700, Ben Greear wrote: > gcc -D__KERNEL__ -I/home/greear/kernel/2.4/linux/include -Wall -Wstrict-prototypes >-O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 >-march=i686 > -DMODULE -DMODVERSIONS -include >/home/greear/kernel/2.4/linux/include/linux/modversions.h -c -o ov511.o ov511.c > ov511.c: In function `ov511_read_proc': > ov511.c:340: `version' undeclared (first use in this function) > ov511.c:340: (Each undeclared identifier is reported only once > ov511.c:340: for each function it appears in.) > make[2]: *** [ov511.o] Error 1 > make[2]: Leaving directory `/home/greear/kernel/2.4/linux/drivers/usb' > make[1]: *** [_modsubdir_usb] Error 2 > make[1]: Leaving directory `/home/greear/kernel/2.4/linux/drivers' > make: *** [_mod_drivers] Error 2 Try this patch: http://boudicca.tux.org/hypermail/linux-kernel/2001week21/1010.html Or use 2.4.5-ac*. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: HowTo: Kernel verbose logging.
On Fri, Jun 01, 2001 at 04:51:27PM +0200, Ola Theander wrote: > Therefore I would like to know if it's possible to compile the used kernel > (2.2.18) in some kind of verbose logging mode? Ultimately every kernel call > should be logged, with parameters and everything. I realize that this > probably isn't feasible but perhaps there is something that takes me > halfway? You probably want strace, see man strace. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: Oops with 2.4.5-ac3
On Thu, May 31, 2001 at 09:45:56AM +0200, Jose Carlos Garcia Sogo wrote: >I've just got an oops with the 2.4.5-ac3 kernel. I have attached the log > to this mail. I have also having more random dead locks, but I haven't > catch any log of them. If I manage to get some logs, I'll send here also. > >Anyway, 2.4.5-ac3 is much more stable in my computer than vanilla 2.4.5, > which was almost unusable. With 2.4.4, I had some problems also. > >I'm using NVIDIA's module for a TNT2 M64 card. Try to reproduce the errors without the nvidia module. If you still get oopses, report them over here. If not, complain to nvidia. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: [PATCH] Procfs Guide
On Wed, May 30, 2001 at 03:10:32PM -0600, [EMAIL PROTECTED] wrote: > So where can find the whole docbook ? I could not find under > linux/Documentation directory. That's correct, I only submitted it for inclusion into the kernel, so it's not yet there. Just patch your kernel source with my patch, run "make psdocs" and you'll have it in your kernel tree as well. However, because we got a similar procfs question on the kernelnewbies list, I already put the html and pdf versions online on the kernelnewbies documentation pages: http://www.kernelnewbies.org/documents/kdoc/procfs-guide/lkprocfsguide.html Erik PS: Was it really necessary to quote my complete message *including* the patch? Next time quote properly before you post. -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: [PATCH] Procfs Guide
On Wed, May 30, 2001 at 09:30:48AM +0100, Tim Waugh wrote: > On Wed, May 30, 2001 at 01:29:17AM +0200, Erik Mouw wrote: > > I'm still looking for a proper way to automatically include the example > > source into the SGML file, this patch with the same content in two > > files is a bit of an ugly hack. > > Probably your best bet is to get the Makefile to pass a copy of the > real example source through sed to &entity;ify the bits that would > confuse SGML (<, >, etc), and into example.c.sed, make that into an > entity, and include it. > > See http://people.redhat.com/twaugh/docbook/selfdocbook/> for > instance, which does this with its own SGML source. Thanks, that was a really helpful example. So how about this version? Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ Index: Documentation/DocBook/Makefile === RCS file: /home/erik/cvsroot/elinux/Documentation/DocBook/Makefile,v retrieving revision 1.1.1.30 retrieving revision 1.1.1.25.2.2 diff -u -r1.1.1.30 -r1.1.1.25.2.2 --- Documentation/DocBook/Makefile 2001/05/15 12:14:07 1.1.1.30 +++ Documentation/DocBook/Makefile 2001/05/30 20:31:18 1.1.1.25.2.2 @@ -1,7 +1,7 @@ BOOKS := wanbook.sgml z8530book.sgml mcabook.sgml videobook.sgml \ kernel-api.sgml parportbook.sgml kernel-hacking.sgml \ kernel-locking.sgml via-audio.sgml mousedrivers.sgml sis900.sgml \ - deviceiobook.sgml + deviceiobook.sgml procfs-guide.sgml PS := $(patsubst %.sgml, %.ps, $(BOOKS)) PDF:= $(patsubst %.sgml, %.pdf, $(BOOKS)) @@ -9,6 +9,7 @@ IMG-parportbook := parport-share.fig parport-multi.fig parport-structure.fig EPS-parportbook := $(patsubst %.fig, %.eps, $(IMG-parportbook)) JPG-parportbook := $(patsubst %.fig, %.jpeg, $(IMG-parportbook)) +C-procfs-example = procfs_example.sgml books: $(BOOKS) @@ -67,6 +68,17 @@ $(TOPDIR)/scripts/docgen $(TOPDIR)/drivers/media/video/videodev.c \ videobook.sgml +procfs_example.sgml: procfs_example.c + echo "" > $@ + expand --tabs=8 < $< | \ + sed -e "s/&/\\&/g" \ + -e "s//\\>/g" >> $@ + echo "" >> $@ + +procfs-guide.sgml: procfs-guide.tmpl procfs_example.sgml + $(TOPDIR)/scripts/docgen < procfs-guide.tmpl >$@ + APISOURCES := $(TOPDIR)/drivers/media/video/videodev.c \ $(TOPDIR)/arch/i386/kernel/irq.c \ $(TOPDIR)/arch/i386/kernel/mca.c \ @@ -128,6 +140,7 @@ -$(RM) $(BOOKS) -$(RM) $(DVI) $(AUX) $(TEX) $(LOG) $(OUT) -$(RM) $(JPG-parportbook) $(EPS-parportbook) + -$(RM) $(C-procfs-example) mrproper: clean -$(RM) $(PS) $(PDF) Index: Documentation/DocBook/procfs-guide.tmpl === RCS file: procfs-guide.tmpl diff -N procfs-guide.tmpl --- /dev/null Thu Mar 22 14:04:47 2001 +++ Documentation/DocBook/procfs-guide.tmpl Wed May 30 22:32:02 2001 @@ -0,0 +1,603 @@ + + +]> + + + +Linux Kernel Procfs Guide + + + + + Erik + (J.A.K.) + Mouw + + Delft University of Technology + Faculty of Information Technology and Systems + +[EMAIL PROTECTED] +PO BOX 5031 +2600 GA +Delft +The Netherlands + + + + + + + + 2001 + Erik Mouw + + + + + +This documentation is free software; you can redistribute it +and/or modify it under the terms of the GNU General Public +License as published by the Free Software Foundation; either +version 2 of the License, or (at your option) any later +version. + + + +This documentation is distributed in the hope that it will be +useful, but WITHOUT ANY WARRANTY; without even the implied +warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR +PURPOSE. See the GNU General Public License for more details. + + + +You should have received a copy of the GNU General Public +License along with this program; if not, write to the Free +Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, +MA 02111-1307 USA + + + +For more details see the file COPYING in the source +distribution of Linux. + + + + + + + + + + + + + + +Preface + + + This guide describes the use of the
Re: unresolved symbols printk ?
On Mon, May 28, 2001 at 07:00:39PM +0200, Nico Schottelius wrote: > I am having problems with loading modules: > I always get the unresolved symbols message. > I didn't find any documentation for that, can you help me ? You did read question 8.8 from the linux-kernel mailing list FAQ? http://www.tux.org/lkml/#s8-8 Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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: Problem compiling kernel 2.4.5 with gcc 2.96
On Sun, May 27, 2001 at 01:53:03PM +0200, Peter Klotz wrote: > When creating the modules (make modules) for my 2.4.5 kernel the compilation > aborts with the following error messages. The problem seems to be related > with Video for Linux and the Iomega Buz Driver. buz.c is broken, you need 2.4.5-ac1 for it. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~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/
